|The Art of Hiding – Part II|
|Vision and Visual Disabilities – An Introduction|
|An Introduction to Designing User Interface Controls at SAP|
By Gerd Waloszek, SAP AG, SAP User Experience – April 30, 2002
These days a computer user can access a huge universe of information and functionality via a computer. But there is a bottleneck: the computer screen is only a "peephole" to this virtual world. Due to the limited space that it offers, the user can only see a fraction of the information that is potentially accessible, or needed for performing a specific task, at any one time. It is as if computer users suffer from "tunnel vision" and have to shift their gaze to gather all they need. (For an explanation of tunnel vision, see Vision and Visual Disabilities – An Introduction in the SAP Design Guild).
Let's compare that with accessing information from books. In a book, information is spread over many pages. The reader can only see one or two pages at a time and has to browse through the pages in order to access certain information. A table of contents, an index, and page numbers are mechanisms that help readers to find and access that information. A computer is a much more complex system than a book - so, information access and presentation mechanisms have to be far more sophisticated. Of course, this is not a new insight. From the first interactive computer systems on, developers have had to fight this visual bottleneck and invent numerous solutions to overcome it. This article and a second one analyze the situation and present some of the solutions that have been developed.
Let's start with some very general principles of how information and functionality can be hidden from the users' view and nevertheless made accessible. In the second article, I will present examples of how certain controls implement these principles.
One hiding principle is the "one for all" principle. That is, one item stands for a number of items that are currently hidden and can be made visible through a user action.
There are two variants of the "representative" item: (1) a category name, and (2) the current choice.
Pulldown menus are a typical example of a category label representing a set of functions. We all know the menu titles "File", "Edit", "Help" etc. at the top of a window or screen (Macintosh). These are the standard categories that appear in any application. In addition, there are categories that are application-specific but serve the same purpose, namely telling the user that he or she can find a certain set of functions under that category label.
Figure 1: The label "Edit" serves as a category for the edit functions of an application; these functions are hidden from the user's view until he/she opens the pulldown menu
Other controls, though functioning very similarly, do not show a category or other label but the current choice. Examples of these are menu buttons and dropdown listboxes (see figure 2). In cases such as the dropdown listbox, the elements are described by an additional label.
Figure 2: Several dropdown listboxes in this floating window indicate current choices
A similar principle is the "one at a time" principle. A piece of information that is too large to be displayed as a whole, such as customer data, is split into several meaningful units, called views, that are given labels. The user is given the set of labels and one of the views is displayed.
A typical control following this principle is the tabstrip. A set of tabs describes the information chunks, while a title or label may describe the purpose of the tabstrip as a whole, if necessary.
Figure 4: This application uses tabstrips, even in floating toolbar windows for settings
An alternative to a tabstrip would be to present all the information on one large screen or page, so that users have to scroll down to access information. On a Web page, links to subunits would help users to access them faster.
Figure 4: This preferences dialog offers a view switching mechanism that is functionally equivalent to a tabstrip but better suited to many categories
Tip: A developer or user interface designer has to decide, which option is preferable in a particular context. In a classical template-oriented GUI application, a tabstrip may be appropriate, whereas for a paper-like form or a Web page, a long page that has to be scrolled may be the better choice.
"All or Nothing" is not just the name of the Small Faces hit record from the sixties, but also a principle for hiding information. The "nothing", however, is not quite accurate because there is usually an indicator that communicates to the user that something can be shown or hidden. This indicator can either be hidden itself inside a pulldown menu (the respective menu items are typically represented as toggle items) or by a text, icon, button, or combination of those elements.
For example, in the R/3 system toggle buttons are used to show or hide certain screen areas. Where the area is hidden, the button remains visible; it indicates that there is a group of screen elements that can be made visible if needed. Similarly, iViews contain a show/hide icon in their title bar, which allows you to "close" iViews and just keep the title bar on the page as an indicator of its presence. (In addition, users may remove iViews from a portal page by personalizing the page; in this case, the iView is removed completely from the screen.)
Figure 5: A toggle button in R/3 shows or hides the marketing plan details
One of the most frequently-followed hiding principles is to tell users nothing about a certain function or feature on the screen. This has the advantage that the screen is not cluttered with this information – it does not use up any real estate at least. But it has the obvious disadvantage that only those users who have knowledge or expectations (from their previous experience) will be able to find and access this information or functionality.
Strictly speaking most conventions, such as the double-click or the use of pulldown menus, are neither intuitive nor evident to new users. They cannot immediately start working without asking someone else or consulting a computer manual. However, most of these conventions are so easy to learn that users forget that they, too, had to learn them once. Other features, however, are not as evident and repeatedly lead to more cumbersome activity, disuse of features, or even severe interaction problems.
Drag-and-drop is one of these "hidden" features. Drag-and-drop means that users can move objects "physically" across the screen as if they were real-world objects. Thus, drag-and-drop is the "classical incarnation" of direct manipulation. Only a few systems indicate that this feature is available. Users mostly have to speculate from their previous experience with other systems and test, whether drag-and-drop is available and which objects are possible drop targets. (Sometimes highlighting objects or cursors indicates drop targets but then you have to move an object.)
Human beings always want to know where they are, where they came from, and where they are going (or can go) - they want to be oriented. This is due not least to the fact that we can only be physically in one point at one time. Moreover, we don't have a Roentgen vision that goes through walls to the borders of the universe. So, we have to be content with what we see and build a model of the rest of the world in our brains – our thoughts can wander around limitlessly. The same applies to computers: We only see what is on the screen – the huge "remainder" is hidden, and we have to create a mental model of it.
So, another hiding principle that I want to talk about is providing an onscreen orientation for users, telling them where they are, where they can go, and perhaps where they came from. And in some cases it may also be helpful to provide a useful model of the remainder of the virtual world "behind the scene."
The first item, the "here you are" information, is the simplest. Most of today's computer systems provide at least some indication of which program is running, which document is open, or which screen the user is on. Nevertheless, cases of "orientation loss" are frequent because users overlook those often-subtle indicators, such as a window title or a small program icon.
Figure 6: The title bar provides the title, file name, path, and type of the document, the name of the application, and even its icon. Few users will probably take notice of this.
The second item, the "where you can go" information, is usually communicated via buttons, menu items, or hyperlinks. Often these devices convey only vaguely what the users' options really are. For example, the consequences of taking such an option may be unclear. Moreover, if you take too many of those paths, you might get lost. The "lost in hyperspace" phenomenon describes this situation for hypertext systems, such as the Web.
Figure 7: The SAP Design Guild navigation bar tells visitors where they can go for information
If you don't know where to go, you may want to go back. But how do you know, where you came from? There are at least some indicators for this in most computer systems. In hierarchical systems, the computer can provide a path info like DOS does. Breadcrumbs, which are typically used in large information systems, Websites, and portals, may provide a fast backtrack through links in the path info.
Figure 8: DOS prompt with – not so deep – path information
Figure 9: This breadcrumb control offers links in the path info for easy backtrack
In contrast to the "structural" path info, a history list registers each of the user's moves "historically" and allows him or her to jump to any target within the list. Web browsers offer such history lists.
More explicitly – and now we are moving toward a model of the whole system structure – you can provide a structure of the system. The Explorer does this for the Windows file system; the Macintosh Finder is a similar system, which works a little bit differently. Documents often display a hierarchical table of contents to help users move around.
Figure 10: The Windows Explorer displays the file structure of a computer
Some systems only convey the structure of a single item, such as a document or Website (site map) while others attempt to provide a model of the whole computer system, such as the Explorer and Finder. The larger the system is to model, the more complex the model gets – and the greater the chance that only a few people will find it useful. On the other hand, attempts to base such models on "real-life" metaphors, such as books, houses, or cities, soon reach their limits. When systems become complex, real-life models may even hinder the understanding of the system instead of being useful.
In the preceding paragraph, I was talking more about what is visible than about what is hidden. But the visible and the invisible are always closely related. For example, sometimes we convey information by leaving certain things out – but these are special cases. Normally we set the focus by showing certain things and by hiding others. That is, we decide what is relevant and what can be left out. This accentuation corresponds to the foreground-background phenomenon in perception. By making things visible we push them into the foreground, while we push things to the background by hiding them or making them less prominent (for example, smaller, lighter).
Figure 11: The Necker cube is an example of ambivalent foreground and background information – the interpretation of this image shifts between two different views
And then, there is the phenomenon of noise. Noise is irrelevant information that should be in the background. But it can be so prominent that it disturbs or even masks the information in the foreground. Below, I present examples where bad visual or interface design increases the noise to such a high level that the information in the foreground is masked and thus hard to find.
Let's return to screen design. Up to this point I have discussed controls and techniques for hiding or showing information on a computer screen. Now I've raised an issue that demands that a screen designer actively decides what is relevant and what is not. In my experience, this is one of the hardest and toughest issues for user interface designers and developers. Such decisions require experience, knowledge of users and tasks, and understanding of the context in which a software product is used. Often this knowledge is hard to get. To attain it requires a user-centered design process with site visits, user involvement, and market research, as well as a good knowledge of the application area.
This principle is better known as "progressive disclosure". It has been introduced by Apple Computers and is, among other things, applied to the design of dialog boxes. Following this principle you provide users only with as much information, options, or fields as they typically need in the current usage context. More advanced or rarely used options are hidden, and can only be accessed by clicking buttons. Of course, designers need a good understanding of the typical or most often used options. If you offer the wrong choices, you may drive users crazy because you create additional work for them. For example, by forcing them to always click a button to get to the options they want to set, or to the fields they want to edit.
Now let's turn to the "dark" side of information hiding. In many cases, certain techniques or controls are overused or misused. Though these techniques certainly allow information or functionality to be hidden, they fail with respect to access. If users cannot access hidden objects, then these objects do not exist for them and they cannot make use of them. Other "techniques" of hiding information or functionality from users can be attributed to bad screen design or incorrect choice of terminology.
There is a disease called "tabstripitis." It is the tendency to put every piece of information inside a tabstrip. An even more serious form of this disease is the tendency to hide information inside nested tabstrips. Then the number of choices (or doors) for searching an item multiply, for example from ten to 10*10=100.
Figure 12: In this section, the tabstrip looks quite harmless – but look at the next figure...
As usability guidelines often prohibit the nesting of tabstrips, creative designers find other ways of "simulating" the effect of nested tabstrips. For example, the outer tabstrip is replaced by a set of buttons or links that switch the views. For users the effect is the same, even though they may not realize what has been offered to them right away...
Figure 13: A "hidden" nested tabstrip – the three buttons with icons create an "outer" view switching mechanism
There is an old saying that the best way to hide information is to paste it on a door at eye level. Similarly, we often find that users do not carefully scan the screen for information and often overlook what they are desperately trying to find. You can enhance this effect by overcrowding and cluttering a screen so that relevant information does not "stand out".
Using "crazy" color combinations for foreground (text) and background, low contrast, or hard to read fonts (or too small font sizes) also helps to hide information from users. This can be made even more effective by adding distracting information, such as blinking text or animation, that pulls the users' attention away from the relevant information to useless diversions.
But what if users find the information or function in spite of all the obstacles that they had to overcome? Then the best way from keeping them from using it is for the interface to talk to them in an unfamiliar language. Technical, uncommon, or very abstract jargon are perfect "languages" for this purpose.
So, after all those "dos" and "don'ts" let's get to work. The second article on the "art of hiding" will present examples that demonstrate techniques, and the proper use of controls for hiding information and functionality.