Free eBook from Flashbulb Interaction

Earlier this week Jake Burghardt at Flashbulb Interaction emailed to tell me about his new eBook entitled: ”Working through Screens: 100 Ideas for Envisioning Powerful, Engaging, and Productive User Experiences in Knowledge Work”.

I’ve not had chance to read it all yet, but what I have read so far is very good, so I saw no point in delaying sharing it with you all!

Working through Screens is a reference for product teams creating new or iteratively improved applications for thinking work. Written for use during early, formative conversations, it provides teams with a broad range of considerations for setting the overall direction and priorities for their onscreen tools. With hundreds of envisioning questions and fictional examples from clinical research, financial trading, and architecture, this volume can help definers and designers to explore innovative new directions for their products.

It is available in 3 formats:

  • Online html
  • A 143 page pdf
  • A highly summarised ‘Idea Cards Edition’

I love the ‘Idea Cards Edition’ idea – so much valuable information is lost when it’s bound up in a book that people haven’t the time to read!

He’s generously released it under the creative commons license (Attribution-NonCommercial-ShareAlike) so if you enjoy it you can share it with your friends!

Grab yourself a copy from the Working Through Screens mini site

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Misc | Tagged | 1 Comment

Usability Issues When Integrating Systems

Sometimes it is necessary for us to integrate our software with another system in order to offer its features to our customers, in fact a new class of applications has emerged where separate systems are created from integrating other products – the ‘mashup’. Allowing a user to take advantage of another system from within your application presents a number of problems that can impact on the usability of the software you deliver.

The other system was written by different team of people. Any team working towards a common goal becomes a microcosm and develops its own way of doing things. This is likely to differ from yours. Sometimes, the differences are small things such as international date conventions (dd/mm/yyyy vs. mm/dd/yyyy) or maybe your application saves a user’s work automatically whereas theirs requires a save button click to commit changes. Unfortunately, these seemingly minor inconsistencies add up and have a huge impact on the overall usability of the product.

If you tightly integrate the external system, your users will be unaware of where your product ends and the other starts. Actually, they wont care; they’ll just be angry that it behaves differently in different places and they keep making mistakes.

So, what can you do to mitigate these issues?

Don’t integrate the front end

When the opportunity presents itself, by far the best approach is to write a new user interface from scratch for the system you are integrating – following your own standard conventions. This gives you an opportunity to make the experience completely seamless; taking advantage of the other system’s tried and tested business logic without compromising the user’s experience. Of course, this is not always possible, you can’t easily replace the interface of something like Google Maps – it’s simply too visually focussed, alternatively, you simply may not have the skills in house to do so. In these cases one of the below approaches must suffice.

Act as a Portal

If rewriting is not an option, consider only partially integrating the systems. Perhaps you can connect behind the scenes to display some ‘totals’ or other summary information but defer to the other application for the detailed view or for making edits. For example, if you wanted your application to integrate with a finance system; rather than embedding ways to create orders and invoices etc. simply retrieve the totals so that this information is available in context, but then redirect to the finance system to view order line details or create new invoices. This approach has the following benefits:

  • It cuts down your work and reduces the chances that you’ll introduce any inconsistencies
  • It lets the user perform the external task quickly in a, possibly familiar, tool designed explicitly for the task
  • They won’t have to learn your implementation
  • You still get the benefits of showing some data in context with your application
  • You just integrate the features that really matter

You’re not in Kansas anymore

Sometimes you are stuck in the awkward position of not having the time or resources to rewrite the entire interface and a partial integration effort is not sufficient. Unless the external system fits in well with the rest of your application, the best approach is to not pretend that it is a part of a whole. Make the integrated features look like they came from somewhere else (maybe even going so far as to say so?). If the user is aware that the functionality they are using is from another vendor they will be much more forgiving of any inconsistencies – they will almost expect them.

If you take just one thing away from this, remember don’t integrate the look without the feel!

A Cautionary Note

Whenever you integrate another application’s functionality, by definition, you are expanding the scope of your own. Ask yourself if this is wise. Make sure the user will gain something from the integration – your application doesn’t need to do everything, it’s fine for them to go to another application! You will be positioning yourself as the focus of any bug reports and complaints for a component that you may have little or no control over.

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Tutorials | Tagged | Leave a comment

