By and large, graphical interface design has stayed pretty steady since Xerox® PARC thought it would be fun to create a virtual desktop. Most keyboards have physical designs similar to those of the first mechanical typewriters. As a whole, the computer industry has a great deal of baby duck syndrome; that is, we tend to implement things by following the same model on which we learned them. My first video game was not merely a roguelike game, but a roguelike game with the same inventory management and window layout used by the Omega game I had been playing when I decided to write one.
Usability studies and projects often focus on ways to improve the way things work. Alternatives can be risky and are unlikely to be well-understood. As a famous example, touchscreens were expected to be the way of the future until people tried them and found them unusable. Only after the introduction of the Newton® and the Palm® did people find a way to really use touchscreens.
Several aspects of traditional computer systems offer some opportunities for alternatives rather than mere elaborations on essentially the same theme.
Despite the amount of time and effort designers put into ergonomic keyboards, most keyboards are essentially built on the same design of early typewriters. They have keys that are offset at angles based on the need to have adjacent levers operate smoothly without running into each other. Debates over the benefits of this Dvorak layout continue, with both sides claiming studies supporting their views. Nonetheless, the essential physical structure of keyboards is pretty stable.
Keyboard users now have several real alternatives. Kinesis Ergonomics introduced a contoured keyboard, in which the keys come in vertical rows that are actually curved rather than flat. The Maltron ergonomic keyboards, likewise, changed the physical layout of keys substantially. They also offer a different arrangement of letters, while the Kinesis keyboards come primarily in Qwerty and Dvorak layouts.
Other keyboards go a step further. Chording keyboards offer several rocker switches, using combinations of keys to indicate letters. Other designs, such as the DataHand®, use arrangements of small switches, which are physically quite different from conventional keys. The DataHand has five keys per finger; one fairly traditional vertical switch, and four vertical tabs that are pushed sideways instead of down. The learning curve for such keyboards is necessarily quite steep compared to switching from one conventional keyboard to another, but many users are quite firmly convinced of the benefits. (Myself included; I wrote this article on a DataHand. I could not be a full-time writer on a conventional keyboard.)
To users in the Mac® and Windows® worlds, the notion of choosing a different windowing system pretty much begins and ends with changing the graphical appearance of the standard windows, or possibly going so far as to move some of the graphical widgets around (perhaps moving the close widget further away from other widgets). On X11 systems, though, there are many interesting options that are entirely unlike this. Two notable options in X11 window management are ratpoison and Ion, both of which reject one of the first and oldest assumptions in window management: that windows must overlap.
Developers and users have assumed an overlapping window feature in their desktops for a long time. These windows have advantages and disadvantages; for many users, the tendency for windows to get lost under other windows is a disadvantage. In the model's defense, this feature precisely reproduces a well-known feature of physical desks with more than one piece of paper on them. MacOS® 10.3 introduced the Exposé feature, which lets you see all your windows at once and pick one, and this mitigates the hassle. Ion and ratpoison both seek to avoid it entirely.
The common idea behind Ion and ratpoison, and more generally of several "virtual desktop" features in X11 window managers, is that it's more convenient to have your entire screen in use most of the time, ideally, with only the program you're currently using. Virtual desktop managers let you page back and forth between multiple desktops, each with its own collection of windows. There's a PowerToy for Windows XP that simulates this relatively well, but many applications don't work reliably with it. Amiga users might be familiar with the notion of multiple applications, each offering its own screen. Ion extends this to tabs; a single frame (often a full screen, but you could split a screen into multiple frames) might contain several windows, but you can only see one at a time. The popularity of tabbed browsing in Firefox® and Safari™ suggests that this feature ought to be desirable, and indeed, it often matches user habits much better than the overlapping windows of other systems.
A major design goal of ratpoison, and the source of its name, is to eliminate mouse dependency. Ion supports the mouse, although it offers keybindings and commands for everything; ratpoison simply ignores the mouse entirely. With keybindings and virtual workspaces, you can perform a keyboard-bound task (such as writing articles) and go for an hour or more without having to once touch the mouse, even when using multiple applications. The convenience and performance are impressive; the learning curve, however, daunts many users.
You can make reasonable comparisons of usability between similar systems. For example, you can compare Gnome™ and KDE™ and have users perform similar tasks (such as switch from one window to another) and compare results. It's much harder to make a fair comparison between, say, Gnome and Ion. Which is easier: holding down the Alt key and hitting 2, or clicking on a window title bar? How can you compare ease of use for beginners, or ease of use for experienced users?
Users of ratpoison aside, most computer users these days spend a fair amount of time using some sort of pointing device. Variety in pointing devices is pretty broad. Most pointing devices are based around relative motion; they indicate how much to move the pointer. Some, such as tablets and touchscreens, use absolute motion; they indicate where the pointer should be right now, without the need for it to cross intervening space. It is probably unwise to get too involved in the question of which of these is better; in fact, both are likely useful choices for some applications.
Pointing devices show some real innovation. For instance, the addition of scrolling devices to trackballs and mice has revolutionized their use. These devices have radically changed the use of scroll bars in interfaces, often making them merely a graphical feedback element rather than a control element.
Your choice of pointing device can have a huge impact on what interface decisions are reasonable or unreasonable. For many years, Mac users were stuck with an unwelcome variety of workarounds for mice with only one button; this is most noticeable in ported software coming from multibutton environments -- software that adopts conventions (not always the same ones) for representing right-clicks. A given action, such as clicking and dragging, might be convenient on one mouse but inconvenient on another.
It's hard to really see the assumptions you make until you see them from the outside. The assumptions of how video games, which use the WASD cluster for movement, should be made were unexceptional to me until I learned Dvorak. Users who grew up on the Amiga, or on X11, find virtual desktops habitual and usual; users on other platforms often find the very concept alien and confusing. The tendency for user interfaces to be built in terms of incremental improvements on other interfaces keeps learning curves fairly low, but limits the potential for real innovation.
That said, if you're designing a new program, please don't invent your own concept of window management for your application alone. Consistency does offer some virtue.
This week's action item: If you use X11, spend a couple of hours experimenting with Ion. The development tree for Ion3 is stable. You might need to give it some hints about specific programs to make it interact nicely with them.
- Check out "Cultured Perl: Fun with the Ion window manager" for more information on the Ion window manager (developerWorks, Sept. 2004).
- Peruse developerWorks' Web Architecture zone to expand your site development skills.
- Read any of the earlier cranky user columns.
- Look at this example of a roguelike game.
- Read a review on the benefits of the Datahand keyboard -- it uses a smaller number of keys, plus shift states, but is not a chording keyboard.
- Stay current with developerWorks technical events and Webcasts.
- Participate in developerWorks
blogs and get involved in the developerWorks community.