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.