10 Ways to Improve Usability When You Thought it Was Too Late

You’ve spent months working on your project and delivered it to the client. Initial feedback was positive, but they’ve spent a few days with it now and have asked if there is anything you can do to ‘make it more user friendly’. Ouch. It’s a bit late in the day to start any major restructuring. Surely, there must be something you can do! This article gives you 10 ways you can improve your application’s usability when you thought it was too late!

The 80/20 Rule

The 80/20 rule is well known and has wide applications – in this case you can say:

  • 20% of your applications features are used 80% of the time
  • 80% of errors are caused by 20% of interactions

So, the first thing you need to figure out is what are the 20% of features your users really care about or are causing problems. You can do this a number of ways: ask them (crazy idea, I know!), watch them using the product or you could add logging functionality to your application (probably the most reliable way – what users think they want and what they actually want are very different ).

Once you have arrived at these features you can focus on polishing them:

  • If they are going to be used the most frequently, see how you can make them easier to access e.g. make their icons more prominent, add shortcut keys etc.
  • If a user is getting stuck somewhere try and identify why; is there a clash of terminology? is the next step of the process not obvious?

By focusing your efforts on this 20% of features and issues you will greatly increase the overall perceived usability because you are focusing on the areas that matter the most.

Open Office toolbar shows frequently used commands and allows easy access

Open Office toolbar shows frequently used commands to allow quick and easy access

Aesthetic Usability Effect

Make your application pretty. When your users ask for usability improvements, secretly they may be crying out for it to be less ugly!

This is actually a known phenomena, attractive applications and products are perceived to be better and more user friendly than ugly ones. So ask a designer for some help, spruce up the CSS and you may be amazed about how much more user friendly your application becomes – just by making it prettier!

Constraints

Use constraints to stop the user from using your application in ways that you didn’t intend and ensure only they only enter valid data. This will cut down on errors and make interactions more intuitive. There are a number of ways you can do this:

  • If your database column only accepts a certain number of characters – prevent the user exceeding this limit. Stopping them make the mistake is better than throwing an error or, worse, truncating their data.
  • If a field should only accept numbers, don’t let it accept letters in the first place! Don’t wait until you are validating the input to tell them they’ve got it wrong!
  • When a user is entering a delineated field (e.g. a MAC address, serial number or credit card number) don’t make them guess whether they should put spaces, colons, hyphens etc. between the blocks of input – have one field for each block and display an uneditable delineation between them.
    The Product Key dialogue removes the uncertainty as to whether to enter the dashes

    Windows XP Product Key dialogue removes the uncertainty as to whether to enter the dashes

  • You wouldn’t have a user entering 1 and 0 or True and False for Boolean values; you’d have a checkbox! So, consider using controls such as sliders or dials for entering other data so that users CAN’T enter invalid values
  • If a control can’t be used at a particular time grey it out or remove it altogether. Don’t tell a user off for clicking a button when they shouldn’t!

Make it CRAP

Ok this is 4 things for the price of one… but they all fit in to one acronym so only take up one place on the list. CRAP is an acronym from the field of graphic design; it stands for Contrast, Repetition, Alignment and Proximity. I wrote an in depth article about using CRAP to improve user experience in: How to make your user interface CRAP. These principles are easy to apply and can make a big difference without a huge amount of effort.

Lighten the load

Dealing with large amounts of information increases a user’s cognitive load and makes your application harder to use. Cognitive load is the amount of mental activity used to accomplish a task and includes things such as memory, perception, thinking/understanding etc. You can take steps to reduce this load and make your application more user friendly:

  • Ask for as little as possible. Long forms, asking for lots of information, are intimidating. When a user can get away with it they’ll not bother filling them in. Where the user has a means to fill in the detail later, try to ask for as little information as possible to complete the task and let them move on.
    Creating a new project in Base Camp. Just the name and who\'s involved. The rest can follow later.

    Creating a new project in Base Camp. Just the name and who's involved. The rest can follow later.

  • Where you need a lot of information that can’t be deferred for later entry, break the form up in to a number of pages and walk the user through page by page. Make sure you indicate progress so they know how far they are through the process!
  • Remove unnecessary information from the display. Each piece of information on a display should add to understanding rather than clutter. If it isn’t relevant or adding value then remove it.
  • If possible, explain fields near where it is entered so your user doesn’t have to think about what it means. This is even more important when you are dealing with technical terms and acronyms – it saves a user’s blushes if they haven’t heard of it before! The screen shot of Base Camp above shows a good example of this by explaining what they mean for the field “Name the Project”

