Reprint: Human Factors in Systems Design, 1987

Published in People and Computers III, Edited by D. Diaper & R. Winder, British Computer Society, 1987

 Human Factors in Systems Design: A Case Study

Christopher Finch Reynolds

Department of Computer Science, Brunei University, Uxbridge, UB8 3PH, United Kingdom.

MicroCODIL is a teaching package which also acts as a test bed for human factors research in the CODIL project. This paper shows how human factors can be considered at all levels of systems design, starting with the way that poorly structured information is represented and processed, through the provision of diagnostic windows, to the use of colour to syntax check lazy input. The need to minimize the effects on the user of the limitations of low cost hardware is also considered.

1. Introduction

Far too often the letters H.C.I. are interpreted narrowly to mean "Human Computer Interface". Such a cosmetic approach usually means that elegant looking systems turn out to be wolves in sheep's clothing when things go wrong, or requirements change in an unexpected manner, and savage the user. It would be more beneficial if H.C.I. was extended to mean "Human Computer Integration" and involved a properly integrated approach to human factors within the discipline of system design. The resulting systems would, ideally, provide a symbiotic relationship between the computer and the user that could survive the intricacies of real life operational requirements.

This paper shows how such an integrated approach has been used in the design of an information technology teaching package called MicroCODIL (Reynolds, 1986 [10]). This is done by identifying the following design areas and showing how human factors have been taken into consideration in each area.

• Information must be represented in a way which is immediately recognisable to the pupil as being relevant to his studies. If the information is ambigious, incomplete or ill-understood (a common intermediate stage in learning about anything new) it should still be possible to represent it. This allows the pupil to explore the consequences of his own way of thinking about the problem, in a way which is analogous to Papert's approach to using Logo.

• The average school child can be assumed to have no knowledge of formal mathematical logic or advanced psychological models. The underlying processing model therefore needs to be extremely simple, and explicable to all. To be useful this simplicity has to be achieved by generality rather than by restriction. (Many existing teaching packages work by restricting the pupil to precise mathematical models. For example, all input might have to fit into a normalized relational data base, or all rules might have to conform to first order predicate calculus. The approach described here should be considered to be complimentary to these formal techniques.)

• Any computer activity can go wrong, particularly if initiated by children who are learning. An "expert system" approach is needed so that the pupil can find out what the system knows, how it got there, etc .. This may be required at either the system level, or within the context of a specific classroom activity.

• In the class room context, particularly when working with younger children, the keyboard/display interface is extremely important. A powerful package can easily find itself set aside because it does not present a friendly enough image.

• School microcomputers are often short on facilities compared with the latest personal computers. Any non-trivial software system is therefore going to involve some compromises. It is essential to consider the human factor consequences of such limitations at an early stage in the design process if they are to be minimised.

2. Background to MicroCODIL

A full description of MicroCODIL's pedigree is beyond the scope of the paper. The initial CODIL proposals (Reynolds, 1971) were based on earlier unpublished research into the design of commercial software that was to be easy for sales staff to use, with further studies relating to scientific information storage and retrieval. An experimental data base software package was implemented in order to test the ideas, and this has been used for a wide variety of application. The ability to handle comparatively poorly structured information was tested using historical data (currently the files contain 5,800 biographies) an ongoing medical project (Reynolds, 1978, 1986 [9]), and data for a D.E.S. report (Johnson et ai, 1982). A subset of the file handling ideas were adopted by a widely used personal computer data base package called Superfile (Southdata Ltd., 1986). Interactive tests included the use in teaching packages (Reynolds, 1981) - including one in which about 500 undergraduates wrote essays about their experiences over a period of 5 years. This was written up as an interactive electronic publication (Reynolds, 1983) as a spin-off from the BLEND project.

CODIL has two major limitations. The first is a somewhat uninspiring user interface designed for low baud rate connections to scrolling terminals. The second was a lack of an adequate theoretical model. MicroCODIL started as an experiment to design a fully interactive interface. It soon became obvious that a useful teaching package (based on the earlier main frame work) was possible (Reynolds, 1984, 1985, 1986 [10]). However in order to make the most of the small computer involved a total reassessment of the design concepts was undertaken. This has lead to a far deeper theoretical understanding of the "CODIL" approach (Reynolds, to appear). In particular it has been shown that the underlying architecture is significantly different to existing conventional and artificial intelligent languages. A full discussion of this novel architecture is beyond the scope of this paper.

