|  Skip to Content  |  Search  |  Contact us  |  Newsletter  |  Sitemap  |  Article List  |  www.sap.com

Home & Services   Resources   Editions   Community   Goodies

Design Tidbits    Editorials    Stories    Books & People    UI Events    Forums

Design Tidbits

 To Overview of Tidbits

Design Tools

• My Design Tools – Part I
• My Design Tools – Part II
• Using Prototypes
• UI Toolbox: Capturing and Editing Screenshots – Part I
• UI Toolbox: Capturing and Editing Screenshots – Part II

Simplification

• What Does "Simple" Mean?
• Anti-Simplification – How to Make Life Harder for Users
• Reducing Complexity
• Error Prevention Comes First
• Don't Let Your Interface Lie
• Don't Let Users Suffer from System Weaknesses

Interaction Design

• Bridging the Gap – Part I
• Bridging the Gap – Part II
• Bridging the Gap – Part III
• Did You Make Your Selection? – Part I
• Did You Make Your Selection? – Part II
• Did You Make Your Selection? – Part III
• Did You Make Your Selection? – Part IV
• The Software Works The Way I Think: Beyond Point and Click
• A Layman's View on Interaction Styles – Part I
• A Layman's View on Interaction Styles – Part II
• Selecting Objects By Attributes – Part I
• Selecting Objects By Attributes – Part II

Screen Design

• The Art of Hiding – Part I
• The Art of Hiding – Part II
• Screen Layout – Part I: General Considerations
• Screen Layout – Part II: Layout Hierarchy
• Screen Layout – Part III: Examples

Hierarchies

• Hierarchies - Categories vs. Vectors
• Fighting (with) Hierarchies –
  Part I: Basics
• Fighting (with) Hierarchies –
  Part II: Presentation
• Appendix: Fighting (with) Hierarchies – Presentation Techniques I
• Appendix: Fighting (with) Hierarchies – Presentation Techniques II

Visual Design

• Some Color Mysteries
• Some Mysteries of Colored Text
• Animation – The Chili Pepper of the Web
• Appendix: Definitions of the Most Common Types of Animation on the Web

Design Process

• The Construction Cycle – Another Way to "Organize" the Design Process
• User Feedback
• What Does User Integration Mean for Software Design?
• Mapping a Conceptual Interface to a Physical Interface

Web, Web Applications, Web Design

• The Web – A Short Introduction
• An Introduction to Designing User Interface Controls at SAP
• From Dropdown Listboxes to Comboboxes
• List Box Tweaks (Part II)
• Concept Statements and Website Messages – Part I
• Concept Statements and Website Messages – Part II

Performance

• Waiting at the Computer: Busy Indicators and System Feedback – Part 1
• Waiting at the Computer: Busy Indicators and System Feedback – Part 2
• Waiting at the Computer: Busy Indicators and System Feedback – Part 3
• Human Performance at the Computer – Part 1: Introduction
• Human Performance at the Computer – Part 2: Making Applications More Responsive
• Human Performance at the Computer – Part 3: Perceived Performance
• Human Performance at the Computer – Part 4: On the Way to Performance-Oriented UI Guidelines
• Addressing a "Design Issue:" Start-Up Time
• Examples of Poor Responsiveness

Miscellany

• Adding Value to Your Interface by Using Simple Math and Matching
• Refreshing Three HCI Laws: Fitts' Law, Hick's Law, and the Power Law of Practice
• How Much Documentation Do Applications Need? – A Simple Example
• Human-Computer Dialog: How Good Does "Good Enough" Need to Be to Appear "Perfect"?
• Narrative User Interfaces
• Golden Rules for Bad User Interfaces
• Universal Usability
• User Interface Controls and Interaction Techniques of Horror

 

 

The Art of Hiding – Part II

By Gerd Waloszek, SAP AG, SAP User Experience – Updated: May 8, 2002

Hiding Information | Hiding Functionality | Final Word

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 Information

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.

Screen Sequences and Hierarchical Applications

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.

Windows, Views

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

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

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).

Moving Information into Sight (and out of Sight)

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 (continuous, by page)

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 – Tabstrips

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

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

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)

Compressing Information – The Efficiency Aspect

In some cases several presentations for an object may be available, with different space requirements.

Icons

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, Images

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

Small Size Equivalents

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

Clarifying the Meaning of Labels Through Examples

Websites and Intranets offer huge amounts of information. But how can users access it? There are two "extreme" solutions to this problem:

• Offer only high-level categories (5 to 7 ideally) as entry points to the different areas, for example, in a navigation bar
• Offer a complete tree structure (or one that is restricted to a few levels) as an index to the information

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

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

The Control Zoo – Including Elements within Controls

Tabstrip

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:

• Related fields (within complex data objects)
• Related options, settings, or attributes
• Sections or units within a longer (text) document

Figure 14: Tabstrip on a preferences dialog (see also figure 4)

Dropdown List Box, Combo Box

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:

• Provision of predefined values (for example, in value help)
• View switching
• Variable labels

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

Norgies and other "Beasts"

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).

Control Combinations and Complex Controls

Finally, I will present some more complex mechanism for managing the amount of displayed information, filters, and focus-and-context techniques.

Filter - the Shuffler

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)

Starfield Displays

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)

Focus and Context Techniques

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)

 

Hiding Functionality

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.

Pulldown and Context Menus

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.

Menu Buttons

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.

Drag-and-Drop

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

Adaptive Menus and Toolbars, Progressive Disclosure

Category: Foreground vs. Background; Progressive Disclosure

Adaptive Interfaces

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.

Progressive Disclosure

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".

Adaptive Interfaces vs. Progressive Disclosure

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.

 

Final Word

This concludes my short series on the "art of hiding". In the "real world" you will find many more applications of this art.

 

top