Enterprise Firefox Adoption Part 2: Where are my Bookmarks?

All these Bookmark syncing engines out there are great. Unfortunately, many large enterprises are simply at a point where policy restricts or greatly limits an employee's ability to expose information outside of their Firm. Bookmarks are no exception to the rule. Talk to a friend who works in Finance, you'll hear interesting stories directly from the battle field.

I don't have a solution for the above - this will take more scaffolding work. I do, however, want to raise the issue of synchronizing bookmarks between different browsers on a single Desktop -- for starters.

Some more realities of Firefox Adoption in the Enterprise:

• Not every business critical application will work with Firefox on Day 1 if all you have deployed Firm-wide is the Not Firefox Browser.
  
• Users will continue to use the Not Firefox Browser. Assume this is forever.
  
• Mose users will have years of bookmarks stored in the Not Firefox Browser and this list will grow.
  

As you can see, simply "Importing" Not Firefox Browser's bookmarks into Firefox just doesn't solve the problem. When multiple browsers live side-by-side in an Enterprise, users will want bookmarks to always be in sync between All browsers on All Desktops that they may ever use.

This is a two-step project:

• Step 1: how do I make Not Firefox and Firefox share bookmarks on a single Desktop?
  
• Step 2: how do I roam these as I move around from Desktop to Desktop?

Challenges
Theoretically, it is not very difficult to write a Desktop application that will listen for changes to your Not Firefox and Firefox bookmarks, resolve the differences, update each repository, etc.

But did you know that with Firefox 2, there is no easy way to reload bookmarks from disk while Firefox is active? The Bookmark Service just doesn't expose that functionality. Furthermore, when you shut Firefox down, it will out-dump bookmarks stored in memory back into the bookmarks.html file, effectively trumping any changes you've made to the file with your Syncing Engine.

Of course, there are workarounds and it is possible to hack your way around everything BUT who has the time or the will to do that??

What would an Architect say?
Managing two or more discrete, proprietary repositories for Bookmarks on the Desktop is a huge pain for the End-User, the Support servicing these Users, and for IT trying to enable this synchronization.

Any architect would already be thinking: "Centralize & Federate - store in one spot, leverage the one spot, make things easy".

Plain Old Favorites indeed!
At what point does it make sense to replace Firefox's Bookmarking engine with something else? I don't want to replace the whole interface per se, just don't want bookmarks stored in bookmarks.html anymore.

In fact, I want to leverage the Favorites folder for storage on my Windows Desktop.

Perhaps the File System implementation for bookmarks is not as flexible as what Firefox 3 promises to deliver via SQL Lite for Places. Still, the Favorites solution exists today and it is the greatest common denominator for a bookmark datasource. That is, by design, every browser can understand the File System with ease. Not to mention, it is a lot easier to get Firefox to read files for bookmarks than it is for IE to learn to read bookmarks.html - for example.

This is why I think that Alex Sirota's PlainOldFavorites extension is brilliant as a vehicle for Firefox Adoption.

Immediately, I spot some some tiny performance issues and a feature gap between what Firefox's bookmarks engine offers and how much of it is implemented under the auspices of "Favorites". Still, this is much simpler than having to engineer synchronization for two distinct data sources.

This also makes Step 2 much more light-weight and simpler to implement.

Part 3 of this post will focus on my research on PlainOldFavorites as an Adoption vehicle. I hope Alex Sirota will help me out...