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!

Darwinian Evolution of Software?

In high school math class, we learned about gradient descent. The idea is to find the low point on a graph, like finding the lowest elevation in a geographical area. Although it sounds pretty straightforward, there is a problem doing this: we can tell if something is a local minimum, but not if it is globally the lowest. The algorithm for gradient descent can be summed up “go downhill”, which will eventually find you to a low point. It’s possible that right next door to your low point, however, is a much lower point, but you would have to go uphill to get there so you’re never going to.

Lots of things behave like this, which I’ve always found interesting. Rivers lie where they do because they seek out the lowest point. And evolution acts this way too, because the best it can do is to improve on what’s currently available. Each generation can have mutations based on their parents, and if it’s an adaptive mutation, the new trait lives on. But, if the improvement is dependent on something else happening first, and that prerequisite is detrimental, then the improvement isn’t possible. That’s like going uphill to look for a new minimum.

My favorite example of this is that the back our eyes have a hole where the optic nerves bundle together and pass through the eyeball to get to our brain. This is needed because the nerves come out of the front of the receptor cells, instead of the back. If the nerves came out the back, we wouldn’t need the hole, but we happened to evolve the receptor cells and optic nerves in this order, where by the time the eye was finished, the pipes were layed wrong. If only the intelligent designer could refactor, right?

From http://www.2think.org/eye.shtml

Ok, now I’ll make my point. In software, we should be intelligent designers, and we should be able to refactor. If we made an eye with a hole in it, we could probably fix that in release 2.0. And yet, in a larger and slower scale, software really does “evolve,” and critical mistakes aren’t corrected if it would mean the technology is temporarily crippled. Instead, we build on them and move on to the next layer of abstraction with those funky things still frozen in that layer.

Around 2002, as the web was turning into a place for applications to live instead of just reference material, a need arose to have appealing and highly functional user-interfaces in a web browser. We wouldn’t have chosen to turn a web browser into a rich-client platform if we had a big meeting about it, but they were already deployed on everyone’s desktop. It was clearly descending the gradient to just put an application on that platform, since we weren’t sure our users would put up with downloading and installing something without their employer making it mandatory. Also, we need it to be cross-platform since we don’t want to make any assumptions about what hardware our users have. Java tried to get onto the desktop, which would have made more sense, but it didn’t catch on.

So then Web 2.0 came along, and improved the browser’s ability to present a decent UI. We deploy rich-client applications in a browser using the XmlHttpRequest javascript feature. Javascript has to be the most abused programming language ever, and at first I was aghast that AJAX would push it to do so much. It felt buggy and unnatural, and again I think this was an evolutionary process – we’re writing web applications, we have developers who know CSS and DHTML, lets put them to work.

Bruce Eckel wrote about this in his article on moving to Flex. He gives a nice history of the presentation layer, finally ending up on Adobe Flex. I’m sure many of us are a little annoyed by the frequency of the Bruce Eckel “thinking in Flex” ads that have been all over the place lately – it reminds me of how I wanted to get away from T-Mobile when they had Jamie Lee Curtis everywhere. But Flex does make evolutionary sense – now that we’ve evolved these capabilities to write web applications, let’s improve our toolset and move to ActionScript and have some better graphics and animation capabilites. We don’t have to deploy much to clients because again they mostly have flash plugins in their browsers already.

So now here comes Apollo:

Jesse and Gabe were experimenting with it, and from what I could tell, this is a neat way to take the current evolution of Web 2.0 presentation technology and bring it back to the desktop again. This is where I think of the hole in the eye – it’s great to have a true desktop app that can interact with peripherals and be responsive and work offline, but some of the technology stack comes from the web. CSS wasn’t intended to layout a rich-client desktop app, was it?