With Google Chrome, it is ample clear that browsers will evolve into application environments. Its first design give good hints as to where this is all going. For example, the inversion of the tab bar and navigation controls is not merely a cosmetic preference, but a reversal of the containment hierarchy: where as before, navigation was a universal control which manipulated tabs, now tabs are a universal control (task management) which manipulates work flows (some of which are browser like, others not so much). The bigger picture here is that the browser is taking on some of the responsibilities of the OS GUI, specifically, managing applications. As more user activities such as music playing, document editing move inside the browser, the existing browser interface will quickly become unfit for the job.
From tabs to tasks, the evolution of web activities
Computers have made us all into multi-taskers. The original innovation around tabs is conceptually similar to the collapsing of task buttons introduced in Windows XP: group a bundle of similar tasks under a single container. And similar they were. In the old web, the everything you did was more or less a browsing sequence of documents connected via hyperlinks. However in the past few years, web activities have evolved significantly away from sequential document browsing. How would you classify the activity of having Pandora in the background? Or editing a new blog post? These activities would originally reside in WinAmp and MS Word and have little resemblance to document browsing, and thus should have little resemblance to a browser interface.
Classically offline activities are now shifting into the browser window. They are diverse in 3 major dimensions: (1) their multiplicity, (2) degree of engagement, and (3) control schema compared to traditional document browsing.
Pandora, for example, is a single-instance (1) activity that usually occurs in the background (2) and almost never uses the standard back-forward-reload-locationbar browser widgets (3). Blog editing, other otherhand, is likely a single-instance foreground activity with again, totally different controls. This necessitates different task management interfaces beyond a horizontal tab list. Does it make sense that Pandora occupies a whole tab, like its a document waiting to be read (2)? No, I think many people would prefer to ”faviconize” it. Single-instance apps, such as email or RSS readers make more sense as master tabs or container groups, not as yet-another-tab in a sea of open documents (1). Finally, the standard browser controls don’t always make sense for highly specialized, non-document and non-browsing applications (3). Take the email example: I rarely ever use the back-foward button, and certainly never the location bar (unless I navigate away). Back-foward interfaces make no sense in email: you’re navigating through a hierarchy (inbox->label->conversation->message) as opposed to a sequence.
Borrowing from prior work
So what is the correct GUI behavior for a Pandora or word processing task? Just look to desktop applications! The Pandora air app sits inconspicuously in the system tray, and when active, doesn’t feature the standard browser navigation controls. Popular blog editing tools are single-instance and sit outside of the browser, and again, feature no navigation controls.
The app management problem has already been solved before, just look to the behavior of desktop applications and how they interact with the OS’s provided task management interfaces (e.g. taskbar + system tray, dock + expose)
Browser developers should be keen to borrow these interfaces and extend such access to web apps.
The road forward
I think ultimately, this is about web apps catching up to desktop apps in richness of their GUIs. You can have the sexiest possible GUI for your webapp, but it’s still constrained within the window. Can a web app pop up balloon notifications? Run as a minimized background process? Register contexual actions on desktop icons e.g., “Upload to Box.net”? The true role of the browser will not simply to “display and view webpages”, but to bridge every available aspect of the GUI with a web application.


