posted by Richard Wareham on Mon 8th Mar 2004 20:49 UTC

"Command Line is your friend, Page 2/4"
Application of Tillie's model to user interfaces

Before discussing a computer interface for Tillie, we need to find out why she is using a computer. She has heard that computers can make her life easier and quicker. She has heard she could communicate with Eric without paying international postage. Someone told her that she could get groceries delivered to her door using something called 'online'. Basically she wants to see if she can do broadly the same tasks she does every day but quicker and easier. Tillie is not a gamer, a power-user or a hacker. She wants an interface that assumes you will be using the computer as much like a domestic servant as like a tool. We may assume that some knowledgeable user has initially set up her machine and Internet connection since Tillie will use the computer much like her washing machine, dishwasher and cooker. All of them are appliances installed, connected and tested by a qualified Engineer.

We may now design an interface for Tillie to allow her to move some of her daily tasks to the computer. Referring to the previous section we can specify the desirable properties of a hypothetical 'perfect' computer interface from the point of view of mapping easily onto Tillie's existing model of the world:

Tillie is used to having dialogues with things or people. Such dialogues make her feel in control of what is happening and puts her at her ease. Like most humans she (perhaps somewhat unfairly) feels happier when she perceives herself to be the most intelligent or knowledgeable person in the dialogue.
At any one time, Tillie's attention is focused on one particular task. Other tasks may be progressing in the background but Tillie need not have to give them her attention until she wants to.
The interface must, from first switch on, provide a clear direction for a new user to go. At each stage it should encourage experimentation while providing adequate notice of important or key features.
Different task elements or objects have a place or method of access that is either well known or readily discoverable. Related tasks should be in nearby places. Tasks are related both by similarity and by concurrency; the letter to send is placed near the door so that Tillie sees it when exiting the house.
Appropriate Notifications
When tasks wish to inform Tillie of an event, the notification level should match the importance of the event. The kettle boiling is a small audible click, the fire alarm is a constant loud ringing. Tillie may choose to ignore any of these without interrupting her task but is aware of the relative risks in each case.
The Command line - a 'perfect' solution?

In the remainder of this essay I will discuss why I believe that a command line interface (CLI) similar to that found in Unix and Unix-like operating systems is a surprisingly good match for Tillie. I will use some examples from the trial I conducted. I shall also describe how the existing Unix-like interface matches and extensions which could make it even better for Tillie. I'll discuss each of the desirable properties above individually.


The command line is all about dialogue. Newbies communicate with the computer by giving it commands/asking it questions and reading the response. All interaction is done via the keyboard, something familiar to the users in the CLAIT class, often from their experience of typewriters. One can give the users the mental model of writing the computer notes, or talking to it via Instant Message (depending on the experience of the newbie, quite a few middle aged newbies were familiar with MSN).

The mouse was avoided initially. The command line is one-dimensional with a single point of concentration: the cursor. The vertical axis of the screen is always time and provides the newbie with a constant reminder of what they did along with a record to show their instructor when they have problems. Introducing a mouse causes the vertical axis to be both time and space depending on the nature of the program running. Also the users must get used to using a mouse, not easy for a new user let me assure you.

Users find the model of CLI dialogue with the computer natural. Indeed one user has, when instructed in the basics of the Unix command line, said "Oh I see! I talk to the computer in text [speak]" referring to the common practise of removing vowels from SMS messages sent to and from mobile phones, especially in the UK. Once she had noticed this, she progressed rapidly in remembering the command names now pronouncing commands like 'mkdir' as 'muk-dear' as opposed to 'em-kay-dee-eye-ah'.

Experience with the CLAIT class above showed two things about the CLI method. One was that it mapped very naturally onto existing models for interaction. Users very quickly picked up on the '<verb> <subject>' syntax for commands and found it very useful. The second, most important, thing was that users reported that they felt more 'in control' with the CLI.

This should possibly be discussed further. It was explained to the users that computers were stupid and would only do as you told them. They understood a special restricted form of language "as if you were talking to a child". "Much like children," it was said, "they should be told specifically what to do and if they don't understand they will ask for more detail". Users were assured that no effect they could have on the computer by typing could harm the PCs and that any accidental "removals" of files could be repaired.

With this knowledge in place, the users immediately felt more in control as they perceived themselves as more intelligent, having to phrase their request in simple enough terms for the computer. This was opposed to their experiences with GUIs where they were the ones that felt like children pushing buttons at random on control panels. Since they were afraid that pushing the wrong button could cause disaster they were less inclined to experiment. With the CLI they could experiment secure in the knowledge that if the computer didn't understand, it would complain.

This superior attitude encouraged experimentation because it gave the users the impression that they would actually have to state specifically how to break the computer if they were to make the machine do something wrong, something they were confident they were unlikely to do.


It was noted by the users that the CLI was less confusing because "not everything is on the screen at once". The CLI allows the user to concentrate on one task at a time and they were happy not to have interruptions from other tasks. The users reported that with a GUI they were always getting distracted by having to swap between the mouse and keyboard and click carefully less they bring up the wrong window and interrupt what they were doing.

Some users asked if it were possible to make the computer do some tasks "without waiting for them to be done". These users were introduced to the job control features of the bash shell. Here a small script was written by myself called 'inbg' which was functionally equivalent to the ampersand (&) modifier in bash. It is worth noting that the user who made the "text speak" remark immediately started pronouncing this "in background". The users were initially confused by the termination messages given by bash when a background task terminated but once it was explained that this was the computer saying that it had finished the task they found it very useful.

At this point the users started to diverge between those who wanted their finish notifications to be printed as soon as the task finished and those that liked the way "the computer waited for me to finish what I was doing before telling me". This will be discussed further in the section dealing with extensions.

Table of contents
  1. "Command Line is your friend, Page 1/4"
  2. "Command Line is your friend, Page 2/4"
  3. "Command Line is your friend, Page 3/4"
  4. "Command Line is your friend, Page 4/4"
e p (0)    94 Comment(s)

Technology White Papers

See More