(Note: this is such a good summary that I made a local copy of it so that my students could get easy & reliable access - SB)

Understanding IT: Developing Multimedia Courseware by Fred Riley

Contents

Preface iAcknowledgements iii1. Introduction 11.1. Quality Courseware 21.2. What this Book is About 21.3. Intended Readership 31.4. The Courseware Development Team 31.5. Content of the Book 42. Multimedia Courseware 52.1. Multimedia and Hypermedia 52.2. Advantages of Multimedia 52.3. Disadvantages of Multimedia 62.4. Advantages of Hypermedia 72.4.1. Hypermedia and Human Memory 72.4.2. Landmarks 82.4.3. Interactivity 82.5. Disadvantages of Hypermedia 82.5.1. Directed Learning 82.5.2. Increased Development Effort 92.6. When to use Hypermedia 103. The Content of the Courseware 113.1. The Content Provider 113.2. Copyright 113.3. Sources of Public Domain Material 123.3.1. Clip Art 123.3.2. Photographs 133.3.3. Resources on the Internet 133.4. Digitising Content 143.4.1. Audio 143.4.2. Images 153.4.3. Video 154. Courseware Production 194.1. Introduction 194.2. Stepwise Refinement 204.3. Iterative Development 204.4. Prototyping 214.5. Concepts 224.5.1. Needs 224.5.2. Resources 224.5.3. Pedagogy 234.6. Target Audience and Delivery Platform 234.7. Specification 244.7.1. What the User Wants 244.7.2. Functional Specification 254.7.3. Scheduling 254.7.4. Costing 254.8. Design 264.8.1. Development Tools 264.8.2. Other Software Tools 284.8.3. The Development Machine 284.8.4. Network Awareness 294.8.5. Distribution Media 294.8.5.1. Disk-based Distribution 294.8.5.2. Distribution over Internetworks 304.9. Implementation 314.9.1. Modularity 314.9.2. Application Documentation 324.9.3. User Documentation 324.9.4. Testing 334.10. Delivery 344.10.1. Setup Routine 344.10.2. Technical Support 344.10.3. Maintenance and Upgrading 354.10.4. Version Control 354.10.5. User Evaluation 36Bibliography 37Appendix A: Archives on the Internet 39

Preface

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

a) most non-commercial, academic courseware has been, and continues to be, produced in this way.

b) large-scale software production - software engineering - is a vast field of enquiry which is well covered by a raft of impressive texts (see the Bibliography for a few examples). Large, multi-site projects have no shortage of development models to choose from, whereas small-scale developers often search in vain for development guidelines.

The book is primarily written for developers and would-be developers in the UK Higher Education sector and whilst there are some specific references to UKHE it is hoped that the concepts within will be applicable to readers working outside this sector. The work concentrates on academic software production as this has different imperatives to commercial software, not least that the goal of the software is to improve teaching and perhaps save teaching time, rather than to make direct profits.

In addition the book concentrates upon Computer Aided Learning (CAL) rather than Computer Based Training (CBT). Although the methods used in developing learning and training materials are often similar they sometimes diverge radically, and of course the goal of the instruction is very different - put crudely, learning is about the 'why' and training about the 'how to' and this difference is mirrored in the respective courseware.

The work has been written from my perspective as a practising courseware developer whose formal training has been in computing and whose only teaching experience was acquired training people in the use of applications software. I'm not an academic, and have only a sketchy knowledge of pedagogical issues, and thus I shall not be discussing the merits of CAL in general, or its application in academia in particular. Scores of books and papers have been written on this topic by practising educators and I do not feel that I can add any value to this argument, which in any case is becoming stale and sterile in the face of imposed reality. The main question is not whether CAL should be used in education but how, and to what end, and there are much better qualified people than myself writing on this subject today.

Fred Riley, University of Hull

June 1995

Email: f.h.riley@langc.hull.ac.uk

Tel: 01482 466316

Acknowledgements

This book was written at the University of Hull under the auspices of the Information Technology Training Initiative (ITTI) project Multimedia-based IT Training for the Humanities. ITTI is an initiative of the Information Systems Committee of the Higher Education Funding Councils.

I would like to thank all the people who have helped me, directly or indirectly, in the writing of this book, in particular Dr Brian Powell and Jenny Parsons. Of course, they are not responsible for any errors or omissions in this work, for which I am solely to blame. I also wish to thank all the staff at the University of Hull Computer Centre for all the help and invaluable expertise they have given me in this and other projects, and the staff at the Language Centre for giving me a home and cups of tea.

Registered Trademarks

The following table lists the registered trademarks used in this work:

Trademark          Company                        

Actionmedia        Intel                          

Authorware         Macromedia                     

Corel Draw!        Corel                          

IconAuthor         Aimtech                        

Macintosh          Apple                          

PhotoCD            Kodak                          

Quicktime          Apple                          

Video for Windows  Microsoft                      

Visual Basic       Microsoft                      

Windows            Microsoft                      

Introduction

Educational software, or courseware, is rapidly moving into the mainstream of teaching in UK higher education. More and more lecturers are using courseware as an integral part of the courses they teach. There are a number of reasons for this emergence of courseware as a teaching tool, not all of which are solely concerned with pedagogy. They include:

Falling power/cost ratio of desktop computing. For less than a thousand pounds, at the time of writing, an academic can have a high-speed, high-capacity, multimedia-capable microcomputer on the desk.

Improved quality and availability of multimedia courseware. Various publicly-funded initiatives have been, and are, currently engaged in producing large numbers of low-cost courseware packages, and the commercial world has been actively targetting both the domestic and academic markets with educational software.

Appreciation of pedagogical advantages of courseware. There appears to be an increasing realisation by teaching staff that, in particular situations, courseware - particularly multimedia courseware - can offer a pedagogical improvement on traditional teaching methods.

Increasing pressures on teaching time. The number of students entering HE has been steadily rising yet staff numbers have remained relatively constant, so greater 'productivity' is required of teaching staff. In certain situations courseware can free time for the hard-pressed lecturer.

Government encouragement. The government has actively promoted the use of computers in teaching by funding 'initiatives' (CTI, ITTI, TLTP) in order both to increase awareness of computers as a teaching tool and to produce materials, particularly training courses and software.

To this list might also be added student expectations. Increasingly students are attending university to whom the computer is an everyday appliance and not a mysterious machine the workings of which are unfathomable except to the enlightened. 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.

Quality Courseware

Unfortunately the quality of educational software in the past has left a lot to be desired. Software production has often been a 'cottage industry', the province of enthusiastic academics and amateurs with some knowledge of a programming language or authoring system. 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. Up to a point the variable quality has gone relatively unnoticed, not least because there were so few packages available that the scope for comparison was limited. In addition, student expectations were low. Many were excited simply by using computers in any capacity and few had had access to desktop machines prior to university.

