Movements to a target occur in 2 distinct parts: firstly a big movement to get approximately in the right place, followed by a series of fine tuning motions to lock on. You can see these in action – watch your finger as you point at a small object at the far side of the room you are sat in now e.g. a light switch. Chances are you’ll move your arm in a big movement, probably overshoot, then make a series of smaller movements until you are pointing directly at it. Now try it with a bigger object – maybe you have a big TV hanging on the wall. Here you will make the same big arm movement, but because the target is so big you don’t have to make as many (or any) fine tuning motions – so it’s easier to acquire the target.

Lets look at some examples. In all of the below graphics the red box is the target; the dashed line represents the travel from the starting point to the target and the area marked over the target represents the dimension in which the user can decelerate and acquire the target:

Here we have a big target on the far side of the screen, because it’s big it shouldn’t be a problem to click on quickly:

The big target area means that the fine tuning motions aren’t necessary before the cursor comes to rest over the target.

In this next example we have a much smaller target on the far side of the screen so it’s going to be harder:

Because we have to move the cursor a long way and it’s a small target it’s going to take a series of fine tuning movements before the pointer is correctly aimed at the target.

However, if the small target is close by – it is less of a problem to hit because the initial movement to get there is smaller – reducing the risk of needing to correct an overshot.

It is important to bear in mind that for irregular shaped targets, size is relative to the plane of movement. In the following example, if you are moving to the target horizontally the button is quite big, however, when approaching from above or below the target presents a much smaller area.

In addition to the size of an object, we can make a target easier to acquire by placing it at the edges or corner of the screen. This is because they are “infinitely targetable”; that is – you have an ‘invisible barrier’ to work against. You make the initial big movement then you don’t need to make the smaller fine tuning motions as any excess overshoot is ignored.

This is used by both of the major OS vendors to good effect:

Mac OS X has the Dock at the bottom of the screen; this is infinitely targetable as you can’t point your cursor at a point lower than the dock so it’s always clickable:

On Windows, the Start menu is in the bottom left corner of the screen – the corner is infinitely targetable as if you make a big mouse gesture towards that corner you will always end up over the start menu button.

One of the big differences between Mac OS X and Windows is the location of program menus. Mac OS X has the menu across the top of the screen whereas Windows has them attached to individual application windows. Fitts’ Law shows that in many cases the Mac approach is superior: On the Mac you throw your pointer to the top of the screen and you automatically end up over the menu. On Windows you have to go through the full sequence of making a big movement, then smaller correcting movements before you end up over the menu. There is no region of infinite targetabiltiy.

However, the Mac’s approach is starting to see limitations. Whilst it is infinitely targetable, Fitts’ Law includes a measure of your current location. As large monitors and multiple monitor set ups become more and more common, the Mac user is having to travel a significant distance to reach the menu at the top of the screen, potentially outweighing the time saved by reducing the need for finer movements.

Fitts’ Law Applied

One of the biggest disappointments for web developers is that we can’t easily take advantage of the edges and corners of the browser window. So we have no infinitely targetable areas we can use to our advantage. So what can we do:

• Make your links bigger by increasing the targetable area. Use padding around links so that the user has a little forgiveness around the text they are trying to click
• When you have several clickable items or links together either make the items larger or space them out a little. Page navigation links on search results is very often done badly. For example, this results page has far too much too close together: Whereas Amazon do a much better job, nicely separating the individual links:
• Make the button a user is most likely (or most wanted) to click bigger. E.g. Make your OK button bigger:
• Group actions together – if related interactions are near to each other this not only increases their relatedness in the eyes of the user but also reduces the mouse movements necessary to move between them

Finally, don’t be afraid of experimenting! 37 Signals have a really interesting use of Fitts’ Law on their “Signup” button for Sortfolio – as you hover over the button it grows and shows more information – so as you begin to make the fine tuning movements to precisely acquire the button, the need for them is reduced by the target button growing! Fantastic stuff!

The link above proposes 3 competing technologies that could unseat the QWERTY keyboard as the interface mechanism of choice, especially on the iPad. I’d like to respond to each of them before making my point.

Swype

This one isn’t really replacing qwerty as such – rather providing an alternative mechanism to typing individual keys. This is an interesting technology, but I think it has a number of flaws:

