|How Much Documentation Do Applications Need? – A Simple Example|
|Self-explanatory Web Design: How Can Portals be Designed so that they are Easy to Use and that Users Find the Information and Functionality they Need?|
|SAP Reference Lists|
By Gerd Waloszek, SAP User Experience, SAP AG – September 13, 2009; updated: October 12, 2010
Humans are inherently prone to errors and fuzziness. When we talk to each other, slips of the tongue and unclear statements abound, and one might wonder how humans understand each other at all. There are definitely misunderstandings between people all the time, but the real miracle is that most of our conversations go smoothly, even though we select the wrong words, cannot think of a word or name, change the order of words, or break grammatical rules (case, inflection, number, tenses, ...). Of course, some people correct our mistakes like teachers, but most of them do not even seem to notice these slips of the tongue – or at least, they do not point them out to us. All in all, humans seem to be fairly tolerant to the weaknesses of their human dialog partners, but how do they react when their dialog partner is a computer? My personal impression is that we are not as tolerant with computers as we are with humans – at least I am not. In this article, I will first explore the possible reasons for this lack of tolerance and then collect a few well-known rules that can help reduce the number of times our tolerance is put to the test. With this is mind, I will look at two areas where dialog exists between humans and computers: screen texts and system messages.
Screen texts are the computer's primary medium for addressing humans. They come in a number of different guises, such as labels, titles, and longer text passages. Labels characterize input and read-only fields as well as some other controls, while titles describe windows, field groups, tables, table rows and columns, tabs in tabstrips, and so on. Traditionally, longer text passages are rarely found on business screens (with the exception of help texts and online documentation), but since the Web has become ubiquitous, computer screens have become a lot more wordy. In the following, I will present a potpourri of the screen text issues that can disturb and annoy users. The issues apply to more or less all kinds of screen texts.
Screen texts, be they labels, titles, phrases, or longer text passages, that use computer or expert jargon annoy users for a number of reasons – the most common reason probably being that users do not understand them. Other issues comprise texts that are too abstract, uncommon to the domain, ambiguous, or even misleading. All these issues slow users down and can even lead to a breakdown in the dialog which can thus affect how efficiently and effectively the task is performed: Users give up frustrated and annoyed. As users cannot the computer questions (apart from clicking a Help icon or link), they often feel powerless and helpless. This asymmetry of the dialog and the resulting state of mind may explain why users are less tolerant with the computer than they would be with a human dialog partner in a similar situation.
Abbreviations, particularly uncommon ones, also irritate users because they do not understand them. Often, space restrictions make abbreviations necessary, but other design options should be explored first. If more space is not available, at the very least, a legend or a tooltip explaining the meaning of the abbreviation should be provided. Uncommon abbreviations are to be avoided at all costs.
Figure 1: Text that is abbreviated after the translation even though the buttons were enlarged
Figure 2: Text that is abbreviated after the translation without need
Figure 3: Another example of text that is abbreviated after the translation without need
Figure 4: And yet another example of text that is abbreviated after the translation without need
Personally, I am easily annoyed when I am confronted with the peculiarities that result from the translation of the user interface into a different language (for example, from English to German). In some cases, the word choice is strange, in others, it is the word order that seems odd. The most common issue, however, seems to be truncated texts: The translated text is longer than the text in the original language, but as not enough space has been provided, the remainder of the text is cut off. Truncated texts result in incomplete information, and often it is the most relevant part of the original information that is lost. This issue also affects system messages (see below).
Figure 5: Text that has been truncated because of the translation, but what does the application want to tell German users?
My intolerance to mistakes in screen texts also extends to grammatical errors. While the following example refers to a system message – the topic of which is covered in the next section – the basic argument applies to screen texts as well: When I see a message such as "1 files copied" I am embarrassed. A message such as "2 file(s) copied" would be correct, but seems too formal and looks unnatural. Dealing correctly with the cases "one item" and "more than one item" (and "zero items"), would require a little more effort from the programmer but would increase the users' trust in the system. User tests consistently reveal that incorrect texts have a detrimental effect on the users' trust in computer systems.
The shuffler, a combination of text labels and controls for formulating simple queries (or filters), indicates the complexities that designers face when a screen has to be translated into another language: A query that sounds natural in English, may be grammatically incorrect (and might require the order of the screen elements to be changed) if it is directly translated to French or German (see figure 6).
Figure 6: Shuffler in English (left), direct translation to German (center), and translation that would be more appropriate in German (right)
Obviously, it is not "good enough" for users if the system does not talk their "language," if it does not take their mother tongue into account, and if it does not adhere to grammar rules. Particularly in the latter case, the computer makes it clear that it is a machine, not a human being, and users may feel "betrayed" by a system that mimics a human, but does so badly.
Screen texts are more or less static screen elements. In system messages, however, the computer's role in the human-computer dialog is more dynamic. I will look at two types of messages: (1) Messages that refer to the system's state, including its progress in operations, and (2) error messages.
State and progress messages are "kind" system messages: The system is "nice" to the users and informs them what it is doing or going to do, how long an operation will take, when something has been finished, and much more. These messages are generally well received by the human dialog partner – as long as the system is not misleading or even lying and the messages are not getting in the users' way and thus impeding their work
I will use a few examples from the "responsiveness" area to demonstrate what I mean by misleading and lying. Progress bars are good examples of this (in this case, they are called "phony" progress bars). A progress bar that displays "pretend" movement (see figure 7) is definitely cheating users because it gives the illusion of progress even though there is none (the system may even hang). A progress bar that tells users that the process will be finished in less than five seconds, whereas the process actually lasts for another 10 to 30 minutes, is simply lying to the users. After a few minutes, users will become aware of this deception and get angry.
Figure 7: Progress bar (Mac OS X) with an animated bar that may provide the illusion of progress even if there is none
Humans often make imprecise predictions, but we are used to that and can cope with it (more or less...). Developers like to make precise predictions, or better displays, because computers are good at calculations. However, what is the use of a prediction if the numbers are exact but changing rapidly and unpredictably? Users will soon realize this message is just another kind of cheating. It is much better, therefore, to make the prediction (display) less precise and to use human precision (see figure 8). Users will find this approach much more trustworthy.
Figure 8: Different states of a progress bar (Mac OS X) showing time remaining according to "human precision"
Error messages are probably the most critical dialog element in the human-computer dialog – for a number of reasons. Error messages make any problems with the system clearly evident, and there are a number of Websites that collect curious and abstruse examples of error messages (however, the messages on the Websites I looked at seemed to be fake messages...).
System weaknesses show up dramatically through error messages, and there are a number of Websites that collect curious and abstruse ones (on the Websites where I looked, the messages seemed to be fake messages, though...). Of course, faulty or cryptic error message do not do anything to increase the users' trust in the system or increase their tolerance levels for poor system texts – these mistakes are far too obvious and show careless or even brainless design.
In the textbook Designing the User Interface (Shneiderman et al.), I found the following remark on error messages: "Improving error messages is one of the easiest and most effective ways to improve an existing interface."
One of my personal favorites is the "Unknown Error" which comes in many forms and is responsible for quite a number of system or application crashes. It clearly shows that the developers did not invest much time in error handling, and, as a result, the users will be very annoyed about these errors.
Figure 9: This is a typical example of lazy error handling (found on the Internet)
Sometimes it is not just the error that is unknown, but also the application in which it occurred. In other cases, the system seems to know less than it should know: Sometimes I get a message on my Mac because an application quit "unexpectedly," but the reason it did so was because I had forced the quit from its icon in the dock (see figure 10).
Figure 10: The operating system does not seem to know that it was the user who forced the quit – there is no need for sending a report...
There are more reasons why error messages are not favored by users: Many error messages blame or even insult users despite the fact they are – or at least believe themselves to be - not guilty of causing the error. Although it is clear a user may occasionally select an incorrect command, he or she should not be able to crash a correctly programmed application – a crash is the developer's fault, not the user’s. In an ideal world, users should always be able to undo an incorrect step (or multiple incorrect steps). An error message should help users rectify their errors and allow them to undo steps and then proceed correctly. And even if their application or computer crashes, users should still be able to save their valuable work rather than just having to accept that they will lose everything.
After all, the need for error messages that assist users is a variant of the general requirement that a system should be informative and tell users what they need to know to accomplish their tasks.
Figure 11: Some users feel blamed or insulted when then see such a message (BASIC error message on early Microcomputer)
To sum up, users do not consider it "good enough" when the system sends messages that either mislead or lie. Similarly, they do not believe it is "good enough" if the system blames or insults them in its messages. However, it is "perfect" if the system provides sufficient information or even assistance in its messages – even though there may still be room for improvement.
In the textbook Designing the User Interface (Shneiderman et al.), I found the following optimistic statement about messages: "Improved messages will be of the greatest benefit to novice users, but regular users and experienced professionals will also benefit; [...]. As examples of excellence proliferate, complex, obscure, and harsh interfaces will seem increasingly out of place. The crude environments of the past will be replaced gradually by interfaces designed with the users in mind."
To summarize what I have discussed in this article, I would like to provide a number of simple rules that help improve the quality of the computer's role in its dialog with humans and thus the dialog as a whole. Hopefully, applying these well-known rules will make users more tolerant with regards to poor computer-human dialog because they will feel more respected:
In their book The Media Equation, Byron Reeves and Clifford Nass demonstrate that humans often treat computers as if they were human beings and, under certain circumstances, they are even polite to computers. On the other hand, there are also reports of people shouting at their computers or even damaging them (a famous video example of the latter was, however, a fake). Thus, in a number of situations, the users' tolerance for "dialog slips" by the computer is much lower than for human dialog partners. If designers take the design rules listed above into consideration, which may require them to invest more time and care in their work, users should become more tolerant to computer systems and may be more willing to accept one or two imperfections in the human-computer dialog. With enough care, "good enough" may require some effort, but need not necessarily mean that the human-computer dialog has to be perfect – "good enough" will already be "perfect" for human users.