Towards a Framework for Open Courseware

Abstract

Keywords

Contents

• 1 Introduction
• 2 Context
• 3 Limitations of the current generation of courseware
• 4 Courseware development - lessons to be learned from software engineering
  • 4.1 Recognising the problem
  • 4.2 Recognising the solution
• 5 Working with an open courseware environment - a typical scenario
  • 5.1 Background
  • 5.2 The lecturer's view
• 6 A framework for open courseware
• 7 Some protocols for the open courseware framework
• 8 Current state of the research
• 9 Future research
• 10 Summary

1 Introduction

• issues of instructional strategies and generic educational activities
• issues of structure, views, navigation and orientation
• issues of structural interfaces, resource interoperability and integration
• issues of interactivity, presentation metaphors
• issues of visual style, cosmetic issues

These are all issues which tend to influence discussions at all stages of courseware development. For example, discussions about template design will require consideration of all the above issues, as will discussions about courseware development tools and techniques.

Discussions of some of the issues of structure, views, navigation and orientation can be found in [LINE94, SIVI93, SIVI94]. Discussions of instructional strategies can be found in [BUND94]. This paper is specifically concerned with the issues of structural interfaces, resource interoperability and integration.

2 Context

This rise in interest is not confined to the UK. In other countries there exist thriving and enthusiastic communities of educators and researchers involved in the production of courseware resources of various kinds in a diverse range of subjects [HYPE94]. The international nature of these developments is witnessed by the growing number of international conferences on the subject.

The motives behind these developments are varied. Some of the stated aims include:

• enhancing the quality of the learning experience
• extending access to education by enabling more open learning and distance learning
• increasing the cost effectiveness of teaching and learning
• giving learners more control over their learning

Whatever the hopes of the CAL community, the ultimate success of these ventures relies upon the resulting courseware being eagerly adopted and exploited by colleagues in the courseware authors' institutions and elsewhere. Unfortunately, there are many reasons why this may not happen [LAUR93]. The bottlenecks which impair the successful exploitation of courseware range from cultural to technical and are quite diverse. Within this paper we restrict our discussion to bottlenecks of a technical or design nature.

3 Limitations of the current generation of courseware

• resources are rarely "perfect" - lecturers expect to have to modify them to their own style of teaching
• resources need frequent updating as the subject matter to which they relate evolves

As a result, a courseware package which may only be used in its entirety will be used by only a few lecturers (and only to the extent that they approve of its instructional approach). Moreover, even those lecturers who use it when it is first available will stop using it as soon as it goes out of date. We cannot prevent courseware from going out of date - subjects change. Courseware development projects should therefore address seriously the task of maintenance. Unfortunately, few projects do so. Updating even a small part of today's courseware packages can be inordinately expensive, due in large part to the monolithic nature of their design and implementation.

At this point it is useful to note the way in which lecturers construct courses using traditional materials such as books and journal articles. It is a rare delight indeed to find a text book upon which one can base an entire course. It is more likely that we will tell our students to "read chapter A of book X, chapter B of book Y, paper P (pages 10 - 15) from Journal J" and so on. We pick and choose, mix and match, from the available resources. This approach deals with the features of educational resources stated above. Textual materials can be accessed at many levels of granularity with equal (and minimal) effort, so it does not matter that any given book is not exactly what the lecturer requires. Moreover, evolving subjects generate "small scale" texts in the form of journal papers etc. which lecturers incorporate into their courses.

We need to be able to adopt a similar approach to the use of courseware. i.e., we need to be able to easily put together a package of courseware which enables the learners to (for example) work through simulation S from Smith's "Fluid Dynamics 2" package, then do self assessment exercises 4 and 5 on screen 3 of the package "Fluid Dynamics Made Easy" by E.P.Jones, and so on. Unfortunately, the current state of courseware technology is such that it is simply not a practical proposition for most lecturers to take courseware packages apart and reassemble them in this way. The next section explores some of the reasons for these limitations.