• On the iPad this would be a really poor technology. On a small screen – great – it reduces the need to hit a tiny individual target key. But on the iPad – a device with a keyboard almost the same size as on a MacBook (and much bigger than many netbooks) you’d have to slide your finger way too far for this to be pleasant to use. Even one-handed I suspect I would rather type normally
• Another problem is that unless you know where to slide your finger to (i.e. you know the qwerty keyboard well) you will struggle. If you watch the video in the above link the user’s hand is obscuring a good amount of the keyboard. Users who aren’t that familiar with qwerty wont be able to make those smooth meaningful gestures that can be quickly interpreted by the software.
• It is also quite confusing to a non-familiar user. The UI presents keyboard style buttons. But you never “press” these buttons, you slide across them – this creates a an uncomfortable conflict between the visual representation and the desired interaction.

So in a nutshell Swype doesn’t remove qwerty anyway – just gives a new and interesting way to interact with it. But I’d like to see this develop further – maybe in time it will take off. Mobile phones are a hotbed of interface innovation so who knows – if it can gain traction here and the problems I have identified above can be mitigated then maybe it will become widely used.

Thick Buttons

The author is ill informed here. Thick Buttons is just a poor copy of a technology the iPad already has! Thick Buttons implementation is continually resizing the buttons on the screen based on a key’s probability of being struck next. This makes them jump around and be a moving target whilst you are trying to type! I can’t imagine this being anything other than maddening! The iPad’s OS has a superior implementation – the hit zone for the buttons resizes rather than the buttons themselves.

This video was released by Apple around the time when the iPhone was released – have a look at around the 2:40 mark for a demonstration of Apple’s implementation:

Phonetic Typing

Hmm. I can’t really see that approach taking off with the average user! Even the original author discounts this one! Probably more likely to remain as an academic exercise!

My take

How much time do you have invested in the qwerty keyboard? Years? Decades? For the vast majority of us it’s the only keyboard we’ve ever known (not withstanding pecking at a number pad on our mobiles back in the pre-iPhone days!) The DVORAK keyboard, despite being shown to increase typing speed, has gained little traction. To those of us who have been typing for so long, our fingers just “know” where to go. It’s almost muscle memory. We don’t think about typing we just do it. With practice we can even type reasonably fast on tiny phone qwerty keyboards.

So what might ultimately replace qwerty? Speech recognition? It’s the holy grail of data input. But even if the speech recognition was perfect – compensating for regional dialects, accents and slang. Even then, would you want to be in a office full of people talking in to their computer? The noise would be unworkable and how would you write personal emails?!

Could subvocal recognition (if it can develop far enough) overcome this drawback? Quite possibly, but I certainly type differently to how I speak. Would I want my written word more closely match my spoken word? No, not really. The written word doesn’t have the tone and inflections used in speech, so we use different words to achieve the same ends.

We know there are better ways of inputting data. We know the DVORAK exists. But how many of us want to learn it? How many of us have time start again? We introduce children to the qwerty keyboard when they are so young. By the time they are old enough to do anything about it they might have over 15 years of practice! Despite its flaws, can many people say their text entry is slow enough to warrant the learning curve? Even then, would you consider a different input mechanism or just look at ways to speed up your typing?
Then if you did learn another input mechanism – how would you cope when using someone else’s computer? There’s a lot of qwerty keyboards out there!

Inertia is a powerful thing. When something has been around for over 100 years it’s built up a lot of inertia. So, it will take something several orders of magnitude faster, trivially simple to use and quick to master before anything stands a chance of unseating qwerty. But I doubt it will be in my lifetime.

The same 80/20 split can be seen in many places; management, economics, software/interface design, quality control systems and many more places. Whilst the rule is called the 80/20 Rule – the actual percentages are not all that important: 90/10, 70/30, 80/20 are all valid variations. Indeed – it is perfectly valid to say 70/10 as there is no requirement that the two sides add up to 100 – the important thing is the principle that a large number of outputs are determined by a relatively small number of inputs.

So using the 80/20 rule we can say:

• 80% of users only use 20% of features
• 80% of bugs are caused by 20% of the code
• 80% of development time is spent on 20% of the code

