This book is concerned with the development of small-scale multimedia courseware at a single site which is intended for off-site distribution. By small-scale the author means the creation of courseware by one or a few people at a single site, rather than the 'size' of the courseware. He has concentrated upon this scale because:

Educational software, or courseware, is rapidly moving into the mainstream of teaching in UK higher education. There are a number of reasons for this emergence of courseware as a teaching tool. They include:

To this list might also be added student expectations. Many students have used a desktop computer and whilst most of their experience will be of computer games the emergence of CDROM-based educational software at an affordable price means that more and more will be exposed to high quality educational software. Many students will expect computers to be used as an integral part of teaching, and may well make this a criterion by which they select the university to attend.

Unfortunately the quality of educational software in the past has left a lot to be desired. Whilst the educational content has often been very high the quality of the software has been patchy - interfaces have been unfriendly and difficult to use, technical support has varied from good to non-existent, bugs have been legion, and many packages have had an unnerving tendency to fall over unexpectedly.

The consequence of this to the small-scale courseware developer is that development requires full-time commitment and a methodical and professional approach. The consequence for higher education institutions is that they have to allocate sufficient resources for their staff to undertake development, in particular of courseware intended for off-site distribution. High-quality courseware requires a professional approach.

The book explores the complete courseware development cycle, from initial concepts to product delivery. It looks both at the software life cycle and at the process of acquiring and designing the courseware content, which is after all the most important part of any courseware package. It is an attempt to impart generic guidelines of software development that can be of use to developers and would-be developers of courseware in HE, regardless of hardware platforms or software environments. As a developer of PC applications the author naturally uses examples and case studies from that environment, in particular PCs running Microsoft Windows, but this is only a reflection of his own area of expertise. There is no 'true path' to perfect courseware, but instead a track which at points is firm and straight but which for the most part slops through puddles and peat bogs forcing the traveller to take diversions or even to backtrack to find firmer ground. Moreover, one of the advantages of workng on the small scale is the flexibility of approach this allows compared to working with large teams and consortia with stricter procedures.

The book is aimed at developers and would-be developers of courseware in the academic community in general, and the UK Higher Education sector in particular. The reader is expected to be sufficiently computerate to be comfortable using their computer, but otherwise no specialist expertise is assumed. You do not have to be a programmer to read this book, although if you are you may still find it useful.

Throughout the book the author has assumed a courseware development team consisting of a content provider and a developer. The content provider supplies the educational content of the courseware, almost always commissions the project, and has little or no knowledge of software development. The developer is charged with developing the software by programming and/or authoring, and has little or no knowledge of the subject of the courseware

However, in general, the concept of a division between content provision and software development is a useful one, and it is hoped that readers will be able to adapt the model to their own circumstances.

Chapter 2 explores the nature of multimedia courseware and looks at the pros and cons of multimedia and hypermedia courseware with regard to linear and text-based applications.

Chapter 3 is concerned with the most important part of any courseware, its pedagogical content. The responsibilities of the content provider in obtaining and/or designing content are outlined and possible sources of material - such as images, or audio clips - are looked at. The process of turning analogue resources such as photographs and sound recordings into digital resources (digitisation) which can be incorporated in software, is looked at in practical detail.

Chapter 4 is the heart of this book and outlines the author’s proposed model of courseware development. The concepts of stepwise refinement, iterative development, and prototyping are introduced, after which a five-stage process of development - Concepts, Specification, Design, Implementation, and Delivery - is explored in detail.

This Chapter discusses the definitions of the terms multimedia and hypermedia, and goes on to consider the pros and cons of each paradigm with respect to the educational value of courseware.

Whilst the terms multimedia and hypermedia are often used interchangeably there is a conceptual difference between the two. Multimedia refers to the integration of two or more different information media within a computer system. These media can include text, images, audio, video, and animation, and in the medium-term future we can expect tactile media from the VR world, such as datagloves and spaceballs. Hypermedia is the extension of the hypertext paradigm to multimedia. Hypertext systems consist of nodes, holding textual information, and links, which represent semantic associations between the nodes and could be thought of as cross-references. The links are created by the author of the system, and in most cases the user is free to follow links in a non-linear fashion. In hypermedia the nodes of information may be any medium, not just text.

