For the past couple weeks, I’ve been playing around with both Fluid (for OSX) and Prism (on Vista). For those that are unfamiliar, both apps do basically the same thing: they let you create a site-specific web browser that presents itself as an app on your machine. So, if you use Gmail, you can easily create an app for Gmail that logs you into the service when your app is launched from the dock or taskbar. These little apps are especially handy when used with an app launcher like Quicksilver or Launchy.
Though skeptical of the concept at first (I kept thinking, “Isn’t this what tabs are for?), I’m now sold. I love the idea of running a dock full of applications all powered by other machines out in the cloud. The hurtle as I see it isn’t in the concept; it’s in the design of these applications. And I’d like to humbly submit one thing that all web app authors must do to fit in with current and future generations of these single-site browsers:that remain are less about flaws in the concept
Your app must not rely on the browser’s back button.
With Fluid, you have the option of turning on standard browser controls, but in Prism, you don’t. In my opinion, for the concept to hold water, you really should dispose of the browse buttons anyway.
Look at the apps you have open right now on your machine. Besides a file browser or a finder, how many of them have buttons that imitate the forward/back buttons of a web browser? One, maybe? I’m betting zero is the norm. For a web app to feel like a desktop app, it needs to at least follow the basic rules of desktop apps.
Most web apps I use pass this test handily. Netvibes does the best, with Basecamp coming in a close second. (Basecamp, unfortunately, is missing some features in Prism that I’d like to see. For instance, I wish I could switch to a project in a new tab rather than leaving the project I’m currently viewing. Also, Prism doesn’t let me refresh the page, which is crucial for fast, efficient use. And in fact, I think it’d be great if Basecamp included a refresh button on every page.)
For the most part, Google does okay, but when you start using their apps in a site-specific browser you start uncovering minor flaws in their design pretty quick. One example: Google has a habit of placing links to other services in the header of their services. These links frequently open in a new window and expose no way for you to return to your application without the use of a back button.
It’s not even worth arguing whether the use of web apps will ever eclipse the use of desktop apps. (For the record, they will – at least in the way we currently define a desktop application.) If these site-specific browsers grow in popularity, app developers must consider the small features that let folks working outside of the typical browser box use all features of the app quickly and efficiently.
Comments
Whaddya think?