(This is certainly not to criticise the pioneers who developed early courseware, often academics who had to write in their own time because of the lack of enthusiasm, or even opposition, of their departments. Without these early enthusiasts, who laboured hard for little reward except personal satisfaction, we would be much less advanced in our use of educational technology than we are now, and I would not be writing this book or doing the job I do.)

However, the advent of Graphical User Interfaces (GUIs) and cheap multimedia applications has significantly raised the expectations of users. Users in general will no longer tolerate text-only interfaces, abstruse command lines, and programs that fall over on incorrect input. Their expectations are conditioned by the high-quality off-the-shelf software produced by software giants like Microsoft and Lotus. Students who use fully-featured, robust, and easy to use word processing packages - like Word for Windows or MacWrite - to type their essays are going to judge courseware, however unfairly, on the same criteria of usability and functionality. Their expectations and demands are high, and justifiably so. They expect "plug-and-play" applications with friendly, intuitive interfaces, online Help, and readable manuals, which do not impose a steep learning curve on the user. In a word, they expect quality.

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.

What this Book is About

This work is concerned with the development of small-scale multimedia courseware at a single site which is intended for off-site distribution. Many academics, research assistants, and postgraduates are already engaged in creating software packages for use on-site within their own department and over which they can have close control of usage. In such situations the developer can afford to be fairly relaxed about the development process (although a methodical approach is still desirable) as any errors are confined to the site and can be easily remedied by the authors. However, software which is intended to be used off-site needs to be of a high standard, particularly if it is to be marketed, and thus requires a more rigorous approach to development and the provision of technical support to end users.

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 I will naturally use examples and case studies from that environment, in particular PCs running Microsoft Windows, but this is only a reflection of my own area of expertise. Principles of software development should be, as far as is possible, independent of implementation environments. Although at the technical level writing PC applications is very different from writing for the Mac, or X-Windows, the overall development process is no different.

It is not my intention to put forward a simple, "painting by numbers", model of courseware development. Whilst it would be nice to have a predefined development 'template' which could be followed without too much thought, the reality is that software development, like life itself, is messy and iterative. 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 working on the small scale is the flexibility of approach this allows compared to working with large teams and consortia with stricter procedures.

Intended Readership

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.

The Courseware Development Team

Throughout the book I have 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. One or more people may be engaged in each activity. For example, a number of academics may be charged with collating and writing content which the developer then implements in software. Similarly, a number of developers may be employed to write different modules of the courseware. The concept of a division of roles is a useful one which is commonly adopted in software engineering texts.

Of course in many cases the provider will have some technical expertise and the developer some subject knowledge. It is also possible that one person can be both, or that those involved in the project act in both roles, or that some situation might obtain which my limited imagination has not envisaged. 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.

Content of the Book

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 my 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.

At the end of the book there is an annotated Bibliography and an Appendix which contains pointers to useful resources on the Internet.

Multimedia Courseware

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

Multimedia and Hypermedia

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.

Whilst all hypermedia systems are of necessity multimedia, not all multimedia systems are hypermedia. This distinction will be important, particularly when we are discussing courseware, as we shall see in the following sections of this Chapter. In particular courseware developers, and academics who provide the courseware content, should give careful consideration at an early stage in the development process to the pros and cons of hypermedia before deciding whether or not the paradigm is appropriate for the educational project being proposed.

Advantages of Multimedia

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. The old saying that "a picture is worth a thousand words" often understates the case especially with regard to moving images, as our eyes are highly adapted by evolution to detecting and interpreting movement.

So, for example, a photograph of Dentdale in the Yorkshire Dales, apart from being aesthetically pleasing, can contain a wealth of information relating to the geology, climate, society, history, and economics of the area. Similarly, a recording of a politician's speech can allow us to discern significant semantic factors which would not be apparent in a written transcript. Even when an image or sound can be described accurately and concisely in words it can still be processed by the brain more quickly and easily than its text equivalent because text, as a symbolic system, incurs 'processing overheads' - the symbols have to be decoded before their information content is released.

To the student one advantage of multimedia courseware over the text-based variety is that the application looks better. If the courseware only includes a few images at least this gives relief from screens of text and stimulates the eye, even if the images have little pedagogical value. More often than not, however, the inclusion of non-textual media into courseware adds pedagogical value to the application. For example, a piece of courseware describing a dig at an archeological site would be of much more value to the student if it included images of the site, such as enhanced aerial images showing interesting features like old field boundaries, or diagrams illustrating where digging and scanning took place, than if it merely used text even in an imaginative and interesting way.

Disadvantages of Multimedia

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. As a result of the challenge this has presented to hardware designers multimedia has been a late arrival on the desktop, particularly in the PC arena, and this means that there are many machines currently in use that struggle with multimedia elements. Although at the time of writing a standard, mid-range desktop PC is capable of displaying multimedia documents, most machines only 2 or 3 years older struggle to do so and in many cases require 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.

Advantages of Hypermedia

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. For example, in a hypermedia tutorial I recently developed in collaboration with a lecturer in Hispanic Studies on the subject of the Spanish Civil War, the student may click on a hypertext reference to Largo Caballero, a prominent socialist politician of the time, which lead to a biographical page containing his photograph and a recording of a speech by him as well as a textual description, which in turn contains hypertext references to his party which can be followed to a description of the party, which contains references to prominent figures which can also be followed, and so on. 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 can also lead to them investigating other related, but perhaps tangential topics in a way which would be very difficult in a linear system, such as a tutorial or a book.

Hypermedia and Human Memory

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. Indeed, we find it difficult to remember data otherwise, and when faced with such data the human brain attempts to find or impose order and patterns upon it, one obvious example being the organisation of stars in the night sky into constellations. Steven Rose gives an example of memory by meaning when he writes that he can remember with ease the 48-digit number

5247193827936335212554409086532251141355600362269

This is because it

"contains a sequence of birthdays, telephone numbers and other codes that I have a regular need to use and therefore remember... this particular unique number sequence has a meaning which is also unique for me." [Rose 1992, p.96. Emphasis in original.]

To me this example is analogous to hypertext, with each code representing a node connected by meaningful links to other nodes. Of course, if the numbers were rearranged randomly the information content in the sequence - its meaning - would be lost and the new sequence be very difficult for most people to memorise.

We each organise information in ways which are meaningful to us personally. 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.

Landmarks

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.

Interactivity

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. To be sure this is only partial control insofar as s/he is using a 'hyperspace' which has already been defined by the authors of the application, but nevertheless this does represent a qualitative shift of control to the user. 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.

