Less or more chrome for webapps?

February 12, 2010

This is part 3 in a loosely coupled series of blog posts about improving the browser for the cloud, particularly Firefox. In the first post of the series I made my case for why we need web browsers that are designed for today’s cloud apps. In parts 2a and 2b I have been exploring tabs, particularly how to deal with lots of them. And how a simple change in tab behaviour can allow me to blend the previously separate concepts of bookmarks and tabs (cf. my BarTap extension.)

In this post I’d like to muse a bit about creating tighter integration between the browser and webapps. We’re using a lot of webapps these days and a lot of them we never quit. Hence people came up with the idea of “app tabs” which are tabs in your browser that are always there. There’s an extension for this, and more importantly, app tabs will be an integral part of the future Firefox UI.

Part of the idea is that app tabs don’t need any chrome, which is geek-speek for the browser UI. Think back/forward buttons, URL bar, etc. In a way that’s true because the webapps displayed in these app tabs are typically self-contained and don’t need navigational UI elements. But this got me thinking: Perhaps there are other UI elements that a browser could provide to make the webapp experience easier? As outlined in the first post of the series, I find it a bit worrying that webapps employ so many different UI paradigms, thereby evading the most humane feature a UI can have: consistency.

But as I also said in that post, closed environments like a mobile platform (e.g. the iPhone) have shown that apps like Facebook and WordPress can actually be made to have a similar look and feel. Why not do the same thing, possibly on a smaller scale, in the browser?

Due to a transcontinental flight I had some otherwise unproductive time earlier this week, so I hacked together a small extension called Vanadium that does just that, albeit in a very very primitive way. It basically hides the navigation chrome for app tabs and instead displays the “vanadium”, a toolbar that represents actions for the webapp. Here is Vanadium in action using Gmail:

Using Vanadium for Gmail. All of the toolbar buttons are hooked up, including the search. The Home button takes you to the inbox.

I’ve also integrated it with Twitter, though of course the Reply button doesn’t make that much sense there:

Vanadium hooked up to Twitter. Not all of the toolbar buttons make sense.

All in all it was a fun experiment (certainly a nice way to spend a flight) and I think it’s worth pursuing the idea further. Of course not all toolbar buttons make sense in all webapps. And the way the Vanadium toolbar works together with the webapp would definitely have to more sophisticated. I think the most promising item would be the search bar so I’m thinking I’ll be investigating a cross-webapp search bar next.

What do you guys think?

4 Responses to “Less or more chrome for webapps?”


  1. Just playing devils’ advocate, but why would a “compose” button in the browser toolbar be better than the one inside GMail? Unless GMail was tightly coupled with the extension, I think it could cause confusion, if nothing else then in documentation and internal references to actions.

    • philikon Says:

      Of course that’s a good point. A tight coupling is exactly what I’m trying to investigate. Having a common toolbar across different webapps is just one possibility, and it’s first thing I could think of.

      I don’t think it necessarily causes confusion. If anything people would form habits. IMHO that’s a good thing. It *would* be confusing if the software wouldn’t behave as expected once you’re applying your habits to a new site.

  2. Matthew Wilkes Says:

    Hmm, while it’s an interesting idea, you’d also need to provide feedback to the webapp about what navigation is being provided in the browser’s chrome.

    The app needs to know if it’s a normal site or an app tab, then it needs to know what options are visible in the toolbar so it can show the others. In addition, it’d need to know if something’s hidden from a toolbar so it’d show in the app or if the option isn’t wanted.

    • philikon Says:

      Yes. Actually I think it should be other way around. The webapp would ideally have some feedback for the browser which toolbar buttons make sense for that particular app.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: