Requirements analysis for hypertext applications: the Why, What and How approach

Andrew Dillon

This item is not the definitive copy. Please use the following citation when referencing this material: Dillon, A. (1991) Requirements analysis for hypertext applications: the why, what and how approach. Applied Ergonomics, 22(4), 458-462.

Abstract

The present paper presents a simple task description procedure for text usage aimed at supporting human factors input to the specification stage of hypertext and electronic document design. The need for such techniques is outlined and the approach is described in the context of designing hypertext versions of software manuals. Applications and limitations of this procedure are discussed.

Introduction

Research in the domain of computer presented text has mushroomed in recent years, concentrating particularly on possible differences between reading from paper and reading from screen (e.g. Wright and Lickorish 1983, Gould et al 1987). Computer applications such as hypertext however offer the ability to interact with published material in previously impossible ways and this gives rise to a whole new set of problems about text usage and information structure. It is now becoming clear that design guidelines that enhance information presentation in one medium, such as paper do not transfer simply to another such as screen. Furthermore the sheer diversity of texts that currently exist and the range of uses to which they are put suggests that general principles of text presentation on screen are unlikely to emerge overnight.

Reading as a physical and cognitive skill

Psychologists have long recognised the complex nature and range of skills involved in text usage (see e.g., Huey 1908, Orasanu, 1986). On the physical side, the apparently simple operation of lifting up a text provides the reader with information on size, age, and assuming an informative cover, the likely quality of the contents. Manipulation skills, acquired by readers early in life, support jumping back and forth to various parts of the text. Furthermore, these physical skills are transferable across most reading situations.

Cognitively, with little obvious effort, the reader is capable of scanning the text rapidly to decide upon relevance to current needs, range of issues covered, depth of coverage and level of detail. Evidence suggests that the reader builds a mental model of both the author's message and the organisation of the text itself (Johnson-Laird 1983, Rothkopf 1971) In the former case it is a matter of comprehension, in the latter, it is a case of appreciating the way this message is organised through the presentation medium. Both provide useful information for navigation and manipulation purposes.

The physical and cognitive aspects of reading are inter-related. Without the ability to manipulate texts physically many of the reader's cognitive demands would be unfulfilled. This may seem a trivial point but in the design of electronic systems to facilitate reading it is important to identify and support both kinds of needs. Presenting black text on a white background, on a high resolution screen, may satisfy some human factors needs but may still lead to user rejection if suitable manipulation facilities are not available, or only partial use if optimal text structures are not considered.

To date ergonomists have been poorly served in terms of tools and techniques that can be employed to input human factors into the specification stage of design (Meister 1973, Catterall et al 1989). This is generally true of many software domains, especially for innovative products, but is particularly the case in the domain of hypertext applications where limitations in our knowledge of human issues pertaining to information structuring, presentation and usage are such that few decisions about usability can be made in advance of a prototype or simulation.

To have utility at the specification stage a human factors input need not necessarily be precise or formal. If it can successfully constrain the design space by limiting the available options to be considered or suggest the problems likely to be associated with a proposed design in advance of a prototype it will have value. Thus, while not lessening in importance, or questioning the value of, formal methods and models geared to quantifiable analysis of design specifications (such as GOMS models), it is worth realising that heuristics and ergonomic rules-of-thumb also have a significant role here. The present paper outlines one such approximate task description procedure aimed at structuring the consideration of user issues at this stage in the design of hypertext or other electronic texts.

Considering text usage according to reader-relevant criteria

At HUSAT we have been examining such issues as part of our work on the design of hypertext databases. In particular we have sought a method for discriminating between the wide variety of real-world documents in a relevant manner i.e., one that would input to the specification and/or evaluation of electronic documents. As a result of a repertory grid analysis of readers' perceptions of documents, Dillon and McKnight (1990) concluded that readers distinguish between texts in terms of three meaningful attributes pertinent to the development of hypertext versions:

  • Why they are read:

    The motivation for using a text is an important variable in discriminating between documents. Individuals might read for pleasure, for help, for work purposes, for education and so forth and this will influence the applicability of any given design to their needs.

  • What type of information they contain:

    Documents differ in terms of their contents. They might be primarily textual or graphical, contain general information or specific details, might have single themes or be wide-ranging in content and so forth. More importantly, they frequently possess a structure that readers are familiar with and which aids use. This aspect is crucial for potential hypertext structures.

  • How they are read:

    This refers to the type of reading style or strategy employed by an individual in the course of his interaction with the material. It might involve scanning, proofreading, studying, browsing and so forth. Obviously depending on the type of reading style involved, different presentation formats will have varying effects.

