EasyChart: a Usability Teaching Tool to Demonstrate Interface Design from Hell
Do you have students or programmers who don't quite seem to "get" the importance of following the rules to make an interface that is easy for the end user to deal with? Maybe you should make them use EasyChart. Created as an educational tool to deliberately break every design usability rule, it just might lead to an "a-ha" awakening. Eliana Stavrou walks you through some telling examples from the program.
EasyChart: a Usability Teaching Tool to Demonstrate Interface Design from Hell - Help Documentation (Page 3 of 4 )
What is the first thing you do when you use an application for the first time? You search the Help documentation for a quick introduction to the system. Well, notice the main menu bar. At first glance, you can not locate a Help option. You recognize two main options, the “File” and “Edit” options; a “Games” option that has nothing to do with the operation of the tool; and a “Go” option that does not give you any hint as to what is in the menu.
This menu breaks the “Aesthetic and minimalist design” principle at a high level, because it provides irrelevant information that confuses the user. It also violates the “Error prevention” principle, because the “Go” option misleads the user who is trying to find a specific task that may not be there, thus making an error.
Anyhow, you decide to explore the “Go” option and, if you are lucky, find information to use the tool.
As you can see from the previous figure, there is a sub-option called Assistance. The selection of “Assistance” rather that “Help” violates the “Consistency” and “Match between system and the real world” principles; Help is more common and recognizable by all users as it relates to real-world situations.
Now you expect the Help window to be launched, but instead you get the following message:
The message is confusing, because on the one hand it informs you that Help is unavailable, and on the other hand it provides a Help button that reloads the same dialogue! The button “Never mind” closes the message, although its name does not indicate the close action. This message violates a bunch of usability design principles: the “Help and documentation” because it doesn't provide either; the “Visibility of system status” because it does not provide any title to the message to indicate feedback about the action taken; and the “Match between system and the real world” and “Aesthetic and minimalist design” principles due to the selection of the buttons’ names.