This rule of thumb is useful when focusing our time and efforts on improving our products. We first need to find out what our most important 20% is. The easiest approach to this is to simply ask customers what their favourite features are or maybe observe them using the product. Developers of web applications could use tracking software such as Google Analytics to provide detailed information on which pages customers are accessing the most. Alternatively, simple logging could be added to a desktop or web application.

Armed with this information we will know which 20% of features provide 80% of the value of our products. We can then spend time polishing these features rather than diverting efforts on to rarely used features. This approach will lead to the greatest improvements and make the biggest contributions to customer satisfaction. If we make a change that benefits 80% of our customers then that’s a big win and is going to generate a lot of good feelings. Much more so than adding a similar scoped feature to an area that falls under the less used category.

This isn’t to say we should completely neglect the less frequently used features – that proportion is likely to be very important when it is needed – but when we are faced with limited time and resources, focussing our efforts on the most used 20% will gain a disproportionately large benefit to our product and users. It is rarely considered a bad thing by users when we make improvements to the benefit of our most used and popular features!

Lets start off by getting something out of the way. Don’t use alert boxes. They are jarring, often steal focus, interrupt the flow of what a user is doing (which is kinda their idea but that’s not my point) and are generally unpleasant. It’s like you are shouting something at the user. They tend to be overused (Crystal Reports XI I’m looking at you…) when they really should be reserved for the most critical of information.

So, always work on the assumption that there is a better way. Here’s some typical uses:

• Validation Errors: If a field is invalid, don’t pop up an alert box; simply highlight the field that has the error (e.g. by putting a border around it) and show an explanation next to it. There might be a reason they haven’t filled in the box correctly (e.g. returning to it later) so making the user dismiss an alert box is annoying
• Information Messages: Telling a user something has changed. Ask yourself – do they care – do they need to know? Can they (or do they need to) do anything about it. If not then you don’t need to interrupt work flow to tell the user about it! If the user doesn’t need to know and can’t do anything about it but you STILL want to tell them – this is a strong contender for a log file message!
• Completed MessagesThese are when an alert box is thrown up to tell the user that something is complete. Is it that important that you stop the user doing what they were doing; make them dismiss an alert box before allowing them to continue just to tell them that something is complete? I suspect in most case it isn’t that important. Replace the alert by maybe showing a subtle message in the tool bar (or a Growl message for the Mac). When a CD has finished importing iTunes plays a sound. You know it’s done – but you don’t need to do anything about it if you don’t want.

Remember that you are interrupting the user. The things that you want to know about and be alerted to whilst programming the app are likely to be very different to the things the end user wants to know about! Put yourself in their situation and ask yourself if you would like to be interrupted for that reason. So let’s have a look at a couple of valid alert box uses:

• “You have been inactive and will be logged out if you don’t start using the system”. This use is valid. The user is alerted to the fact that their inaction is going to have a consequence. The user needs interrupting for this. It’s like telling you “if you don’t get a move on you’ll miss the bus”
• “The operation could not be completed because….”. This one is a grey area. It is a valid use – the user expected the operation to complete so they need to be interrupted to say it didn’t. However, does it require their immediate attention? Can you say with any degree of certainty that your alert is more important than what they are working on in another window? Probably not. So use with caution

There aren’t many scenarios where an alert box is the best choice. But if you must have an one for whatever reason, bear the following in mind:

• People probably wont read them – they are often just OK’d without being read
• So, keep them short
• They are modal so the user wont be able to follow any instructions once they’ve dismissed the message. If your instructions are more than 1/2 steps make sure there’s a way to see the instructions after the alert box has gone
• There probably is a better way that you haven’t thought of yet

These results show that the apparent usability is less correlated with the inherent usability compared to the apparent beauty… This suggests that the user may be strongly affected by the aesthetic aspect of the interface even when they try to evaluate the interface in its functional aspects and it is suggested that the interface designers should strive not only to improve the inherent usability but also brush up the apparent usability or the aesthetic aspect of the interface.

The aesthetics of a product have far reaching consequences. The desire to posses attractive items is an innate part of the human condition and we should use this to our advantage. All other things being equal, when comparing two products:

