Archive for August, 2008

Stalemate – Providing Helpful Help

Wednesday, August 6th, 2008

I am sitting on a plane, and decided to have a game of chess with the on-board entertainment system. The player is required to first select the piece to move, and then the set of possible destinations for that piece are highlighted. The player then selects one of the destinations. At some point I selected a piece by accident. I now wanted to cancel that selection and move another piece. After some fumbling I did discover that it is possible to unselect the selected piece. It is performed by selecting the current location of the selected piece. This is not particularly intuitive, but it is easy to do once you know how.

During this fumbling period I decided to consult the games built-in help facility. I was disappointed. The help feature contained a lot of information on the rules of chess and even some interesting suggestions on tactics. However it failed to tell me how to use this particular implementation of the game. Most people who choose to play a game of chess against a computer probably already know what the legal moves are. Had I wanted to learn openings from the grand masters, I would have bought a book in the airport. However, no amount of chess expertise will tell me how to unselect the selected piece. When authoring the help they should have focused on the application specific knowledge first. The domain knowledge should be considered an optional extra. There are many places where the player can get information on how to play chess, but the built-in help is the only place that can tell the player which buttons do what in this game.

I have also seen this problem on a lung ventilator. The machine used an on-screen icon that I could not decipher. When I consulted the help, which was quite lengthy, I found medical definitions of the breathing patterns that the machine used. This is information carried in many medical text books. The meaning of the mysterious icon was not defined, and again, that is not something I could have learned on another machine, or investigated with a web search.
So when you are building help, focus on the things that will be new to your user, especially if your device or application does it differently to applications already familiar to the user population.

The second thing to bear in mind when authoring help documentation is that the more text you put on the screen, the less likely it is that someone will read it. Try to be brief, and focus on the areas where the user is actually likely to need help. Some help systems try to be complete, and in the process include paragraphs describing every button and option in the system. If a large percentage of these are easy to use, then there is a danger that the really useful help is lost in a sea of text about things that are already obvious to the user.

Now back to that Zukertort opening …