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, 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:
Design systems so that users perceive all information they need to operate it, and can easily learn to use it:
Design systems so that users can operate them with minimum physical effort:
Design systems so that users complete tasks efficiently, quickly, and with minimum error:
Systems should be designed to
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:
Clearly, GUI keyboard interaction can be improved. In considering ways to build better keyboard interfaces, consider four strategies:
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.
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.
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.
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.
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.
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.
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.
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.
I thank Melissa Monty for our discussions and brainstorming sessions. Her ideas contributed directly to the usability model described in this paper.