The pedagogical strength of multimedia is that it uses the natural information-processing abilities that we already possess as humans. Our eyes and ears, in conjunction with our brain, form a formidable system for transforming meaningless sense data into information, that is data imbued with meaning.

To the student one advantage of multimedia courseware over the text-based variety is that the application looks better.

Multimedia places considerable demands on computer hardware in terms of processor speed, memory, disk space, and data throughput. Sound, images, animation, and especially video constitute bodies of data magnitudes greater in size than text files. It requires significant modifications in terms of extra memory and expansion cards to handle multimedia to an acceptable standard. Hence a major disadvantage of writing multimedia courseware is that it may not be accessible to a large section of its intended audience which does not have access to multimedia-capable machines.

This is particularly the case in the academic sector where the provision of microcomputers for staff and students is a significant item of expenditure and one which the institution is not likely to want to repeat every 2 or 3 years. For this reason courseware developers should think very carefully about which multimedia elements to incorporate into applications and only include those which have significant value.

The essence of the hypermedia paradigm is its non-linearity. Hypermedia systems are non-linear and non-sequential. In practice this means that the user does not have to proceed through an application in a set manner - screen A,, then screen B, then screen C, etc - as would be appropriate in a tutorial or a demonstration, but instead has the freedom to roam around within the application, to move from node to node via semantic links. With hypertext and hypermedia the user can choose to view information at a superficial level by not following links, or to investigate a topic in depth by following the hyper 'trail'.

This semantic non-linearity of hypermedia fits in well with current theories of memory and learning. Scientific research into memory [Rose 1992] shows, perhaps unsurprisingly, that the brain stores memories semantically, according to meaning.

An example might be the way that particular songs bring to mind memories of situations associated with those songs. The loose, associative, structure of hypermedia applications can similarly help the user to construct meaningful links within their mind and thus aid retention. By emulating human memory processes hypermedia applications may help people learn faster and retain information longer, although as yet there is little empirical evidence one way or the other.

Allowing users to navigate their own paths through material runs the risk that they will lose their bearings and be unable to find their way to where they want to be in the application, that is be 'lost in hyperspace'. It is very important, therefore, for the designer of the hypermedia system to provide sufficient navigational aids for users to find their way around with ease. Such aids usually take the form of easily accessible features such as visible buttons, 'control panels', or menus, which provide 'landmarks' to guide users.

The interactive nature of hypermedia applications is different from the more usual situation in which software controls available options in a strict way. The user has control over how to use the application by making choices about which links to follow. This degree of interaction with, and control of, the courseware can increase student motivation by making the student feel more in control and also by simply being more fun to use than a linear application.

The loose, associative, and non-sequential structure of hypermedia systems can also be a disadvantage. Hypermedia systems are ill-suited to situations where directed learning is required. In these situations the user or student has to be taken from an initial situation where they lack knowledge of a subject, or skill at a task, and taught/trained in gradual steps along a set route to a situation where they have acquired the relevant knowledge or skill..

An additional danger in the hypermedia approach is that the student could indulge in clicking on links as they appear and going from node to node without any serious attempt to assimilate the information contained in the nodes.

Undoubtedly the construction of a hypermedia, as opposed to a linear, system places much greater burdens upon the shoulders of both the developer and the content provider. The source material needs to be organised into standalone nodes so that it fits into a hypermedia paradigm. The authors have to remember that the student is very likely to take a non-sequential path through the courseware and thus cannot structure the material in a linear way as one does when writing a book or a paper. Considerable time and effort have to be spent designing the both structure of the courseware and its interfaces, in particular its navigation facilities.

The choice of whether or not to use the hypermedia paradigm for multimedia courseware is an important one which has to be made at an early stage in the development cycle based on the pedagogy and content of the proposed courseware with relation to the characteristics of hypermedia. As already described above the non-linear and interactive nature of hypermedia is very much a two-edged sword where education is concerned and the authors have to ask themselves whether it is pedagogically desirable to allow the student to roam freely through the application. Moreover, research on the effectiveness and pedagogical value of hypermedia is still, like the technology, very much in its infancy so the developers cannot draw on an established body of research to guide their decision. Of course courseware can be created which combines linear and non-linear features.

