Taking Browser Tabs Seriously

I’ve just updated my favicon library, which I first wrote about here. I’ll explain more about the update in a separate post. For now, I want to talk about browser tabs.

Browser tabs were introduced by Opera. Then Firefox adopted them a few years later, as did Safari. Then Microsoft stepped into the ’90s with their own IE tabs. Meanwhile, tabs became teh coolness and Kevin and Alex joked on Diggnation about how you could get brownie points by saying it’s a tabbed interface. And so you get tabbed terminals among other things, and fortunately there is some consistency on keyboard shortcuts (typically ctrl-t to make a new tab and ctrl-w to close it, or option-t/w on mac).

We’ve outgrown the rudimentary functionality that is available for managing tabs.

The browser is the new operating system, the tab is the new system process, the tab bar is the new taskbar.

Power users struggle to keep up with 20+ browser tabs and grasp what’s inside them. The Firefox Tab Mix extension is a superb addition and should be part of the core. But there is a lot more that could be done, for instance:

  • Notifications. The whole issue of attention and notifications needs re-thinking in light of the new world of rich web apps. Quintessential example is web chat – how do you inform the user someone has sent a message, in another window? The favicon library helps here, and the update in my next post, helps a bit more. Playing a sound is also possible. Still, I would like to see API support for ambient dialogs, like Growl/Snarl and the Windows “sunrise” notfier that emerges from the taskbar (what’s it called officially?). And sound. It’s 2008, why can’t browsers issue a single beep like a good 1970s PC, without requiring flash or unreliable hacks!!! Speaking of sound …
  • Where’s that sound coming from? There’s a sound in my browser, but I don’t know where! Tabs should provide a visual indication if a sound is emerging from them.
  • Default/Custom Favicons. If a site doesn’t have a favicon, browsers show nothing. Bzzzt!!! They should provide more sensible defaults, e.g. at least show the site’s background colour or a thumbnail of the first image. Something to make them all different from each other.
  • Provide a Summary List. Like clicking on Ctrl-Alt-Delete in Windows to get a task list or “ps” in Unix. You’d be able to see how long each tab has been open, memory usage, other excitement.
  • Hover info Similar to the previous point, let web developers provide tooltip info which will be displayed as the user hovers over the tab.
  • Popup menus Why even open up a web page? Sometimes, you want to do something quickly without having to switch tabs. Let web developers create site-specific popup menus that emerge from the tab. For example, you could use this mechanism to record simple events as they occur. Or start and stop a timer. Or to switch channels on a music website.
  • COLOUR AND STUFF!!! Browser tabs are pretty dull – just an icon and some text. Using cues such as colour and font styles, the browser could say a lot more about what’s happening in the other tabs. Perhaps it could be set by the programmer or perhaps it could be set by the user (e.g. create a heatmap highlighting the least used tabs).
  • Javascript events. Javascript onEntered()/onExited() events to let the application know if it’s active or not. (Similar to what desktop apps receive.) This would be absolutely brilliant for when you are notifying the user about something they need to see (e.g. a new chat message) – once they re-enter the tab, you can switch off the notification.
  • Open Forms. What about when I start writing something in a form, then switch tabs, and forget which tab has the form, or forget that it’s there at all. The browser should indicate when there’s a form open that you’ve been writing to. (Though in some cases auto-backup features may mean that’s not necessary.)
  • Search. No-brainer. Browser search should work across all tabs, not just the one currently open. This would not only help you find some text, but also pinpoint one of the fifty tabs you have open.
  • Virtual Desktop. Maybe it sounds mad, but I’d like something similar to virtual desktop (“Spaces” for Mac-heads). ie Switch from “work” tabset to “social” tabset, etc.
  • Auto-remove. Instead of forcing me to close all windows, or some random subset, or restart the browser altogether, provide some support for removing the tabs that matter least. e.g. the tabs that I haven’t used for the longest and which I appear not to have interacted with (ie started editing a form), and/or the tabs that are taking up the most resources.

I’m sure there’s a lot more. The main point is to take inspiration from the way operating systems let users deal with open applications, and then some. The dynamic favicon library is a small part of the solution, but there’s only so much libraries and even browser add-ons can do…it needs to become a core feature of the browsers. Just as Opera and then Firefox owe a big chunk of their initial popularity to their the cult of the tab, so too do the manufacturers today have a similar opportunity to take it to the next level.

Choose Web

Choose Web!

I recently learned about a team which had adopted a proprietary Windows application to do agile (Agile [TM]) project management. Eeek! Wrong at so many levels, but I’m going to focus on the web vs desktop angle.

In an ideal world, there would be multiple UI platforms available for any application. e.g. do your project management on Windows, Macs, the web, and the phone. In practice, there’s usually just one. Which one will depend mostly on the application domain and the usage patterns involved. Each application domain lends itself to a particular UI platform. With an application space like agile project management, the platform is clearly the web.

In my view, enterprises should adopt a “Choose Web” policy. Similar to a preferred vendor policy, this kind of policy states: The web is the default choice for our applications; anytime we make a critical commitment to a desktop application (i.e. a large purchase or a large deployment and training exercise), we are obliged to justify why it is more suitable than web equivalents.

