I finally spent some time to make a DMG for XUL Explorer. It doesn’t have fancy background images, but it seems to work. One thing that surprised me was the size, even when compressed – 18MB. Also, I find it hard to believe that the “standard” way of distributing software for the Mac is a disk image that the user needs to “drag-n-drop” on the Applications folder. Anyway.
Once installing XUL Explorer on my Mac, I did notice how poor the UI fit in with the Mac look. I’ll be working on that. I should have a Linux archive ready soon too.
Mac DMG: xulexplorer-0.3.dmg
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:
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
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.