3. The MicroCODIL Package

MicroCODIL is best considered as a knowledge base shell which is designed to handle poorly structured information in a flexible manner. It is aimed at the school market and the software is supplied with a dozen ready made knowledge bases, and a similar number of worked problem solving examples. The knowledge bases range from simple information retrieval exercises via interactive lessons to mini-expert systems and artificial intelligence examples. The package can be used to demonstrate a wide range of information processing ideas from data bases, through approximate and fuzzy matching to production rules and expert system concepts. However it can also be used to support actual applications in subjects such as biology, chemistry or history.

MicroCODIL is designed to run on the BBC Model B and Master microcomputers with discs. These machines were chosen because they are very widely available in British schools. Unfortunately the Model B has very limited memory (32 Kbytes for all purposes on the basic model) and may only have limited disc capacity (lOO Kbytes). To meet processing speed targets, implementation in BBC Basic and 6502 assembly language was the only feasible option. There are also serious limitations in the standard BBC disc filing system. These limitations mean that it has sometimes been necessary to balance user convenience against the need to have a system that is usable within limited school budgets.

4. The Representation of Information

A user oriented information processing system should reflect the user's view of the real world which may well include incompletely understood information. MicroCODIL attempts to provide a much greater degree of freedom to handle such poorly structured information than is provided by conventional data base systems. In theory a MicroCODIL knowledge base consists of a collection of items, where an item is recursively defined as a collection of items. A full discussion of this conceptually simple, but infinitely recursive, definition is given in Reynolds (in prepatartion). Instead some simple, non-recursive, examples will be given. These are taken from a knowledge base of elementary chemistry, which contains the following collections of items (among others):

CHEMICALNAME = Lead

USE = roofing

COLOUR = grey

HARDNESS = 1

MELTING POINT = 327

NAME = Copper sulphate

CHEMICALNAME = Copper (11) sulphate

USE = Copper plating

USE = fungicide

APPEARANCE = Crystalline

COLOUR = blue

HARDNESS >= 3

HARDNESS =< 4

The first of these describes the properties of lead and it is quite easy to imagine such information being stored in a relational data base. The second statement is more interesting in that USE occurs twice and HARDNESS has two values which define a range. If a visual comparison is made between the statements it will be noticed that the second includes a NAME and APPEARANCE item, but does not contain a MELTING­ POINT. Although not immediately apparent, it should be noted that the order of the items is immaterial.

If the intended user (a pupil learning chemistry) asks questions of the second statement he will expect to find that USE = fungicide? and HARDNESS = 3.5? are true and that MELTINGPOINT = 205? is false. These answers are so obviously correct to anyone observing the display that one needs to be reminded that most computer systems require the user to be explicitly aware of multiply valued items, ranges (perhaps in the form HARDNESS-MAX and HARDNESS-MIN), and "missing" data.

If we consider "recursive" examples, the pupil would find that, for the first example, NAME = Lead?, SOLIDS? and HARDNESS = soft? are true. In chemical terms this should not surprise him, although in conventional computing terms such results would be unexpected. NAME = Lead? is true because a higher level item CHEMICALNAME (ISA) NAME extends the meaning of CHEMICALNAME = Lead. SOLIDS is an item in its own right, and it is also a reference to a construct (i.e collection of items) which contain the above examples. It is true because the description of lead is true when compared with itself. In the third case there is a higher level item, HARDNESS (CONDITION) = HARDNESSTYPE, which is used to link HARDNESS with a construct of alternative definitions called HARDNESSTYPE.

It should be noted that explicit structural parentheses, such as those that confuse the user of Lisp or Prolog, do not exist in MicroCODIL.

5. The Processing Model

In most conventional computer systems the internal workings are hidden from the user by layer upon layer of software. However the greater the variability of the information being processed the greater the need for the user to understand what is being done on his behalf. If the stored program paradigm is used programs rapidly become more complex, and hence less understandable, as the variability of the data being processed increases. What is needed, in human factors terms, is a paradigm which the complexity of the processing model remains constant (and comparatively simple) regardless of the complexity of the information being processed.

