How to write an alert box

Alert box saying "I only exist to annoy you"
Alert boxes are a user interface element that pops up to alert the user of some critical piece of information. This post explains how to write them.

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
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

Aesthetic Usability Effect

The aesthetic usability effect is where a user will perceive an attractive product as easier to use than an ugly one. It doesn’t actually matter if they are easier to use or not they are perceived as such so users will make subconscious concessions and overlook many difficulties. The seminal work on this principle is “Apparent usability vs. inherent usability: experimental analysis on the determinants of the apparent usability”. This is available for ACM members to download from the ACM Portal (If anyone knows of a freely available source for this paper please share it in the comments!). The conclusion from their abstract nicely sums things up though:

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!

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

Reducing Damage Through Usability

I spent my weekend installing a new central heating system. When I unpacked one of the radiators (the largest one at 1.2m x 0.5m ) it was damaged. Most of the radiators had the odd dent in the grills but could easily bent back in to shape. This one however had been in the wars so it had to go back. A trip to Toolstation later and I was unpacking its replacement. This one was even more damaged than the last! Feeling stupid for not checking it out in the shop; I made another 40 minute round trip.

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!

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

Call to Action vs Mental Models

After reading John Gruber’s post An Ode to DiskWarrior, SuperDuper, and Dropbox over at Daring Fireball, I decided to give Dropbox a go.

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!

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

Why We Test

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.

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

Five Hat Racks

The Five Hat Racks was first developed by Richard Saul Wurman in his book Information Anxiety. It’s a bizarre name, but makes sense: the hats are information…. hat racks organise hats…. and there are 5 ways to do it. Fine, call it what you like – at least it’s memorable! In a nutshell, there are 5 ways to organise information: By Location, Alphabet, Time, Category and Continuum. Every way you can think of to organise data will fit in to one of those groupings.

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!

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

Leading the Eyes

Every good magician knows how to lead an audience’s eyes with their gestures. This allows them to make the audience look in one direction, and whilst their gaze is averted, the magician is free to perform a sleight of hand or develop his illusion.

This same effect can be used in design. Here in the UK, or at least near where I live, pedestrian road crossings are being replaced with a new generation that exploits this principle. It’s going to save lives.

The old generation had a button on the pole to start the crossing timer, then you looked across to the other side of the road to above head height where the green/red man (Walk/Don’t Walk) display was located:

Press the button on the pole

Press the button on the pole...

Then look away from the traffic

...then look away from the traffic

The new generation have the green/red man located on the pole, but crucially, your attention is directed so you are forced to look in the direction of the oncoming traffic:

New control has the wait signal in line of sight of the oncoming traffic

New control has the wait signal in line of sight of the oncoming traffic


This is fantastic, by moving the interface element that has your attention, it puts a secondary element (the oncoming traffic) in your peripheral vision. Personally, I’d argue the oncoming traffic shouldn’t be the secondary element – cars hurt more than crossing timers….

You can apply this same principle when designing software interfaces:

  • Spend time thinking about what parts of your interface will have your users attention then carefully position these so that other events can occur within the same field of vision
  • Progress indicators guide a users eyes from left to right as the percentage complete increases. Use this to direct a user’s gaze to the next element they will interact with – e.g. the ‘next’ button that will become enabled or a region that will fill with content
  • Group conceptually related elements. When laying out your interface if related controls are grouped together, your software will feel more fluid. People will look near related controls first and they’ll be happy if they consistently find things where they expect them to be.
  • If you need to lead someone’s eyes to an element that is not currently visible … make sure that you scroll it in to view!
Share this post:
  • Add to favorites
  • email
  • Digg
  • Reddit
  • del.icio.us
  • Slashdot
  • Google Bookmarks
  • Technorati
  • HackerNews
  • StumbleUpon
  • Twitter
Posted in Physical Interfaces | Tagged , | Leave a comment

iLife and the Untitled Document Syndrome

There’s a fantastic article over at Daring Fireball about the friction of saving an ‘Untitled Document’ – It’s so true! Well worth a read.

I completely agree with his observations about the iLife suite. Both iTunes and iPhoto abstract away the location of their actual files from the user. Recent switchers to the Mac have a really hard time with this concept – “But where are my files?!” they cry!

The files are there; if you really must see them they are easily findable. The uncomfortable leap of faith comes with letting go; not caring where they are physically located. The files are an implementation detail – what you as a user care about is can you find the photo or song in order to use it. In both cases, an app specifically designed to manage that kind of media makes for a much better experience than a general purpose hierarchical directory browser. If you then need a copy of that file for whatever reason – just drag it out of the app on to the desktop then you can use and abuse it at your leisure – safe in the knowledge that the appropriate iApp is keeping the originals safe.

I remember going through the transition myself and it is an odd feeling for someone accustomed to managing their own data. But, once you let go it’s very liberating!

