|  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
• 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

• 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 new

Miscellany

• Adding Value to Your Interface by Using Simple Math and Matching
• How Much Documentation Do Applications Need? – A Simple Example
• Narrative User Interfaces
• Golden Rules for Bad User Interfaces
• Universal Usability
• User Interface Controls and Interaction Techniques of Horror

 

 

Did You Make Your Selection? – Part IV

By Gerd Waloszek, SAP AG, Product Design Center – 02/16/2001

In my fourth and final article I cover function selection including the selection of options. In many menus and toolbars both functions and options are offered together. Where required, I also discuss how these are different for Web pages.

Here's a brief overview of my previous articles on selections. In the first article I cover the basics of selections, such as selection modes and how to "physically" select one or more objects with the mouse and the keyboard. In my second article I ask which objects can be selected on screens and take a look at some of the controls where selections are involved, namely those which are exclusively dedicated to selections. The third article of this series deals with more complex controls and their selection "peculiarities."

 

Selecting Functions

Functions are typically selected through menus, pushbuttons, toolbar icons (or toolbar buttons), and a variety of keyboard shortcuts. Functions are selected one at a time, that is, through single-selection. There is usually no such thing as "multiple function selection." Since humans have a hard time performing more than one main task at a time (the old patting your head and rubbing your stomach at the same trick).

If users want to perform several functions on an object or object set, the steps are typically performed one after the other. If users need guidance, the steps can be packaged as a wizard. If they want to be relieved from the burden of initiating each single function, the steps can be collected into a macro.

Function selection requires that one or more objects have already been selected to which the function can be applied. Problems may arise if a function is neither temporarily nor permanently applicable. The system may react with a simple beep, a message dialog, nothing, or run into an error. In many cases, the first indication is the best one, because it disturbs users least. Message dialogs make sense if the situation is complex and an explanation is appropriate (if, for example, a function is temporarily not available). The other two options should be "forbidden." However, it is better to react "proactively," either by disabling a function, as is typically done in pulldown menus, or by not offering it, which is preferable for context menus. As the object has already been selected, the system knows, whether a function is applicable to it and can disable or hide the respective menu item or button.

Menus

Menus are the primary means of selecting functions on graphical user interfaces. The two most often-used menu types are pulldown menus in the menu bar and popup menus, such as the context menu called when you click with the right mouse button. Menus are a "single selection" mechanism for functions or options: only one menu item can be selected at a time.

Figure 1: Professional programs like Macromedia Dreamweaver 3 offer highly complex menu structures; however, to overcome this complexity, the program also offers toolbars and floating palettes.

Web pages do not have menus for content, only for the browser functionality and options. This is not a problem for information-oriented Web pages because these require little functionality. For Web applications, however, this may cause a problem because menus are the easiest way to offer a large number of functions, especially if cascading menus are used. So how can one present a large number of functions without using menus? Should developers offer them through other channels, such as pushbuttons, or are there other design options? As we will show below, pushbuttons are the only design option for offering functionality on "pure" Web pages – there are no keyboard commands for the Web content itself. However, pushbuttons take up a lot of space and distract users from the content of the Web page. So, without making a real mess, there can't be more than a few buttons on a page, which means that only little functionality can be offered this way.

The solution to this dilemma is to think the "other way round" and to create simple Web applications with reduced and tailor-made functionality, offered through pushbuttons (see Figure 5 below). This fits well into the notion that the Web is for everyone, that is, for computer "idiots," and not for professionals only. If the Web had remained a professional medium as it was in its early beginnings, we would really have a problem with Web applications.

These days, you can implement menus on Web pages using Java or Javascript. This, however, clashes with the notion of easy to use Web applications and is not widely used yet. A new and rapidly spreading use of simulated menus on Web pages is the two-level navigation menus, as mentioned in my previous article and shown again below:

Figure 2: The navigation menu at www.apple.com follows the recent trend to implement a two-level navigation bar as a variant of the tabstrip which, actually is an "inverted" pulldown menu (the original image is slightly larger)

Keyboard Shortcuts

There are two types of keyboard shortcuts in graphical user interfaces:

• Control characters (or control codes)
• Accelerator keys

Control characters are unique within an application and provide access to frequently-used functions. As Figure 1 shows, control characters are restricted to a subset of the functionality, because the character set is limited and because most users can remember only a few codes. Programs like Microsoft Word, however, allow users to assign any control key combination to a function or option. When doing so, be careful not to use combinations which are already in use or have a widely-used meaning on a given computer platform, such as Ctrl-S for the "save" function.

Control characters or codes are typically reserved to functions appearing within menus; however there may be functions that wouldn't make sense to include in a menu (for example, the function "Menu bar" in R/3, which moves the cursor to the menu bar), so instead they only have a control key assigned to them. Typically, control codes are shown to the right of menu items as a reminder (see Figure 1).

Accelerator keys are unique only within a certain context (control, menu, tabstrip view). For example, they are unique within a pulldown menu. Accelerator keys are displayed as underlined characters. They are not restricted to menus, but may appear nearly everywhere in an interface, such as on buttons, on tabs, or in menus.

Note that there are no accelerator keys on the Apple Macintosh. These is also no support for accelerator keys within HTML pages; the same applies to control character. Accelerator keys and control characters can only be used for the Web browser itself, not for the page content.

Pushbuttons

Pushbuttons are based on the analogy of real pushbuttons and are used as a shortcut for selecting functions. Sometimes they appear with text, with icons, or with both. On toolbars, buttons typically have icons only because space is limited.

Figure 2: Buttons in a dialog window

Figure 4: Even more buttons in a dialog window; the buttons at the top imitate a toolbar and use icons to save space. The two buttons at the top right are toggle buttons and select different presentations for the file list.

