HyperCourseware is a conceptual framework, supported by various techniques, tools and templates, which attempts to address the issues mentioned above. HyperCourseware is a relatively mature framework (Macintosh versions date back to 1989) and the framework continues to evolve to meet new requirements. The current version of HyperCourseware for the PC makes extensive use of ToolBook.
Given that this is a ToolBook User conference, the presentation will describe in detail the various roles which ToolBook plays in supporting the HyperCourseware system. i.e., how ToolBook's software development capabilities support the development of HyperCourseware Tools and Templates, and how ToolBook can be used as a main courseware authoring tool within the HyperCourseware framework.
The HyperCourseware framework provides viable approaches and, in some cases, pragmatic solutions to several of these issues. Given that this is a ToolBook User conference, the presentation will briefly describe the various roles which ToolBook plays in supporting the HyperCourseware framework. i.e., how ToolBook's software development capabilities support the development of HyperCourseware Tools and Templates, and how ToolBook can be used as a main courseware authoring tool within the HyperCourseware framework.
The authors regard all of the following as important aspects of large-scale courseware development projects:
HyperCourseware is based upon the following definitions:
These definitions are very flexible and allow authors to determine what constitutes a coherent collection of related topics for a particular piece of courseware, and what constitutes a coherent collection of related educational activities for each topic in a course.
Educational activities for a topic might include some traditional ideas such as:
An educational activity can be composed of any combination of primitive activities, e.g., read a piece of text, look at a picture, listen to a sound, look at an animation (computer based or video based), play with a computer based interactive device (e.g., simulation), or follow some instructions to perform an assignment away from the computer.
We have found that identifying an appropriate HyperCourseware model (i.e., the hierarchical network of topics and activities) is an essential stage in the courseware development process and one which should take place very early in the lifecycle so that the resulting HyperCourseware model can be used as input to the construction stage.
Briefly stated, the process of specifying this model entails varying iterations of the following activities:
The specification process described above should be supported by many other authoring considerations, e.g., specifying educational aims and objectives, concept presentation strategies, etc.
Once the model has been specified, the rest of the software development part of the project falls into two broad categories:
The first of the above categories covers those features of the courseware which are particular to the given project, in that they are curriculum dependent, whereas the second category covers those aspects of functionality which are required by many courseware implementations. (This is an over-simplification. In fact, the first category often benefits from the reuse of templates. This is discussed below.)
Examples include:
Solving these problems is an extremely time consuming part of any courseware development project and yet, as already stated, the problems commonly recur and need to be solved (or else are sadly neglected) in most courseware projects; they are generic problems which all projects face to some extent. It is obvious that software tools are required which support, or even totally automate, many of these common development tasks. One of the motivations behind "HyperCourseware for the PC" is to provide some of this software tool support.
The templates are immediately usable by authors or can be further customised by authors as required.
The templates include:
These facilities are described generally here but the appendix to the paper contains screen-shots which illustrate how various authors have utilised the facilities.
The templates are designed with a consistent but "neutral" look. On the real computer screen the visual impression is of a console with its own (virtual) screen. The console comprises, at the top, a status/caption bar and a single button which invokes a comprehensive controls palette; at the bottom (on some templates) is a navigation bar. The upper status bar and lower navigation bar occupy a minimum of screen space and this leaves almost the entire (real) screen available to authors as an area designed to look like a (virtual) screen. The status bar at all times indicates the current course, the current topic within the course, and the current "place" within the topic (the "place" could be a lesson/activity or excursion (whose name would be displayed), or a learner's tool such as a Lessons Map, a Course Map, on-line Help etc.).
The activity templates include templates for activities such as presentations, self-assessments and "about this topic" (including statements of intended audience, objectives and pre-requisites). The templates include a selection of navigation/orientation devices including next/previous buttons, frame counters and buttons for invoking a map of activities (referred to as the Lessons Map) for the current topic. Also included is a mechanism for launching excursions into related activities or topics, and returning to the current point in the current activity when the excursion is over.
When creating Lessons Maps and Course Maps, the functionality for the maps is generated completely by HyperCourseware utilities, thus relieving the author/developer from these software development tasks. The author/developer is therefore free to concentrate on non-programming tasks, such as aesthetic design, defining contents of on-line advice, defining abstracts for topics, etc.
The Course Controls Palette, invoked by pressing the button at the top of the console, provides access to more built in functionality. In particular, it offers some of the functionality identified above as being common to all courseware, including:
The system can be instructed by authors to close down any applications which the learner may have inadvertently left open, at certain strategic points (e.g., on exiting from a topic). This "smart application launching" utility provides the basis for integrating lessonware produced using a variety of authoring tools.
Much of our current research effort is going towards substantially upgrading the HyperCourseware Reference Model so that it can seriously contribute to a Framework for Open Courseware. The software world has long recognised the need for software interoperability and continues to evolve rapidly in the direction of open systems. In contrast, it seems that the courseware development world has remarkably little experience of an open systems mentality. Courseware continues to be developed today using thoroughly out-of-date software practices which impede rather than support the integration of diverse courseware. We believe that a Framework for Open Courseware is an eventual necessity for the courseware development community. We also believe that the currently internal protocols for our HyperCourseware Reference Model could form the core of such a framework.
On a less theoretical level we are currently enthusing (if that's the right word!) over rewriting our existing HyperCourseware tools to exploit the excellent new version of ToolBook.
Our tools development work has always been accompanied by actual courseware development projects. With our courseware development hats on, we find that an emerging requirement for computer-based courseware is the need to provide effective computer support for collaborative learning (CSCL). There is a need to provide suitable metaphors in a layer of software which links the learner to a data communications network (anything from a LAN to the World Wide Web). One good example of this is given in Alexander (1993) which describes a rooms-based metaphor, including a library where the learner can interact with learning materials, a study where they can use applications to carry out assignments, write essays etc., and a meeting place where they interact via email with other learners. Clarifying how such environments will interact with and interface to courseware management systems is an area of our current research which is closely related to our work on a Framework for Open Courseware.
Siviter,D., Brown,K. HyperCourseware. In: Computers and Education Vol. 18, No. 1-3, pp. 163-170, Pergammon Press, (1992)
The screen dumps have been chosen just to illustrate the structural features of HyperCourseware rather than to illustrate anything about the specific computing courseware.
The authors of this paper are indebted to the particular courseware developers who have been developing the courseware from which these screen dumps were captured, i.e., our thanks, to Rachel Bundy, University of Brighton and Andrew Milroy, South Bank University.
The following description provides a walkthrough of a typical piece of HyperCourseware and illustrates how the HyperCourseware structural model has been utilised.
Each course has its own 'Course Launcher' made from a ToolBook template which authors merely edit cosmetically. A user would launch a specific course by double clicking on its launcher (using Windows Program Manager or File Manager in the normal way).
Remember that HyperCourseware is a hierarchical collection of Topics (Topics and sub-Topics are like directories and sub-directories). The Course Launcher would initialise the course and then automatically progress to the Title Page for the Root Topic of the course (the highest level topic in the course).
For example, Figure 1 is the Title Page for the Root Topic in the Object Oriented Design course. In this example the Root Topic happens to have the same name as the course.
Each Topic automatically has its own Title Page (authors just edit it cosmetically). Similarly each Topic automatically has its own Lessons Map and collection of Lessons (educational activities) which authors customise to their own requirements.
In this example walkthrough we assume that the user did not bother looking at any of the Root Topic's lessons but preferred instead to immediately navigate to another topic in the course. This was achieved by summoning the Course Controls Palette (clicking on the square button at the top right of the console). Having summoned the Course Controls Palette, the user summoned the Course Map which provides an overview of the Topics in the Course.
Figure 2 shows an example Course Map (actually this is just a map of a fragment of the Object Oriented Design Course - the eventual map will be a multi-page structured map to cope with a very large number of topics). The Course Controls Palette is a separate ToolBook instance which communicates (via DDE) with the main course instance. It acts as a floating palette which can persist in the foreground while the user navigates around the main course. (The Controls Palette happens to be positioned at bottom left of the screen in Figure 2.)
The Course Map contains a 'Tutor Information' icon which invokes a pop-up containing recommendations on which Topics a student should look at. These 'Tutor Information' pop-ups are built into the template maps and are always trivially easy for authors to edit.
As a user selects each topic the abstract for that topic is displayed in an 'Abstract Pane' which is again trivially easy for authors to edit. To avoid saying this over and over again, all the features which these screen dumps illustrate are provided in ready made templates which can be used 'as is' or extensively customised by authors.
When the user is satisfied with a choice of topic, the 'Launch Topic' button closes the map and takes the user to the Title Page for the selected topic. In this example the user selected the topic 'What is an Object?'. Having arrived at the Title Page for that topic, the user would then select the 'Lessons Map' for that topic.
Figure 3 is the Lessons Map for the topic 'What is an Object?'. It shows all the lesson/activities which are available for the topic. You could compare this to Figure 8, which is a Lessons Map from the Structured Methods courseware. Note that they have similar functional features but it is obvious that the respective authors have adopted very different visual layouts for their Lessons Maps.
Before embarking upon one of the main lessons for the topic the user may choose to read 'about the topic'. A standard ToolBook template exists which conveys all kinds of information about the topic. This is deliberately maintained as something which authors (or lecturers) can very easily edit (maybe at the last minute just before students use it). Figure 4 shows one screen from the 'About this Topic' template. It also illustrates how a typical activity template is divided into facets where each facet is one or more screens in length. The activity is called 'About this Topic'; it has facets 'Aims and Objectives', 'Pre-requisites', 'Target Audience', etc. When the user has finished with the activity (the 'About this Topic' activity) s/he presses the Lessons Map button and from the Lessons Map (Figure 3) makes another choice of lesson/activity. A 'Tutor Information' icon is available on the Lessons Map which would give pop-up advice on which activities to use and why.
In this example the user elected to use the activity called 'A Person's Physical System'. Figure 5 shows a screen from this seriously light-hearted interactive vehicle for teaching about 'state' and 'behaviour' which are fundamental concepts within object oriented computing. When the user finished with this activity s/he invoked the Lessons Map again and chose to explore the lesson called 'The FM Tuner Object'. Figure 6. and Figure 7. show two screens from this activity which again exploits a highly interactive device with which users play. Other lessons later in the course use the same tuner object in a variety of ways, e.g., visually disassembling it to show its 'part-of' hierarchy, etc.
Figures 8, 9, and 10. are from a different but related piece of courseware on 'Structured Methods in Systems Analysis'. The presentations in this courseware make heavy use of 'walking through case studies' gradually building representations of the case study, i.e., it emulates the methods which a systems analyst would use. So Figure 9 indicates that the user is on screen 11 of 12 screens which have been devoted to introducing the elements of data flow diagrams and gradually building up a simple example of a data flow diagram. Each of the six facets of this activity (External Entities, Data Flows, Processes, etc.) used one screen containing a sequenced flow of text and diagrams and was then followed by a second screen of self assessment material.
Figure 10 shows the last screen of the first part of a case study. In this activity the user has been through a series of screens where in each screen the user would be prompted to reflect upon part of the text of the case study and to consider how it would be drawn on the diagram. The diagram is incrementally drawn under the user's control. The last screen contains the entire diagram and the user can reveal the case study text for each section of the diagram simply by pointing to any part of the diagram. In the example, the user pointed at the external entity 'Member' so a pop-up field appeared to explain what 'Member' is.
Each of the components discussed above, i.e., maps, title pages, lessons/activities, is implemented as a separate ToolBook book. The whole course is deliberately modularised in this way for maximum reconfigurability. The HyperCourseware Management System enables this large modular collection to be structured and restructured simply by authors. All of the 'views and navigation' features are built and maintained automatically by the system. Authors simply customise the visual aspects and devote their energy to designing meaningful educational activities.


Figure 2. Course Map for part of the Object Oriented Design course, plus floating palette

Figure 3. Lessons Map for the topic "What is an object?"

Figure 4. A screen from an "About this topic" activity

Figure 5. A screen from the lesson "A person's physical system"

Figure 6. A screen from the lesson "The FM tuner"

Figure 7. Making the tuner's state explicit

Figure 8. A Lessons Map from the Structured Methods courseware (c.f. Figure 3)

Figure 9. Customising a presentation activity template (c.f. Figures 5, 6, 7 and 10)

Figure 10. A screen from another Structured Methods lesson "Drawing a level 1 diagram"