Plainly the educational content of the courseware is of paramount importance as it is the very rationale for the software in the first place. An application may have technical virtuosity, but as educational software it stands or falls on the quality of its content. This Chapter discusses the role of the content provider, the question of copyright, sources of material in the public domain, and digitising content.

By definition, it is the responsibility of the content provider to supply the educational content of the courseware by putting together source materials - texts, audio clips, images, etc - and organising them coherently. In this context content represents both source material and organisation, the latter representing pedagogical 'added value'. Even if the content provider is adapting an existing course to be implemented in software its material will still have to be reorganised, and greatly so if the application is to be hypermedia. It is, however, of crucial importance that most of the content be in place before implementation of the courseware begins, for two reasons:

The situation regarding copyright and multimedia works to the disadvantage of both holders and users, and moves are afoot to alleviate the problem by various schemes, including agreements between groups of users and holders in particular areas. In the meantime the multimedia courseware developer has to tread very carefully and should avoid using copyrighted material except where absolutely necessary, and instead either create material or find copyright-free material in the public domain.

Sources of Public Domain Material

There is a considerable amount of usable material available in digital form in the public domain which the courseware developer can profitably use or adapt.

This is the generic term given to non-photographic images, in digital form, which can be freely copied, distributed, and used without any copyright restrictions. Occasionally the author may make acknowledgement of their authorship a condition of use but this is hardly an onerous or disabling restriction. The images come in a wide range of graphics file formats, both bitmapped and vector, although the recent trend is towards vector images which are more manipulable, although less detailed, than bitmaps. Vast amounts of Clip Art are available, particularly from shareware dealers and on the Internet. (See Appendix A for details of useful archive sites.)

Printers and designers have always had access, for a fee, to stock libraries of images for publication. In recent years, particularly with the advent of Kodak PhotoCD, high-quality digitised photographs have become available on CDROM,the only medium with the capacity to handle the enormous multi-megabyte file sizes. Advertisements for photo CDROMs can easily be found in computer magazines, particularly those with "CDROM" in the title. Copyright restrictions may well apply to the use of such images but will be specified in accompanying material or on the CD itself.

The Internet is a massive resource base not only of software but of free material on a wide range of subjects, in particular texts and images. Unsurprisingly, the majority of this material is biassed towards scientific disciplines and Information Technology, but an increasing number of non-scientific resources are coming on stream. The major problem with the Internet is finding the required resources. No definitive index of Internet resources exists, and indeed would be next to impossible to construct given the highly dynamic and anarchic nature of the Internet.

The majority of the content of a courseware application is likely to exist initially in analogue rather than digital form: printed images, audiotape, videotape, and photographic slides and negatives. Nowadays, though, any analogue source of sound and images (still or moving) can be digitised using suitable hardware..

Sound is the easiest, and cheapest, analogue medium to digitise. Many Apple Macs have built-in facilities for the recording and playback of high-quality audio. PCs require slot-in sound cards which are increasingly being supplied as standard accessories

Images in hard copy, whether that be paper, negative, or slide, are digitised by scanners of one form or another. A scanner will shine light on (paper) or through (film) a hard copy image and record the value of a dot (pixel) on that image as a number.

Scanners vary considerably in price, the major determinant, of course, being scan quality (resolution and colour depth). Although widely advertised in the computer and photographic press it is wise to investigate the technology before deciding on a purchase.

Digitising video can be problematic, despite advertisers claims to the contrary, and is certainly the most expensive form of content digitisation. Developers and content providers should think long and hard before deciding to incorporate video clips within courseware. Whilst video can undoubtedly aid the learning process, because our visual perception is highly attuned to movement, the pedagogical value added by video in courseware must be balanced against the technical complications and costs that it incurs.