Disadvantages of Hypermedia

Directed Learning

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. It could be counter-productive in such situations for the student to have access to material more advanced than their current knowledge/skill level, as might be the case with a hypermedia system. For example, it would not be helpful for a student to read about the future perfect tense in French when they are at the Beginner level. In such situations a modular, sequential, and directed approach is normally used for successful learning. Indeed, even in situations where directed learning methods would not normally be used the accusation of formlessness can be levelled at the use of hypermedia. That is, if the student moves through the material following associative links the danger is that they will be unable to place the information learnt within a coherent overall structure and this could result in misunderstanding of the subject in question.

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. Moreover, the more non-textual clips in an application the greater is the likelihood that a student may flick through the application ignoring any text and playing any clips s/he comes across - the equivalent of browsing through a book looking at the pictures. To get the most from a hypermedia application the student must be motivated to learn about the subject.

These are serious criticisms which must be borne in mind by anyone thinking of creating a hypermedia application. Whilst no one can legislate against the lazy user the effort should at least be made to structure the courseware coherently for motivated learners, perhaps by constructing the application content around a core of material such as a narrative thread. In more complex courseware a number of different paths could be created which students interested in particular topics could be advised to follow. A geological hypermedia encyclopedia comprising screens for, say, individual rock types and formations, would contain a vast amount of information. Different paths through the encyclopedia could be laid out for students interested in petrology, geomorphology, glaciation, or any other specialism which the encyclopedia could serve.

Increased Development Effort

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.

When to use Hypermedia

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. An example might be a language course comprising a number of modules which the student would have to undertake in a specific order, while within each module s/he may be free to roam and additionally access hypertext dictionaries and grammatical help.

The Content of the Courseware

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. Whilst this may seem obvious it is all too easy for both content providers and developers to be seduced by the technical wizardry which modern hardware and development software allows, and to neglect the core of the application. This Chapter discusses the role of the content provider, the question of copyright, sources of material in the public domain, and digitising content.

The Content Provider

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:

a) the content will, to a great extent, dictate the structure of the courseware;

b) development requires content to advance the application

The content provider is only responsible for providing content in analogue form, such as text and images on paper, audio tapes, and video tapes. This is not to say that it isn't useful for the developer for content to be supplied on disk, particularly text, but that it should not be expected of the content provider. (See the section on Digitising the Content later in this chapter.)

Copyright

This is a serious issue for all multimedia courseware developers. The laws of copyright apply to software as they do to books or music or any other media, that is that the use of any material requires the permission of the copyright holder(s). This may not always be easy to obtain. There may be multiple copyright holders. The holders may be difficult to track down, or they may simply not reply to permission requests.

A common practice in the academic world is to send a letter to the holders informing them of the users intention to use their material for a particular purpose and asking for permission to do so, but with a statement that if they do not reply within a certain period of receipt of the letter the user will assume that they have granted permission. However, the best solution is for the user to gain the explicit permission of the holder to use the material for a stated purpose, or not to use the material in the first place.

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. Such material includes:

texts, including some literary classics

clip art

photographs, such as stock libraries on CDROM

audio clips

video clips

It is, however, erroneous to assume that because material is in the public domain that it is necessarily copyright-free. If any documentation is present with the material, whether electronic or hard copy, it should be scrutinised carefully for conditions of use. Similarly, material available on the Internet is covered by copyright laws, although there is an understanding amongst Internet users that material placed in the public domain, not accompanied by details of use restrictions, can be used freely for personal and non-commercial purposes as long as it is attributed.

Clip Art

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.)

Modern day commercial graphics packages often come bundled with large image libraries on CDROM, which are often described as Clip Art but nevertheless are covered by use restrictions in the application licence agreement. Although it is unlikely that any problems would arise from single-site use, before distributing applications containing such material it is wise to inspect the licence agreement closely.

It has to be said that the vast majority of Clip Art images are useless from an academic viewpoint but the sheer volume available means that, Murphy's Law and its derivatives notwithstanding, there is a good possibility of finding a desired image.

Photographs

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. They exist on a wide range of subjects, although as the photos are aimed at the commercial market they tend to be quite general and there is as yet a relative dearth of academically-useful material. However, in my opinion the situation is likely to improve in the near future as more specialised photo libraries come on to the market. 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.

Resources on the Internet

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. However, a number of search engines, such as Veronica and the World Wide Web Worm, exist which present partial indexes of Internet resources and which allow the user to search by keyword. This is not the place, however, to discuss Internet use in any detail - the reader is directed towards the burgeoning literature on the Internet, a good example of which is Krol [1994]. Appendix A contains a number of Uniform Resource Locators (URLs) pointing to resource archives on the Internet, which may be of use to developers.

Digitising Content

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. At the time of writing the majority of microcomputers - and certainly the vast majority of PCs - require additional hardware to enable digitisation of analogue sourcese. This extra hardware, in the form of expansion boards or external devices, which may also - directly or indirectly - create a need for additional software, naturally adds to the cost of the computer to be used to develop the project. As digitisation is a technical matter the responsibility properly falls upon the developer, rather than the content provider whose role it is to collate and/or create the content. The content provider is responsible for the pedagogical content of the courseware, a hard enough task without being distracted by the technicalities of preparing information for the computer.

Audio

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. Essentially audio digitisers are simple analogue-to-digital converters (ADCs) which take an audio waveform as input and sample the wave - record the numerical value of its amplitude - so many times a second (the sampling frequency). Each sample is stored as a binary number which the computer can process like any other data. Playback of digitised, computer-generated, sound is accomplished by the reverse process using a digital-to-analogue converter (DAC).

The quality of digitised sound is determined by two factors: the sampling frequency and the number of bits allocated per sample. The higher the sampling frequency the less is lost from the original sound and thus the better the quality. Sampling frequency usually ranges from 8kHz (voice quality) to 44kHz (CD quality). Similarly, the more bits per sample the more accurate that sample will be and again the less will be lost from the original sound. Currently standard audio hardware can sample at either 8-bit (28 = 256 possible sample values) or 16-bit (216 = 65,536 possible values). Of course, the higher the quality the greater the size of the resulting audio file. Digital audio is now a mature technology with established standards and presents few technical obstacles to the developer.

Images

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. With monochrome scanners the number will be either 0 or 1. Colour scanners, however, will record the pixel value as a number triplet denoting the red, green, and blue (RGB) components of the pixel, and the greater the number of bits allocated to this value the greater the number of colours visible in the resulting scanned image (its colour depth). The other major determinant of scan quality is the resolution of the scanner, or the number of dots per inch (dpi) it can resolve on the hard copy - the higher the resolution the higher the quality. At the time of writing widely available paper scanners can handle 300dpi x 24-bit colour (16.7 million shades) and slide/negative scanners up to 4096 x 2732 pixels and 32-bit colour. This is more than adequate for images to be displayed in courseware.

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. Many computer graphics texts (eg Corrigan [1994], Riley [1993], Rowell [1991]) describe the technology in accessible terms. Investment in a graphics package to manipulate the scanned images is also likely to be required.