In MicroCODIL this is achieved by implementing a simple paradigm based on a highly recursive short term/long term memory model driven by a "decision making unit", or DMU, which compares pairs of items, or declares selected items to be true. The reason for choosing this approach is motivated by the need for a paradigm which is easy to explain to people with no knowledge of computers (or formal psychology). There has been no attempt within MicroCODIL to specifically explore more sophisticated psychological models, except where it is felt that these would be meaningful to the unsophisticated user. A separate paper is in preparation exploring the paradigm in detail. In this paper the approach is briefly outlined, and some simple examples are included to illustrate how it works.

Within MicroCODIL the "short term memory", or "the facts", consists of a list of items (such as the examples given in the previous section) which collectively describe the information context as seen by the DMU. The items in the facts may be direct input from the keyboard, statements "windowed" from the long term memory, or items deduced by the DMU. The total number of items is quite deliberately kept low, so that a user can inspect them all at one time. For most tasks the number of items in the MicroCODIL facts is significantly less than 15.

The knowledge base can be considered as a kind of "long term memory" consisting of constructs, such as SOLIDS. Each construct consists of lists of items, and whenever a construct is identified by the DMU a "window" is opened which contains either a single item (the criteria item) or a single statement (seen in the facts), depending on context.

The DMU is conceptually very simple. It can ask for a new criteria item (from the keyboard or the knowledge base), it can ask if this item is true in the context defined by the facts, or it can "add" the criteria item to the facts. If the criteria item is a construct, or is qualified by a construct, the DMU may be recursively entered. (System function can be considered as dummy constructs which are activated in appropriate contexts.) The logical power of MicroCODIL results from the highly recursive nature of the DMU interacting with the recursive information structure. In par­ ticular, different system behaviours are achieved by dynamically varying the recursive paths through the DMU.

The variety of ways in which the DMU works can be illustrated by a series of examples using the following simple French-English dictionary. These examples are taken from a series of interactive lessons provided with the MicroCODIL software (Reynolds, 1986 [10])

1 FRENCH WORD = aime,

2      ENGLISHWORD = like.

1 FRENCH WORD = animal,

2      ENGLISHWORD = animal.

1 FRENCH WORD = animaux,

2      ENGLISH WORD = animals.

1 FRENCHWORD = arbre,

2      ENGLISHWORD = tree ..... etc

The person who has been brain-washed by too much exposure to conventional computer systems will tend to view the construct DICTIONARY as no more than a file to be searched by a program. It is, of course, possible to use MicroCODIL to write the equivalent of a procedural search program, but most people do not think in terms of von Neuman machines and there are many other more interesting ways of looking at information. Some of these are listed in table 1.

Table 1: Some uses of DICTIONARY

1		Task:		Deduce English word given a French word
		Facts contain:		FRENCHWORD = arbre
		User types:		DICTIONARY
		System response:		ENGLISHWORD = tree moved to facts
2		Task:		Confirm that this word pair is true
		Facts contain:		FRENCHWORD = avion
				ENGLISH WORD = plane
		User types:		DICTIONARY?
		System response:		"True" displayed
3		Task:		Display English for each French word entered
		Definition:		FRENCHWORD (ACTION) = DICTIONARY
				ENGLISHWORD (ACTON) = MESSAGE
		User types:		FRENCH WORD = aime
		System response:		"like" displayed
4		Task:		French word true, if English known
		Definition:		FRENCHWORD (CONDITION) = DICTIONARY
		Facts contains:		ENGLISH WORD = plane
		User types:		FRENCHWORD = avion?
		System response:		"True" displayed

In the first example DICTIONARY is used to deduce an English word, just as if the construct was a set of production rules. In the second example DICTIONARY is used as a boolean function to confirm that a given word pair exists. In the third example DICTIONARY is defined to be a demon associated with FRENCHWORD in the ACTION context. This means that when a FRENCHWORD is typed in DICTIONARY is automatically activated (with the same effect as in the first example). By associating the system function MESSAGE with ENGLISHWORD an appropriate output is generated.

