This project uses the text of a conventional book about C (Kay and Kummerfeld, 1989). The goal is that a future version of this book will be used in conjunction with a hypertext version of much the same material.
In writing a book, one is charged with making many compromises: a fixed written text can only have one form and that must be chosen to approximate the expected needs and preferences of a target audience. If the authors achieve this, their book can at least meet the needs of one target audience.
The audience we selected for our book was people who have learnt one programming language. Indeed, the students who are half way through the second year of our own computer science major programme were the first target group. Our 'user model' for this audience represents the users as competent Pascal programmers, who know some computer architecture and have a good grounding in many aspects of programming and computer science. Further, we assume they want to become highly competent programmers.
Our book appears to have matched the requirements of such an audience quite well: it has had very positive reviews and good levels of acceptance from readers who match this audience expectation closely. However, there are many levels at which it has failed to satisfy some readers. A brief discussion of these highlights the types of adaptation we are trying to offer in the hypertext edition and from this we will indicate the areas in which a user model and adaptation are useful for achieving effective communication.
We had to choose a compromise in assumptions about reader's backgrounds and we tended to explain any major concepts that are commonly difficult for the less well grounded readers. This tended to be tedious and boring for those who knew these well. In our hypertext version we prefer to deal with this quite differently. We ask the reader to do a 'concept inventory', a short dialogue to build an initial model of the user to indicate how well they know these background aspects. Then, users who have a solid understanding of the underlying concepts will have those relegated to a glossary. So, for example, a user who has a good understanding of the parameter passing mechanisms, call-by-value and call-by-reference, are told about C parameters using these terms.
These glossary words are initially highlighted in the hypertext to show they are accessible in a glossary. So the reader can check out their meanings if they wish. Once the reader has successfully progressed through early stages of the book, even these terms no longer appear highlighted. We do not wish to distract the reader with clearly irrelevant links to a glossary.
Note that the term 'successfully progressed' has a precise meaning in our system. The hypermedia system not only includes the text of the book. It also has exercises for the reader to do as they read. If the reader can give good answers to the exercises, they are regarded as have 'successfully progressed'.
The role of the exercises is rather different from that in an ordinary book. Usually exercises help the reader consolidate their understanding of concepts that have already been presented. We want to do that and more. We know that learning is more effective if the learner is actively involved in the learning task. So, where possible, rather than present important concepts directly, we present them in a manner that enables the reader to deduce things for themselves as far as possible. For example, if we know that the reader is familiar with Pascal and we want to introduce a concept that is different in C and derives from principles the reader has met, we ask the user to deduce the C concept. Ideally, they should be able to do this without direction but if they fail to do so, we can offer a hint by stating the C principles that are the basis for the concept.
Interaction with the reader involves more than simple traversal of a hyperspace. Often the user is asked to do a task and submit their answer. Our system can do various forms of analysis on these. This is used to update the user model and to generate the hypertext that the user will see. In class use, this mechanism can also be used as part of the assessment.
We are particularly conscious of the benefit to some users from somewhat gentler if wordier explanations rather than just the terse and abstract ones of the current text. In addition, we would like be able to customise some of the use of jargon. For example, some Pascal programmers use var-parameter and non-var-parameter for the terms call-by-reference and call-by-value. The former terms are very useful for such readers and totally irrelevant to people not coming from Pascal. We are also very conscious of the different needs of many readers for whom English is a second language: they are often confused by humour and may have difficulty with some of the more sophisticated uses of English which are so useful for terse, precise, abstract writing.
For example, we know that some people like mathematical examples and others loathe them. Equally, some of our readers are excited by examples that are related to systems programming, even (or especially) if these introduce new ideas, while some readers find these confusing.
Some people like tiny focused examples while others prefer longer complete programs that they can actually play with to explore the ideas. Similarly, a single task that is used to explain a series of concepts suits some readers while others prefer separate, unrelated examples.
The overall architecture is:
ci
| \
Mosaic---httpd-----+ um
| /
pt
The Mosaic browser is used because of its wide availability for
multiple
platforms as well as its ability to interpret most of the current
definition of HTML, the HyperText Markup Language used by the World
Wide
Web. Most importantly, it can present HTML forms to the user and
return the
resulting information to a program executed by the HTTP server. The NCSA httpd server is used both to invoke our programs to carry out the customisation and interact with the user modeling system and also to provide some security of access to the hypercourse. The latter facility is important to prevent impersonation of a user and resultant corruption of the user model.
The 'ci' program presents a concept inventory to the user. It does this by consulting the user modeling system, 'um', for a list of concepts and creating a HTML form to be filled in by the user. A companion program analyses the completed form and interacts with the user modeling system to update the user model.
The 'pt' (Personal Trainer) program takes an uncustomised unit of hypertext and the user model to produce a customised result. The hypertext units contain commands in the style of the C preprocessor (Kernighan and Ritchie, 1978) (#if etc) and pt adds a series of #define commands to the beginning of the text to set relevant values from the user model. Pt then uses the C preprocessor to produce a final text.
The C preprocessor was chosen because of its simplicity and ready availability. Pt can be configured to use other customisation languages.
For example, the following illustrates how one can selectively present information that is only relevant to a Pascal programmer:
<P>
A C program is a collection of functions.
One must be called <TT>main</TT> and this
runs first.
#if PASCAL > 0
As a Pascal programmer you should note that the line
<TT>main()</TT> does
<I>not</I> have a semicolon at the end of it.
#endif
Two problems in this are related to user control and insta-bility of the document. Both can be addressed. Simple approaches, like the viewable (and adjustable) user model permit straightforward control at that level. If the user wishes to explore the impact of their user model on hyperspace, they can do so by tinkering with the model and exploring the resultant hyperspace.
Alternatively, we plan to provide tools to support such exploration by the user. This is particularly useful for establishing the language style that the user prefers. For example, it is easy for a user to read two versions of an explanation and say which they prefer. If we try to determine this in other ways, the user may need to be familiar with what we mean by terms such as "abstract".
The second issue, of a changing hyperspace, is related. Our current plan is that as users progress through their learning of C, the material presented converges to the form of the printed text, and is intended for reference use. Tutorial level material would still be accessible deeper in the hyperspace.
As the above description indicates, there is a merging of intelligent teaching systems and hypertext teaching materials. The user model that generates a customised hypertext is critical in building this bridge for customised communication.
Kay, J and Kummerfeld, R.J. (1989), 'C Programming in a Unix Environment', Addison Wesley
Kernighan, B.W. and Ritchie, D.M. (1978), 'The C Programming Language', Prentice-Hall
Mosaic Project, http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/NCSAMosaicHome.html
Paris, C.L. (1989), 'The Use of Explicit User Models in a Generation System for Tailoring Answers to the User's Level of Expertise'. In: A. Kobsa and W. Wahlster (eds.), User Models in Dialog Systems. Berlin: Springer Verlag, pp 200-232