An increasingly popular way to convert photographic slides and negatives into computer graphics is Kodak's proprietary PhotoCD technology. The developed negative or slide is sent to Kodak, usually via a retail outlet, who scan the image in five different resolutions at 24-bit colour and place the results on a CDROM, up to 100 images per disk. Although the images are in a proprietary graphics file format (.pcd), software is readily available to read and convert them to other formats. PhotoCD is a highly cost-effective way of digitising photographs, the only disadvantages currently being the long turnaround time (2 weeks or more) and the danger of losing the film in the post!

Video

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. These include:

Cost of the capture card. The digitising of video requires an add-on capture card. Whilst an increasing number of cheap video capture cards are coming on to the market these have technical limitations, such as not being able to handle sound and thus requiring the mixing of sound files with the video. A professional-quality card bundled with professional-quality software will, at present prices, leave little change from £1000.

Lack of standards. As with any immature technology no definitive standard has arisen for digital video. Currently the major digital video file formats are AVI (Video for Windows) and Quicktime (Macintosh) for software-only playback, and AVS (Intel Actionmedia) and MPEG (Motion Picture Expert Group) for hardware-assisted playback - that is, where the delivery machine also requires an add-on card. Conversion between these file formats is problematic at best, and impossible at worst. Similarly there are a number of incompatible proprietary hardware architectures, of which only one or two will survive into maturity. An example is Intel's Actionmedia board which appears to have been abandoned by the company: as a result software drivers are no longer being written for it and it is rapidly becoming obsolete.

High delivery machine specification. For the captured video clip to play at an acceptable size and frame rate the delivery machine either has to have an add-on card, such as an MPEG decoder (not a feasible proposition for mass-distribution software), or a fast processor and plenty of RAM. Even with a 486 PC digital video clips often only play back in software at 15 frames per second (fps), the minimum tolerable, in a window 160 x 120 pixels in dimension, and in 256 colours. Inclusion of video clips in courseware can limit its target audience to those with sufficiently capable hardware and even then the replay may not be of an acceptable quality.

Disk space. Video clips use immense amounts of disk space, even when sophisticated compression algorithms are used. For instance, a 42-second video clip I recently digitised in the AVI (Video for Windows) format took up 4.5Mb of disk space. The inclusion of video clips makes it certain that an application has to be distributed on CDROM.

Throughput. Video clips require a lot of data to be delivered very quickly. Whilst modern microcomputers have hard disks and data buses fast enough to handle such data throughput this cannot be said with such confidence for CDROM drives and networks. Single-speed CDROM drives are incapable of handling the throughput, and double-speed drives often struggle, dropping frames in the process - once again, inclusion of video within courseware limits the hardware on which it can be used. Similarly video clips often play badly over Local Area Networks (LANs) because of the data transmission limitations, which militate against the steady data flow required for video. Again, this has implications for delivery, particularly as many users of courseware will want to run it on a LAN.

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.

Courseware Production

Introduction

To reiterate a point made in the introductory chapter, there is no one foolproof method to produce good courseware, no 'true path' to the perfect product. Even in the world of large-scale software production there is a multiplicity of software engineering models for development teams to follow. If this is the case in the highly formalised area of Software Engineering then it is hardly surprising that there are probably as many models of small-scale, single-site courseware development as there are developers.

Although there is no 'true path' to developing courseware some paths are less rocky and winding than others. However, the full rigour of software engineering models, with their intricate flow charts and formatted documentation, is clearly inappropriate for small-scale software production. Any attempt to slavishly follow such models would lose the small-scale developer the main advantages that being small bestows, in particular flexibility, adaptation, and improvisation. Nevertheless the would-be developer is advised to read a software engineering text, such as Sommerville [1985], to gain an insight into large-scale development processes and perhaps adopt or adapt ideas to the developer's own situation.

Thus in this Chapter I outline 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 - I identify, which are explored in detail in later sections, are:

Concepts

Specification

Design

Implementation

Delivery

Even if the reader disagrees with this model of development it is my hope that the concepts within will help to clarify the mind and encourage developers to be rigorous.

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

Stepwise refinement

Iterative development

Prototyping

These important ideas will be explored in the next three sections.

Stepwise Refinement

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. This is little more than common sense and as a concept is used by us all in our work and personal lives. When planning a project, whether it be the restructuring of a Faculty or the laying out of a flower bed, we first look at the big picture and then add detail step by step. (Although as the next section on Iterative Development explains, this is not always a one-way process.)

Whilst this may appear obvious it is all too common for developers to start at the level of detail and work up. They may have a loose idea in their heads of the final product and some of the functions it should have and proceed to author or code those functions without fitting them into an overall project. This is an approach many untrained programmers take, which is a little akin to designing a car by starting at the wheel nuts, and results in increasingly patched-up software as new functions written necessitate tinkering with the code in older functions. The resulting program/application is an unstable mishmash of ill-fitting functions and ad hoc patches ready to fall over at the slightest provocation.

Iterative Development

Software development is not a one-way process with arrows going in one direction through a flowchart, from concepts to delivery, but rather an iterative process,. Information and experiences from later development stages can be fed back into earlier stages. For example, the developers may find during implementation that a desired feature of the application is not technically feasible and so would have to go back to the content provider and renegotiate the software specification. Alternatively, a technical possibility may arise during implementation which would enable the developer to propose additional features in the product which again would be built into a redefined software specification.

Hence, 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. Whilst this dialogue may seem onerous to some developers, who may not want interference in what they consider to be their domain, and content providers, who may be satisfied to provide the content and wait for a product to come out at 'the other end', it increases the probability that the courseware will be what the content provider wants, robust and bug-free, and user-friendly.

How the dialogue is managed is of course a local issue, and in most cases is likely to be informal, but it is probably a good idea to have periodic progress meetings of which written records are kept. This not only safeguards against misunderstandings but can also be of aid in the future when new versions of the software are being planned.

Prototyping

Modern software development tools - programming languages and authoring systems - allow for the rapid creation of working models and mock-ups. In Visual Basic, for example, a non-functional screen may be drawn in a matter of minutes by placing buttons, fields, and other objects on a form. Moreover, applications can be compiled and run inside the application development environment. This undoubtedly gives the modern day developer considerable freedom to experiment. It also allows the developer to prototype at all stages of development, from the moment the first code is written, or object drawn, right up to the last beta version. This is not only a considerable help when it comes to program testing but it can also enhance and facilitate the dialogue between content provider and developer.

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:

misunderstandings are identified by showing on screen what was previously on paper

the user can test modules from their viewpoint and ask for amendments if necessary

possibilities can be demonstrated to the user who will sometimes need to be shown what is possible before s/he can formulate requirements

the feasibility of application features may be assessed particularly from the viewpoint of 'user-friendliness'

For example, at the appropriate stage the developer might present the content provider with some possible user interfaces which have no functionality but aid the content provider in choosing the 'look and feel' of the finished product. In summary, prototyping is an integral part of iterative development which benefits both parties in the development team, and which should not be neglected.

Concepts

The first stage in any model of software development is plainly that of concepts when the idea for the courseware emerges. At the start of a courseware project it is always better to be ambitious than conservative with regard to application features simply because it is easier to prune down an over-bold wishlist during the development process than it is to add features to a conservative software specification, particularly after development has commenced. 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.

Needs

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

This question will be particularly pointed if the costs of development are to be borne by the institution itself rather than, say, external funding bodies, as opportunity costs will need to be considered - the costs of the courseware could be used, say, to employ a lecturer for a year.

Resources

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. Developing courseware for off-site distribution is a non-trivial and costly exercise. Even if personnel employed on-site have the necessary expertise their time will still have to be bought out to pay for temporary staff to cover their normal duties, and if personnel have to be externally recruited then that necessarily adds costs such as advertisements and travel and relocation expenses, and will delay the onset of the project.

Moreover, recruitment may not that easy. Most courseware development projects will be of short duration and it is often difficult to recruit skilled software developers for short-term contracts, or if one succeeds to retain them for the full contract, particularly given the fact that in IT generally demand for labour exceeds supply so that lucrative positions in the commercial world always beckon.

Additionally, one also has to budget for the time of the content provider, assuming that s/he is currently working at the development site. The workload of academics in UKHE is steadily increasing and 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.

In comparison to the labour required the cost of any hardware and software is trivial, although of course it still has to be considered.

All in all, at current prices, a 1-year full-time courseware development project is unlikely to leave much change out of £20,000. Of course not all of this has to be cash, as such - no doubt a lot of creativity can be applied so that much of the cost is only 'on paper'. However, in the feasibility stage at least, it should be assumed that any costs are real and should be planned for accordingly. Courseware development is not cheap.

Pedagogy

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 represented pedagogical 'added value' in comparison to currently used teaching methods?

As an example, I work within the Language Centre of the University of Hull. It would be perfectly possible for me to develop multimedia courseware for, say, intermediate students of French, incorporating audio and still and/or moving images. However, how would this improve upon current learning methods whereby students use self-study rooms containing televisions with video players and cassette tape decks, with texts, videotapes, and audiotapes to hand?

The point is that 'analogue' methods of teaching and learning should not be abandoned and superseded by 'digital' methods unless there are clear cost and pedagogical advantages to be had. Certainly courseware should not simply be the transcription of analogue material into digital form.

Target Audience and Delivery Platform

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. This means that academic institutions can write specialised courseware which would not be produced in the commercial world because it would never sell enough copies. 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. (Ideally, of course, some sort of 'market research' is desirable, but this is unlikely to be within the capability of a small team and the target audience is more likely to be defined by intuition of an 'untapped need'.) Similarly, it is important that the delivery platform for the courseware - the target machine - be defined at this stage, as this is a criteria in defining the target audience. The lower the delivery platform specification the greater the potential audience, although of course the application functionality may be reduced. At least the decision as to the target machine can be informed by statistics generally available as to the distribution of hardware within academia., although the circumstances at the development site will often be the most significant influence.

Specification

Once the courseware development project has been given the go-ahead the business of drawing up a software specification begins. This is a continuation of the process of stepwise refinement so that increasing detail is added to the initial concept of the software, until a sufficiently detailed specification of the software emerges with which the developer can commence implementation.

What the User Wants

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 developer needs to be involved in order to advise the content provider on what is, and is not, technically possible to achieve. This may involve the developer encouraging the content provider to be more adventurous and imaginative or throwing cold water on outlandish suggestions.

The resulting document can be thought of as a User Requirements Specification (URS) [Macro 1990] and should be a complete statement of all of the requirements of the content provider, although it will not be the blueprint used for implementation. It does not have to be consistent, and may indeed retain a 'stream of consciousness' element, but it must be complete.

Functional Specification

Once the URS, or its equivalent, has been drawn up it has to be refined into a document detailing the functional requirements of the courseware which the developer can use as a basis for implementation of the software. This document is the Functional Specification (FS) [Macro 1990]. 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'. Essentially it is a URS from which all inconsistencies, ambiguities, and errors have been ironed out. The FS should be as complete a functional description as is possible at the requirements stage.

Scheduling

Software development projects are notorious for going over schedule and over budget. There is a variety of reasons for this which is beyond the scope of this book, but at the top of the list are unforeseen technical difficulties and losing staff. 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. In particular, it is a good idea to specify a minimal application which can comfortably be achieved within the timescale, even with a generous allowance for technical problems. If things go smoothly during implementation then additional modules and features can be added to the product, and if not then at least the team will have something to show for their efforts at the end of the project. The developer, in particular, has to temper optimism with realism.

Costing

Much of the costing for the project will have been carried out at the concepts stage when the question of resources was addressed. However, once the FS has been drawn up the team will be in a much better position to cost the project accurately. It might even be advisable to place the detailed budget within the FS. 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, which is minor in comparison. If possible, some slack should be left in the budget to cater for unexpected extra work by either the content provider or the developer.

Design

By design I mean primarily the planning of the implementation of the application by the developer, that is how it will be programmed/authored. The topic of application design is dealt with in detail by books on programming, and no doubt each developer has his or her own method of software design, so the topic will not be covered in any depth here. In this sense software design and implementation are the province of the developer because s/he has the necessary technical expertise.

Additionally, of course, a lot of the screen design will occur at this stage. However, screen design should be considered in the concepts and specification stages - indeed, specifications may well include screen diagrams - and is thus not restricted to the software design stage. Moreover, the content provider can provide useful input into screen design, and at the very least should be able to approve or veto designs. Whilst the content provider may not be competent to judge the relative efficacy of sorting algorithms, for example, s/he will probably know what the end product should look like and may well have better aesthetic judgement than the developer.

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.

Development Tools

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:

Expertise of the Developer. The degree of technical expertise possessed, or which can realistically be acquired, by the developer is fundamental. If the developer has used particular tools in the past then time may be saved by using them again, even if they are not as technically suitable for the job as other tools. Also, if the developer has programming expertise an authoring environment may well be too limiting and frustrating for them, in which case a mainstream programming environment such as C++ might be called for.