Like menus, buttons allow only a "single selection" of functions, following the rule that it's hard for a person to do more than one thing at a time. A function list with radiobuttons for each option plus an "action" button labeled "OK" would not be a very practical alternative to a set of buttons. However, though such a design may appear cumbersome, it could be a valid design option for critical functions.

As already mentioned, buttons are the primary means of calling functions on a Web page. Buttons may come in several forms:

• Text or graphic buttons using hyperlinks or image maps – these are mainly used for navigation purposes
• Form buttons like the "submit" and "reset" buttons
• Buttons using Javascript for more extensive processing, such as checking user input, doing calculations, changing page elements, etc.

As nearly everything can be made a button on a Web page, buttons may look very different from one another. Do you remember the button hype which caused the creation of huge button collections all over the Web; many HTML editors also offer button collections. However, there is an inherent problem with such a variety: users may be unsure what's a button and what's not – the feedback given by the mouse cursor may not be a sufficient clue for them.

Now the first button hype is over, and we now have a new hype – rollover effects. Short Javascripts track mouse events, such as "mouse-enter," "mouse-out," or "mouse button pressed" and switch button graphics in order to simulate a "button press" or a "button will react" effect. As designers' imaginations are nearly unlimited, you will also find a multitude of solutions for this on the Web. Today, many HTML editors offer support for rollover effects by supplying the necessary "ready-to-use" scripts and graphics for the different button states.

We already discussed the problem of squeezing a lot of functionality into a Web application. Figure 5 shows an example of the opposite approach – simple applications with reduced functionality, usable by everybody.

Figure 5: Web applications typically offer a reduced, tailor-made functionality with pushbuttons; this is a prototypical example of a SAP Web application, a so-called IAC (click image for larger version)

Menu Buttons

Menu buttons are buttons which do not initiate one function or option, but offer a selection of them, typically related function or variants of one function, which can be accessed through a pulldown menu. This is indicated by a small triangle to the right of the button text or icon. The button itself may initiate a "default function" and may also show the icon or text of the currently selected function or option.

Toolbars and Palettes

Toolbars are a shortcut for buttons and menus. They offer a set of small icons for frequently-used functions and options and make them permanently visible. Often the users can choose whether the icons are accompanied by text labels, or if only icons or only text labels are shown. Alternatively, tooltips can indicate the icons' meaning, but using tooltips requires the users to move the mouse pointer over the respective icons.

Toolbars may be palettes (floating windows on top of all other windows) that can be freely arranged, as is typical for the Apple Macintosh, or attached to a certain location like the top or left window border, these are the "original" toolbars. In Windows, toolbars typically can be dragged to a position of the user's choice or made to float; most Macintosh programs nowadays offer this feature too. As there are many programs available on both platforms, the differences are diminishing more and more all the time. However, often you can still tell whether a program was initially developed for the Macintosh or the Windows platform.

While the main advantage of toolbars is to make functionality visible and easily accessible to the users, there is no rule without an exception. In Microsoft Windows you find lots of toolbars with small double arrows for expanding the toolbars with additional items. Look at Microsoft's presentation program PowerPoint, and you will find, that the toolbar even adapts to different window sizes (all Microsoft products behave this way). You may question whether this is really a useful feature. I often find out that the wrong icons are removed with respect to my personal preferences and uses (maybe that there is a hidden personalization feature, but I can't figure it out, if it's there).

Figure 6: Toolbar in MS PowerPoint – on top you see is a "long" version for a large window (click image for expanded version), below is a version for a smaller window. When users make the PowerPoint application window smaller, the toolbar adapts itself dynamically to the new window size . The two small arrows at the right edge and pointing right indicate that there are even more toolbar options. These appear as a "dropdown" palette.

      

Figure 7: Different versions of the format palette after it has been dragged out of the toolbar. There are even more variants possible through resizing the palette.

Of course, you can even top this. I found a toolbar with a tabstrip in Allaire's HomeSite 4.5:

Figure 8: Toolbar with a tabstrip for selecting different formatting options (Allaire HomeSite 4.5)

If you drag this toolbar out of its place and make it a palette – voilá – you have a palette with a tabstrip:

Figure 9: The same toolbar now as a palette.

Currently, the Web is a "toolbar-free" zone, except for the browser itself. There are, however, many "toolbar simulations" using graphics and image maps. But floating palettes are still cumbersome to implement and use. This may change if Java becomes more widely used, or if future versions of Javascript offer more advanced design options for toolbars.

 

Complex Settings

Many toolbars or palettes nowadays go far beyond simply offering a set of functions like the early MacPaint toolbar did on the Apple Macintosh (see Figure 13). Look at a Macromedia Dreamweaver 3 Properties palette as an example:

Figure 10: Properties palette for Dreamweaver 3, expanded version

Figure 11: Properties palette for Dreamweaver 3, small version

This palette offers a lot of options for setting the properties of the currently selected object. Depending on the object type, certain options are enabled or disabled. Also, the palette may be resized to a smaller version displaying only the options in the upper half (see Figure 11).

Figure 13: The original Mac Paint and its toolbars; almost – the drawing window has the modern MacOS 9.1 look. Figure 12: The Adobe Photoshop tools palette doesn't look much different from the first version 1.0 to version 5.5; it still resembles the "classic" Mac Paint toolbar (see Figure 13).

 

Conclusions

This concludes my article series on selections. After all these articles, wouldn't you agree that making selections is one of the more complex parts of today's graphical user interfaces? You also saw that the Web's user interface is much simpler than standard graphical user interfaces. This is one of the reasons why the Web is so easy to use – it can be used by everyone without the need to learn complex selection rules.

 

top