Introduction The visual nature of AmigaOS has always encouraged the use of Graphical User Interfaces (GUIs) as primary means of interaction between the user and software. It did take some time to define and refine the direction in which the Amiga GUI-programming API was heading, including a complete false start (the 1.x Intuition) and a cul-de-sac called GadTools. Surely the programmer is now much better-off with BOOPSI/ReAction; yet the power, sophistication and comfort of the toolkit does not guarantee anything. The quality of the GUI is determined by the quality of its designer’s thinking – the toolkit itself is a secondary factor. You can make a lousy piece of GUI with ReAction, MUI or Zune just the same! This article focuses on common GUI design problems because even the greatest features will come to nothing if the application behaves or speaks rubbish. I’ve picked fifteen particular problems in five problem areas; I may add some more in the future if there is interest. The article is based on a rather extensive research and distills material from many sources, of which the most helpful (and the least academic) is probably Jeff Johnson’s GUI Bloopers 2.0, a book which I can recommend as a perfect reference material for further study. GUIs are designed for (and by) humans, so the quality of the user interface can be perceived in a subjective way. Rather than preaching what is good and what is bad (I have no authority to do that anyway), this article tries to explain why a particular solution may degrade user experience or hamper workflow. To illustrate my point, I use examples from real Amiga software wherever possible. This is not to criticize or deride the individual program authors, so don't get offended if you find your software being picked at here. The idea is to help you improve your software, much as reader feedback will help me improve this article. PROBLEM AREA 1: Naming and text-related bloopers 1. Excess use of jargon Despite all the modern efforts towards "user-friendliness", you cannot avoid using jargon in software: some kind of specialist knowledge will always be assumed. There are two types of jargon typically found in Amiga GUIs:
- technical jargon ("technicalese"), which refers to computing stuff in general, and
- Amiga jargon ("Amigalese"), which specifically describes AmigaOS internals and concepts.
"When a menu item brings up a window or requester, an ellipsis (three dots) should be appended to the menu item's label." "When an action gadget brings up another window or requester, the label should end in an ellipsis (three periods)."Clear and well-defined for sure – but not really what Apple had in mind. The positive outcome is that in Amiga software you'll rarely find the ellipsis missing in places where it is appropriate. The negative outcome is that the ellipsis tends to be overused. The criterion for using the ellipsis is not whether the particular command brings up a window but whether it will execute immediately: this is how ellipsis is standardized in the relevant GUI guidelines on all major operating systems. Immediate commands perform an action requiring no further user input, no additonal information or selection. From this viewpoint there is no difference between, say, "Help", "About", "Copy" or "Paste" functions: they get executed with no step in between; what happens (the text is copied/inserted, the requester opens etc.) is their ultimate result. Gadget or menu labels for such commands should not end with "...". If you look at the AmiUpdate screenshot above, you'll see that the "Info" button (which opens a subwindow containing information about the update) does not append an ellipsis. This is correct usage in this particular case. Similarly, RunInUAE is compliant in using no ellipsis for "Help" and "About" in its Project menu: On the other hand, commands that require the user to provide further information or to make a selection before they execute should always indicate this with an ellipsis at the end of the label. The AmigaOS WBStartup preferences editor gives an example of correct usage: Also, if the programmer wants to specifically indicate that there will be an opportunity to cancel (for instance, in delete-type operations), the ellipsis can be used. The user may feel safer clicking on unfamiliar commands if he/she knows they just bring up a requester. 15. Annoying requesters A confirmation requester is, surely, a safety measure but it gets in the way and slows down workflow. If you want your software to be hated, look no further and sprinkle it with requesters! Now seriously. Do not require confirmation for actions that pose no risk, or at least make the request configurable. If your program does not create any data (a calculator, a dictionary, a media player etc.), do not ask "Do you really want to quit?" before you... erm... quit. Should the user exit from such a program by mistake, he/she will start it again, no biggie. Just don't treat them as idiots who hit buttons randomly and do not know what they are doing. And, there's a better way: the current trend in software design is a universal Undo function, i.e. one that does not apply to edit-type functions only. If there's a way to always take an operation back, who on Earth needs confirmation requesters? Food for thought maybe.