4 Courseware development - lessons to be learned from software engineering

4.1 Recognising the problem

In contrast, this open systems mentality is conspicuous within the courseware development community only by its absence.

The lack of interoperability may well have been an annoyance and frustration for users of standard software applications, but a similar isolation within the world of courseware has far more disastrous consequences. Cynics of computer based courseware enjoy pointing out how much money has been spent in past initiatives on the development of courseware which has subsequently been used either sparingly or not at all. The reason why "closed" software is more debilitating in courseware than in the more standard types of software application is that the two types of software are very different in nature. Word processors, for example, were very useful even before they could communicate with other software. Once you had one you could use it for years and still extract useful functionality from it. On the other hand, as we saw in section three, lecturers must be able to integrate small units of courseware from different sources or they are unlikely to use them at all.

4.2 Recognising the solution

• lecturers could browse through libraries of courseware, importing (or perhaps just linking) "chunks" of courseware, of varying size, into their own "course book" which their students could then work through.
• these libraries could grow incrementally, as any piece of framework-conformant courseware - from small "home grown" items of "lessonware" to large scale packages purchased from publishers - could be added to the libraries and be immediately accessible to teachers and learners.
• maintenance could be carried out at the appropriate level of granularity - e.g., if a small part of the courseware becomes obsolete it can be replaced without affecting the rest of the package. This should reduce the cost of courseware maintenance, turning it into a viable process.

The following section briefly describes a scenario which illustrates the first of these points. It is the kind of scenario which we believe will become commonplace once an open courseware framework has become accepted. We also believe that this is not only a desirable state of affairs to aim for, but that it is actually a necessary pre-requisite for the large scale exploitation of computer based learning software.

5 Working with an open courseware environment - a typical scenario

5.1 Background

Among the available on-line courseware resources are Computer Aided Learning (CAL) modules covering a huge range of topics, including some specifically written for teaching aspects of:-

• Object Oriented Design (What is an Object?, Object linkage, Class, Operations and services, Static structures, Dynamic behaviour, Notations for dynamic behaviour...)
• Real Time Systems (What are real-time systems?, Life Cycles Overview, Ward-Mellor, State transition diagrams, Connecting Data Flow Diagrams and State Transition Diagrams, Formal Methods For Concurrency, Extensions To Data Flow Diagrams, Representing Behaviour, Methods integration, Behavioural Models...)
• Structured Methods of Systems Analysis and Design (Life Cycle Models, Process Analysis / Data Flow Modelling, Data Analysis / Logical Data Modelling, Entity Life Histories / Event Analysis, Model Associations...)

There are also many modules available for subjects as diverse as Fluid dynamics, Cosmology, Food Hygiene, Business French, and so on.

The lecturer has seen some of this courseware (but not all) so she has some idea of the kind of material which is available. Her intention is to browse through the on-line courseware and select a few items which she thinks will be suitable for her particular group of students, studying this particular topic (the Dynamic model from OMT) at the particular level of this unit (e.g., introductory). Of course, it would be very convenient if there was a single CAL module which met her requirements, but, just as it is rare to find a book which precisely meets a lecturer's requirements, so it is rare to find a CAL module which is perfectly matched to the objectives of a particular tutorial. Instead the lecturer will most likely have to use pieces of courseware taken from a number of different CAL modules.

The lecturer pieces together her tutorial using a software tool which we will call a "browse and build" tool. This tool interacts transparently with a number of other software entities to search for CAL modules, present lists of them to the lecturer, execute them on demand, and create a tutorial consisting of selected modules, or parts of modules. The resulting tutorial takes the form of a file to which the lecturer can direct her students, and which will result in the selected CAL material being presented to the students.

5.2 The lecturer's view

