|The Art of Hiding – Part I|
|An Introduction to Designing User Interface Controls at SAP|
By Gerd Waloszek, SAP AG, SAP User Experience – Updated: May 8, 2002
In the second article on the "art of hiding", I present examples of "hiding" techniques that can be used in our daily work as user interface designers. Some of these techniques are implemented by simple controls, some combine different controls, and others are based on the functionality included in controls.
You will find many common screen elements here, but the context may be new – presenting as much information and functionality as possible in a limited space and providing access to the remainder.
In my previous article, I presented general principles of how information and functionality can be hidden from the user's view.
Hiding and presenting information are closely related – they are two sides of the same medal. I will, therefore, sometimes talk more about presenting information than about hiding it. Presenting information also includes the aspect of efficiency: Efficient presentations allow you to display information that would otherwise remain hidden.
Early interactive computer programs offered very little onscreen information and functionality to users compared to today's systems. Information was typically organized on screens that were viewed in a certain order, which was either fixed or depended on the decisions of the users. For more complex applications, menu screens were introduced that served the sole purpose of offering choices to the users.
With the advent of graphical user interfaces (GUIs) this situation did not change much – at least in the realm of complex business software, such as in SAP R/3. Complex information, such as in data entry screens, was split into parts and distributed over several screens, which had to be viewed in succession. The order in which the screens were viewed was again either fixed or depended on the user's choice (in R/3, a dedicated Goto menu allowed access to certain parts of the application.) Moreover, application structures became so complex that the screens rarely formed a strict sequence; most applications had a hierarchical or even a network structure. Dedicated navigation functions had to be invented for handling the movements within such applications.
The obvious disadvantage of the early approach described above is that users only see one piece of information at a time. They also do not usually see where they are within the structure. The following two techniques can help to overcome this bottleneck.
Windows imitate sheets of paper on a desktop. They can be viewed in parallel (at least as long as the screen space suffices), quickly brought on top, resized, hidden, moved, and so on. However, the more windows there are on the screen, the more cumbersome the handling. The Windows® taskbar or dedicated "Window(s)" menus have been introduced for easier window handling.
Figure 1: A desktop filled with windows – the task bar at the bottom allows window handling
Figure 2: The "Window" menu in Macromedia Dreamweaver 3 allows handling of the document and floating windows within an application
Views are information units dedicated to one purpose. Typically, views are presented alternatively and supported by simple and fast mechanisms for view switching (see below).
Cutting information into pieces has to be supported by mechanisms that allow easy access of currently hidden pieces. Here are three mechanisms for accessing hidden information.
Scrolling is based on the paper roll analogy. It moves information into sight, either continuously or in a piecemeal fashion, for example, by page. Scrolling is useful for smaller pieces of information and allows only linear movements. It can be fast and efficient if it is not overused. It is better used for text documents than for form-like screens.
Figure 3a-b: Microsoft Word offers rather sophisticated continuous scrolling mechanisms (left); HTMLB tables used in iViews offer scroll buttons for scrolling by item or page
View switching is based on the analogy of information pieces placed on cards. Any card in the deck can be shown through a switching mechanism. The tabstrip is a typical control based on this approach. Here, however, the number of views should be limited to a small number. In addition, its use should be restricted to cases where views can be randomly accessed.
Figure 4: A tabstrip can be used for offering several views
View switching mechanisms can also be based on buttons, link lists, or a dropdown list box.
Figure 5a-b: A link list and a dropdown list box can also be used for accessing views
Links extend the notion of moving information into sight in a special way – they move the user to the information. Links may be text passages, icons, images, or image sections.
Links have been introduced in hypertext systems; through the popularity of the Web they have become commonplace not only in text systems but as a general access mechanism for information. On the Web, links can transfer readers to sections within the same page, to a different page on the same Website, or even anywhere on the Web.
Thus, combined with anchors, links can serve as a "view switching" or "fast scrolling" mechanism within one screen or document. They augment the "dumb" linear scrolling mechanism by a directed, content-sensitive movement.
Figure 6: Anchor links to passages on the same page can be regarded as a content-related view switching mechanism
In general, links are a "view switching mechanism" that is based on content and leads to one specific piece of target information. More advanced linking mechanisms provide users with a choice of possible jump targets (for example, via a context menu).
Show/hide mechanisms come in many guises. For example, certain containers, such as trays, tiles or group boxes may offer the option to hide the content. The title bar usually remains visible. (There may also the option to fully hide the container, which is offered in a personalization dialog, screen or page.)
Figure 7a-b: The Windows® minimize button (left) of is an example of a show/hide mechanism for windows; the tray's Open/Close toggle button allows the collapsing and expanding of iViews on a portal page (right). (Expand opens the iView on a new page)
In SAP R/3 this mechanism is simulated through buttons that show or hide a certain screen area (see figure 8).
Figure 8: Show/hide mechanism in SAP R/3 (from SAP R/3 guidelines)
Show/hide mechanisms are also widely used in visual presentations of hierarchical structures. For example, typical tree controls you allow to hide and show a node's content (including the root node, which results in a "hide all" command). In outliners, such as the outline mode in Microsoft Word, you will find an option for hiding all nodes below a certain level, instead.
Figure 9a-b: Part of the hierarchy of the SAP Design Guild preparation folder; the "plus" and "minus" icons allow the hiding and showing of single nodes (including subnodes) (left); a SAP Design Guild article in the Microsoft Word outliner (right)
In some cases several presentations for an object may be available, with different space requirements.
The best known example is the use of icons instead of text labels. In toolbars especially icons allow you to squeeze in many more commands than would be possible with text labels. In some cases, however, the application developers do not seem to trust their icons – they add text labels to them (see figure 10). Sometimes, users may choose between icons, labels, or both.
Figure 10: Microsoft outlook toolbar with icons supplemented by text labels
Charts and images may present the same information in a tighter space than a corresponding table or text would require. However, the different representations are often are not fully equivalent and have both merits and disadvantages. In this case, I suggest also offering the alternative presentation through a button, link, or menu command.
Figure 11: A complex chart may reveal information much more effective and may save more space than tables or text
It would often be better to present secondary information or functionality less obtrusively than the main information. One possible solution is to use small size versions of controls and small text, offering two advantages: (1) the main information is easier to recognize, and (2) more space is available on the screen. The latter option can be used to squeeze in more information or screen elements but it would be wiser to use this extra space to achieve a cleaner layout.
Figure 12a-b: Standard size field label vs. small field label above a field for saving space
Websites and Intranets offer huge amounts of information. But how can users access it? There are two "extreme" solutions to this problem:
The problem with the second approach is that it needs a lot of space and may be cumbersome to use. The problem with the first approach is that the category levels are often so general that users may not know where to go and frequently have to backup.
A third approach would be to go with the category levels but add between two and four examples (the most often needed, or "prototypical" ones) to the categories, which demonstrate what the categories actually mean (that is, what kind of information users can expect behind the categories). With this approach, most of the index remains hidden but users have a better idea of where to go.
Progressive disclosure is an approach to reducing complexity of screens that was introduced in the Apple Human Interface Guidelines. Following this principle, you present the most common choices to users while initially hiding more complex choices or additional information. Progressive disclosure helps to develop an interface that it is easy for novice users to learn and includes the features and power that advanced users need.
For example, the early Sherlock search dialog on the Apple Macintosh was based on the principle of progressive disclosure. When called up, it offered only a few search criteria. If the user needed more criteria, he or she could expand the dialog by clicking the More Choices button; the user could even make the dialog smaller again by clicking Fewer Choices.
Figure 13: The early Sherlock search dialog on the Apple Macintosh was based on the principle of progressive disclosure
Category: One at a Time
I mentioned tabstrips already in the context of view switching. This is, however, a very general notion. Let's be a little more concrete with respect to what "views" can mean:
Figure 14: Tabstrip on a preferences dialog (see also figure 4)
Category: One at a Time
The dropdown list box is used to offer a limited set of options to the user and has many applications:
The combo box (that is, the dropdown combination box) combines an input field with a dropdown list box. It allows users to enter a value or option that is not predefined and possibly to extend the predefined set. The dropdown list box is often erroneously called a combo box.
Figure 15: HTMLB dropdown list box – used here for selecting a language
Category: All or (Nearly) Nothing
Norgies are small triangle icons (or other icons, such as the plus and minus symbols in Windows) that allow users to hide or show information. You can find them inside tree controls, outliner trees, in the tray headers of iViews, and so on. In Windows, plus and minus icons serve the same purpose (see figure 9a).
Figure 16: Norgies in tray and group boxes (from SAP Business HTML Cookbook)
In Windows, each window has the minimize and maximize icon at the right edge of its title bar (see figure 7a). This serves a similar purpose (although, you have to click a button in the taskbar to open a minimized window again).
Finally, I will present some more complex mechanism for managing the amount of displayed information, filters, and focus-and-context techniques.
Category: Foreground vs. Background
Filters are an efficient approach to limiting the amount of displayed data. One well-known version of this technique is the attribute-based filters, such as Cooper's shuffler. The shuffler allows you to formulate natural-language-like queries that can be understood by users without them requiring a course in logic. There are problems with translating such statements into other languages. In such cases, you can use statements that do not form sentence-like statements.
Figure 17: A shuffler used for filtering a workflow inbox (section)
Category: Foreground vs. Background
Starfield displays, developed by Ben Shneiderman and the HCIL group at the University of Maryland in the United States, offer more-dimensional filters that help to effectively reduce large data sets to relevant items. The items are usually displayed as a two-dimensional scatter diagram. The graph responds dynamically to changes in the filter settings.
Figure 18: An early version of the FilmFinder by Christopher Ahlberg and Ben Shneiderman that utilizes the starfield display principle (larger version)
Category: Foreground vs. Background
Focus and context techniques constitute a new research field that would merit an article in its own right. The basic idea is to present a selected item, such as the page of a document, within its context. "Focus" means that the item in focus is given most screen space while the context is given less screen space. For example, if this technique is applied to a text document, the page in focus would be presented in the center of the screen, while the context pages would be presented at the borders as small thumbnails. Thus, at least part of the context is visible and directly accessible. The flip zooming and the Zoom Browser visualization techniques by Lars Erik Holmquist are based on this principle (figure 19a-b).
Figure 19a-b: The principles of flip zooming – unzoomed view (left) and zoomed view (right) (by Lars Erik Holmquist)
The hyperbolic browser can also be classed among the focus and context systems because it accentuates the focused nodes. The farther apart the displayed nodes are from the central node, the smaller they are displayed (using hyperbolic geometry).
Figure 20: A hyperbolic browser (from inxite)
Many applications are loaded with functionality. This functionality serves different purpose, such as, initiating processes or actions that are related to the task in hand, or simple action that are necessary steps in handling the computer. For example, saving a requisition may finish the processing of an order, while selecting a text portion and calling up the copy command may be a simple step in filling in address data. If you counted all possible commands in both categories you would be astonished how large these numbers turn out. It is no wonder then, that most of an application's functionality is hidden from the user's view. I present some of the techniques that can be used below.
Category: One for All (pulldown menu) and Only the Knowledgeable Know (context menu)
When graphical user interfaces were new, pulldown menus were one of the first things that people had to learn about. They became such an integral part of applications that they were even imitated in character-based simulations of window systems.
From the beginning , the commands were clustered into groups, such as the now well known "File" and "Edit" menus. There is only one problem with this grouping – many users still do not know which category to use for a particular command.
Figure 21a-b: Pulldown menu and context menu in Microsoft Outlook
There are some variations of pulldown menus, such as dropdown menus and popup menus. The latter are also know as context menus (or right mouse button menus) and have come into widespread use since being more intensively used in the Windows operating system. There is one big difference from pulldown menus though – there is no indication of whether such a menu is available and how to call it up. Users have to know or find that out. In fact, it took me quite a while to make more use of this feature.
On the other hand, Web pages initially came without both types of mechanisms and both mechanisms are regarded as "complex". Nowadays, may alternatives and "clones" have been invented to make these features available on Web pages.
Category: One for All (category or current choice)
Menu buttons are a special case of pulldown menus. They typically offer a set of related commands. Menu button labels may consist of text, icons, or both. They may show a category name, a prototypical command or the last used command. (There are no clear-cut rules for labels.)
Figure 22a-b: Menu buttons – showing the current option (left) and the default command (right); both images enlarged
Figure 22c: The menu button of figure 21b "pulled down"
Menu buttons are often used in toolbars; there they minimize the number of visible toolbar commands.
Category: Only the Knowledgeable Know
Drag-and-Drop hides functionality because there is no visible indication on the screen that such a function is available. This is the advantage as well as the disadvantage of this feature. During the Drag-and-Drop operation itself, however, there should be indicators, such as a changed cursor, highlighting of possible drop targets, and do on.
Figure 23: A folder is moved to the trash can for deletion; the drag target, that is the trash can, is highlighted to indicate that the folder can be dropped
Category: Foreground vs. Background; Progressive Disclosure
Adaptive menus are currently widely used in Microsoft applications. Instead of providing the whole list of menu items in a pulldown menu, only a selection of important and often used items is provided. A menu button with two arrows pointing downwards allows users to expand the menu to its full length. (The previously hidden items are displayed in a lighter gray.) Luckily, this feature can be turned off.
This feature is combined with changing the order of the menu items according to usage. For example, Microsoft Outlook always put the most recently used item at the top of the Open menu. This is a mixed blessing because half the time this is what I need but half the time it is not.
Figure 24a-b: Adaptive pulldown menu in Microsoft Outlook – most often used commands (left) vs. full menu (right)
Microsoft uses a similar technique for toolbars. If space does not suffice for displaying all toolbar items, only a selection of commands or settings is offered. A menu button with an ">>" icon is displayed in addition, which allows users to access the hidden functions.
I have already talked about progressive disclosure in the context of offering options or information to users (see figure 13). You can also offer functionality in a piecemeal fashion, that is providing basic and frequently-used functions first and giving access to advanced or nice-to-have functionality "on demand".
Thus, both adaptive systems, as well as progressive disclosure, are techniques of starting with a limited set of options and/or functions and offering more options/functionality "on demand". So, you might ask, which is the better way to go? Both these approaches have their merits as well as their disadvantages.
In adaptive systems, the user behavior determines the set of initial options. In an "ideal world", this would always provide the options that the user needs. In the real world, however, the hit rate may be far lower. In addition, adaptive interfaces are not stable and change continually. This may puzzle users, for example, when an option that was available the last time has vanished because another option threw it out of the menu. For designers, such systems are attractive because they relieve them of the burden of finding out what the most relevant options or functions are.
Progressive disclosure, on the other hand, requires designers to have a firm understanding of their user's needs. If they have that, users are rewarded with a flexible but fairly stable interface that provides all they need.
This concludes my short series on the "art of hiding". In the "real world" you will find many more applications of this art.