Such technical problems should not obscure the value that video clips can add to a courseware application. Human vision is highly attuned to movement, and moving images can hold vastly more information than still images. Moreover, the technical difficulties that currently beset digital video are temporary and are likely to be overcome in the near future as microcomputer hardware improves and digital video standards come into force.

It is hardly surprising that there are probably as many models of small-scale, single-site courseware development as there are developers.

This Chapter I outlines a fairly simple, and often imprecise, model of the courseware development process, in the main part loosely adapted from concepts in Macro [1990] and Sommerville [1985]. The five stages of development - the software lifecycle – the author identifies, which are explored in detail in later sections, are:

However software is developed there are three important concepts which should be in the forefront of the mind of the developer at all times:

The concept of stepwise refinement is common to nearly all models of software development and is taught to programmers at a very early stage in their education/training. In essence, stepwise refinement is the process whereby, starting from the original conception of the software, increasing detail is added to the project until the level of detail necessary for implementation has been achieved.

Dialogue between the commissioners and developers of software is critical to its success, particularly in view of the power and flexibility of modern development environments (see the section on prototyping below). Dialogue should be ongoing, detailed, and critical. Continual dialogue ensures that the commissioners - or content providers, on our model of courseware production - are at all times aware of the progress of the courseware and its state and are able to participate in the design and development process..

Modern software development tools - programming languages and authoring systems - allow for the rapid creation of working models and mock-ups.

At all stages of the software lifecycle the developer should produce prototypes both for internal testing and to demonstrate to the content provider. Prototyping is a major part of the developer-content provider dialogue for many reasons. Amongst these are:

The first stage in any model of software development is plainly that of concepts when the idea for the courseware emerges. The content provider should draw up an ambitious list of desirable application features with relatively little consideration of technical problems.

However, there are a number of important issues which must be addressed at this stage, including cost, desirability, and need.

Without considering the question of available resources, the obvious first question to be asked is: "Do we need this courseware?" That is, will the courseware perform any one or more of the following functions:

· improve teaching quality

· improve teaching productivity

· gain a higher profile for the institution and thus help to raise funding

· make money for the institution

The second question to be asked is: "Do we have the resources to develop this courseware?" The resources in question are, of course, money, time, and people, no one of which is sufficient. A would-be content provider should not assume that s/he can produce courseware content and continue her normal duties, and money should be put aside to employ temporary cover if necessary.

Related to the question of needs, and just as important, is the question: "Will the courseware improve the quality of teaching?" In other words, to use a commercial term, does the courseware represent pedagogical 'added value' in comparison to currently used teaching methods?

The courseware should be aimed at a particular population of users, for example first year chemistry undergraduates, or final year language students taking a phonetics option. Unlike commercial software, academic courseware is not solely judged on sales. Such courseware is more often judged by its effectiveness in teaching its target audience, and/or releasing the time of tutors for other course-related activities. The important point, at this stage in the development process, is that the target audience, however large or small, be accurately identified by the development team

One of the first things to do is to document what the content provider wants from, and in, the courseware. The content provider and developer together need to produce a wishlist of desirable application features from which the eventual application 'blueprint' will be produced.

The 'blueprint' of the software system, the FS is the document that implementation is based on and represents the 'contract' between content provider and developer, and must therefore be explicitly agreed by both parties, perhaps even to the point of 'signing off'.

Even though the courseware development project should have a definite timescale with explicit target dates for deliverables, it has to be faced that the probability of slippage is not inconsiderable, and this should be taken into account when compiling the schedule.

Much of the costing for the project will have been carried out at the concepts stage when the question of resources was addressed. The possibility of cost overruns, like time overruns, should be borne in mind. The main cost components are the people involved rather than the hardware and software.

By design the author means primarily the planning of the implementation of the application by the developer, that is how it will be programmed/authored

The content provider can provide useful input into screen design, and at the very least should be able to approve or veto designs.

The main point that needs to be made is that design and implementation follow the same paradigm of stepwise refinement that applies to the software lifecyle as a whole - that is, to an overall plan adding increasing detail until sufficient detail exists for coding/authoring to take place.

