David Emery Online

Browser Interfaces

8 September 2006

One of the more popular interface patterns that have come to the fore recently is the “Browser” design. By browser, I don’t mean web browser, but the UI used that was first popularised by NeXT (to my knowledge, I would be surprised if it hadn’t been done somewhere else first) and hence later the Mac OS X Finder, where it is called column view. The basic premiss is that you can drill down a hierarchy, with the previous steps shuffling out of the way so that you can focus on the active pane, and quickly get to the information you want.

After the Mac OS X Finder, the next major application to use this UI widget was iTunes, with its “Browse” view. This is fairly important, as almost everybody has used iTunes, so it’s a fair assumption that everybody has probably used a browser interface, and hence the learning time is minimal. In iTunes, it works particularly well, as iTunes typically contains a large amount of data, which is always sorted into a hierarchy (genre->artist->album).

However, iTunes is also responsible for the widest used and most popular implementation of the browser interface: the iPod.

Facing the same requirements as iTunes – the easy navigation of a large dataset – coupled with the need for incredibly simple controls, the browser interface was a perfect fit. The subtle touches in the iPod interface really make it really work on a mobile device; the transition animation from one column to the next is vital, as it reenforces the metaphor the interface is using – that as you navigate the interface, you’re moving from left to right over a series of views. Also, the persistent header give you all the information you’re going to need at a glance – where you are, if you’re playing a track or paused and how much battery life you’ve got left.

The browser interface works particularly well for mobile devices, even without the iPod’s click wheel. The major hurdle for mobile device UIs is having to cram a large amount of information onto a very small screen size, and the traditional solutions have been things like tabs and contextual menus. However, the browser interface would be perfect for many mobile interfaces – and as a lot of flexibility, so you could – for example – change the menu structure based on previous options, and reduce what may have once been a series of check boxes that require precise pen tapping into a quick series of column menus.

In conclusion, it’s quite clear that browser interfaces are a user interface pattern that solves a lot of problems in a simple fashion, and the popularity of iTunes and the iPod mean that people already know how to use them. With the recent popularity of ajax, they are now possible to implement on the web as well – I can already think of many web apps that would benefit immensely from the use of a browser view…