Anyway, without further ado, over to Daring Fireball: Untitled Document Syndrome

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

7 Ways to Annoy Your Users

  1. Your users will probably mess things up. Some are just down right stupid. Don’t trust anything they say, it is probably a mistake. The best way to deal with this sort problem is to ask them lots of questions, even when it’s obvious they meant to do what they just did. Are you sure you want to do this? Absolutely sure? This will interrupt their workflow so much that they wont have time to do any damage. Or work. Which is probably for the best.
  2. Make sure any text in your application is as verbose as possible, your users will appreciate having something to read. So avoid short labels such as “User Name” they want to see descriptive text like “Please type in your username in this text box over here:”
  3. Make careless errors throughout. Where possible make any choices ambiguous so that they don’t know what the impact of decisions will be. You can also save time by not doing any spell checking on your application or worrying about how things line up on the page in to natural groupings.
  4. Your users have all the time in the world to trawl down long lists of data. Any mechanism for filtering and sorting that data would lead to confusion so it’s probably best left out.
  5. Avoid any form of established conventions – it will probably be obvious what you meant. Whilst you are at it, fit as much information on one page as physically possible and don’t worry about its location either. Users will almost certainly be able to spot the pertinent piece of information amongst all the clutter. If you want something to aspire to, John Gruber found this beauty. I think we all can learn from that!
  6. Don’t provide any easy way of getting data out of your application. Why would users want to when they can use the features of your app? If they want to do advanced work with their data using specialist tools then that’s an opportunity for you to enhance your app! They can just wait until you’ve implemented those features (obviously, once you’ve charged them for the privilege!)
  7. Treat your users as criminals by making sure you have draconian security measures in place. Bonus marks if your app dials-home every time it is run, just in case the user has stolen it since the last time they ran it. Of course, it’s better to devote time to making a poor product hard to steal than releasing a quality product that people are happy to pay for!

If you were in any doubt; the above is very much written tongue in cheek. However, the amount of times I’ve seen these mistakes in the wild you’d think that people were deliberately trying to alienate their customers and users or taking the above seriously!

I’d be interested to hear of things that you have encountered in software that almost seem like they were added for the sole purpose of annoying you!

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

The Importance of Conventions

Conventions are important. They emerge as the ‘way things are done’. As such, when we see a control on a device, we apply our previous knowledge of similar systems and make assumptions about what will happen when the control is activated. The more experience you have in a particular field, the more conventions you know. The more conventions you know, the quicker you are at learning something new; but only as long as the conventions are followed.

When you held your first MP3 player you (probably!) instinctively knew how to play and pause a track. You’d never used one before, but you knew how to do this because the manufacturer correctly followed the control conventions from CD players, which in turn had followed the conventions of cassette players. You didn’t need to learn anything new.

A convention has built up for audio playback that vertical bars are used for volume controls and both Windows XP and Mac OS X use them. This fits in with previous conventions, audio mixing desks have vertical sliders too. It also has a good affordance – you push the slider up to turn the volume up and pull it down to turn it down.

Horizontal bars, by convention, are used for indicating the progress of a track. For example, in iTunes, the shaded area represents played audio, the unshaded area represents unplayed and the diamond is the current position in the file:

Other applications follow similar conventions, so why, when designing the iPhone’s volume control did Apple do this?:

To my eyes, the controls at the bottom are skip back, pause, skip forwards then a track position indicator. It even follows all the conventions: It’s horizontal, it has a shaded area to show the elapsed audio, an unshaded area to represent the unplayed and a marker to show the current track position! Fantastic, until you try and use it to skip to the end of a track and then painfully find out it’s the volume control! I’ve seen so many people do this when showing them my iPhone – I probably should warn them actually!

So, what could Apple have done to follow the convention and have a vertical slider?

  1. Use a vertical volume slider running down the side of the screen
  2. Have a smaller slider to the height of the control pane
  3. Have a pop up volume control

Ok, 1 is just ugly. We don’t do ugly so that one can be discounted. Option 2 sacrifices fidelity of control (or would at best make it fiddly) and for something as personal as volume this would be unacceptable. Also, 1 and 2 would stop the interface looking nicely balanced and symmetrical which wouldn’t do! So that leaves us with option 3. This is no good either as it makes changing the volume a 2 step process and for a common interaction like changing the volume this would be annoying!

So, it appears Apple had a legitimate reason to ignore the convention – a tall thin screen makes a horizontal volume control the best choice. However, where they went wrong is that they broke a convention but then kept it secret until you discover it through making a mistake! They should have done something like this:


This simple addition of volume icons removes any questions over what the slider does and that is worth the price of a slight reduction in slider length.

We notice when conventions aren’t followed and get tripped up. This doesn’t mean it’s wrong to break them as long as your reasons are good and you make it clear to your user that you have done so!

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