|
Unix Programming - Unix Interface Design Patterns - The Roguelike Pattern
The Roguelike Pattern
The roguelike pattern is so named because its first example was
the dungeon-crawling game
rogue(1)
(see Figure11.2) under BSD; the adjective “roguelike” for
this pattern is widely recognized in Unix tradition. Roguelike
programs are designed to be run on a system console, an X terminal
emulator, or a video display terminal. They use the full screen and
support a visual interface style, but with character-cell display
rather than graphics and a mouse.
Commands are typically single keystrokes not echoed to the user
(as opposed to the command lines of the ed
pattern), though some will open a command window (often, though not
always, the last line of the screen) on which more elaborate
invocations can be typed. The command architecture often makes heavy
use of the arrow keys to select screen locations or lines on which to
operate.
Programs written in this pattern tend to model themselves on either
vi(1)
or
emacs(1)
and (obeying the Rule of Least Surprise) use their command sequences
for common operations such as getting help or terminating the
program. Thus, for example, one can expect one of the commands
‘x’, ‘q’, or ‘C-x C-c’ to
terminate a program written to this pattern.
Some other interface tropes associated with this pattern
include: (a) the use of one-item-per-line menus, with the
currently-selected item indicated by bold or reverse-video
highlighting, and (b) ‘mode lines’ — program status
summaries carried on a highlighted screen line, often near the bottom
or at the top of the screen.
The roguelike pattern evolved in a world of video display
terminals; many of these didn't have arrow or function keys. In a
world of graphics-capable personal computers, with character-cell
terminals a fading memory, it's easy to forget what an influence this
pattern exerted on design; but the early exemplars of the roguelike
pattern were designed a few years before IBM standardized the PC
keyboard in 1981. As a result, a traditional but now archaic part of
the roguelike pattern is the use of the h, j, k, and l as cursor keys
whenever they are not being interpreted as self-inserting characters
in an edit window; invariably k is up, j is down, h is left, and l is
right. This history also explains why older Unix programs tend not to
use the ALT keys and to use function keys in a limited way if at
all.
Programs obeying this pattern are legion: The
vi(1)
text editor in all its variants, and the
emacs(1)
editor;
elm(1),
pine(1),
mutt(1), and most other Unix mail readers;
tin(1),
slrn(1),
and other Usenet
newsreaders; the
lynx(1)
Web browser; and many others. Most Unix programmers spend most of
their time driving programs with interfaces like these.
The roguelike pattern is hard to script; indeed scripting it is
seldom even attempted. Among other things, this pattern uses raw-mode
character-by-character input, which is inconvenient for scripting.
It's also quite hard to interpret the output programmatically, because
it usually consists of sequences of incremental screen-painting
actions.
Nor does this pattern have the visual slickness of a mouse-driven
full GUI. While the point of using the full screen interface is to
support simple kinds of direct-manipulation and menu interfaces,
roguelike programs still require users to learn a command
repertoire. Indeed, interfaces built on the roguelike pattern show a
tendency to degenerate into a sort of cluttered wilderness of modes
and meta-shift-cokebottle commands that only hard-core
hackers can love. It
would seem that this pattern has the worst of both worlds, being
neither scriptable nor conforming to recent fashions in design for
end-users.
But there must be some value in this pattern. Roguelike mailers,
newsreaders, editors, and other programs remain extremely popular even
among people who invariably run them through terminal emulators on an
X display that supports GUI competitors. Moreover, the roguelike
pattern is so pervasive that under Unix even GUI programs often
emulate it, adding mouse and graphics support to a command and display
interface that still looks rather roguelike. The X mode of
emacs(1),
and the
xchat(1)
client are good examples of such adaptation. What accounts for the
pattern's continuing popularity?
Efficiency, and perceived efficiency, seem to be important
factors. Roguelike programs tend to be fast and lightweight
relative to their nearest GUI competitors. For startup and runtime
speed, running a roguelike program in an Xterm may be preferable to
invoking a GUI that will chew up substantial resources setting up
its displays and respond more slowly afterwards. Also, programs
with a roguelike design pattern can be used over telnet links or
low-speed dialup lines for which X is not an option.
Touch-typists often prefer roguelike programs because they can
avoid taking their hands off the keyboard to move a mouse. Given a
choice, touch-typists will prefer interfaces that minimize keystrokes
far off the home row; this may account for a significant percentage of
vi(1)'s
popularity.
Perhaps more importantly, roguelike interfaces are predictable
and sparing in their use of screen real estate on an X display;
they do not clutter the display with multiple windows, frame
widgets, dialog boxes, or other GUI impedimenta. This makes the
pattern well suited for use in programs that must frequently share
the user's attention with other programs (as is especially the case
with editors, mailers, newsreaders, chat clients, and other
communication programs).
Finally (and probably most importantly) the roguelike pattern
tends to appeal more than GUIs to people who value the concision and
expressiveness of a command set enough to tolerate the added mnemonic
load. We saw above that there are good reasons for this preference to
become more common as task complexity, use frequency, and user
experience rise. The roguelike pattern meets this preference while
also supporting GUI-like elements of direct manipulation as an
ed-pattern program cannot. Thus, far from
having only the worst of both worlds, the roguelike interface design
pattern can capture some of the best.
[an error occurred while processing this directive]
|