Here are the advantages of the web platform over the desktop in the case of agile platform management.

  • You can introduce team members – anyone who needs to access the application – as users a lot faster. Instantaneously, really. With desktop apps, they have to go through the whole download-and-install business, which can be a lot of trouble in the enterprise.
  • You will be more popular and contribute to greater staff happiness, which in turn means less turnover and more work done. Enterprise web apps tend to be neat and cleanly designed. Enterprise desktop apps tend to be clinical and grey. For some reason, no-one has yet thought of putting images into enterprise desktop apps, whereas images have appeared on enterprise desktop apps for 10+ years. On the whole, users choose the comfort, familiarity, and “liveness” of the web.
  • It’s open to everyone, including those who would never download a desktop tool, but might stumble upon the web app. It’s useful to have user stories and the like in a place that people from other areas of the business can see it – it might lead to serendipitous collaboration. It sucks to be on a phone call with someone and they ask you for info about the project and you have to spend ages telling them, or print out a screenshot or something, because you know that it will be way too much hassle for them to install it just to find out a one-off piece of information.
  • As you have a web server equipped with the data, you can easily serve out data in useful formats, especially RSS. e.g. a feed showing recently created (or completed) tasks.
  • You can link to other web-based resources such as the staff directory.
  • It’s easier to track usage and berate team members if they don’t log in. (Don’t do this. Be nice.)

There are, of course, arguments in the other direction – reasons to choose desktop over the web. But in the case of agile project management, as with many enterprise apps – the reasons don’t stack up against the web.

  • You can use desktop apps offline. This is fairly pointless for a modern project management tool, where multiple people are using and contributing to it. In any event, people are generally online in the enterprise.
  • You get rich graphics Unnecessary for many enterprise apps. In fact, enterprise web apps tend to have more bling anyway.

OAuth-OpenID: You’re Barking Up the Wrong Tree if you Think They’re the Same Thing

OAuth, OpenID…they sound like the same thing and they kind of do vaguely similar things But I’m here to tell you, OAuth is not Open ID. They have a different purpose. I’ve been playing around with OAuth a bit in the past couple weeks and have a grip on what it’s aiming to do and what it’s not aiming to do.

To start with, here’s what OAuth does have in common with Open ID:

  • They both live in the general domain of security, identity, and authorisation
  • They are open web standards. Created and evolved by people with an itch to scratch and evolved pragmatically by a loose, fluid, alliance. Think REST, not SOAP. Think Bar Camp, not The 25th Monosemiannual International Convention for the Society of Professionals who Devise Acronyms Quite a Bit.
  • They both celebrate decentralisation. There is no central Open ID or OAuth server that holds all the security information in the universe (cf Passport). Anyone can set up as a server or a client.
  • They both involve browser redirects from the website you’re trying to use – the “consumer” website – to a distinct “provider” website, and back again. Meanwhile, those websites talk to each other behind the scenes to verify what just happened.
  • The user can actively manage the provider website, exerting control over which websites can talk to it and for how long.

With that much in common, the casual observer could be forgiven for confusing them. But they’re different. Not different as in “vying to be the no. 1 standard”, but different as in “they let you do different things”. How so?

Open ID gives you one login for multiple sites. Each time you need to log into Zooomr – a site using Open ID – you will be redirected to your Open ID site where you login, and then back to Zooomr. OAuth lets you authorise one website – the consumer – to access your data from another website – the provider. For instance, you want to authorise a printing provider – call it Moo – to grab your photos from a photo repository – call it Flickr. Moo will redirect you to Flickr which will ask you, for instance, “Moo wants to download your Flickr photos. Is that cool?”, and then back to Moo to print your photos.

With OAuth, you still need to log into the provider. e.g. When Moo sends you to Flickr, you still have to log into Flickr (or be logged in already). How Flickr decides you’re logged in is completely orthogonal to OAuth. It could be a standard username-password login, it could be via a physical password device, or it could well be via Open ID.

With Open ID, there is no suggestion of two web apps sharing your data. Except in the very limited sense that the Open ID provider may hold some general information about you, e.g. some photos, addresses, phone numbers, etc., and with your consent, send it back to the consumer so you don’t have to re-enter all the boring profile details again. However, this is data of a generic, non-application-specific, nature. (And even this limited form of sharing is an extension to the core Open ID spec.) With OAuth, any information you hold on any website can be shared with another website. You could share your GMail with a clever consumer that automatically tags items by inspecting the content, if GMail was an OpenAuth consumer.

Or you could copy your GMail address book into Facebook, by allowing Facebook to read your GMail account. Right now, the only way to do that is to give Facebook your GMail username and password. Clearly a dumb thing to do, and that’s exactly the kind of thing OAuth is set up to prevent. OAuth prevents it by explicitly asking you if you want to let Facebook grab your details from the provider. That’s not a problem Open ID solves. Even if Facebook and GMail used Open ID and you had accounts with both against the same Open ID, you still couldn’t get Facebook to read your GMail account. The Open ID provider wouldn’t let Facebook log in to GMail as if it was you. Even if an Open ID extension came along to allow it, you wouldn’t want it. It’s too coarse-grained and would allow the consumer to do too much potential damage. OAuth is more fine-grained – consumers can do some things with your provider data, not everything.

Ruby is Rails is … REST

Will the peripheral IT community come to view REST and Rails as equivalent? It might sound ridiculous, but consider: Unix==Linux, Wiki==Wikipedia, Ajax=Web 2.0, blogging==RSS, podcast==spoken MP3. Last but not least, every knows that


So it only stands to reason that the REST equivalence shall come to pass, as REST hops on for a free ride on the Rails worthy-hype machine.



(For the sake of completion, yes, Ruby==REST.)

The possibility of Rails==REST didn’t occur to me until I read this – probably quite necessary – clarification:

I want also take a step back for a moment, and mention that REST is not a Rails-only thing. REST was developed long before Rails, and is simply an approach that can be applied to many kinds of software applications.

If Rails can bring REST to the fore of mainstream development, in addition to other goodies like Convention Over Configuration and Migrations, that’s one more reason to heartily <heart> Rails.