• alphabetic indexes of Courses
• alphabetic indexes of Topics within a Course
• course maps showing the Topics within a particular course in a way defined by the courseware author (this is more than just a "pretty" presentation of the list of Topics - it may arrange the Topics visually in a way which in itself has educational content; e.g., showing structural/conceptual relationships between the Topics)
• lessons maps showing Activities within a particular Topic, some of which may be faceted (again, this has added value over a simple list; e.g., because it may suggest a sequence in which the learner should use the Activities within the Topic)
• a keyword search facility, which allows the lecturer to enter a search string (e.g., "dynamic model") and which, depending on the setting which the lecturer has made in one of the search dialog's check boxes, returns either a list of Courses, a list of Topics or a list of Activities, which are relevant to that subject

Using the various search and import facilities of the browse and build tool, the lecturer finds a number of modules relevant to her tutorial. (We use the term "modules" here to refer to pieces of courseware of any size, from a single activity covering a single concept and lasting just a few minutes, to an entire course intended to be covered in the duration of a semester.) She reviews several Topics (i.e., she works through the courseware) in some cases deciding to use an entire Topic as it stands, and in other cases deciding to use some of the Activities from a Topic but ignoring others. After about an hour she has collected the following set of courseware resources.

From the Course "Object Oriented Design" she has an entire Topic "Dynamic behaviour" consisting of several Activities. From the same Course, she also has two Activities ("Object diagrams" and "Interaction diagrams") from the Topic "Notations for dynamic behaviour". Finally from the Course "Real Time Systems" she has the Topic "State transition diagrams", again consisting of several Activities.

To complete her tutorial she now needs to provide a convenient way for her students to access these modules. The browse and build tool has facilities for building simple maps, so she creates a blank map and adds four buttons, which she labels "Dynamic behaviour", "Object diagrams", "Interaction diagrams" and "State transition diagrams". She then selects the "Dynamic behaviour" button and chooses "Link to..." from the menu, which brings up a floating palette with buttons "Link" and "Cancel". She then launches the lessons map for the Topic "Dynamic behaviour" and presses the Link button on the palette. She is returned to the browse and build tool. Pressing the "Dynamic behaviour" button will now launch the lessons map for the Topic "Dynamic behaviour". She links the other buttons to their respective Topics and Activities in the same way, and then adds a graphics background to her map to make it more attractive. It is the background she always uses, and which her students now recognise as hers. Finally she chooses "Make tutorial file" from the menu of the browse and build tool. This creates an executable file which students can run, and which will present her new map.

The whole process has taken approximately one hour, most of which was spent reviewing the CAL material itself before deciding whether or not to include it in the tutorial.

6 A framework for open courseware

Our open courseware framework is based on communicating/co-operating courseware objects. We distinguish between two views of the framework. The first view, which we call the macro view, treats the courseware objects as black boxes and illustrates some of the communication which must take place between them. It enables us to draw up requirements for the protocols of this inter-object communication. The second view, which we call the micro view, looks inside the courseware objects and illustrates those aspects of their internal structure which enable them to participate in an open courseware system.

The macro view
In its most generic form, the macro view of an open courseware framework can be illustrated as in figure 1.

Figure 1. A generic view of communicating courseware objects

An open courseware framework enables interaction between software entities in order to provide teachers and learners with interactive hypermedia tools for teaching and learning. These software entities may be "courseware resource objects" (CROs) - chunks of courseware of any size. They may equally be "courseware management objects" (CMOs) - applications which are used to exploit the CROs.

Figure 2. A scenario showing two example CMOs (the browse-and-build tool and the librarian tool)

Examples of CMOs would include "browse and build" tools and courseware librarian tools enabling the construction of new "courses" or tutorials, as described in section five and illustrated in figure 2, or they may be "study workbenches" with tools enabling the learner to browse the on-line CROs, communicate via EMail with other learners and create their own documents incorporating resources "captured" while browsing the CROs (and other on-line resources) as indicated in figure 3. These views can all be considered "macro views" of the open courseware framework.

Figure 3. Showing another CMO - the study workbench - and interaction with external tools and resources

