Figure 1. Two examples of authors implementing arbitrary structuring approaches.
"The distinction between Courseware and Lessonware.
To appreciate the relevance of open courseware it is important to differentiate between large-scale courseware and small-scale lessonware. Many people are engaged in the process of developing lessonware, i.e. small units of Computer Assisted Learning (CAL) material developed using a diverse range of authoring tools, programming languages, software applications, etc. As yet, there are far fewer people engaged in manipulating hundreds of lessonware products to form large-scale courseware resources.
The use of terms 'courseware' and 'lessonware' is not meant to imply that there is a clear line dividing the two; it just draws attention to the fact that on the one hand we have the physical development of small chunks of CAL material - lessonware, and on the other hand we have the manipulation of hundreds of chunks of CAL material - courseware. To differentiate further, we refer to 'lessonware development' as being the process of authoring and constructing a small piece of CAL material, and we refer to 'courseware management' as being all the techniques used to implement, adapt, and use large-scale courseware resources. These two aspects of implementing CAL material require different tools and techniques."
(Section 3.1 of Report No. 1 "Report of the TLTP Working Group on Open Courseware".)
Section 3.2 of Report No. 1, discussed the relevance of courseware management and gave an overview of some current approaches to courseware management, including the use of CD ROMs to publish magazines, or to distribute TLTP products; the development of courseware management facilities by some TLTP projects; and the use of the internet (especially World Wide Web) for delivery of courseware. In Appendix B of this report we provide further details about several systems which provide a variety of solutions or partial solutions to several areas of courseware management. The list is not a summary of all the interesting projects which exist; it just includes some of the systems which members of the EPOC Working Group have either discovered, or been involved with, and which can serve to illustrate courseware management issues. An overview of these systems provides a reasonable introduction to what courseware management involves. Systems reviewed include: Caleidoscope, EDEC, HyperCourseware, Mathwise CMS, Mentor, Microcosm, SuperCal, WinEcon.
In this section we discuss how to make comparisons between some existing Courseware Management Systems (CMSs) and we highlight a minimum set of issues which these systems need to address. A CMS is not a piece of courseware as such. Rather it is a software system which is used to organise, launch, and generally manage large collections of courseware units [1]. It is part of the application suite which lecturers and students would use to create and interact with customised learning environments.
We want to concentrate on the issues addressed by CMSs generally rather than the specific details of the CMSs reviewed here. In particular, we want to keep the discussion well above the level of the underlying courseware technology. Hence, it makes no difference whether the courseware is implemented using WWW technology or more traditional authoring systems; the issues remain the same. However, some familiarity with specific systems is essential in order to appreciate the issues fully. In the appendices to this paper we provide brief overviews of a number of CMSs. All of these systems address a range of issues which are recurrent in any courseware development project. The particular issues addressed by each system are however quite different, reflecting the particular perspectives of their designers or the particular requirements of the projects which prompted their development. Any attempt at a comparative evaluation of such systems - even just to see why we consider them to belong to the same family of applications at all - must use some kind of reference model against which the systems can be measured. One such model (though we do not claim it is the only one which could be used) is the HyperCourseware Reference Model, first described in [SIVI94b]. This model enumerates a number of issues which are of importance in any courseware development project, viz:
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.
It is useful to consider each of the above issues and to examine what each CMS has to offer in terms of supporting or constraining users. A detailed comparison is well beyond the scope of this report, so only the most pertinent issues will be discussed here. For example, even though issues of instructional strategies and generic educational activities are extremely important we will simply state (as an over-simplification) that a good CMS strives to remain neutral on these issues, allowing courseware developers and lecturers the flexibility to adopt whatever instructional designs and educational activities they care to implement.
Looking again at the HyperCourseware Reference Model we find issues of structure, views, navigation and orientation, and then issues of structural interfaces, resource interoperability and integration. We believe that it is these two sets of issues which define a minimum set of requirements which any CMS must address. The CMSs which we are comparing all partly address these issues, and it is this common ground which makes us consider them to be CMSs.
To discuss any of the above means adopting some terminology. It is interesting (and frustrating) to see in the appendices how, within the various CMSs, different terms are used to describe similar ideas and similar terms are used to describe different ideas. The terminology used here is derived from HyperCourseware.
Authors and courseware developers will quite naturally never be satisfied with any system which is too rigid and which dictates how courseware should be structured. Figure 1 illustrates two totally arbitrary structuring approaches which one could easily imagine an author inventing. Figure 1 is intended to convey that there are endless possibilities which authors can and will invent. One major issue for a CMS to address is how to enable an endless variety of structuring approaches to be adopted and in some sense supported.
Figure 1. Two examples of authors implementing arbitrary structuring approaches.
HyperCourseware [SIVI92, SIVI94a, SIVI94b, SIVI94c, SIVI94d] provides a course structuring approach 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:
It can be seen that a Topic in HyperCourseware terms can masquerade as whatever an author requires, e.g., in figure 1., each of the courseware chunks Course, Module, Unit, Session, etc. would be implemented using Topics in HyperCourseware.
Figures 2, 3 and 4 elaborate on HyperCourseware's approach to structuring courseware.
Figure 2. HyperCourseware's generic approach to structuring courseware.
Figure 3. Structure of a Topic in HyperCourseware.
Figure 4. Implementing an Educational Activity.
The CMS not only provides developers with the means to create and manipulate courseware structures, it should also provide tools for creating and maintaining multiple views of those structures. The CMS needs to address issues of automation, e.g., an alphabetical index can be generated dynamically by the CMS whenever required. Other views, such as maps, are more subtle and may require semi-automation, i.e., the CMS could generate the map's functionality but still leave the developer with the means to visually customise the view. All views have the potential to be active navigation devices. Figure 5. illustrates in miniature how a small music course could be navigated using multiple views.
Figure 5. Multiple views of a small music course.
Having barely introduced the issues of structure, views, navigation and orientation, we hope the descriptions of the various CMSs provided in Appendix B will be slightly easier to assimilate. Issues of structural interfaces, resource interoperability and integration are all areas of concern for CMS developers and users. These are discussed in the next sections on "picking and mixing" both within and across systems.
In this section we describe how the kind of "pick and mix" facility described in the introduction can be achieved provided the user is working exclusively within the bounds of a particular CMS and using lessonware designed to work with that CMS. The "pick and mix" activities are illustrated using HyperCourseware and Caleidoscope, but similar facilities are to be found in other CMSs and it is the ideas that are important rather than the specific approaches adopted by these CMSs.
A detailed description of the "pick and mix" facilities within HyperCourseware can be found in Appendix B of this report. For the purposes of this section we present a simple example of just one aspect of "pick and mix" - adding a HyperCourseware Activity to an existing Topic. For the sake of clarity, we also present a slightly simplified view of how the HyperCourseware structure of Topics and Activities maps onto the underlying resource of directories and files. Once again, this is treated more thoroughly in appendix B.
In the HyperCourseware course structure, the hierarchical aspects of the Topic's structure are achieved by mapping directly onto the directory/folder structure of the computer's file system. Each Topic occupies a directory, Activities within a Topic are implemented as files within the Topic's directory, and sub-topics appear as sub-directories. Activities designed to work with HyperCourseware (HyperCourseware Activities) are ToolBook books (or HyperCard stacks) based on one of the HyperCourseware Activity templates.
To add a HyperCourseware Activity to an existing Topic, a user (e.g., a lecturer as described in the scenarios) does two things:
The first of these tasks is a trivial operation which can be carried out with the Windows File Manager (or Macintosh Finder). The second task is also trivially simple, requiring just the following copy, paste, and text entry operations:
It can be seen that this kind of "pick and mix" facility is powerful and easy to use. The whole operation takes literally only a minute. However even this could be further simplified to be completely mouse, menu and dialog driven, eliminating the need to use the File Manager, and eliminating the need to manually edit a Lessons Dictionary.
Figure 6. A lessons map with Activity launchers.
Figure 7. Editing the Activities dictionary.
Activities are added to a Caleidoscope course by one of two methods:
Once an Activity has been added, it is possible to change its attributes as shown in Figure 9.
Figure 8. Importing a file directly from a hard disc or network drive.
Figure 9. Changing the attributes of an Activity.
The previous section might give the misleading impression that open courseware is already a reality. Sadly, that is not yet the case. Although "pick and mix" is possible now within the bounds of a particular CMS, problems soon become apparent when we try to "pick and mix" across systems. To illustrate this, let us see what happens when we try to add a HyperCourseware Activity to a Caleidoscope gateway.
To begin with, everything looks fine. The Caleidoscope CMS "import activity" option is used, and the HyperCourseware Activity launches and appears to function. However, certain of the controls within the Activity will be assuming that the Activity is operating within a HyperCourseware environment, and will fail when the user attempts to use them. There are a number of such controls - we will examine one to illustrate our point.
On every HyperCourseware Activity template there is a button marked "Lessons Map". Authors using HyperCourseware may rename this button - e.g., so that it says "Contents" - but its functionality is always to invoke the Lessons Map (contents page, call it what you will) for the current Topic. This Lessons Map is the place from where the Activity was launched. The Lessons Map button achieves this by sending a request to the HyperCourseware system to launch the current Topic's Lessons Map. Note that the Activity cannot assume that it knows which Topic it belongs to - that would preclude "pick and mix" - hence it needs to ask HyperCourseware (which does know the current Topic) to launch the Lessons Map on its behalf. Unfortunately, in our current "pick and mix" scenario there is no HyperCourseware system - the CMS is Caleidoscope. When the Lessons Map button is pressed, the request to the HyperCourseware system is greeted with a "no such handler" error message (or similar). Naturally this can be fixed. It transpires that Caleidoscope expects a Dynamic Data Exchange (DDE) communication from its equivalent of the HyperCourseware Lessons Map button. We can code such a DDE call into this particular Lessons Map button and it will then invoke the relevant Caleidoscope gateway. This is missing the point however - delving into recoding the DDE communications can hardly now be described as "simple pick and mix"!
The above description would have read almost exactly the same using any combination of CMS and Activity; e.g., adding a Caleidoscope Activity to a HyperCourseware Topic, a WinEcon topic to a Mentor module, or any courseware-oriented HTML file to any web-based CMS, etc. Hence, with the current state of CMS technology, we do not have true "pick and mix" across systems – i.e., we do not yet have true open courseware.
The problem is this: all of the existing CMSs can achieve "shallow integration" by simply launching applications, and when faced with a "foreign" Activity this is precisely what they do. It is the same simple strategy adopted by web browsers with helper applications and plug-ins. However, really effective courseware requires that the Activities communicate frequently with the resident CMS. The Lessons Map button is but one relatively trivial example of such communication - there are very many others. We might call this rich communication "deep integration". CMS developers have achieved this typically by writing templates with the required capabilities and ensuring that the Activities are based on those templates. While this works fine for the lessonware being produced within a project, it has the side effect of tying it to a particular CMS.
As we have already pointed out, the problem with the Lessons Map button in the above scenario is just one example of a general requirement for Activities to communicate with whatever CMS has launched them. Here is a non-exhaustive list of some of the other types of communication which may need to take place between CMS and lessonware module:
Since we want "pick and mix" across systems, an Activity cannot assume that it is running in the environment created by a particular CMS. Instead we need to agree a set of protocols which will enable any Activity which uses them to communicate effectively with any CMS which also uses them. This set of protocols needs to be implementable on standard technology such that it makes no difference whether lessonware chunks are implemented using HTML pages, Java applets, Authorware modules, ToolBook books, spreadsheets, etc. This set of protocols also needs to be extensible, because courseware developers will never stop thinking of new things that they want their courseware to do. It also needs to be public domain, to encourage its widespread adoption. Finally, its first incarnation needs to be agreed by the major existing CMS developers so that existing systems and courseware can be quickly brought to compliance.
Under its existing terms of reference, EPOC is committed in the short term to developing FRAMEWOC so as to enable bi-directional communication between lessonware and CMSs, as discussed in this report. This will enable a degree of "pick and mix" across systems which is currently impossible to achieve without detailed knowledge of the inner workings of the CMSs and lessonware involved. We are also committed (in the longer term) to specifying a full object-oriented architecture to enable cooperative courseware objects (CCOs) to interact to provide the kind of courseware management functionality described in the illustrative scenarios in this report.
Under its existing terms of reference, there are no plans for FRAMEWOC to extend to the inner workings of lessonware Activities, other than those functions which are concerned with communicating with CMSs. For example, FRAMEWOC has nothing to say about the use of graphics, video, animation etc. within an Activity. We are quite aware however, that the distinction between the "inside" and the "outside" of an Activity will become increasingly blurred. For example, we can foresee the development of a CMS which takes the burden off courseware developers for loading and playing a video clip at a particular location on the screen, and providing basic video controls to the user by autmatically routing such a request to a standard system movie tool. It would doubtless make sense to standardise the protocols by which lessonware can take advantage of such facilities, and so we can see FRAMEWOC extending to incorporate those standard protocols.
This is just one example of an area which we can foresee FRAMEWOC encompassing in the future, but which at present we do not intend to pursue. It is for this reason that we see extensibility as a vital characteristic of FRAMEWOC, and we believe that an appropriate object oriented architecture, combined with a suitably abstract protocol vocabulary, will give FRAMEWOC the extensibility it needs to enable the continuing development and maturation of open courseware.
Given the very wide range of functionality which FRAMEWOC is seeking to address, and the even wider (and ever expanding) range of functionality which it may address in the future, there is clearly a case for defining FRAMEWOC compliance at a number of different levels. For example, level 1 compliance may include those functions required to enable basic "pick and mix" across systems, while level 2 compliance could include those functions required for the exporting of student data, and so on. These are merely illustrative examples, however. We are still considering what the different compliance levels should include.
We consider that the most desirable route to open courseware is one of evolution rather than revolution. In the future we foresee new lessonware and CMSs being constructed to appropriate levels of FRAMEWOC compliance, and we see FRAMEWOC being continuously extended to incorporate functionality which today is considered peripheral, or possibly does not even exist. For existing lessonware the position is necessarily less clear cut. It would be marvelous indeed if we could simply "plug in" open courseware compliance to existing lessonware and thereby transform non-integrated, non-cooperative, authoring-system-dependent pieces of lessonware into well behaved, articulate, cooperative courseware entities - we can all dream. In reality, any lessonware wanting to be upgraded to FRAMEWOC compliance will need to be modified in some way. However the upgrade may not need to be too onerous a task. It really depends on how the lessonware was constructed in the first place. Projects which have produced modular lessonware Activities will find it easier to upgrade than those which have not, and those which already use a CMS of some kind should find the process easiest of all.
Essentially, EPOC is attempting to offer existing lessonware an upgrade path to basic "pick and mix - ability" by:
We are very concerned to ensure that FRAMEWOC is seen to emerge from and belong to the courseware development community. To this end EPOC welcomes dialogues with other courseware developers and implementors, and especially with other developers of CMSs. We see this dialogue as having the following mutual benefits:
Anyone wishing to collaborate with EPOC in the specification and/or evaluation of FRAMEWOC is invited to join the tltp-epoc mailbase discussion group and post their contributions there. (You are also welcome, of course, to contact us directly.) Details of how you can do this can be found on the EPOC home page, at the following URL: http://www.amtp.cam.ac.uk/icrd/EPOC/