WWW Cantor Access Inc.

Dimensions of Usability:
Toward a Rational GUI Keyboard Interface

Introduction

Imagine a truly functional keyboard interface for a GUI. What would it be like? In this paper I explore this question by refracting keyboard interactions through a usability prism. I begin by outlining a four-dimensional usability model. I harness the model to illustrate why keyboard interaction in Windows is problematic, and use the findings as a springboard to imagine novel ways to design and build more accessible and usable GUIs.

Usability

Usability, according to The Free On-line Dictionary of Computing, is the "effectiveness, efficiency, and satisfaction with which users can achieve tasks in a particular environment of a product. High usability means a system is: easy to learn and remember; efficient, visually pleasing and fun to use; and quick to recover from errors."

Consider four dimensions of usability: cognitive, physical, practical, and emotional:

1. Cognitive factors

Design systems so that users perceive all information they need to operate it, and can easily learn to use it:

• Make information perceptible
• Create consistencies in appearance and function
• Make it easy to learn by discovery
• Support learning by other means

2. Physical factors

Design systems so that users can operate them with minimum physical effort:

• Minimize operating forces
• Encourage neutral body positions
• Minimize dexterity requirements
• Minimize repetitive actions
• Minimize continuous forces

3. Practical factors

Design systems so that users complete tasks efficiently, quickly, and with minimum error:

• Make it easy to complete tasks
• Make it possible to complete tasks quickly
• Minimize chances for triggering unanticipated actions
• Allow for graceful recovery from errors

4. Emotional factors

Systems should be designed to

• Be fun to use
• Foster a feeling of success

Applying the model to Windows

Windows is used successfully by millions of people who cannot (or prefer not to) use a mouse. In some respects, the interface is fairly accessible. Examining the interface through the lens of this model, however, demonstrates that the design is not particularly usable. The design falls short in at least six ways:

Cognitive

1. Information is hard to perceive

• Some focus indicators are inconspicuous; at least one is invisible.
• Visually busy screens complicate identifying the object that has focus.
• Hardcoded text can be too small to be seen without screen enlargement software.

2. Inconsistencies in appearance and operation are common

• Alt-key behaviour is inconsistent. It acts as a sticky key for menu selection, and as a normal modifier key when pressing key combinations like Alt+F4. Users who inadvertently press the Alt-key may get "lost" when the focus unexpectedly transfers to the menubar.
• Menubar menus, context menus, and the Start menu work differently. For example, navigation keys that work in menubar and context menus, such as Home and End, do not work in the Start menu. When a menubar menu is activated, its first command has focus. When a context menu or the Start menu is activated, the entire menu has focus.

3. Discoverability breaks in some contexts

• In Windows 3.1 applications, one technique allowed users to navigate to all three menu systems attached to the menubar. Windows 95 cut the link from the menubar to the Document System menu, necessitating a hotkey. Windows XP cut the link to the Application system menu, necessitating another hotkey. In the past, users could use one technique to discover all menu commands; today, they must know a technique plus memorize hotkeys.
• The operation of recent versions of "Help" and "Find" cannot easily be learned through discovery. New versions are driven by hotkeys that users must memorize.
• Some controls, e.g., list-boxes and edit fields, lack built-in labels that provide programmatic associations. If a programmer fails to include static text or a tool tip with a control, screen reader users will not have reliable access.

4. Keyboard techniques are not adequately documented

• Although recent releases of Microsoft Help list keyboard commands, many techniques remain poorly-documented. E.g., the command that switches focus between Word's "Find and Replace" dialog box and a document, and the rich set of selection techniques based on Word's "ExtendSelection" command.

Physical

5. Repetitive actions are the norm for keyboard users

• Screen reader and keyboard-only users are forced to press keys dozens of times to perform straightforward tasks, especially when navigating web pages and accessing commands buried deep in menus.

Practical

6. Making a simple error cancels the menu selection process

• There is no tolerance for error when a keyboard user accidentally chooses an unavailable menu command. When selecting an unavailable command, the menu closes; the user is forced to try again. When an unavailable command is clicked with a mouse, the menu stays open.

Toward a more rational, usable keyboard UI

Strategies for moving forward

Clearly, GUI keyboard interaction can be improved. In considering ways to build better keyboard interfaces, consider four strategies:

1. Address imperceptible information issues first

When information is not perceivable, accessibility breaks. Users cannot act on the information. Problems caused by imperceptible (or hard-to-perceive) information should be addressed first during bug fixes.

2. Consider existing methods and standards

Seek out and incorporate the best keyboard-centric features from all available computer systems. Some techniques and hotkeys are logical, well-known, and enhance usability and accessibility. Retain, for example, Shift+directional keys to select text, Ctrl+A to select all, Tab to navigate between links and controls, and so on.

3. Do not degrade the quality of the mouse UI when improving the keyboard UI

Keyboard and mouse interaction are not opposed. Improvements in one mode of interaction may actually improve the other. The goal is to offer choices in how to operate software.

4. Pay attention to accessibility

Incorporate accessibility features. Historically, efforts to improve accessibility for people with disabilities has enhanced usability for everyone. For example, people without visual impairments change menu and icon fonts to make commands easier to see.

Imagining a more usable keyboard UI

1. Emphasize keyboard techniques rather than hotkeys

It is easier to internalize a handful of frequently-used techniques than to memorize dozens or hundreds of keystrokes. A rationale UI would allow users to discover specific hotkeys in the course of applying basic techniques. Knowing techniques reduces the need to remember hotkeys.

2. Create a set of conspicuous focus indicators

The key to operating a GUI without a mouse is the ability to spot which object has focus. Unambiguous focus indicators would go a long way toward improving the usability of the keyboard interface.

3. Introduce more flexible ways to move the focus

Giving focus to objects is easy for mouse users: they slide the pointer over an object and click. Giving focus to objects by keyboard is often clumsy. For example, there are two standard keyboard techniques for selecting an item in a Windows list-view: a brute-force method using directional keys such as up-arrow, down-arrow, Home and End; and an elegant (yet imperfectly-implemented) incremental search. A user initiates the search by typing the first letter — or by quickly typing the first few letters — of a word that appears in the left-most column of a list.

This search capability allows users to type their way to objects. The technique, as implemented in Windows, is extremely limited. It works only in list-views; the time-out period is hardcoded; and the search scope is restricted to text at the leftmost boundary in one column.

I have built models to demonstrate the untapped potential of the type-to-object method. In my prototypes, all text is searchable; there are no time-outs; and typos can be corrected on-the-fly. Complementary "find next" and "object select/deselect" commands result in a simple, intuitive, and less error-prone method of selecting a list item. No standard keyboard technique can match it.

In addition, I have constructed another model along similar lines that improves keyboard navigation in text editors, word processors, web browsers, and other documents that consist primarily of text. The "Find as you type" feature in Mozilla demonstrates that the technique is viable for individual web pages. The approach may also prove useful for navigating other list-like structures such as menus, drop-down list boxes, and combo boxes. The technique may also be practical as an alternative means to navigate in dialog boxes.

Conclusion

A comprehensive, rational interface that supports both mouse and keyboard interaction has not yet been fully realized. The perspectives contained in this paper will, I hope, inspire software developers to challenge conventional wisdom about interface design. Viewing keyboard interaction through a usability lens is an important step toward the development of systems that are easy to learn and remember, efficient, forgiving of errors, and fun to use.

Acknowledgement

I thank Melissa Monty for our discussions and brainstorming sessions. Her ideas contributed directly to the usability model described in this paper.

Quick Links