Jake Herringbone

Site-specific Browsers

To start, an announcement: I’m going to start work at Google in September! I’m in California now, and partly moved to Sunnyvale, one town south of Mountain View, home of the Googleplex. Google is kind of like a college campus, where I can do awesome coding without feeling political pressure to deal with bosses, or pressure to get into the business side of things to have a viable career path. Yet as terrific as that is, I have a dark secret that makes it an unlikely place for me to work: I don’t like web applications.

At first, I wondered if webapps were just the fashion. They’re easy to code (at first), trivial to deploy to many client computers, updates are mandatory so you pretty much don’t have old clients still running. The fashion shifted to creating web applications and now that’s what we get. Even for internal company systems, where you have control of the client machines, and your app is intended to be used as the primary work interface for a good chunk of a person’s day, I see a lot of big organizations writing a web app without considering a rich-client app. And now I’m not sure it’s just fashion – it seems to be the way we’re headed.

The browser is built for browsing

One problem with web applications is that they all run in this web browser program, which is a Multi-Document Interface. (More specifically, a TDI) Inside that browser, you have a number of documents going on. You’re reading some news, you’re logged into a company IT system, you’re shopping for a t-shirt, you have a couple pages you were reading but lost interest in, and of course your webmail. On IE7, Safari, or Firefox, you’re probably managing those documents using tabs, all within one browser window.

Now, you also have some other programs open, and you have developed whatever mechanism you’re comfortable with for switching – maybe the mouse, maybe ⌘-Tab. This works well, you have icons that represent each program so that your brain’s exceptional image-processing can figure out where you want to go without adding any reading tasks in the middle of your task-switching.

All those tabs in your browser don’t cooperate with your app-switching mechanism, that’s the problem. For the documents you were just browsing, this isn’t a big deal – your browser is good for browsing. But your webmail and your corporate IT system – what are those doing in there? Those are web applications, and should be in the same context-switch with the rich client applications. I don’t want to remember that Firefox is the first thing to switch to, then use a different means (I recently found ⌘0-⌘9 for choosing the active tab) to get back to my webmail.

Then there are the other issues with MDI’s: they don’t play with Expose, and it’s not always possible to drag a tab out onto another screen if you’re actively using two of the documents at once. Popup windows don’t get associated with the document that opened them.

Launching and quitting the Web Application

If I want to do banking, I’d like to launch my bank’s application from my Dock (actually I use Overflow) just like my other apps. When I’m done, I’d like to exit my banking application with ⌘Q.

In the browser, there is a very different way to accomplish this. I’d either find a bookmark (which would be mixed in with browsed pages) ar I’d put something in my toolbar, or just start typing a URL. I usually find the latter is the quickest, which is kind of dumb because I’m typing a lot of characters to get to this place I go all the time. Then I probably have to navigate to my personal account login, which is another dreaded pageload or two. When I’m done, I have to log out.

Security

A big problem with my online banking is that my bank’s session is stored as state in my browser. If I load a URI from my bank site, it’s treated as authenticated. But what if I’m browsing a page with an image in it like

http://mybank.com/account/transferMoney?toAcct=012345&amount=100.00

and my browser requests that? It will send along my session cookie and give you $100 from my account. That’s dumb. My bank’s application shouldn’t be running in a shared environment with untrusted stuff I’m reading online, it should be a separate app and if it wants to use cookies and HTTP, great, but they should live in the banking app only.

Interacting with the rest of the computer

This is a problem Adobe AIR and others are trying to address with the “Rich Internet Application” concept. I should be able to drag files into GMail to attach them, have my webapps give me Growl notifications, have them add things to the MenuBar, and so on. Maybe they should be user-scriptable in Greasemonkey, like you’d do with Applescript on a Cocoa app. To me, this is actually the least compelling problem with web applications, mostly because apps that need to do these things are delivered as Rich-client apps already.

There’s also the issues that Mark Finkle writes about: the web application should probably run in its own process, and doesn’t need all that extra chrome or toolbars. I get most emphatic when I talk about the Back button. It’s based on this idea that you’d like to return to the document you were viewing when you followed the link that brought you here. Web developers go to lots of trouble to try to make the back button do something reasonable in a web application. Why is it even there???

The Solution

Site-specific browsers are the best way to resolve all this. The web application doesn’t have to change – my bank doesn’t need to be involved to fix this problem. We just need a convenient way to spin up a Webkit into a little standalone app.

Here are a few approaches:

• Gabe’s Browsair turns a site into an Adobe AIR application
• Some Google apps have been turned into Mac apps: Mailplane, GCal.app
• Mozilla’s Prism (previously WebRunner)

None of this has really caught on, as far as I can tell. I have been on this bandwagon for several months and I haven’t seen it go anywhere. This needs to get solved!

2 Comments to Site-specific Browsers

Brad Sneade
August 18, 2008

You should check out google gears (at least in the google context). It allows for desktop integration and local storage non associated with browser information.

Leave a comment