As a framework for task description and subsequent analysis these dimensions provide a useful guide for knowledge elicitation or information gathering as well as providing a means of interpreting the expanding literature on reading from screens. They ensure that a range of issues pertaining to a readership's use of texts are identified and thus facilitate sensible decisions at the specification stage about how they should be presented. Such an approach has been used to good effect by Dillon et al (1989) to study academics' interactions with journals in order to estimate the likely impact of electronic journal presentation and to develop a specification for a full text, searchable database. That analysis revealed three broad reading strategies for the text ranging from a rapid browse of the essential sections to a start-to-finish serial read of the full article, the organising principles underlying such texts (i,e, the readers' models of the information space) and current searching practices among the target end-users. For example, it became clear that the typical structure of articles was seen as a useful indicator of likely contents and experienced readers could accurately predict where specific information would be found in the body of the text. Such results were fed into the design process and further details of the resulting database can be found in McKnight et al (1991).

In the present case this approach was applied to software manuals in order to highlight shortcomings of present paper versions of these texts and suggest ways in which suitable electronic versions could be designed. This analysis is presented as an example of the approach to human factors in system specification advocated here but the results themselves have intrinsic interest.

Describing manuals in terms of Why, What and How

Background and procedure

Fifteen subjects participated in this study, nine female and six male. No sophisticated sampling procedure was employed, all subjects were casual users of software manuals.The basic procedure involved an interview to collect information on why subjects used manuals and what types of information they thought such a text contained. Typical prompts at this stage involved variations of the Why and What aspects, pursuing points as they developed and concentrating on those areas that have any impact on usage. Subjects then interacted with a sample of five relevant texts (MacWrite manual, MULTICS guide, Qisk Installation manual, HyperCard Manual and a Statistics package manual) simulating their typical usage according to their expressed reasons, articulating what they were attending to as they did so. They were prompted as necessary by the interviewer. After describing and simulating their typical usage of the texts the interviewer described his impression of their style and sought confirmation that it concurred with the subjects' own views. When agreement had been reached the interview ended.

Results and Discussion

The results will be broadly presented in terms of the three text usage criteria: why, what and how. Other aspects that emerged as a result of the interviews and observations are included where relevant even though they may not strictly conform to these aspects.

Why use manuals?

Subjects stated numerous reasons for using manuals though there was a large degree of consistency in their responses. These were categorised according to meaning by the experimenter and their relative frequencies summed. The categorised comments are presented in Table 1.

Why use a manual? No. of Ss. (%)

For reference/How do I do this? 11 (73)

How to get started 10 (67)

When in trouble 8 (50)

For a summary of package's facilities 5 (33)

Aid for exploring software 2 (13)

As a guide before buying 1 (7)

For detailed technical info1 (7)

Table 1. Stated reasons for using software manuals

Clearly, readers have a limited range of motivations for using manuals. The three main reasons: reference, introduction and when in trouble, were all offered by at least half the subjects. These highlight the problem-driven nature of manual usage. In fact, all subjects remarked that manuals were only ever used in work or "task" domains. It should also be noted that while using a manual to get started was one of the most common motivations for use, six subjects stated that they would hate to rely solely on a manual to learn a package, preferring to use it only when absolutely necessary. Furthermore, all but two of the subjects stated that they would much rather ask someone for information than access a manual.

What type of information is in manuals?

The responses to questions of this nature displayed a high degree of commonality across all subjects. Invariably material was described as "technical", "specific" and "detailed". While it might be argued that the very nature of manuals is that they contain such information most subjects seemed to find this off-putting. A third of the subjects remarked that manuals were heavily loaded with jargon and information on simple actions was often difficult to locate or extract as a result.

All subjects remarked that manuals were too textual and that more graphics would often aid the user's location and comprehension of information. However, it was repeatedly pointed out that graphics should be relevant and one manual (for the MacWrite package) was much criticised for using superfluous pictures of desktops, scissors and documents.

The need for different versions of manuals which are structured according to the users' needs was suggested by 4 subjects. Typically, these should consist of a manual for a "total novice" which explains how to perform very basic procedures and a more detailed version for users who have acquired a greater degree of competence.

The structure of manuals was discussed with all subjects and responses varied between those who are aware of text structure as it pertains to this text type and those who felt it existed but had difficulty articulating their perceptions of it. Primarily, a sense of order seems to be lacking in manuals though some subjects felt that there might be a progression from easy to hard as a reader moves from the beginning to the end of the text i.e., the more complex operations are dealt with towards the back of the manual. One subject remarked that while it might appear that an easy-to-hard progression exists, a structure based around command frequency was probably more frequent, i.e., commonly used commands or actions were more likely to be located at the front of the manual and less common ones at the back. Another suggested order, general-to-specific was made by two subjects. Two subjects argued that if any order such as easy-to-hard could be observed if probably existed at the task rather than the global level i.e., within sections rather than across the manual.

The perceived modal structure for manuals that emerges from the comments of the present sample is:

  • contents,
  • getting started,
  • simple tasks,
  • more complex tasks,
  • index.

As this structure indicates, heavy emphasis was placed on the task as a structural unit for organising manuals. There were variations on this modal structure. For example, two subjects placed training exercises at various points in the structure, the gradation between basic and more complex tasks was extended in two cases to include an intermediate level, while others mentioned a glossary of commands, technical specifications and lists of error messages as further typical units of a manual.

Many of the problems users of manuals seem to experience are related to the question of structure. Invariably this was criticised as "poor" or "disorganised". The present sample seemed divided between those who felt that overall order was less important than the procedural order at the task level and those who were content with procedural ordering but felt that high-level ordering was unsatisfactory in many manuals.

How are manuals used?

The procedure for extracting information from a manual was assessed using all subjects in order to ensure a balanced extraction of readers' behaviour. Unsurprisingly, a relatively stable behavioural pattern was observed between and within subjects over the range of manuals. Figure 1 represents usage styles in flowchart form.

Insert Fig. 1 Here

The first thing readers do is get a feel for the document's contents. Thus readers initially open the text at the contents or index sections. The majority (8) stated that the contents is usually checked first and if that did not suggest where to go, the index was examined. However, it seems that much depends on the nature of the problem. If decoding an error message or seeking information on a particular command then the index is likely to provide this and will therefore be accessed first. If more general information is sought then the contents offer a better chance of location. This highlights the extent to which book conventions have become internalised in the minds of contemporary readers. Furthermore, the index or contents list is not read in a simple pattern-matching fashion for a word template- rather the reader tries to get an impression of context from the contents i.e., what items precede and proceed it, or may have to think of other terms that might yield satisfactory information if the term being sought is not present (a common problem with technical jargon).

If the reader fails to locate anything in the contents or index that appears relevant he may either dip into the text and move about looking for relevant information or give up. The latter option appears common according to the data (three subjects stated that they would give up immediately if the contents and index session did not provide a direct reference to their target term, a further four said they would give up if a quick browse failed to improve matters) and represents a failure in document design that must be overcome. If on the other hand a relevant item is located then the reader turns to the relevant page and if it is not immediately obvious, will scan about looking for a relevant diagram, word, phrase etc. to indicate that the answer is there.

At this stage the reading strategy adopted by the reader depends on the particulars of the task. If it is a simple matter of decoding an error message or finding the correct syntax for specifying command parameters then rapid scanning is adopted. If on the other hand the reader wants to perform a new sequence of actions more procedural reading will occur. However, even though the latter form will require more serial reading of the text, few subjects reported actually reading complete sections. The tendency to "get-on-with-it" seems firmly established in users of manuals and the present sample report moving freely from manual to system in order to achieve their goal.

Only three subjects manifested any tendency to read around an area or fully read a section before moving on and even these admitted that they would be tempted to skim, tend to get bored if they felt that they were nor resolving their problems and only read complete sections if all else has failed.

General Discussion

What can we say about designing a hypertext software manual on the basis of these data? Potentially, the observed interrogative reading style seems highly suited to electronic presentations. However, an electronic text that merely replicated the paper manual would be relatively useless. It would share all of the disadvantages of the paper version but none of the advantages of manipulation, portability, familiarity and image quality. Since usage is so goal-oriented, large sections of a manual's contents are irrelevant for much of the time and providing a single multi-page text for the reader to search seems a less than optimal method of presenting information.

Therefore in order to ensure usability one would need to consider an alternative structure and means of access. Given the typical usage style noted above it is likely that searching facilities that supported location of information on a term or concept would be useful. It is conceivable that a thesaurus of terms would enable better searching. Detailed contents/indices with selectable items would be another enabling mechanism. None of these facilities should be beyond the scope of a well-designed hypertext application.

A continually emphasised attribute of hypertext is the ability of authors to "hide" layers of information that can be accessed by links (e.g. McAleese 1989). Thus users could conceivably follow a trail of information about a concept to whatever level of detail is required. For the curious user this could be easily achieved by actioning links. For the user who has no desire for such in-depth coverage such a presentation format could "hide" copious amounts of unwanted material. Thus we can see the emergence through templates of "versions" of manuals for different user types requested earlier. Such a structure would support the typical model readers possess of this information type.

Obviously this discussion of potential hypertext attributes to support electronic manuals is superficial. No mention has been made of the potential for such attributes as "interactive figures" (where users can point at sections of a diagram to gain further information on that part),"fish-eye"views (Furnas 1986) scrollable pop-up windows, enriched indexes (Gomez and Lochbaum 1984) or links to alternative procedures and methods for accomplishing a goal. However, the aim of this paper is not to present a specification for a hypertext manual but to describe a means of eliciting suitable information to inform that process. To that end it is worth abstracting the points relevant to the intended users of such a procedure: the ergonomist involved in the system specification stage of a hypertext application.

Suitability of the procedure in design specification

This procedure is straightforward and requires little in the way of training. Basic interviewing skills and the careful observation of simulated use will suffice. Secondly, it is fast. For the present sample, no elicitation procedure lasted longer than 30 mins, several were significantly less. Fifteen subjects were picked as a convenience, in practice it is conceivable that important data could be uncovered using fewer subjects (with obvious implications for confidence in the results) or addressing the various usage aspects in other ways e.g. consultation with relevant literature.

The data elicited are immediately in a form suitable for consideration at the specification phase. Information on how a text is used in terms of reading styles, manipulations, duration, frequency and so forth naturally emerge from this process. Questionnaires are unnecessary. No elaborate equipment, measuring device or stimulus materials are required, a few sample texts will suffice.

Obviously there are limits. It makes no claims to be the only way of capturing relevant information. It is applicable only for existing texts. For innovative information types that will surely emerge with the advent of hypermedia such a classification of task relevant issues is not possible (although subsets of the hypermedia information might be amenable to such analysis). Furthermore it is a relatively informal procedure, reliant for its value ultimately on the abilities of the practitioner more than one might like, particularly for mapping responses to interface recommendations.

For all this, it can be used as a method of considering the human factors of an electronic text at the earliest stages of design, a time when human factors inputs are typically weak. As the need for earlier input of human factors in the design process of information technology increases such methods are required. It does not replace more formal task analysis where possible and does not do away with the need for proper evaluation of the resultant design. It can however point out the potential problems that lie in store for any electronic version of a text and for the ergonomist at the sharp end, it can prove a useful means of structuring their initial input.

Acknowledgements

The author would like to thank his colleagues Cliff McKnight and John Richardson for commenting on an earlier draft of this paper.

References

Catterall, B., Allison, G. and Maguire, M. (1989) HUFIT: Specification and Design Tools. In E.D. Megaw, (ed.) Contemporary Ergonomics '89. London:Taylor and Francis

Dillon, A., Richardson, J. and McKnight, C. (1989) The human factors of journal usage and the design of electronic text. Interacting with Computers, 1,(2) 183-189.

Dillon, A. and McKnight, C. (1990) Towards a classification of text types: a repertory grid approach. International Journal of Man-Machine Studies 33, 323-336.

Furnas, G. (1986) Generalised fish-eye views. Proc. of CHI'86. New York: ACM, 16-23.

Gomez, L. and Lochbaum, C. (1984) People can retrieve more objects with enriched keyword vocabularies. In. B. Shackel (ed.) INTERACT'84. Amsterdam: North Holland, 257-261.

Gould, J.D., Alfaro, L., Finn, R., Haupt, B. and Minuto, A. (1987) Reading from CRT displays can be as fast as reading from paper. Human Factors 29(5), 497-517.

Huey, E. B.(1908) The Psychology and Pedagogy of Reading. Macmillan:New York

Johnson-Laird, P. (1983) Mental Models. Cambridge: Cambridge University Press.

McAleese, R. (ed.) (1989) Hypertext: theory into practice. Oxford: Intellect Ltd.

McKnight, C., Dillon, A. and Richardson, J. 1991 Hypertext in Context. Cambridge: Cambridge University Press

Meister, D. 1973 The future of ergonomics as a system discipline, Ergonomics, 16, 267- 280.

Orasanu, J. (ed.) (1986) Reading comprehension: from research to practice. Hillsdale: Erlbaum.

Rothkopf, E. Z. (1971) Incidental memory for location of information in text. Journal of Verbal Learning and Verbal Behaviour, 10, 608-613.

Wright, P. and Lickorish, A. (1983) Proof-reading texts on screen and paper. Behaviour and Information Technology, 2 (3), 227-235.