Use less words

Users hardly read anything. You’d be amazed how little they read. Your application isn’t a news article – if it has lots of descriptive text it simply wont be read. In fact, the shear amount of text will scare your users and make them think your application is complicated and hard to use. Most will just click OK or Next and hope for the best. When this is the wrong thing to do they will resent you.

If you need to prompt your user; use a declarative active voice. You don’t need to be polite and it wont come across as terse. For example don’t label a field “Please type in your full name:” just say “Full Name:”. The user doesn’t need to be asked politely and telling them to type it in is unnecessary – they can’t enter it via the medium of expressive dance. Even if they could – does that label preclude them from doing so? If there is too much to read there is a risk that important information will get lost in the crowd.

Above the fold

The ‘fold’ is a term from Newspaper layout design. The fold literally being where the paper is folded in half. Information above the fold will be seen by more people as you don’t need to unfold it to see the information. This term still has relevance in interface design, but the fold now is the bottom of the visible area without scrolling.

  • Consider rearranging the page so the user can see the most important data without scrolling. Does it make sense for you to eliminate scrolling all together?
  • Some applications display and group all the errors at the bottom of the page. As far as the user is concerned, they clicked submit and the form was just redisplayed to them. By the time they have thought to scroll down they already have thought that it’s a problem with your product rather than their use of it. So, lay out error messages so they are displayed above the fold (ideally, near to where the error occurred, but make sure you scroll the page so they are visible).

Sorting and Grouping

The way you organise the information in your application has a big impact on its usability. Sorting applies widely – from the order your menu items are in to the facilities you provide when displaying a list.

The 5 Hat Racks theory states that there are 5 ways to organise information:

  • Alphabetical: Simply in alphabetical order. This is a good approach when the information can’t be grouped in a meaningful way or a user needs to access any of the information quickly. It’s a popular choice for application menus where the user can access any item in any order
  • Location: Information is grouped by by physical space. If your data relates to the real world you could use this approach in conjunction with a map to show the information in its physical context.
  • Time: In time and date order. Whenever you have a date or time associated with information make sure you can sort by them so the user can view the information chronologically.
  • Category: Information is grouped based on some shared attribute. This could be what they are (e.g. books, dvds etc.) what they are used for (e.g. cold remedies, hair products etc.), colour, flavour etc. Categories are good to use for menus when there are natural groups that a user would expect e.g. financial information such as budgets, orders and invoices
  • Continuum: Ordered in a continuous series. This could be best to worst, highest to lowest, popular to unpopular etc. Where there’s a common measure, provide a means to sort by it

Have a look at how you have presented lists and menus, consider what the information will be used for and how your users will approach finding it. Your users may approach the information differently depending on the context of what they want to do at the time. They will appreciate the ability to change how it is organised to meet their present goal.

Forgiveness

A great way to improve the user friendliness of an application is to look for ways you can make it more forgiving. Forgiveness is the name given to a number of approaches that help users avoid errors or reduce the impact when they do occur.

  • Undo: Let people change their mind if they don’t like the impact of an action. This can be hard to retrofit at a late stage in development but it is one of the best ways of making your application forgiving.
    When you delete an email in gmail it does so without question; but makes it easy for you to change your mind

    When you delete an email in gmail it doesn't ask for confirmation; it just makes it easy to change your mind

  • Confirmation: Make actions 2 step by prompting the user to confirm the action they have requested. Confirmation steps increase the friction of the interface and can be annoying if used too often. You don’t need confirmation steps if the actions are easily undo-able (for example the “Are you sure you want to delete the file” dialogue in Windows XP is unnecessary as the files can be simply removed from the trash). You don’t need to just have OK/Cancel dialogues to add a confirmation step, it could be an additional separate action in an “Arm/Fire” sense. I wrote an article about Google mail’s creative use of a confirmation step to forgive users even when they are drunk!
  • Warnings: Display warnings to alert the user of implications. This is the least intrusive of the forgiveness measures, you could add information in context to explain the consequences of currently selected options.
    Feedburner uses a warning near the Activate button to alert you to implications without interrupting flow

    Feedburner uses a warning near the confirm button to alert you to the implications without interrupting your flow

  • Help: Finally, you can greatly increase your application’s forgiveness by including help and instructions! This is especially important if you find you have made a major irreversible error in your design and need to explain how the application is and perhaps how it differs to how it should be! At least until you can address the problem!

