Many discussions of interface-design focus almost entirely on the Mac/Windows "desktop" metaphor, as if folders, drop-down menus, dialogue boxes, and button-widgets were the alpha and omega of human-computer interaction. When discussing the history of graphics user interfaces, the progression goes something like Xerox, Macintosh, Windows. I suppose NeXT is in there somewhere to, and the KDE/GNOME "wars" somewhere towards the end. What is often ignored is the fact that video games, for example, have been giving us GUIs for two decades now, and have evolved some of their own idioms and metaphors to deal with their specific issues.
My question is: what can designers of "productivity" software interfaces learn from the game industry? In this article, I'll look at three genres of games and suggest ways that their interface designs might inform the designs of "real-world" projects like shells, programming environments, and desktop environments.
The text adventure era was a little before my time; I was alive, yes, but the games were generally too hard for my little mind. Even so, some of my earliest memories of computers were trying to figure out how to kill some stupid alien in a cave on Mars before he killed me or my oxygen ran out. I'm sure many of you have similar memories:
Anyone who has played text adventures probably has memories like this. But these memories aren't exclusive to text gamers; watch your average computer user struggle with the command line and flashbacks of Martian Adventure (or whatever that stupid game was called) appear unbidden. In many ways, text adventures were easier; at least the commands (and, importantly, the error messages) were in English!
- > kill alien
- Be more specific.
- > shoot alien
- I do not understand "shoot".
- (after looking though the list of actions) > blast alien
- Blast alien with what?
- > blast alien with gun
- I do not understand "gun".
- > run away
- To where do you want to run?
- The alien's hideously long claws puncture your spacesuit. Your oxygen supply quickly escapes into the thin Martian atmosphere. More importantly, so does much of your blood supply and several of your internal organs.
- You have died. Your score is 8.
So it comes as no surprise that folks have tried to create CLI (command line interface) shells with Adventure-like interfaces. The most famous of these are advsh, the Adventure shell by John Coker, and a bash-script version by Doug Gwyn. (I'd pick up Gwyn's; I hear that Coker's won't compile on a modern *N?X without hand-modification, although I haven't personally tried.) A similar project is the MUDShell, which simulates the interfaces of MU*s.
Do these projects succeed? As with nearly everything, in some ways they do and some they don't. Like any good interface, they introduce some useful metaphors. For example, directories are rooms, and special permissions might be "magical artifacts" or "keys" that some users possess and others don't. Moving a file consists of literally "picking it up", carrying it around, and dropping it in some other room. On the other hand, the idioms for doing things can be unnecessarily verbose. Walking from room to room is intuitive, but takes much more typing than a simple "cd". Likewise, both the "room" and the "file folder" metaphors for directories are equally valid, but it's a lot quicker to move "papers" from folder to folder in a Mac/Windows interface than to pick up "objects" and carry them to their destination. (Maybe "throwing" these objects to distant rooms would be a suitable metaphor; at least that way you can stay in the same place.)
The biggest problem, in my opinion, lies not in any fault of these shells but in the intended userbase. These days, anybody who's familiar with the various of text adventures and MU*s is already pretty comfortable with a completely textual environment. I've never met a MU*er who claimed that a shell was too difficult. I'm sure most of the downloads of these shells are former (or current) text gamers who play around with it briefly for nostalgia's sake, rather than true newbies looking to learn about CLI. Adventure shells are a bit friendlier than sh, but to the modern, GUI-fed newbie, the difference is negligible.
But even if there are some difficulties with these particular shells, there are still some lessons to be learned from adventure-style CLIs. For one, English is a bit wordy, but it's a lot easier for a newbie to understand than cryptic UNIX monosyllables. Also, never discard a good metaphor; the "files/folders" metaphor may reign on the desktop, but "people and objects in rooms" is useful, too. (Chat rooms, anyone?)
Can an Adventure-CLI paradigm be applied to any other applications, other than shells? Perhaps interactive command-line programming environments might benefit from a (limited) dose. I've always been a big proponent of interactive programming environments like you might find for LISP, Forth, Python, Haskell, etc. I cannot speak for anyone other than myself, but I always notice much higher productivity when such an environment is available. Incremental development and testing help me find more bugs sooner, and these sorts of environments support these practices in spades. (Decades before the term "silver bullet" was coined, Forth zealots were reporting doubled productivity... and I doubt that Forth's beautiful syntax is the cause. ;)
I can picture several (mild) applications of the "objects/rooms" metaphor. Modules are rooms, linked by "include/import" dependencies, and can be explored like rooms. Classes, objects, and functions are objects: Examining a class or object gives you, say, its member data/functions; and "looking" at anything (a class, a function, an object, a module) displays whatever commentary is associated with it. Maybe spiderweb filaments between objects indicate functional dependencies. ;) Essentially, something similar in functionality to the class browsers popular in graphical IDEs, seen through the metaphor of objects in rooms. Something like this would be great for introducing certain programming concepts (especially OO) to programming neophytes. Objects are objects; Classes are blueprints for objects. Functions are... umm... maybe friendly NPCs who do specific things for you: Constructors who make objects, Accessors who tell you what's inside an object, Mutators who modify an object, etc.
The design of console-RPG interfaces was informed by one specific problem: How to navigate lots of options and data with only a "primitive" controller, containing at the very least a directional pad and two buttons. This problem exists for console games of all genres, of course, but the problem is most evident in RPGs, since they tend (to a fault, sometimes!) to provide the greatest amount of options and data to peruse. (Many console sports games are similar, but it's not a genre with which I'm familiar.)
The usual solution offered is the obvious one: many mostly linear menus navigated by the player by means of the directional pad, with the primary button indicating "confirm" and the secondary, "cancel". These menus are usually brought up by a third button (start or select, for example) which, in many cases, is used only for this purpose. Granted, there's nothing particular "clever" about this interface -- it's an obvious solution -- but it has served the genre for many years.
There are good and bad aspects to this interface, each of which is magnified immensely when considered as a computer UI interface. Even the most limited of computers (say, a simple palm organizer) must deal with far more data and many more options than even the most baroque of RPGs. The bad points first:
Some good points... or, rather, one good point that is spread across two bullets:
- Once tasks reach a certain complexity, this sort of interface rapidly becomes a hassle. Modern console RPGs are rapidly reaching this point; the player of, say, Final Fantasy VIII (the Windows Registry of the series) might have to root around in the menus for a half hour to properly configure his party. And if a six-character party is a hassle to configure, I would really hate to configure XEmacs this way.
- The flexibility of this interface is limited; even though you could, say, configure what's in the menus through some sort of meta-configuration menu, there's really only so specific you can get. It would be difficult -- in the case of a shell with this sort of interface -- to pipeline procs, or to grep things. (Of course, this just says "Don't make a shell with this interface".)
So how might this interface paradigm be used in general computing tasks? Well, large parts of it already are... In many programs, if you press <ALT-F>, there's a good chance a File menu will show up, which you can navigate via the arrow keys if you so desire. So there's nothing truly new here for the computer interface designer to learn. There are, however, still good lessons to be learned:
- A pointing device is not needed; it doesn't require a mouse, a stylus, or a grubby finger mashing the screen. This is a bigger benefit than one might at first realize. Your desktop may have a mouse, but not every computer will; this paradigm is as applicable to your computer as it is to a mall kiosk, a video game, your fancy new VCR, or the armrest-controlled personal-entertainment-thingy you might find on a nice airplane.
- And even when a pointer-device is available, you don't always want to use it. Anyone who does a lot of text-heavy work knows it's nice to have keyboard shortcuts to do common tasks than have to switch to the pointer device and select "save" from the toolbar menu. It's faster, and (at least in my experience) isn't as stressful on your hands. Sometimes the pointer device is awkward; I still have trouble doing any fine pointing with a laptop nipple mouse, and the touchpad on my current laptop took some getting used to (although I'm quite fond of it, now).
A sample project using this sort of interface:
- These "arrow-key-menu" interfaces are good for tasks involving small numbers of options that must be accessed regularly. To give a Windows example, pressing and holding <ALT> and hitting <TAB> brings up a foreground-task-switcher that is much quicker to use than pointing the mouse at those taskbar tabs at the bottom of the screen.
- However, menus with many items -- especially ones in which some of these items are themselves menus, can be quite frustrating. Once in awhile, no prob, but doing it regularly would be a big hassle.
A classic example of (somewhat non-traditional) RPG menu design can be found in Square's Secret of Mana, released for the SNES. It was also used to good effect in the sequel, Seiken Densetsu III, but was left out of the recent Legend of Mana for the PSX. It is also used by the excellent Nintendo emulator FWNES.
While playing, pressing the (X) button darkened the screen and brought up a transparent menu screen. Instead of the more tradition vertical or horizontal box (with choices like Equip, Magic, Status, Save, etc), a circle of icons would appear in the middle of the screen. (Left) or (Right) would cycle through the icons, and (A) (also the "attack" button") would select the highlighted icon. There were four different circles: An "item" circle showed your current inventory (luckily, the number of sorts of items in the game was limited, or else this would have become quite cumbersome). A "weapon" circle let you choose you current weapon. A "magic" circle let you choose what sort of magic to use (i.e., water, stone, wind...). The last circle was reserved for less-used options like equipping armor, configuring your party's AI, etc.
To my taste, there were several virtues of this interface:
What sort of computer tasks might this interface be good for? A lightweight window manager might be able to make use of it. Eliminate desktop icons, taskbars, "start" buttons, and related clutter from the desktop. Keep the desktop free for applications. Reserve a button to bring up the menus; something useless like that "flying windows" button you often find on new keyboards, or scroll lock. Upon pressing it, the foreground darkens and a circle of icons pops up, along with a caption box. (The circular orientation, of course, is purely cosmetic.) The various circles might be:
- It didn't clutter the screen with menus (the usual "Fight", "Magic", "Item" suspects) which would have been out of place in an action RPG.
- It was relatively painless to switch, say, weapons during a battle, or use an item or magic.
- It would remember the last cycle you used; pressing (X) during play would bring you to that cycle. This was useful if you were, say, trying out different weapons against a boss, or casting spell after spell; you wouldn't have to wade through all the menus to get there.
- Although this is purely a matter of personal taste, I found it more aesthetically pleasing than the blocky traditional menus.
This would have several virtues: it would encapsulate the functionality of the start button, the taskbar, desktop shortcuts, etc, and furthermore it wouldn't clutter up the screen in doing so. It wouldn't require switching to the mouse to operate, either. Now, there's nothing revolutionary in its design -- in many WMs, you can get the same functionality by right-clicking on the desktop -- but I still think it's worth implementing, if only for aesthetic variety. (I had planned on maybe doing this as a pet/educational project, but I'm still too much of a *N?X newbie to roll my own WM just yet.)
- Tasks: the applications (both visible and minimalized) that the user is running.
- Shortcuts: one or more circles of commonly used programs/documents. One of these would always, of course, be an xterm or equivalent.
- Recent: the most recently used documents and/or programs; maybe the last dozen by default.
- Options: change your background, your screensaver, modify what's in the other circles, etc.
GRAPHICAL ADVENTURE GAMES
There was a time when graphical adventure games -- now nearly extinct -- ruled the roost. What contributed to their demise? 3d-acceleration or other computing advances, maybe? The fact that, after many years of inventory-based puzzling, game designers had to resort to very counter-intuitive puzzles in order to have anything new? I dunno; anyway, it's not the subject of this article. (However, it is interesting to note that, in the near-vacuum of inventory-adventures, console RPGs are making more use of useable inventories of objects and more item-based puzzles. Perhaps adventures and RPGs are finally reconverging?)
Much of what I said above under Text Adventures applies here, as well; the "rooms/objects" metaphor remains unmodified. However, the interfaces of Graphical Adventures have their own idioms and deserve to be treated separately.
The first graphical adventures were pretty much just text adventures with graphics; think of the early Sierra games or the Legend classics. Later, they developed their own idioms, like LucasArts' SCUMM system or Sierra's SCI. SCI games tended to use different cursors for different actions, while games using the SCUMM (Story Creation Utility for Maniac Mansion, IIRC) engine generally had a list of verb-buttons along the bottom of the screen. Clicking on the verb and then on an object in the game window (or an object in your inventory) did the chosen action to the chosen object. Mid-period SCUMM games like Indiana Jones and the Fate of Atlantis or Day of the Tentacle managed to provide rich puzzles using a mere 9 verbs. Later SCUMM games had different takes: Sam 'N' Max Hit the Road used a verb-cursor similar to that of Sierra's SCI, and Full Throttle and The Curse of Monkey Island had the user right-click and choose an action from a little pop-up kinda interface.
Why might this sort of interface be a useful in human-computer interaction? For one, it maintains the "doing actions to objects" metaphor of text adventures, but there's no CLI to frighten new users. Several desktop environments, in fact, have used this metaphor, although none that I've encountered do so satisfactorily. Packard-Bell, for one, used to ship its PCs with a program that made your computer interface look like a (very yuppie-ish) house with which you interacted in a sterile, Myst-like fashion. Its biggest flaw was the fact that you really couldn't do anything with it, and it was about as lightweight, customizable, and extensible as Stonehenge.
One might take the comparison between Myst and SCUMM/SCI a bit further. Myst was extremely simple as regards object interaction. For each object, one thing could be done with it. You clicked on it, and it did something. What that something was was outside of your control. On the other hand, each object in a more traditional graphical adventure had several things you could do to it (although some might not be valid for that object). Modern file managers do a bit of both: most of your actions consist of clicking on a file icon, and the file manager guessing what you want done with it. But there's usually a way to circumvent this: right clicking often gets you a menu of possibilities, limited though they may be.
A proposal for a file manager with somewhat more complexity: Most graphical file managers take very seriously the metaphor of "objects"; the actions you can do to these objects, however, remains limited. (This is why some people -- probably much of the k5 population -- prefer CLI shells; you are able, in a certain sense, to "define your own actions".)
This file manager might consist mainly of two parts: An object-style view of the file system, and a list of "verbs" (represented, perhaps, as labeled icons.) How the file system is viewed isn't an essential feature; you could have a tree-view a la Windows Explorer and its relatives, a view of a room with object icons lying around, a cushion treemap a la Sequoia View, a topological-view thingy with files and directories as vertices, etc. By default, the "view" verb is active -- perhaps the cursor assumes the aspect of an eye -- but right clicking cycles the cursor through the verbs. Nothing here that can't be done in any graphical file manager. However, a big shortcoming of most file managers is the inability to "create new verbs". One of the reasons I still use a command line is because you can't "gcc <file>.c -o <file>.o | less" or something similar. There is no real reason why you should be able to customize the verbs, adding new verbs to your vocabulary (or forgetting ones you never use) as your needs dictate. Behind those "verbs" could be simple shell scripts in a simple shell language (or a full fledged one, if need be). (BTW, if anyone knows of a graphical file manager that can do such things, I'd really appreciate a link.)
The above lessons are, of course, not the only ones we can learn from game UIs; they're simply the first that came to my mind. I've only attacked three genres, after all. God games would, I imagine, be a fruitful source for interface ideas. I haven't even touched 3D games or VR interfaces. (For example, here's DOOM as a tool for system administration.)
What lessons (good or bad) have you learned from the interfaces in your favorite games?