Interface hero: Will Crowther

I consider myself lucky that my first exposure to computing also introduced me to an elegant and effective computer interface. At the time, video games were in dedicated machines, with primitive graphics and joysticks, and computers were operated with a command line. The interface was a keyboard.  With the command line prompt, you could launch programs and create routines that could handle data manipulation and retrieval. However, a creative programmer figured out how you could use these basic elements, launch a program and transport you to an environment rich with humor, exploration, and imagination. This was Will Crowther’s ADVENT. Through his work I quickly fell in love with both computing and human-computer interaction. I’m lucky that this also showed me that with careful planning and thought, the computer could be not only a useful tool but also a great storyteller. Ironically, this era soon ended and interface design worked it’s way through visual paradigms for many years. With the current craze of conversational UI, it’s good to look back on why this sort of interface is powerful, and how to modernize it for the current age.

The movie demonstrates the power of a query based interaction, and you can’t help but be hooked. How do you open the egg without smashing it? Where’s the key to the grate under the leaves? And why is your sword glowing? Interactive fiction was able to circumvent all the limitations of computers by relying on clever writing, a ‘parser’ or something that allowed a limited freedom of expression to the user, as well as feedback. Many dozens of years later, when the GUI or graphical interface became the norm, it became a struggle to keep users engaged at the level they were used to from a command line interface. There were even some axioms that Nielsen and Norman coined to help focus programmers and designers on what is important to users. Look back and see how many of these are present or pioneered in the interface for text adventures.

The Neilsen / Norman Heuristics applied to Zork

Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. Response to typed input was instantaneous.

Match between system and the real world The system should speak the users’ language, with words, phrases, and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. Commands were in simple English, and while terse, the computer was able to “understand’ fairly complex sentence structures, or filled in gaps when needed.

User control and freedom Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. Saving progress in the game was a game changer. You could experiment with different actions without fear.

Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. The tone of the game rarely changed, and the voice of the author helped navigate tricky situations, or in some case the use of puns offered novel solutions.

Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. In this example, I was able to open the egg with the sword, but it clearly told me that wasn’t the right solution.

Recognition rather than recall Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. The system was verbose when you entered a new situation, then when you re-entered it would be concise, if you forgot, looking or ‘l’ gave you the full version back. This was also useful for direction finding, although creating a map was faster.

Flexibility and efficiency of use Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. L for look, NSEW-UD for directional movement were all there from the beginning. X for Examine was added later through feedback.

Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. Since the interaction relied solely on the ability of the author to communicate and the system to parse properly, this was finely honed.

Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. Isn’t it funny that the system wouldn’t work if it used obtuse language? Isn’t it worse that this interface perfected  how to respond to user input and it has taken so long to get it back.

Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large. Once again, outside of difficulty in solving the puzzles, no help was needed, later, online hint and help systems were added with layers of hints to not immediately spoil the fun of figuring it out.

I hope to highlight more of these amazing experiences in my blog, but I know my faith and belief that computers can be both fun and easy to work with stem from this formative experience. Amazing that how 40 years later most of our computer experiences lack one or more of these elements present in such early software.