The Empty State

This is something a lot of software neglects and is a really easy way to improve your application. When you are testing or demonstrating your application it is full of test data. However, when a new customer first starts using it; it’s empty! You know that collapsed area over there will hold the whatsits and the big list at the bottom will contain dooberys – but your user might not! If a user doesn’t know what something is or what it should do they are likely to get confused; you can help them out by:

  • Rather than displaying nothing when there is no information – use place holders e.g. “There are no dooberys to display”
  • If it’s a user’s first time, tell them about the features in the place their content would be.
    Basecamp shows the ultimate empty state. It is empty, but full of information about what should be there and what to do next!

    Basecamp shows the ultimate empty state. It is empty, but has lots of information so you know exactly what to do next!

  • Give a user an option to pre-populate the application with example data. If the data is accurate and meaningful to the user this is a really good approach. It lets the user see each feature in action with some concrete data. However, once the user has a feel for the application, make sure there’s an easy way for them to remove all the test data – making them do it manually record by record won’t win you any friends!

Conclusion

Products tend to be better if usability is thought about all the way through development. However, there are always other pressures and knowing this doesn’t help you much when you find yourself in the above situation! Hopefully, these tips will point you in the direction of some simple tweaks and reorganisations you can make to improve your applications usability when you thought it was too late!

Have you ever found yourself in this situation – how did you improve your application’s usability?

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Tutorials | Tagged , , , , , , , | Leave a comment

Site News: Links page updated!

It has been a long time coming, but this morning brought about the correct alignment of the planets and I’ve finally got around to writing my links page! It’s not an exhaustive list of all the usability sites out there – just the ones I subscribe to. But, if you think I’m missing out on a site that should be on my list then let me know and I’ll get them added!

The list is mainly usability/UX pages, but there’s also a few links to other pages I enjoy that might be of interest to you.

On a related note, I’m now posting on Twitter, so if you like you can follow me here!

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Misc | Tagged | Leave a comment

Juggling, Usability and Features

I love watching people who obviously don’t know much about computers. They are wonderfully pragmatic, and will find the simplest path – even if it isn’t the optimal choice. The other day on the train I saw a guy using Notepad to write a report (his hunt & peck typing gave him away too!). Notepad does one thing; it lets you enter text (and move it around a bit).

This made me notice a parallel between learning a new piece of software and learning to juggle. The more features your software has the harder it is to learn; the more balls you have the harder it is to juggle. Notepad is the juggling equivalent of one ball – it’s easy. Let’s say this man on the train made the leap to Word Pad, or even worse to Word. Now he’s got more to worry about; formatting, fonts etc. More features, more balls. The formatting can get messed up, the fonts might keep reverting to the wrong size – he’s just dropped his juggling balls and is frustrated.

The problem is; people want features (whether they need them or not!) so will put pressure on you to add them: features add complexity, complexity increases bugs, bugs increase support issues …and…erm… support issues lead to the dark side…

Users are selfish. I don’t mean that as a criticism – they have their problems and they bought your software to solve them, so it’s only natural that they will ask for features so that solve them exactly. When you only have one customer the problem is contained – you are writing it just for them. Unfortunately, the more customers you have the more incompatible their requests become. You will eventually reach a point where 2 customers want completely the opposite thing. Adding all the features your customers want doesn’t scale – you can’t be everyone’s girlfriend. The further you go down the path of trying to please everyone; the more complex your product becomes, the harder it is to maintain, the harder it is to learn, the harder it is to use. Ultimately, you’ll please no one. Each feature must add to, rather than dilute, the value of your product to your entire community. Simply say no to the rest.

This philosophy will upset some customers, they may even go as far as to threaten to abandon your product. But, they bought your software for what it is now, they have already decided that what you offer is the best on the market – otherwise they would have taken their custom else where in the first place. Had you said yes to every feature earlier customers had requested you might not have won the customer who is now complaining!