Suitability. Can the environment do the job? Does it possess the features necessary to implement the courseware? This is only really a factor in the comparison of authoring systems, as generic programming languages (3GLs) allow the programmer to do most anything s/he wants. However, some authoring systems and 4GLs are designed for particular functions and are correspondingly weak in other areas (although the advertising always maintains that the package is an all-round application developer!).

Ease of Interface Design. The majority of modern courseware applications are developed for graphical environments such as Microsoft Windows and the Macintosh, where the application interface is of crucial importance. Most modern development environments allow the developer to 'draw' and manipulate objects - buttons, fields, dialogues, etc - on a screen without having to write code for them. This makes the process of interface design, interface editing, and prototyping significantly easier, at the possible cost of 'hidden code' (where internal code of the object is hidden from the developer, and is thus unalterable).

Cost. The cost of development tools ranges from tens to thousands of pounds The least expensive are generic programming languages, such as C or Pascal, aimed at the experienced programmer. The dearest are iconic environments (where icons are used in place of program code) such as Authorware or IconAuthor, aimed at the novice developer. An important factor to be considered when comparing costs is the time that it will take the developer to learn to use the package.

Runtime Licensing. Many, though not all, proprietary authoring environments require runtime modules (reduced versions of the environment with development functions removed) to be distributed with completed applications in order to 'play' them, and the owner of the environment may well charge royalties for the distribution of these modules or impose conditions on distribution and packaging. This can have a significant cost implication if the courseware is intended for a large market. Generic programming languages, which generate stand-alone executables, have a major advantage over authoring systems in this respect.

Future of the Environment. Many proprietary development environments have become extinct over the years, either because the firm went bankrupt or simply ceased to support future development of the tool. This consideration militates in favour of tools which have large installed bases against newer authoring environments.

Technical Support. Is technical support available, either from the tool supplier or elsewhere? Although often sadly neglected, this should be an important factor in tool selection as significant time and money costs can be incurred if the developer is unable to access expertise on the tool when problems arise, and an inferior product can result if the developer cannot find the best ways to implement features. Consideration of this factor obviously militates in favour of generic programming languages and popular authoring tools against little-known newer systems.

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 (which, unsurprisingly, are never featured in glossy promos about the product).

Other Software Tools

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:

Graphics packages (vector and bitmap)

Wave audio editors

Digital video editors

File format conversion utilities

Icon editors

Online Help editors

Database package

Fortunately, much of this supplementary software can be obtained for little or no cost. Digital video editing software, for example, is usually bundled with digital video cards, as also is wave editing software with audio cards. What is not bundled can usually be obtained as shareware or freeware, with the possible exception of good graphics and database packages, for which a full commercial rate may have to be paid. However, even if the financial cost is slight each additional package will have a learning curve and therefore a time cost which should not be discounted even if it is difficult to quantify.

The Development Machine

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. The full version of an authoring system will require a higher machine specification than the runtime version which will be 'played' on the target machine, and editing graphics - particularly bitmaps - is far more demanding than displaying the edited result. One objection to this is that if the development and target machines are similar then the developer will be able to see how the product will fare in the field, and won't build in over-sophisticated features that will perform poorly on the target machine. One obvious way to counter this objection is for the developer to always have a target machine available on which to test the software during development.

Network Awareness

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. To make courseware network-aware the network administrator must be able to specify program and data directories and drives without any significant restrictions. This can be done in a number of ways, including custom Setup or Administration programs, and an editable initialisation file. Even if the application requires a particular directory structure the administrator should be able to specify where its 'root' directory will be placed on the server's disk. Software that assumes a particular machine configuration can be a real headache for administrators who have to emulate the configuration required. Thus, the developer owes it to potential users to be aware of such problems and to avoid creating them in the courseware produced.

Distribution Media

A point that should be considered at the software design stage is how the application will be distributed. As is well known, multimedia applications, particularly those using digital video, can consume tens of megabytes of disk space. Even digital audio can be diskspace-hungry - a high density, 1.44M, floppy disk can barely hold 60 seconds of reasonable quality audio. Plainly traditional floppy disk distribution is insufficient, and inefficient, both for developer and user. Whilst the developer may be able to squeeze the application on to a large number of floppies, s/he is then faced with the time and money costs of duplicating the disks.

Other high capacity storage media, then, are needed for multimedia courseware distribution. At the time of writing the possibilities are:

magneto-optical disks

CDROM

networks

Disk-based Distribution

Magneto-optical disks have large capacities - up to 1.3Gb at the time of writing - and can be written to repeatedly, as with magnetic disks. Currently, however, both the disks and drives are expensive and are only installed on a small minority of PCs. Therefore they cannot be considered a suitable distribution medium at the moment, although they will undoubtedly become standard on micros in the near to medium future.

CDROMs can hold around 600Mb (a figure that will increase as the laser wavelength used to cut and read the disks decreases) and have become the de facto standard for commercial application distribution. Their main disadvantage, from the development team viewpoint, is that initial copies are expensive to produce. Either the project has to obtain a CDROM recorder to cut its own disks or the data has to be sent to an agency which specialises in cutting master disks. However, the cost is far outweighed by the advantages of having the complete application on one disk. Not only is it easy to distribute and install, but it might also be run direct from the disk, a boon for users with hard disks heaving with applications or diskless workstations.

Distribution over Internetworks

Most staff and students in the UK university sector have access to high-speed inter-site networking, in particularly JANET and the Internet. This raises the possibility of distributing courseware via internetworks using tools such as FTP, WWW, and Gopher. Network distribution has a number of significant advantages over disk distribution:

Speed. Delivery time to the user can be measured in minutes, assuming a broadband (megabits per second line speeds) connection and moderate network traffic.

Ease of distribution. Disk-based distribution requires time-consuming disk copying and envelope stuffing, and runs the risk of loss or disk corruption in the post.

Substantially reduced distribution costs. No physical media, no delivery charges, and a network free for users, reduce distribution costs to the cost of server disk space and the time required to mount the application.

Flexible upgrading and patching. Upgrades and bug fixes can be placed on a server as and when required and users informed via email.

Some of the disadvantages are:

Network connections. At the time of writing network connectivity is patchy to non-existent in parts of the UKHE sector, particularly the newer universities. Networking in some institutions is carried out by modems which, even if using ISDN links, do not have the capacity to download multimedia applications without incurring high phone bills. Distributing courseware by networks alone will exclude this potential market

Payment. Unless the courseware is to be made freely available a system of user authorisation and invoicing needs to be created which may require a high level of skill on the part of the server administrator.

