Month: March 2007

A few months ago, I posted about a concept called Site Specific Browsers (SSB). I didn’t invent the name or the concept, but I thought it was a great idea. An SSB is an application with an embedded browser designed to work exclusively with a single web application. It’s doesn’t have the menus, toolbars and accoutrement’s of a normal web browser. Some people have called it a “distraction free browser” because none of the typical browser chrome is used.

The recent talk/hype over desktop/web integration has rekindled my interest in creating a project to test SSB ideas. As is usually the case, I would not be the first:

• GMail in a WebKit application: Nice application in separate process.
• GMail in a XULRunner application: Basic framework running in separate process.
• GMail in a XULRunner application: Small application with some menus and toolbars in a separate process.
• GMail and GCal using bookmarks in Camino/Firefox: Simple way to open a new window without chrome. Not in a separate process.
• GCal in a WebKit application: Application in separate process.

Yeah, Google webapps are a popular choice for an SSB.

Looking at what has already been done and discussions about desktop/webapp integration, I am suggesting the following roadmap for SSB experimentation:

• Separate process: When the webapp goes down or locks up, I don’t want anything else affected. Thankfully, Firefox does have session restore, but that is beside the point. When I open many tabs and have several webapps running in a browser, things get slow and unstable after a day or two.
• Minimal UI: A generic browser UI is not needed for webapps. If any UI is present, make it specific to the webapp I am using.
• Basic desktop integration: Create shortcuts to start the webapp, add ability to show specialized icons in the tray or dock and ability to display notifications.
• Platform with extensions: I don’t want to download a full browser runtime for each webapp. I do want to be able to add some custom code/features that are not directly supported in the webapp. I should be able to install one runtime and then get packages or extensions for each webapp. Think Firefox extensions or Greasemonkey scripts. These extensions should be able to tweak the SSB UI as well.
• Open external links in real browser: If I click a link in the webapp that opens a new site, don’t change my webapp browser window. Open all external links in my default/real browser.

XULRunner’s stable base, feature set and cross platform nature make it a good foundation to build an SSB. In fact, I’d just start with the the WebRunner prototype created by Benjamin Smedberg. Then, I’d turn on the Extension Manager support in XULRunner. Then, I’d create some extensions to “install” or “enhance” webapps. Then, I’d add some patches to add better desktop integration (I’m hoping the patches land for Gecko 1.9). Then, … well you tell me! How about offline mode? What else?

Here is a simple example of a WebRunner-based SSB. It only begins to cover the points on the roadmap, but it is a start. The application is designed to take a -uri parameter on the commandline. The installer will setup desktop shortcuts to launch webrunner.exe with specific URIs for Google web apps. The UI is minimal, just a simple statusbar to show load progress.

Install (Windows-only): webrunner-setup-0.2.exe
Source: webrunner-src-0.2.zip

Rich Internet Applications (RIA)! It’s still a hot topic. Last time, the hype was for Microsoft’s WPF/E platform. This time it’s Adobe’s Apollo platform. Due to be released sometime before mid 2007, Apollo is a neat platform built on Flash, Flex and Webkit. Adobe recently had an invite-only event, Engage, to show off the platform and demo some applications. It created quite a bit of blogbuzz.

I am not really convinced that Apollo will be the next big thing, but I could be wrong. There are some aspects of Apollo, WPF/E (or any runtime wannabe) that cause me to stop and think before falling head-over-heels.

• Platform vendor lock-in: Vendor lock-in is not a black/white issue. Some form of lock-in is always present. It’s more of a sliding scale. Tight lock-in (think MFC/COM apps) to Light lock-in (think cross-browser DHTML).
• Platform openness: Can you fork or hack the system? Can you supply bug fixes?
• Ability to extend with native code: You’ll likely need a feature not supported by the platform. Can you create an extension or plugin? Can you interact with the native OS or 3rd party databases?
• Interaction with desktop: Blending into the native OS is important to user experience.

Of course, the Mozillian that I am, I can’t help but think of XULRunner… Hmmm

Update: Ted Leung and Anne Zelenka have some “stop and think” posts too. I agree a lot with Ted. The day I stopped sharecropping for Microsoft was fantastic.