• The attractive product will be perceived as easier to use. Ease of use is often a criteria in purchase decisions – easy to use products require less training and support. So by improving the attractiveness it increases the perceived ease of use – improving the chances of making a sale
• Users will be more likely to develop positive feelings towards the attractive product. This can lead to:
  • Positive reviews – leading to more sales
  • They’ll tell their friends – resulting in more sales leads
  • They’ll tolerate faults more – reducing support calls
• The attractive product will be perceived as of higher quality
• And, perhaps most importantly; customers may overlook feature deficiencies so they get to use the more attractive product

Spending time and money on the outward appearance of your product makes a lot of sense and that it can more than pay for itself in increased sales. So, if users are complaining that your product isn’t user friendly it might not be a problem with the interface mechanics – it might be their way of saying that it isn’t pretty enough!

During this second journey I started thinking about why so many had been damaged and how can you stop things from being damaged in transit. There are 2 main approaches to reducing damage:

• Make the product physically tougher so it can withstand harder knocks
• Add more protective packaging

Unfortunately, both of these options increase costs. Making the product tougher also adds to its weight, size, appearance etc. so it might not even be an option in all cases.

So, what about increasing the protection from the packaging? Now, a certain amount of returned products due to damage is to be expected – no matter what you do a certain amount of damage is inevitable. So a manufacturer must carefully trade off the cost of the packaging vs the expected cost of returns at any given level of protection.

My radiator was actually pretty well packaged; covered in bubble wrap; thick corrugated card to protect the ends then plastic corner pieces to protect the corners. So, I wouldn’t think adding more protection would be cost effective (then again I suspect that 2 in 3 radiators being damaged can’t be acceptable either!)

Examining the damage it was obvious that they taken a knock whilst being carried/moved. As I drove along I thought about the struggle it had been to carry and load them in to my car. Then it struck me – the problem isn’t with the radiators or the packaging – it’s a problem with the usability of the package as a whole!

These things are bulky – not desperately heavy; but large – you need 2 people to carry them. The problem is – there’s nothing to get hold of. When packaged they are completely smooth – so you need to get your hands underneath them to carry them properly – and trust me after a few squashed fingers you soon stop that! This leaves you with trying to carry them by gripping the edges. When doing this there is a tendency to drop them as you lose your grip when putting them down. You can just imagine how many get dinked by a delivery driver in a rush to unload dozens of them!

I suspect that if some handles were added to the top and sides of the radiator that the number of returns due to damage would reduce markedly. This could be done cheaply by wrapping some heavy duty tape around the edges of the radiator but leaving some loops of tape unstuck to form some handles. This would make the radiator easier to handle and become less likely to take a knock when being carried.

If you find that your products are getting damaged and your returns rate is unacceptably high; don’t forget to take in to account the period between the factory and the store. Usability doesn’t just relate to the product itself; the whole experience including the packaging are worthy of attention and if a slight change to your packaging reduces returns that goes straight on the bottom line!

So I went over to their site for a look:

Nice and clean looking. I watched the video and was sold – sign me up! But, this is where the trouble started. The service is subscription based (with a free option). So I started looking for a link so I could “sign up”. There’s a big download button…. no that’s not it (I need to sign up before I download anything surely!)…. there’s the log in fields in the top corner (so I certainly need to sign up before I can use those) …. but nope no option to sign up there either…. a big list of links at the bottom of the page… still no sign of a “Sign Up” button!

The problem is the wording of the main call to action (the big button in the middle) – it says “Download Dropbox”. However, this is not what my mental model says my next step should be.

A mental model is built up in your mind as a representation of how you perceive something works in the real world. It is based on conventions and previous experiences. It gives your brain a short cut to understand new things. It’s why people who use computers a lot “know” how software they’ve never used before works – their mental model sets expectations and as long as they are met it’s easy to just focus on the differences.

In this case – my mental model was based on using many web based systems in the past. I expected the following:

1. Sign up
2. Download software (if applicable)
3. Start using the service

When your mental model isn’t matched by what you encounter, it takes some time whilst your brain reconstructs a new model based on its input. But your brain doesn’t like forming new models so all along the way it’s trying it’s hardest to try and graft the new information on to the old model. This takes time and leads to feelings of confusion whilst it’s going on.

The big button in the middle of the page is great – it should be obvious that you click it – but because it didn’t match my mental model the thought didn’t occur to me immediately. By saying “Download Dropbox” it is forcing an implementation detail to be my next logical thought. But it isn’t.