Security. Exposing a host computer to a publicly-accessible network runs the risk of it being hacked into, and of course ordering and payment systems need to be secure.

Documentation. Users often prefer hard copy manuals to online documentation, so these may have to be sent out in the post, incurring some distribution costs.

As the number of Internet connections grows, courseware distribution via the Internet will become more cost-effective. In my view, though, it is unlikely to become the principal means of distribution for some time to come.

Implementation

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). Needless to say this is a matter for the developer. Texts abound on the subject of programming and program design, and each programmer or author will have her or his own method of writing software, so I do not intend to go into detail on the question of how to write programs. Suffice it to say that programming is usually considered to be, like the software development process as a whole, a process of stepwise refinement. However, the implementation stage also encompasses tasks other than pure programming or authoring, in particular the production of documentation and the program testing process.

Modularity

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. As well as being modular the software should be designed and developed in such a way as to enable a future developer with a good understanding of the development tool(s) used to 'pick up the baton' and continue development and maintenance. The dangers of allowing one or more people to have exclusive knowledge of the product's development are too obvious to be outlined. As well as in software design developer-independence can be achieved by ensuring the production of comprehensive, continuous, and contemporaneous system documentation.

Application Documentation

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. Writing and, as importantly, maintaining and updating application documentation is a vital task of the developer. The precise contents of the documentation is a matter of preference, but the question that should always be uppermost in the mind when writing is: Will whoever comes after me be able to understand the application from the documentation I write? That is, the person(s) who in the future will have to maintain and upgrade the application must be able to fully comprehend the structure and workings of the application without having to look at the code. Understanding one's own code months later is difficult enough - understanding someone else's is a nightmare.

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:

overall structure of the application in detail

the purpose, algorithm used, and detailed workings of any non-trivial function, procedure, or object

problems encountered and, if solved, details of the solutions, including any revisions to the functional specification

"dead ends": approaches tried but eventually discarded

changing conceptions of the courseware

tables of functions and global variables: their purpose, workings, and values

tables of multimedia resources in the application (images, audio, video, etc) and their sources (for copyright purposes)

User Documentation

The need for documentation for the end user is obvious. Whilst modern applications should be written to be as user-friendly as possible and to require as little sifting through manuals and help files as possible, the user will always need some form of manual for guidance. It is difficult to over-stress the importance of user-friendly manuals. Indeed significant effort should be put into writing user documentation, and time should be allocated specifically for this task. A user faced with turgid, impenetrable documentation is unlikely to make best use of the software.

Given the ease with which online help can be created nowadays, and the fact that users expect it as a matter of course, it is important that user documentation be available in both hard copy and electronic form. The content of manuals, whether hard copy or online, will plainly vary from application to application, but at the minimum should comprise:

the purpose of the application and, if appropriate, its intended audience

getting started: how to install the application

how to use the application

for all but the smallest applications a hard copy index or an online search facility

Useful additional features might include:

application screenshots in the online help with 'hotspots' which the user can click to see a popup description of a screen object

quick reference guide (preferably in hard-wearing cardboard)

glossary of unfamiliar or jargon terms

troubleshooting

Given the high quality and accessibility of user manuals supplied with modern commercial applications the developer shouldn't be afraid study these and copy ideas. It is also a good idea, if possible, to 'test' the documentation on users before release. It is the case that what may seem obvious to the developer may be completely opaque to a user, and conversely what may seem a comprehensive explanation to the developer may appear patronising to the user.

Testing

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. In small-scale development, as this book discusses, alpha testing is likely to be an informal, ad hoc, process. Beta testing, however, should be approached with some rigour. A reasonable number of external testers should be identified, preferably with a wide spread of IT skills and experience, and some of whom should be representative of the target audience for the courseware. Specific questions should be asked of the testers in order to elicit responses that might not otherwise be forthcoming, to compare the responses of different testers, and to be able to draw up some statistics.

Delivery

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.

Setup Routine

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. Users do not like having to create specific directory structures, or manually copy files, or modify configuration files, or even change interrupt or DMA settings, and indeed many do not possess the necessary technical skills to do so. These things have to be done for the user, and s/he should not be asked to make choices beyond her competence. On the other hand, the experienced and technically adept user should at least be informed of what the installation process is doing, especially if it changes system configuration files (when s/he should be asked to confirm the changes), and preferably be able to customise the installation, in particular to be able to specify the target drive and directory for the application. (See the earlier section in this Chapter on Network Awareness). 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.

Technical Support

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. For example, the user of a PC courseware application containing 256-colour images may be running it in the default VGA mode of Windows, so of course the images will be badly dithered. Even if the manual states explicitly that 256-colour mode is required the user may either not have read it properly, or simply may not understand that monitors run in different display modes, and will unfairly blame the application for "not working properly".

And, of course, unexpected technical problems will occur with the courseware. It is a truism that no software is bug-free and the more complex the operating environment the more fertile the breeding ground for bugs.

The developers must expect to deal patiently with such problems for many months, or even years, after the release of courseware. Comprehensive, comprehensible, and sympathetic technical support must be readily available by phone and/or email to the user.

Maintenance and Upgrading

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. Courseware in rapidly-moving disciplines, such as physics or computer science, can show its age very quickly. If the development team wishes the courseware to have a long life, and has not just written it as a one-off, then new versions incorporating both added features and updated content need to be periodically released. As with technical support, this implies a long-term commitment by an institution to courseware, which is not always feasible. Nevertheless the fact is that users will eventually discard software which they perceive as old and outdated, regardless of its inherent quality.

Version Control

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 but at the time of writing the the standard commercial schema appears to be as follows:

pre-release alpha or beta: version numbers less than 1 (0.5, 0.6, etc)

first release: version 1.0

bug fixes: add a letter to the version number, eg 1.1a

minor improvements: add a decimal point to the major version number for versions incorporating minor additional features and bug fixes, eg 1.1, 1.2

major releases: add a whole number, eg 2.0, 3.0. This usually denotes a version that is a qualitative and substantial improvement on the previous major version, often to the extent of being redesigned.

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.

User Evaluation

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. In the case of courseware evaluation is doubly critical, given that both the technical and pedagogical content of the application have to be evaluated. How this feedback is obtained is a major area of debate and to a great extent will depend upon the resources available to the developers. However, two relatively inexpensive and useful sources of garnering user comments and evaluations are technical support and questionnaires. The developer should take detailed notes at the time of the query, which can be later inspected to see what problems users are encountering.