In the final example from table I the response would be true if the facts contained FRENCHWORD = avion or ENGLISHWORD = plane. The mechanism involved is identical to the test for HARDNESS = soft? in the previous section. This is because the DMU is totally unconcerned as to the nature of the items it is comparing, and hence it is totally task independent. This means that a user who has learnt to use MicroCODIL in one application can readily transfer his knowledge to another.

6. Looking into the White Box

It is not sufficient to provide users with a flexible means of representing his information, and an easy to understand processing model. Things will go wrong, and the system may produce results which surprise the user. Alternatively the user may have asked the system to do something impossible. During the design process it was soon concluded that the only way to get users to work with poorly structured information on a computer was to provide a "white box". This is because the less structured the information the greater the need for help, and the harder it is to provide such help using a "black box" technique.

MicroCODIL provides a "white box" approach in that, at any time the system is running, the user may look inside to see what is happening. Because of the limitations of the BBC only one main window into the box can be open at anyone time, but it is possible to switch dynamically between many different windows on demand. For example, the user can view the facts and the items in the knowledge base that the DMU is currently examining. He can look at the output areas, the MicroCODIL "data dictionary", or any construct he likes. He can look at two kinds of diagnostic trace. The first produces a variable speed/single step display in which items from the knowledge base are shown as if they had been typed in from the keyboard. The second provides a continually updated answer to the question "How did I get here?" by displaying the relevant criteria items in the recursive DMU stack.

There are other facilities to help the user. One of the main windows provides a help facility which provides an immediate definition of all system words, and also for any predefined terms relating to the task in hand. It is possible to use this to provide a step by step expert system style commentary on the way the processing is going. Another facility is the ability to associate properties with item names. Thus MicroCODIL can be instructed to pause whenever a new value of PRICE is deduced by means of the definition:

PRICE (ACTION) = PAUSE

As soon as a new value is generated MicroCODIL will give a "Press SPACE to continue" message, and any of the system's windows can be examined before work is resumed.

7. The User Input Interface

The MicroCODIL user can spend much of his time typing in items such as HEIGHT = 180, at least in the early stages of setting up a knowledge base. MicroCODIL contains a number of features which optionally allow the user to minimize their typing, without any loss of clarity. Some of these features are described in detail elsewhere (Reynolds, 1987).

• Case is ignored in item names - so the user could type.

height = 180

• It is possible to define abbreviations for item names. The following show how this is done.

H (SYNONYM) = HEIGHT

H = 180

The latter item is displayed in the facts window In expanded form .