It turns out that you actually sign up when you run the application the first time through the software itself. Given this, I accept labelling the button “Sign Up” would also be wrong. I’d recommend that the main call to action button should be relabelled “Get Started” (or similar) taking you to a page that explains how to install and sign up. Then maybe have a separate link for people who know how it works and just want to grab the installer. I think this would make it clearer what you should do next, regardless of any preconceptions.

In fairness, when you click the “Download Dropbox” link you do get shown a list of your next steps for installing the product. However, even this page doesn’t tell you that you sign up during the first run!

This example illustrates that when you are asking people to do something, before you’ve even asked them anything they have built up an expectation of what you will say. If your proposition does not match their expectation they will have a few moments when they feel confused – and confused people often don’t make the decisions you want!

The 2 buttons in the above picture are for a toilet flush. One button does a big flush using lots of water; the other does a smaller flush using less. Using a small flush when that’s all that is needed avoids wasting water and that’s a good thing.

As you can see the 2 buttons are of different sizes. As an interface designer this poses us a problem – which button should trigger which flush? There are 2 options:

• The big button is for a big flush and the small button is for a small flush
• Or, we assume the small flush will be used more often so it should have the bigger button to make it easier to use. The less frequently used big flush can have the smaller button.

The problem is that neither approach is ‘wrong’ – each is a valid implementation. That’s why we test – once we have seen how people naturally interact with our product we know which decision we should take.

The above example is quite trivial but it illustrates the point – for any given interaction there are multiple valid interpretations. If we want our products to be enjoyable we need to know which interpretation the majority of people hold. This is especially important for new products – as we develop them we are totally immersed – living and breathing it every day (and night!). We know how it works. When we created the interface, we could see no other way that it could be interpreted. However, as soon as we see someone use our product for the 1st time, all that certainty can be washed away in an instant.

Testing reveals the truth. We don’t test to be proven right or wrong; we test to see how things are.

Location

What is it? Organising by physical location; either geographically or a location in space. For example, this could be showing landmarks on a map or sorting objects as nearest to furthest relative to your position.
When should you use it? When giving directions (e.g. order you will encounter landmarks) and whenever relative position is important e.g. landmarks on a map

Alphabet

What is it? Ordering alphabetically, for example how the dictionary or phone book sorts entries.
When should you use it?Whenever efficient random access is needed (applies to most reference material – dictionaries, encyclopaedias, book indexes etc.). It should also be used as a back up when no other sorting strategy makes sense.

Time

What is it? Sorting by chronological order. For example Cinema Schedules, Bus Timetables, Time lines of historical events etc.
When should you use it? Whenever a time based order of events is needed e.g. cooking instructions; when comparing events over a period of time (especially if there is an element of causation between events) or when things happen at set times.

Category

What is it? Grouping by a shared similarity. For example; Churches with and without a spire, Subject in a book shop such as fiction, non-fiction or autobiographies, departments in a department store etc.
When should you use it? When people will naturally look for something by category – e.g. if you want a new blender you would expect it to be grouped with other kitchen appliances. Bear in mind categorical grouping has weaknesses:

• Not everyone will group things the same. This is especially a problem where there is overlap between categories – for example should a waterproof shower radio be in the electricals or bathroom department?
• Categories can break down when there are large numbers of items within each category; leading to sub-categories and sub-sub-categories. This can make things even harder to find especially when compounded by the above differences in categorisation!

Continuum

What is it? Grouping by a magnitude e.g. Best to Worst, lowest to highest, happy to unhappy etc. For example Football league tables, Star Ratings on products, energy efficiency, size etc.
When should you use it? Use continuum when a shared measurement to compare things is available that will naturally be used in comparisons by the user

Conclusion

Don’t be afraid of using more than one hat rack at a time – you could have items sorted by category then within each category you could sort alphabetically.

Just remember that you are trying to present the information in a way that is accessible to the user. Usually this means you may have to allow them multiple ways to view the data. This leads to more usable products as you will be allowing your user to see the information in a way that is relevant to their current goals rather than just the way you thought of when you designed it.

If you are having trouble guessing where/how your information should be sorted and/or grouped – leave a comment and I’ll try and help out!