Usability shouldn’t be a drag

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