It’s a difficult balance to strike, especially when you are starting out and grateful for every sale. But there comes a point when your product becomes bigger than any one customer. You must use your judgement and recognise your role as the software’s custodian; challenge the value of each feature so that your application stays focused on being the best in its niche rather than a poor product in many. If your goal is the best user experience then you must aspire to give your software the best features, not just the most.

“You know you’ve achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away”
–Antoine de Saint-Exupéry

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Software Interfaces | Tagged , , | 1 Comment

Forgive your users; even when they are drunk!

Forgiveness is an important feature of good design. You should help your users by minimising the impact of mistakes or, ideally, prevent them from happening at all.

One way you can make your interfaces more forgiving is by employing a ‘forcing function’ (aka confirmation). This technique makes the user verify that what they requested is what they intended. There are 2 kinds of confirmation: A dialogue; where you ask the user a question e.g. “Are you sure you want to delete all your files?”; or a 2 step process e.g. armed… fire! Both approaches slow the user down so that it is harder for them to perform the action by mistake and give them an opportunity to change their mind.

Google recently introduced a feature to Gmail called “Mail Goggles” where if you try and send an email late at night over the weekend it assumes you are drunk and forces you to answer a series of mental arithmetic questions first! At first I found this quite funny, but the more I thought about it the more I liked it as an idea.

We’ve all sent emails we regret. Some of these are when you have been out at the weekend and returned home a little worse for the wear. Of course, the software can’t tell that you’re drunk but by introducing a 2 step process it means you can’t just send the email without reflecting upon it. By making the second step a mental arithmetic test, they hope that your lessened mental capacity will be unable to perform the calculations and you’ll give up – or at least recognise you aren’t in the clearest frame of mind!

There aren’t many systems that should go so far as to test their users state of inebriation; but it is worth considering how you can compensate for a users state of mind when they are using your products: will they be under stress, working in a hurry or not giving your product their full attention?

  • Use your system knowledge to check unusual or unexpected data – e.g. if the “Quantity” field on your order form averages less than 10, verify the user meant it if they enter 100
  • When the user is performing a critical step – slow them down by making then perform multiple steps – it will force them to pay more attention and prevent accidents
  • Consider delays on some operations and provide an option to cancel e.g. “Your computer will reboot in 5…4…” – this will slow them down if they are in a hurry
  • Can you be like Google and take the time and day into account to infer anything? Maybe your software could act differently at lunch time or last thing on a Friday?

I think Mail Goggles is a great feature and something we should learn from. It shows a high degree of attention to usage patterns and an innovative solution that could save a user’s blushes. Imagine how relieved you’d be the next day when this feature prevented you sending the email where you told your boss what you really thought of him!

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Web Interfaces | Tagged , , , , | 4 Comments

Site News: Usability Friction Amazon Store

I’ve added an Amazon store to the site today. There’s not a vast quantity of stuff in there, I could have just added to the store by Amazon category, but I’ve hand picked everything on there myself. Everything in there I’ve either read (or am in the process of reading!), so if you are interested in usability or design these books represent a great starting point.

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Misc | Tagged | Leave a comment

Site News: Post Titles

I had a bit of an epiphany today about the way I title my posts to this blog. I think most of them are the wrong way up. I have been titling them based on the example – rather than the lesson that can be learnt from it. So unless anyone objects strongly (not sure why you would!) I think I’ll start doing it the other way up. I’ll probably change the structure of the posts themselves to reflect this too – introduce a design principle, explore it and then give a real world example. Here’s a couple that I would rename:

Thinking about how I’d rename these posts has made me realise if I rewrote them now I’d write them very differently and that they would probably be much more useful! This also reflects the direction I’d like this blog to head in; to be a resource for people who are interested in design and usability factors rather than a list of my grumbles!

Thanks to everyone who’s been reading so far – I hope that this change will make the blog better for you!

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Misc | Tagged | Leave a comment

Verbose seat reserved LED signs on Virgin Trains

I travelled to Leeds to visit a client on a Virgin Cross Country train last week. Above each pair of seats on the train is a small LED sign that says if the seat is reserved or not (see the picture – sorry about the quality it was taken on my phone in less than fantastic light). This is a great idea, it means that the staff can enter  the reserved seats from a central computer rather than having to walk down the train to stick the little paper cards in the top of the headrests.

