Outside of conventional classes, outside of schools and universities,
how do people learn things? It can be very different from the way that
we organise learning for students. Where learning is part of working it
is often incremental and informal. I am particularly interested in how
people learn how to use information systems (a loose term encompassing
word processors, spreadsheets, email systems, web browsers, databases,
etc.). For many, a key form of learning is not by going on a training course
(the closest analogue to formal school and university based learning) or
by reading the manual or the online help. Instead they lean over the shoulder
of a colleague at work who is using the system under discussion. Or they
ask a colleague to come over, and who leans over their shoulder and helps
them out. Clearly not all of these frequently occurring interactions are
successful or lead to a wonderful learning experience. The colleague may
not be able to help or may be too helpful and do it all so that the 'learner'
knows little more at the end of the interaction. Nevertheless I believe
it is useful to study these interactions in order to tease out the criteria
for a successful learning interaction. Maybe we can teach skills of help-giving
and even of help-requesting. For example, saying "I'm stuck" isn't very
useful. A more detailed question revealing what you know and what you don't
will enable a help-giver to focus in on the problem more efficiently, saving
the time of both participants. Much can be learned by examining the practice
of help-giving professions such as librarians and software support lines.
However as a computer scientist, that is just the starting point of my interests. I am concerned with the design of systems and particularly the interfaces to systems that can help people to get their work done. If part of the job is learning how to use the damn thing, and if people sometimes learn by this over-the-shoulder approach, then how can we design systems to support this activity? This raises some interesting issues. The domain of Computer Supported Cooperative Work (CSCW) looks precisely at how to design systems to support more collaborative systems. In the case of Over-The-Shoulder Learning, EVERY system is potentially a CSCW system (albeit often for just occasional 5 minute bursts). But these systems were never designed for collaborative use. They were designed on the assumption that they were for single use. Take the example of a library's online public access catalogue (OPAC). The normal assumption is that these are used by individuals, one per terminal (although it is a shared database, the job of the designer is to hide, as far as possible, any awareness of its sharedness which may manifest itself in annoying delays caused by the activities of others). And yet, as we observed in a study at Lancaster University, a significant minority of interactions at OPAC terminals involve some degree of collaboration, with students clustering round a screen to find books or to help their friends. The situation is (unsurprisingly) even more marked at the help desk where the librarian was observed often to twist her monitor round so that what appears on the OPAC screen can be used as a resource to aid the conversation in getting from what the student vaguely wanted to what was available in the library and how to find it.
That OPAC screen was never designed to support collaboration, but it is being used to support collaboration and especially informal incremental learning of some of the functionality. So how can we design in features to its interface to help that process along? That is something I'm working on. For now, one aspect is very clear; it should allow a better context of what the user has tried so far. Surely we should encourage learners to play around with a system, to try and figure out if they can solve their problem on their own. But sometimes they will need help. What the helper would like to know is what the user has tried so far. But that is extremely difficult for a novice to say. (As we have discovered, it's even difficult for an expert - the natural tendency of people to auto-correct led an expert to be convinced that he tried one thing that failed when he actually tried something similar but erroneous). The system needs to be able to record what has been tried and be able to provide this information in an easy to understand visualisation. A mere transcript is not sufficient because they can get so huge, particularly in the case of a doggedly determined user who then will claim in response to pretty much any suggestion: "But I already tried that and it didn't work". Not only is that not useful in the help-giving interaction but it is demoralising for the student who may start to doubt her own competence, or that she just does not have the magic ability to get the computer to work. Being able to show such a student that she very nearly did the right thing (from the context report) but just missed one step that led to her being unable to figure it all out on her own is a much more motivating and likely effective educational interaction.
The design implications for this kind of visualisation are intriguing. We need a visualisation of the process of using a computer system. That often means a visualisation of the process of using a graphical user interface. One could just record the whole interaction and play it back like a movie, but as noted above, that is likely to be overly cumbersome. It is a start, but we should be looking for potentials for abstraction so that an expert can quickly scan the interaction to get a broad impression of activity, before deciding which bits she needs to examine in detail in order to offer the most efficient help. The Unix history command is a good example from the world of command line interfaces. It lists the commands a user has recently issued. It is relatively concise, partly because of the terseness of Unix as a command line system, and partly because history lists what the user did, but may require considerable mental processing to determine the consequences of those actions. It seems that this example of a text-based representation of the process of text based interaction is relatively straightforward, and history is a simple but intriguingly powerful help-giving tool. We have been exploring the development of graphical representations of the process of interaction with text-based interfaces (specifically telnet based connections to library catalogues and bibliographic databases - see the references). The graphical representation allows for interesting ways of visualising activity over time. The next stage is to consider graphical representations of the process of using graphical interfaces.
Another related piece of work is an on-going study of help giving by secretaries in an office. The secretaries explained to each other how to use various features of the software they used (including word processors and email programs). They seemed to prefer giving and receiving help from each other than from the more expert systems administrator. Partly this can be accounted for by the ready accessibility of colleagues in the same office, and that their colleagues could explain the technology in terms of real work tasks. Although not skilled computer scientists, the secretaries used a range of sophisticated techniques in their help giving, while the studies revealed the inadequacies of existing software to support this kind of use which I claim to be widespread and important.
The focus on learning in a work context raises some very interesting issues in learning and its implications for design. The learning is in competition with the work. People have to make decisions (conscious or unconscious) about whether it is worth the effort of learning how to use a new feature. Would that time be better spent in just getting the job done in the old (perhaps more inefficient) way? I am attempting to develop a calculus or cognitive economy of learning to show why on occasion it is entirely reasonable and even rational for people to fail to improve substantially in their use of software.
The analysis of informal help giving needs to incorporate self study and exploration as well. People also try and figure things out on their own. Often it is only when they are stuck that they call in a colleague for help. The result is that the helper then has to both help the user get out of any mess they are in (whether they are aware that they are in a mess or not) as well as help them do the correct operations to match the users goals. The complexity of this task can lead to a learned helplessness where a user always asks for help first time rather than exploring and experimenting. If the consequences of that are potentially costly in terms of time to recover from that exploration (and indeed identify what has been done that is in need of repair), then it is rational to avoid personal exploratory learning. Thus we need to design systems to support recovery from personal exploration and to maximise help-giving interactions. This includes systems and interfaces that can help contribute to the conversation over the typical help-givers question “What have you done so far?” This can be extremely difficult to answer accurately.
In summary, I want to explore the following issues in interface design