Bad UI of the Week: Read This (OK/Cancel)
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Bad UI 10: Read This (OK/Cancel)
Dialog boxes are a pet hate of mine. They are quite possibly the most overused user interface element ever created. Since they are so overused, you might have thought that people would have worked out how to use them competently, but it seems not.
My favorite example is a cash machine near where I live. Wales is a bilingual country, where a lot of things are written in Welsh as well as English. When you put your card in a cash machine, you’re presented with a long question, and two options: Yes or No. You need to read this question every time, because sometimes it asks if you want the UI in English, and sometimes if you want it in Welsh.
What’s wrong with this interface? You actually need to read the question. If the options were "English" and "Welsh," you could completely ignore the question and skip to the right button immediately. Of course, with only these two options, the programmer could just choose one language as the default, and offer an option to switch to the other language when you enter the PIN. Even better, the program could ask you the question once and store your reply on your card (or with your account details on the server), so the machine would always use the correct language when you insert your card.
This is a particularly bad example, but dialog boxes are used in a similar way in a lot of applications. In Windows, the OK/Cancel dialog is almost ubiquitous. The real fun comes from some applications saying "Quit without saving, OK/Cancel" and others "Save changes before exiting, OK/Cancel."
Putting simple yes or no options in a dialog box ignores one very important fact; namely, that users almost never actually bother to read the text. When they do, they read it quickly and may miss something important. When a user quits an application, it might pop up a dialog box asking "Are you sure you want to quit without saving? (Yes/No)" or "Do you want to save before exiting? (Yes/No)." The user recognizes some version of save in either message and probably won’t bother reading the rest in detail, with a 50% chance of hitting the right button.
Instead of Yes/No, the buttons could be Save/Quit (or Save/Don’t Save). In this case, it wouldn’t matter what the rest of the text said. The user can infer the long description from the verbs in the button labels. This approach also helps save time for the user, which is important in a good user interface.
When it comes to dialog boxes, there’s an almost religious debate between whether OK should go on the left or right. As with many other UI problems, this issue comes down partially to context and partially to locale. If you’re reading this article on the main Informit site, there’s a good chance that you speak (or at least read) English. One of the defining features of English and related languages is that letters are arranged in order left to right. People who learn English as their first language tend to regard movement to the left as backward and to the right as forward. This isn’t the case for all languages; some are read right to left, some top to bottom.
This principle gives a good clue as the order in which options in a dialog box should be presented. In a left-to-right reading locale, the option on the left will be perceived as "back" or "undo," while the one on the right will be perceived as "proceed." The placement used for each option is very context-specific. In the previous example, saving is probably the "forward" option, quitting without saving is the "backward" option, and aborting the quit operation is neutral, placed in the middle. This gives the following order for our newly phrased dialog box options: Don’t Save/Cancel/Save.
Another good rule is that options with the biggest potential for data loss should be the furthest "backward" (left, in English-speaking locales). People usually want the "forward" option, so they’re likely to get used to clicking that one. Therefore, it’s important to minimize the effect of clicking the "forward" button by accident. Consider the example of formatting a disk. It would seem that, in a confirmation dialog, the "proceed" option should be on the right. In this case, however, the "proceed" option can result in the loss of a lot of data, and therefore should possibly be on the left. Either way, the default option should be to cancel.
The blame for many bad uses of dialog boxes rests firmly with the creators of toolkits, who make it much easier to display a yes/no dialog than a more appropriate user interface. Programmers following the path of least resistance can end up designing some very bad interfaces because of this practice. The mark of a good UI toolkit is that it makes it easier to design good user interfaces than bad ones, but good toolkits are hard to find.