This sort of user evaluation is negative insofar as it concentrates upon problems users are running into. To find out what users want from future versions a questionnaire approach could be adopted. Of course the questions have to be carefully chosen and worded so as not to lead the user into saying what the developer wants to hear. A major problem with questionnaires, unfortunately, is that most go unanswered, perhaps because the user is too busy, or is satisfied with the software and therefore doesn't think that anything further needs to be said, or simply can't be bothered to fill it in. On the other hand they are fairly cheap, particularly if sent by email.

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 crowded area.

Bibliography

Author                   Title                                            

Barker, Philip           Exploring Hypermedia. 1993. Kogan Page, London.  

Barker, Philip           Multimedia Computer Assisted Learning. 1989.     
                         Kogan Page, London.                              

Brailsford, Tim          New Frontiers of Learning: Guidelines for        
Davies, Peter            Multimedia Courseware Developers in Higher       
                         Education. 1994.  ITTI, University of            
                         Nottingham.                                      

Corrigan, John           Computer Graphics Secrets & Solutions. 1994.     
                         Sybex, Alameda CA.                               

Krol, Ted                The Whole Internet: User's Guide and Catalog.    
                         1994. O'Reilly and Associates, Sebastopol CA.    

Macro, Allen             Software Engineering: Concepts and Management.   
                         1990. Prentice-Hall, Hemel Hempstead.            

Multimedia Ventures      European Multimedia Yearbook 94. 1994.           
                         Interactive Media Publications, London.          

Oliveira, Armando (ed)   Hypermedia Courseware: Structures of             
                         Communication and Intelligent Help. 1992.        
                         Springer-Verlag, Berlin.                         

Riley, Fred              Understanding IT: Computer Graphics. 1993.       
                         ITTI, University of Hull.                        

Riley, Fred              Understanding IT: A Review of Hypermedia         
                         Authoring Packages. 1994. ITTI, University of    
                         Hull.                                            

Rose, Steven             The Making of Memory. 1992. Transworld           
                         Publishers.                                      

Sommerville, I           Software Engineering. 1985. Addison-Wesley,      
                         Wokingham.                                       

Stonier, Tom             Information and the Internal Structure of the    
                         Universe. 1990. Springer-Verlag, London.         

Appendix A: Archives on the Internet

The following is a small selection of pointers to archives on the Internet which developers may find useful, taken from my publicly-available hotlist. However, given the dynamic nature of the Internet it is quite possible that by the time this book reaches the printers some of these URLs may no longer be active, or that the resource has moved to a new URL. The full hotlist, containing pointers to many other resources, and continually updated, can be found at the URLs:

http://www.hull.ac.uk/Hull/Starting_Points/fhr/hotlist.html

http://www.cti.hull.ac.uk/hotlist/hotlist.html

Digital Video

MPEG Movie Archive

http://w3.eeb.ele.tue.nl/mpeg/index.html

Icons

Icon Library. Collection of public domain icons displayed as inline images.

http://www.di.unipi.it/iconbrowser/icons.html

Icon files and software. Icon editors, and icons on a variety of subjects.

ftp://ftp.cica.indiana.edu/pub/pc/win3/icons

Icon Library. 7000+ icons which can be searched using keywords. The icons appear as inline images and download in .ppm format.

http://alice.cli.di.unipi.it/iconbrowser/icons.html

Images

FTP Image Archive in Sweden. A varied collection on a wide variety of subjects.

ftp://ftp.sunet.se/pub/pictures

Silicon Graphics' SILICON SURF Home Page

http://www.sgi.com/

Images from theHargrett Library Special Collection which "consists of rare and unusual manuscripts, books, and materials that are maintained by the University of Georgia Libraries"

http://scarlett.libs.uga.edu/1h/www/darchive/hargrett.html

Rob's New Multimedia Lab. Image, sound, and movie archive.

http://www.acm.uiuc.edu/rml/

Texas Technical University Archive. Clip Art, gifs, jpg, the works - plus links to other image libraries. Also contains sound and etext archives. Excellent overall reference site with pointers to sources of data.

gopher://cs4sun.cs.ttu.edu

Internet 3D Object Repository. Archive of 3D objects in various formats.

ftp://avalon.chinalake.navy.mil/pub

Images, Icons, and Flags. Pointers to image archives (primarily astronomical), collections of national flags, and icon libraries.

http://white.nosc.mil/images.html

Image archives. Pointers to various image archives on the Net.

gopher://miles.library.arizona.edu:70/11/images

Miscellaneous images, unsorted.

http://white.nosc.mil:80/gif_images/

The Pix Archive.

http://www2.ecst.csuchico.edu/~rodmur/pix/

The Graphics Archive

http://www.rahul.net/bryanw/index.html

Sandra's Clip Art Server. Pointers to Clip Art collections mainly in Yale and MIT, but also elsewhere.

http://www.cs.yale.edu/HTML/YALE/CS/HyPlans/loosemore-sandra/clipart.html

Digital Picture Archive on the 17th Floor.

http://olt.et.tudelft.nl/fun/pictures/pictures.html

Software

Apple FTP Server

ftp://ftp.apple.com/

Asymetrix FTP Server Toolbook and Compel files, updates and patches

ftp://asymetrix.com.

CICA Windows Archive

ftp://ftp.cica.indiana.edu/pub/pc/win3

FTP PC software archive

ftp://ftp.demon.co.uk/pub/ibmpc

HENSA Higher Education National Software Archive for UK HE. Free/Shareware for micros (PC, Mac, etc) and Unix boxes.

gopher://micros.hensa.ac.uk

INFO-MAC HyperArchive. Mac software archive.

http://hyperarchive.lcs.mit.edu/HyperArchive.html

MultiMediaMacromind Multimedia Software Repository

gopher://rose.muohio.edu/11/

Microsoft FTP Server

ftp://ftp.microsoft.com

Mac archive

http://web.nexor.co.uk/

Windows Shareware Archive at California State University. This has an especially large Games section.

http://coyote.csusm.edu/cwis/winworld/winworld.html

FTP archive in Sweden. Software, images, movies, USENET discussions, etc. A large and comprehensive archive which also mirrors the CICA Windows archive.

ftp://ftp.sunet.se/pub

FTP archive at Imperial College, UK. A massive software archive for Mac, PC, Unix, Amiga.

ftp://src.doc.ic.ac.uk

Large software and images archive in the States.

ftp://wuarchive.wustl.edu

General-purpose file archive in Oz.

ftp://cutl.city.unisa.edu.au/pub

Text

Oxford Text Archive. Various English, French and Italian texts in ASCII and SGML.

ftp://ota.ox.ac.uk/ota

The On-line Books Page. Over 300 books from various repositories: browse or search by author or by title.

http://www.cs.cmu.edu:8001/Web/books.html

Alex: a catalogue of over 1800 electronic texts on the Internet.

gopher://gopher.lib.ncsu.edu:70/11/library/stacks/Alex