Written by David Tebbutt, Personal Computer World 02/89 - scanned
In the last of his visits to Xerox EuroPARC David Tebbutt learns about Austin Henderson's work in tailorability and development, and his belief in reconciling system design with the changing needs of the user.
Austin Henderson spends his life whizzing between the Palo Alto Research Center in California and the UK equivalent, EuroPARC in Cambridge. When in the UK, he heads up the Tailorability and System development research efforts. He is a kind of human bridge, facilitating cooperation between the two laboratories.
Henderson's view of the world is that effective systems aren't simply designed by producers then used by users. They are developed over time by a wide range of individuals from the system architect right through to the end user. Feed back from the various participants results in change before both and after the product reaches the market. Once in use, people adjust their work practices to accommodate the new technology and, as the nature of the work changes, the technology is modified still further.
Photocopier Patterns
Although his research centres around computer systems, Henderson likes to illustrate the points he makes by using the photocopier as an example. Installing a photocopier is not just a case of plonking it on the floor and expecting everyone to use it. People need to decide things like where it will go, what systems it replaces, who will operate it and how it will be paid for. They then have to figure out how to make the most of it. It's bound to have features they hadn't anticipated and, maybe, lack some they had expected.
Users find themselves involved in the process of discovery, each trying to assess how the copier affects their own work. They all ask themselves 'is this new machine better for me, or worse, than what I had before?'. This adaptation of the individual and the environment to a new system is central to Henderson's research. His team studies the processes of adaption and looks for ways of helping users and designers to come up with better systems.
Even a relatively rigid product like a photocopier stimulates new patterns of usage as people's awareness grows. The manufacture will try to build into the machine as much flexibility and user control as possible. After all, the last thing it wants is for users to call each time they want to do something new.
If the humble photocopier stimulates new patterns of usage, computers must do this to a far greater degree. All the more reason for putting control of this adaption into the hands of the users. Henderson wants to push design as far down the development chain as possible. He thinks that design is a process which should continue even while the product is in use, partly because users often don't know what they want until they start using it.
To continue the photocopier analogy, Henderson talks of users finding that the image doesn't fit on the paper, so they re-orient it or use a different size. This is an admittedly trivial example of what he refers to as 'design continued in use'.
Henderson regards photocopiers as mid-way between low-tech unchanging systems, like paper and desks, and high-tech complex and malleable technologies like computers. Even with static technology like paper, we adapt it to our needs as we use it. We fold it, tear it, staple it and file it according to our personal preferences. But, once other people start to get involved in our paper systems, things change. It then becomes part of a wider system.
The public use of paper involves a lot of agreement between the affected parties. How is it to be filed? Where? What about access by other people? Conflict arises if everyone does their own thing. And that's just paper.
This sort of problem is at the heart of Henderson's tailorability issue. It's the need to reconcile the interests of the individual with those of the group. It's also a question of striking a balance between the design of the system and the user's preferred way of doing things.
Henderson's team focuses much of its research effort on tailorable human interfaces. These enable users to experiment with changes to their systems without the active involvement of any of the systems designers, developers, analysts, consultants, support staff and tinkerers who usually have a hand in the more conventional systems. For such a system to work it has to be very easy to use and, in EuroPARC's view, be as simple as moving icons on the screen.
ROOMS
Henderson is co-inventor, with Stuart Card, of just such a system, called Rooms. This is a window management system which lets users assemble 'Rooms' of the programs and data they need for different tasks. In the 'Mail Room', for example, they may have a word processor, an electronic mail program, a chat window, an address book and an on-line diary. This kind of system works very well, but Henderson would like to find ways of enabling users to make even more complex alterations to their systems.
One of the major causes of user alienation and dissatisfaction with computer systems is that they cannot articulate exactly what they require of the end system. In fact, they usually don't know because they have no idea of what the system will be capable of. What is delivered is usually the system developer's interpretation of what he or she thinks the user wants. Blame is hurled back and forth but it's not really anyone's fault. Until users are actually sitting in front of the finished product, they don't fully realise what they should have asked for in the first place.
Henderson would like to see users in this situation being able to take the design further and to adapt it to their particular working methods. He wants them to be able to imprint their own way of working on the system. So, rather than simply replicating their working practices, the computer will begin to complement and enhance them.
When users are able to tailor their systems, they will often want to share their discoveries with others. They will also want to find out about other people's discoveries to see if the problem they face has already been solved.
Traditionally, programmers have been well known for their resistance to other people's ideas, preferring instead to reinvent their own version of the wheel. This is usually called the NIH, or Not Invented Here, syndrome. Apparently, NIH is less of an issue among users when the solution is directed at improving their work environment. Henderson actually had someone else's 'discovery' running on the screen while he was being interviewed. The program simply stepped through a series of clip art illustrations to prevent 'bum in'. Henderson was obviously immune, but it was highly distracting for the interviewer (me).
Henderson would like to design hooks in the technology to help users to find others of like mind, and locate the community of users who are most likely to want to share ideas with each other. He returns to the copier for more parallels. Setting the contrast for pink forms might be a problem. One day, someone discovers the right combination of settings. Their community is all the 'pink form users'. One way of communicating the discovery might be to install a bulletin board on the wall by the photocopier. This would be a user implemented solution. Or, if the designer of the machine gets to hear about it, he or she could build in a special panel onto which users can stick post-it notes.
This, at the photocopier level, is how patterns of use are developed and shared and the technology evolved. Actually, Henderson believes that non-technological solutions like this are often appropriate, even among a community of networked computer users. He believes 'it is the arrogance of the technologist to assume that all problems have a technological solution.'
On the InterLISP computer system at Xerox, users are able to hide all sorts of complexity, from a note to a full-blown application, behind a device called a Button (see also last month's EuroPARC article in PCW). In one sense Buttons are similar in concept to keyboard macros. InterLISP can be driven from direct commands, some of which can be very complex.
Rather than run the risk of error, Henderson simply makes the most common ones into Buttons, activating them whenever he needs to repeat these commands.
The difference between a Button and a keyboard macro is that the Button is a movable, copiable object and it can be a keyboard sequence, a program or a document. Henderson says: 'I, who can do something arcane, can do something at my workstation, put it in a Button and send it to someone else.' A Button can be sent over electronic mail, on disk, through a direct link or through a chat window hooked up to another user. This is one way of sharing discoveries with others in a way which is very simple for the users. When the Button arrives at its destination, a click of the mouse button activates it and the program executes or the document is displayed.
Henderson's 'Rooms' is also a deceptively simple technique which enables users to define the computer resources they need for any task. This enables them to overcome the limitations of a small screen and the problems which come from trying to display too much information at the same time. When Henderson was dreaming up Rooms, he reckoned that a typical user would need a screen the size of a dining table to display all the possible activities and files. This was obviously impractical and led to the idea of having a different workspace for each task.
A Room is simply a screen, which displays all the application windows a user needs for a given task, in the layout best suited for that task. A user might have a programming room, a writing room and so on. Some applications may, and usually will, appear in several different Rooms. 'Door' icons can easily be defined, which take the user directly into other Rooms. Moving from one Room to another causes all the windows in the current Room to be closed and those in the new Room to be opened. Users can, if they wish, take active windows with them when they change Rooms. Otherwise, the new Room is in exactly the state it was left in the last time it was used.
Another way into a Room is to go in through the Overview, a display of all the Room icons. If users have the time, they can design some quite elaborate Room icons and Room layouts just as they can with the real rooms that they live and work in.
Designing Room layouts and icons doesn't involve the users in any systems analysis and design, they just do it. The benefits of icons and background designs are that they make the workspace attractive and they also make it easier to find Rooms. Since the creation of a Room is so simple, users will even find themselves setting up ad hoc, or transitory, Rooms for one task and then throwing them away immediately afterwards. The creation of a Room results in a source code file in Rooms' own LISP structure. The more adventurous users (programmers perhaps) can edit these and create new ones from scratch. Most users will make their Rooms simply by opening windows and moving icons into them. The source code would then be generated automatically.
In Henderson's EuroPARC world, everyone has access to a Xerox workstation running InterLISP and which is networked. His environment is designed so that no-one else can rummage around from their remote workstations. If he wants to share stuff with others, he likes to do it explicitly. He would like to see a system that incorporates security measures which give remote access to certain Rooms to appropriately authorised visitors. Some would still remain strictly private. Within those Rooms, individual documents might be sensitive, so they might be fronted by a marker saying something like 'For information about this, please call Fred Bloggs.'
SUMMARY
Summarising his work at EuroPARC, Henderson says that the thing to be tailored is not just the technology, it's the practice of its use. The technology is at the centre, but it is work which is being tailored. He stresses the fallacy of seeing design and use as separate stages in the creation of a usable system. He focuses instead on design as an on-going process while a product is in use.
He thinks it is worth pulling out the theme of substrates. The different people involved in the design process operate to different timescales, using different skills.
He reiterates the aim to push as much as possible of a system's tailorability down towards the user, but without making it compulsory. Users should be able to use a system as it arrives. The attitude should be 'you can tailor it if you want'.
He wants the technology to help the social process of information exchange, especially through the capture of knowledge and of its communication.
Behind the Doors
In last month's article, we learned the importance of passing on, to future designers and programmers, the rationale behind an application. It would be relatively easy for someone to pick up the Rooms ideas and to take them further. What they may not appreciate is why the program has been designed the way it has. Henderson and Card identified nine desirable properties for a user interface which would enable users to switch between tasks. Most user interfaces concentrate on helping the user follow the current task through to completion. The truth is that users like to switch back and forth between several concurrent tasks. With a command line system this is exceedingly tedious and, even in a normal windows-based system, much effort can go into moving. resizing and repositioning windows and shrinking and expanding icons. Added to the physical problems are the mental ones of keeping track of all the various tasks and their related data files.
The two problems Henderson identifies in task switching are: a) the amount of time it takes; and b) the complexity of remembering how to invoke the other task and how to get into mental context. He and Card identified three related requirements for an effective task-switching system: fast task switching, fast task resumption, easy to re-acquire mental task context. Fast task resumption is neccesary when the new task is a digression or a short sub-task and users need to get back 'in the swing of things' more or less instantly. A user might need to work with rapid access to a couple of word processor documents, a files browser, a prompt window, a thesaurus, a dictionary and a clock. The user may not be able to have all these windows open at the same time, so the access time is slowed while windows are closed and new ones opened.
These observations led to three additions to the requirements list: access to large amounts of information, fast access to information, low overhead. Although users do switch between tasks, they are only involved in a single task at a time. This led to the decision to set up independent workspaces around each task and to allow fast transitions between them. But the task environments quite often require access to the same resources. This led to the next three requirements: Engaged Tools shareable among several tasks, collections of Engaged Tools shareable among tasks, task-specific presentation of shared Engaged Tools. 'Engaged Tool' is the term used to describe a Tool and the data it contains which makes it unique.
The three properties above enable an Engaged Tool to be used in multiple tasks, for groups of regularly used tools to be used in different tasks, and for the appearance of the Engaged Tool to be varied in different tasks. The Rooms concept, that of a screen-sized workspace containing a number of Engaged Tools, was created to enable the rapid transition between tasks. The icon-like Doors give a one-way route into another Room. Any Room may have several Doors. Because users will want to use the same window in multiple rooms, Henderson and Card had to allow it to change its position and appearance between tasks; otherwise it would impose an impossible constraint on the design of subsequent Rooms. They came up with the abstract concept of Placement, which combines the identity, position and presentation of a Window in a Room. This splits the functional aspect of the window as a Tool from its appearance and position on the screen.
Many users will want collections of Engaged Tools to appear in a number of different Rooms. Furthermore, they will want all changes made to the collection to appear at the other locations as well. An example, according to Henderson, might be a control panel with an executive window, a prompt window, a clock and a system memory indicator. The answer they came up with was Room Inclusion, the ability of one Room to contain another. This way, the common elements could be defined in a Room of their own and then that Room could be included in all the other Rooms that required the information. Sometimes users will want to carry Engaged Tools to another workspace or they may want a permanent collection of Engaged Tools to go around with them, regardless of destination. In the first case, the users can enter a mode in which they select the windows to be carried to the next Room, then they go through the door. In the second case, the act of going into the next Room causes the permanent set of Engaged Tools to appear on the screen. The user would have defined these as a Room first.
Henderson describes the first of these methods as putting the Engaged Tools into the user's Baggage and the second as filling the user's Pocket. As you can imagine, a complex set of Rooms with all sorts of interconnections can cause serious navigational problems. The most obvious of these is how to get back to the Room last used. The answer comes in the form of a Back Door. Because Doors are one-way, Rooms automatically creates a Back Door, in inverse video, which takes the user back to the Room they just came from. This Back Door is destroyed after a single use.
Henderson and Card have provided two solutions to users who have forgotten which rooms exist and how to reach them. The first is a pop-up menu of all the Room names. The other is the Overview mentioned earlier which contains a set of Room pictographs. Each looks like a miniature screen showing its layout and reminding the user of the Tools it contains. The name of the Room is underneath and they are all listed in alphabetical sequence. Other help is provided by allowing the user to instantly expand a Room pictograph to full size or to call upon a drawing command to show how the Rooms are connected.
The final set of facilities relate to the user's need to quickly change the arrangements of Tools and windows in the various Rooms. While in a Room, the user can create, move, shape and delete windows. At the Overview level, the user can copy, move, reshape and delete windows and have the changes reflected within the Rooms. Users also need to save, restore and share their Rooms with other Users. This is all done using the ubiquitous Buttons. The discoveries made as a result of the development of Rooms are that users experience a strong psychological sense of relief when their tasks are separated into different Rooms. They actually end up with a far larger workspace - Henderson estimates it is the equivalent of between one or two five-foot desks in terms of raw screen space. The users tend to make three different types of Room. Firstly they have functional Rooms, such as a mail Room. Secondly they have project Rooms, for the different tasks upon which they're engaged. Thirdly they have management Rooms where they keep Tools for systems initialisation, storage management and so on.