System design in rehabilitation computing.

That's a fairly pretentious title for a fairly unspectacular activity, but it captures the idea. The train of thought began when I first started to look seriously at computer systems for rehabilitation around 1988, and I found myself horrified by the dreadful design - or lack of design - which I found. With some honourable exceptions, programmes were badly structured, and extremely fragile; any unexpected input was quite likely to lead to failure, which could typically not be corrected except by restarting the computer, which in turn was not uncommonly impossible for the person trying to use it. The software was usually completely inflexible and not transportable, and totally lacking in documentation of any sort. Much of it had been written by amateur programmers who kindly agreed to write a programme to perform some special function for a friend, but lost interest as soon as the interesting programming was completed.

This seemed to me to be unsatisfactory, so I looked around for design technique standards for the field. I couldn't find any, so worked out some guidelines. I saw the problem as one of working out a good specification. Given a specification, we are already reasonably good at producing a programme which more or less satisfies it, but there appeared to be no criteria by which specifications for rehabilitation computing systems could be formulated.

I put in some work on this in 1988, and have returned to it occasionally since, but while on leave in 1996 I was able to work it out more thoroughly. Now I'm much more enthusiastic about it, and I think there are some very interesting things to be done. Two lines of development in particular seem to be worth investigating further :

An informal design technique :

This is the direct extension of the original idea. It's a sort of "walkthrough" technique for system description, and can be used as a design aid. There are a lot of ideas, more or less written down in various forms, but they need drawing together into a coherent method, and testing out on a wide variety of examples.

A formal notation :

While at York in 1996, I came across a notation which fits the informal description extremely well. Using this notation ( based on "Interactors" ), the descriptions used in the informal method can be written down much more precisely, leading to the possibility of proving properties of systems, or constructing simulators with which performances of different systems can be compared.

Some background.

The technique which I advocate emphasises the importance of designing to transmit ideas. The aim in communication systems is to copy an idea, as faithfully as possible, from my head to yours, and a system should be designed in order to facilitate this task. It seems to me that many current systems are designed with less ambitious aims - commonly to transmit characters or words, which is the sort of aim appropriate to most computer systems. While we shall certainly wish to transmit characters and words, and to do so as efficiently as possible, it is helpful always to bear in mind that the real aim is to transmit ideas.

In summary : for a system intended to be used primarily for communication between people, human-computer interaction is not enough; if we don't start the design with the aim of achieving human-human interaction, then we'll probably end up with an inadequate system.

( Let's be realistic - we'll probably end up with an inadequate system anyway. But if we aim high, we might just do better, and, if nothing else, we'll find out more about the problems which have to be solved. )

An example illustrates the distinction. The words "I work in Auckland" have a simple meaning, but this can be modified in several ways by adding emphasis in speech, or in printed form :

The implications in any real instance depend on the context, but without the emphases you can't tell what might be intended. If you concentrate on transmitting the words, you omit the emphasis, which significantly changes the meaning - but if you concentrate on the idea, you will consider making provision for the emphasis.

Is it any use ? That depends on whether by using emphasis ( or whatever other non-verbal technique we might choose ) we are able to convey more useful information in the same time. In fact, such features of speech can be very effective means of conveying some sorts of information, so it is at least worth trying to find out whether reserving a few bits per second of the valuable channel capacity to carry an emphasis signal gives a net gain. Perhaps it won't, but if we don't try, then we'll never know.

More if you want it :

TECHNICAL REPORTS :

• Report #46 : A view of rehabilitation computing.
• Report #54 : The representation of information in rehabilitation computing.

WORKING NOTES :

• AC96 ( Adding non-verbal information );
• AC97 ( Interactors in systems design );
• AC98 ( Adding non-verbal information );
• AC99 ( Kites );
• AC102 ( Analysing an interface for music );
• AC103 ( Analysing a rehabilitation interface );
• AC104 ( How many sentences mean approximately X ? );
• AC105 ( Analysing a chord keyboard );
• AC106 ( VTA and a theory of communication );
• AC107 ( More kites ).

Go back to me ( Alan Creak, in case you've forgotten );
Go back to Computer Science.