The micro view
The micro view of the open courseware framework describes a logical internal structure which all CROs can map to, regardless of their physical internal structures. This logical structure is derived from the HyperCourseware Reference Model. A detailed description of HyperCourseware can be found in [SIVI92]. A brief summary is provided below.

HyperCourseware provides a generic course structure - general enough to accommodate any physical structure which a courseware author can dream up, but sufficiently precise to enable the development of software tools to manipulate it, and to enable unambiguous communication about courseware elements, both amongst people and software entities. This generic course structure can be stated as follows:-

• a Course is a hierarchical network of Topics
• a Topic is a collection of educational Activities plus a collection of zero or more subtopics
• an educational Activity is anything an educator wishes to provide, examples include:
  • presentations
  • interactive simulations
  • self assessments
  • games/puzzles/problem solving tasks (on or off the computer)

This generic course structure provides:-

• a common logical structure for all courseware resource objects to map their physical structures onto
• a vocabulary and structure for discussing other aspects of the open courseware framework

A CRO which conforms to the open courseware framework is able to describe its (logical) internal structure in these terms to other courseware objects on request. A CMO must know how to interpret such descriptions and manipulate these structures (e.g., so that it can request a set of Topics from a CRO and do something sensible with the result).

7 Some protocols for the open courseware framework

request the type of a courseware object (e.g., a CRO or a CMO) request the type of a CRO (e.g., entire Course, stand alone Topic or stand alone Activity) request the course name of a Course CRO request a Course CRO to launch a Course request if a Course CRO exports a course map request a Course CRO to launch a course map request a set of Topic names from a Course CRO request a Course or Topic CRO to launch a Topic request if a Topic CRO exports a lessons map request a Topic CRO to launch a lessons map request a set of Activity names of a CRO request a CRO to launch an Activity request from a CRO, a set of keywords relating to Activities request from a CRO, a set of keywords relating to Topics request from a CRO, a set of keywords relating to the Course as a whole

The list in figure 4 is not exhaustive. We have identified many more protocols at different levels of detail (e.g., requesting a CRO to resume execution following suspension, importing and exporting of navigation histories, and many others). However we hope that this brief list gives the flavour of the kind of protocols required in an open courseware framework.

8 Current state of the research

The PC implementation is referred to as "HyperCourseware for the PC". It has proved effective not only as a tool for implementing and managing CROs, but also as a tool for experimenting with the macro level architecture and protocols. It already includes some simple CMOs (e.g., a controls palette which requests and displays Topic lists, manages history mechanisms, requests the launch of Topics, etc.) We have discovered that many of the protocols required at the macro level are actually the same as those already in use at the micro level within HyperCourseware for the PC; e.g., requesting sets of Topics or Activities, launching course maps and lessons maps etc. We are therefore continuing to develop the macro view largely by externalising the relevant HyperCourseware protocols, and only inventing new protocols where necessary.

9 Future research

• determining if a resource is open courseware conformant
• requesting a protocols awareness statement (what protocols does the courseware object understand?)
• distinguishing between exportable Topics and integrated Topics which require their "native" Course to be launched in order to function properly
• requesting the export of a CRO's local CMOs (e.g., controls palettes)

We see the next stage of research into these issues involving the refining of the protocols and architecture of the macro view, and building more working prototypes of entities interacting with courseware objects at the macro level using the specified protocols. In addition, more work needs to be done to distinguish different types of CMO, and to elicit requirements for protocols to support their use. For example, entities such as maps can be viewed as kinds of CMOs which are dedicated to a particular CRO, whereas a course controls palette is a more generic kind of CMO, but one which most CROs will require at run time. These are both of a different kind to the browse and build tool described earlier, which is strictly an "edit time" entity. If a CRO carries with it a set of "local" CMOs (maps, palettes etc.) then perhaps it should be able to export them on demand to other course objects, e.g., the browse and build tool, so that a lecturer can decide which local CMOs to make available in a courseware session.

10 Summary

References