When a seat is reserved it says, for example:

“10 Sheffield to Leeds” (referring to ‘Seat Number’, ‘Reserved From’ and ‘Reserved To’ respectively)

If it is free it says:

“This seat is not reserved”

The problem is that the screens aren’t large enough to display the whole message, so it has to scroll – and it scrolls quite slowly. So when you are trying to find a seat you have to stand and wait to read the slowly scrolling message before you know if it is available. However, this just isn’t possible when there are a lot of people pushing to get on to the train. This situation could be improved:

The unreserved seat problem scrolling problem is trivial so solve. We simply change the message to say what the seat is rather than what it isn’t: “This seat is not reserved” becomes “Available”. Or, if you want to really spell it out “Seat Available”. This is much better – you don’t need to perform the logical deduction of ‘the seat is not reserved therefore it is available’, or as Jakob Nielsen puts it “Usability increases when users need fewer mental transformations to convert a sentence into actionable understanding”. Also, as it is much shorter the display doesn’t need to scroll and you can tell at a glance that it is available.

There isn’t much we can do with the wording on the Reserved seats, but we could make life a little better. As far as I can tell, the notices are put up at the start of the journey and left until the end. This means when I read the notices I am expected to have knowledge of the route – as an occasional train user I don’t know the order of the stops. Major cities I can guess at but I haven’t a clue about the smaller village stations! Have we gone past them? If I take this seat will someone ask me to move in a few stops time? I have no idea! The train knows where we are on the route (there’s another display above the doors showing the next stop) so why not tap into this status and automatically change the seats to “Available” when the stops they refer to have been passed? Granted, this doesn’t tell us if the duration the seat is reserved for is after the point where we want to get off but it is certainly an improvement!

I guess if you catch the train regularly you can quickly spot the available seats; but you are used to an imperfect system rather than it being well designed!

When writing information displays:

  • Say what it is (use positive statements)
  • Use an active voice
  • Your objective is to communicate fact – make every word count (it really doesn’t come across as terse!)
  • Consider the environment they will be seen in and cater for any handicaps this introduces.
Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Physical Interfaces | Tagged , , | 1 Comment

Why Google’s Chrome Browser Tabs get it spot on

Google’s Chrome Web browser was released to much fanfare last week. One of the touted features was their redesign of the tabbed interface. They got it spot on, it’s exactly how it should be.

Here’s how Apple do it in Safari (click to enlarge):

Here’s how it’s done in Firefox (click to enlarge):

And here’s it done right in Google’s Chrome (click to enlarge):

Tab panes are used to group together related items and navigate between them. The address bar, the navigation controls and the page that it loads are obviously related. Firefox and Safari have created 2 visually distinct groups; the controls and the page content itself. Whilst It doesn’t take long to realise that changing the tab attached to the controls also changes the page (their close proximity helps) they should all be grouped together so that the behaviour is less surprising to the uninitiated.

By re-arranging the window so that the tab encloses the address bar, the navigation controls AND the page you are browsing, Chrome ties together the entire view, makes the relationship explicit and it just feels more natural.

This approach has other benefits too;

  • Switching tabs is a fairly frequent task – I’ve lost count of the number of times I’ve missed the tab bar and clicked a link in my bookmarks bar. Moving the tabs to the top and leaving the bookmarks bar where it is solves that one!
  • Whilst the tabs are physically further from the content, when the browser is maximised you can take advantage of Fitts’ Law so that selecting them is quicker – possibly even quicker than in their conventional position.
  • Safari supports dragging a tab into a new window; doing this from the top of the window feels more natural – like you are tearing a page from a notebook. Although, Apple’s slick use of animation to produce a mini version of the tab mitigates the worst effects of this.

Whilst writing this post, I have been pondering why the tab bar is where it is on other browsers. I think the most likely explanation is that whilst it isn’t attached to the content it is very close to it. Its proximity gives it the grouping effect and makes the tabs convenient to click. Also, it is probably the approach that required the least re-design! However, I think on balance it’s Google who are right in this case.

I’m really pleased that Google have released Chrome; though whilst I wont be using it (no Mac version!), I think a fresh face in the browser market with new ideas who is willing to rethink existing conventions is something we all should welcome.

Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Software Interfaces | Tagged , , , | Leave a comment