Last changed 26 Sept 1999 ............... Length about 900 words (6000 bytes).
This is a WWW document maintained by Steve Draper, installed at

Web site logical path: [] [~steve] [mant] [this page]

Information to support prospective deliverers of courseware

Stephen W. Draper
Department of Psychology
University of Glasgow
Glasgow G12 8QQ U.K.

This is the abstract for a talk given at ALT-C99 in Bristol.


When teaching materials are offered for use by teachers other than the authors, those prospective deliverers (PDs) must somehow decide whether this is (to them) useful material, and if so how to use it. Decisions to adopt, buy, and/or use any device are a crucial, but often neglected, user "task" that any design or service must support. Functionally good software has often failed in the marketplace due to neglect of this, and such failure is even more common in the world of educational software.

It is usually straightforward for the PD to determine if the content matter is suitable, possibly by reading the learning objectives (if provided) but usually by looking through the material itself: this is why academics flipping through textbooks is such a common sight. With courseware, again this part of the decision is not often a great problem (as long as the software does allow PDs to "flip through" it).

However PDs also need other kinds of information to answer the many important practical questions related to whether the material will fit into their particular contexts for delivery. With exercises and other tutorial material this is an even more prominent issue. For this, PDs need information such as how many student hours the material will take (for which kind or level of student), what other material it requires before or after it, whether there are elapsed time as well as learning time constraints (e.g. if students are gathering data from other students, then there may only be one good time for this per day or per week: it is not a learning activity that they can do at any time that suits them). After delivering it once, a teacher will have discovered many things about how to introduce it to students, how to organise groups for groupwork on this topic, and so on. It is desirable to communicate this practical experience to PDs, but very seldom done. This is information for teachers, not for learners, though the success of the material for learners outside its home department will depend on it.

Preliminary work will be reported on the development of a format for the tutorial materials developed in the MANTCHI project aimed at supporting remote PDs in their decision about and adoption of the materials. The first designs were refined in the light of the experience of test PDs, and software tools to aid elicitation and presentation of the information were developed. The size of the extra material can easily equal the size in words of the original material written for the learners. This is comparable to how software documentation can be as big as the source code for the software: and similarly, it is because the documentation expresses the reasons for the decisions only tacitly embedded in the code or material itself.

Two pieces of work (HCI exercises developed and delivered during the MANTCHI project) may be found at these links, and illustrate the format developed:

Web site logical path: [] [~steve] [mant] [this page]
[Top of this page]