• Item names can only contain alphabetic characters and this allows lazy input. If the user types the letters "HEIGHT 180" the alphabetic letters will be echoed as typed, but when the "1" is reached it will be echoed as " = 1". This means that the user can be lazy, and other variants are supported.
• One of the problems of lazy input is the danger that the system might interpret the input in a different way to that intended by the user. When there is a danger of this the commonest way is for the system to ask "Did you mean .... ?". This warns the user of the potential ambiguity, but also interrupts his flow of thought, and can be very annoying if the system has in fact expanded the lazy input correctly. MicroCODIL gets round this difficulty by the use of colour. Whenever items are displayed, including echoed characters when typing in items, the item name is shown in blue, qualifiers in green, operators such as > and = in red, and the item value in white. This means that the user knows exactly how a key stroke has been interpreted by the colour used to echo it. If a mistake is made it can be corrected by use of the delete key (possibly helped by using the BBC Microcomputer's inbuilt cursor control editor).
• MicroCODIL also contains type facilities (which reject invalid characters in the value) and the possibility of defining demons which check the value, and if it is wrong requesting a re-input of the value only.

8. Fitting the package to the user and the hardware

MicroCODIL is designed for use in schools and its users could range from primary school children running a predefined teaching package up to a teacher preparing artificial intelligence example for an advanced level class. In addition the nature of the BBC microcomputer and its Basic interpreter places restrictions on the way that the software is organised.

These demands highlight the need to compromise between the human factor ideals, the disparate needs of different groups of users, and the need to have software which will run on economically acceptable hardware. For instance an otherwise acceptable package can seem unfriendly if the the screen flickers whenever it is updated, or if there are long, unexplained pauses. The solution of such human factors problems are "invisible" in that they are only appreciated in their absence.

This can be illustrated by examples from MicroCODIL. For instance the screen updating routines have been designed to minimize flicker. Unfortunately one window may be scrolled by the BBC software when updated and it has not been found possible to achieve flicker free update (the screen can take about 0.1 seconds to redraw). This can be most irritating as the user is distracted by the flicker. On the other hand HELP texts are deliberately slowed down when shown to avoid the abrupt appearance of a text which has to be read.

Another factor that was considered was the occurrence of delays. It was decided that interruptions that might last for more than a second or so should be indicated by a message. For instance it normally takes less than one second to access a file from the floppy discs so this event is not normally recorded. However, if the access involves an indexed search the delay may be several seconds and a "Searching" message is displayed. Major changes in software are always preceded by a change of display (usually a "Loading" message) and the screen is changed as soon as the new program is loaded. This may take several seconds - but the user is comparatively unaware of the delays because of the timing of the screen changes. (By comparison many microcomputer software packages take a long time to load, and leave the user with a blank screen to maximize his frustration.)

It was obvious that it would not be possible to provide all facilities simultaneously. This unfortunately means that users have to know some­ thing about the package structure. It was clearly important that the young pupils should be given the most friendly subset, and that the teacher creating new knowledge bases will have to put up with the most inconvenience! It is inappropriate to go into full details in this paper. However it is quite possible to set up the system for the classroom in such a way that it will directly enter a predefined knowledge base which is limited to the facilities chosen by the teacher. For the more advanced user various levels of facilities are possible, with selections being made from a series of standard format menus.

9. Conclusions

This paper has shown how human factors have been used to help in designing a flexible information storage structure, and an easily understandable processing model, which the user can observe at work through a variety of windows. Human factors have also been applied to the user input interface, and the overall problems of presenting the package within the constraints imposed by the need to use low cost. hardware.

There are three lessons to be learnt from this work. The first is that MicroCODIL needs to be scaled up to work on a wider range of computers, capitalizing on the experience on larger systems already obtained in trials with CODIL. Further work in this direction is planned.

The second lesson relates to the processing paradigm. A simple psycho­ logical model has been used to ease the problems of explaining the system to human users (rather than explicitly to examine the psychological model itself). The result is processing algorithm which deals with complexity by becoming more recursive, rather than becoming more complex.

The final lesson is that the research shows that "Human Computer Integration" should be seriously considered, at least for "green site" applications, where compatibility with people is more important than compatibility with established conventional computer systems.

References

1. Johnson, S. & Maher, B. (1982) Monitoring Science Performance using a Computerized Question Banking System. British Journal of Educational Technology, 13, 97-106
2. Reynolds, C. F. (1971) CODIL: The Importance of Flexibility. Computer Journal, 14, 217-220
3. Reynolds, C. F. (1971) CODIL: The CODIL Language and its Interpreter. Computer Journal, 14, 327-332.
4. Reynolds, C. F., Sutton, G. & Shackel, M. (1978) Using CODIL to handle Poorly Structured Information", Proceedings "Medical Informatics Europe", 465-474.
5. Reynolds, C. F. (1981) CODIL as an Information Processing Language for University Use. IUCC Bulletin, 3, 56-58.
6. Reynolds, C. F. (1983) A Software Package for Electronic Journals. 7th International Online Information Meeting, Learned Information, 111-118.
7. Reynolds, C. F. (1984) MicroCODIL as an Information Technology Teaching Tool, University Computing, 6, 71-75.
8. Reynolds, C. F. (1985) A Microcomputer Package for Demonstrating Information Processing Concepts. Journal of Microcomputer Applications, 8, 1-14.
9. Reynolds, C. F. (1986) A Personal Information System for Doctors. Published in "Knowledge Representation in Medicine and Clinical Behavioural Sciences", Kohout, L. & Bandler, W. (editors), Abacus Press, 183-191.
10. Reynolds, C. F. (1986) MicroCODIL Manual. CODIL Language Systems (33 Buckingham Rd, Tring, Herts).
11. Reynolds, C. F. (1987) The Use of Colour in Language Systems Analysis. Software Practice and Experience.
12. Reynolds, C. F. (to appear) CODIL: The Architecture of an Information Language, Computer Journal.
13. Southdata Ltd (1986) Superfile Manual. (166 Portobello Rd, London W11 2EB)

'