A crucial decision to make is which development tool to use. There are hundreds of development environments on the market to choose from - programming languages, authoring tools - which need to be reduced to the one or two (rarely more) necessary for developing the courseware. Among the criteria that can be used are:

It is also a good idea, whenever possible, to acquire working models of tools in order to try them out. Only with hands-on experience of a tool can one really assess its functionality, ease of use, and above all difficulties.

Software other than the development environment will be required. At the very least, the project requires a word processor in order to write documentation and may need a spreadsheet to handle the accounts. Additional software for a hypermedia courseware application incorporating images, sound, and video, may well include:

As a general rule the platform on which the courseware is developed (development machine) should be of a higher specification than the platform on which it is to be run by users (target machine), primarily because the demands of development software will be greater than the demands of 'display' software.

Increasingly courseware is being mounted on Local Area Networks (LANs) and run by diskless desktop computers. If the development team intends that the courseware should be runnable from a network this has to be catered for during the design and implementation process as a number of technical adjustments have to be made.

Network distribution has a number of significant advantages over disk distribution:

Some of the disadvantages are:

As the number of Internet connections grows, courseware distribution via the Internet will become more cost-effective.

After the software has been conceived, specified, and designed, it has of course to be implemented, that is, coded or authored using the chosen development tool(s). The implementation stage also encompasses tasks other than pure programming or authoring, in particular the production of documentation and the program testing process.

The final courseware should be both modular and developer-independent. That is, it should be composed of autonomous, or near-autonomous, program modules which can be removed, replaced, or altered, with little or no effect upon other modules or the application as a whole.

This is the documentation which describes the application in detail from the developer's viewpoint, and which is often sadly neglected by software developers, in much the same way as programmers often neglect to fully comment their code. The main purpose of application documentation, then, is to aid the process of application maintenance and upgrading, part of the Delivery stage of courseware development, as I have identified it (see the later Section in this Chapter). It should be a complete and readable description of the application. Among the topics it should cover are:

The need for documentation for the end user is obvious.

The content of manuals, whether hard copy or online, will plainly vary from application to application, but at the minimum should comprise:

Useful additional features might include:

Plainly the application should undergo continuous testing throughout implementation. This will in all likelihood happen as a matter of course, as modern software development tools allow the construction of small application modules which can be independently tested, and to some degree encourage such an approach to programming and authoring.

Internal testing - that is, on the development site - is formally known as alpha testing, and this should be conducted with as much rigour as possible before the next stage, beta testing, where the application is released to the external world.

The delivery stage of the development process not only entails the final delivery of version 1.0 to the outside world, but also ongoing technical support and software maintenance, the production of future versions, and user evaluation. Courseware that is not supported and improved will rapidly fall into obsolescence and disuse.

Ideally, the installation of software should be simple. The vast majority of modern commercial applications for both Mac and PC have easy-to-use installation routines that require little effort from the user apart from feeding disks into the drive. The creation of seamless yet customisable installation routines can be a non-trivial task, although some software development systems now incorporate utilities which manage the creation of installation routines for the developer.

This is absolutely essential to the success of courseware, or indeed software in general. Every application will generate technical problems, particularly if running on PCs with their multitude of possible hardware and software configurations. More often than not, these problems will be due to inexperience, lack of technical ability, or simply lack of confidence, on the part of the end user.

Comprehensive, comprehensible, and sympathetic technical support must be readily available by phone and/or email to the user.

As with applications software, courseware also needs to be upgraded periodically with the release of new versions, perhaps even more so given that the knowledge content of courseware can date as quickly as the technical content.

Maintenance and upgrading of courseware requires some form of version control, particularly in the sense of version numbering, which should be logical and consistent. Various schemas exist for version numbering.

Whatever schema is used, it is important - particularly from a technical support viewpoint - that previous versions of the courseware together with associated documentation be preserved at the development site.

Post-release user feedback can improve the chances of success of any software. Applications which cater for the stated needs of users are more likely to succeed and be used than those which cater for the perceived needs of users.

Although there is no easy solution to the problem of obtaining useful and honest user evaluation of courseware it is self-evidently necessary if courseware is to survive and thrive in an increasingly crowdedarea.