Kent L. Norman

Laboratory for Automation Psychology

Department of Psychology

University of Maryland

College Park, MD 20742-4411

kent_norman@lap.umd.edu

Many instructors are quickly turning to the World Wide Web (WWW) to host the materials and interactions for both distance education and classroom-bound courses. Desktop hosting of WWW-based course materials is becoming a feasible alternative to institutionally provided central servers. Moreover, emerging software is making personal hosting easier and more cost effective than hosting with large courseware shells on central servers. The pros and cons of the institutional versus personal approaches involve pragmatics, academic freedom, intellectual property rights, and interface design. It is argued that desktop hosting provides instructors with a greater sense of control over and ownership of the course and a greater flexibility to design their own course at all levels from the organization of the materials to the layout of the interface. HyperCourseware™ provides a case in point.

The World Wide Web (WWW) provides an opportune media for education. It provides many, if not all, of the potentialities required in the course of education from the simple display of materials for presentation to interactions among the students and instructors and simulations of systems and environments. The advantages of digital media in education are numerous. The list of "x-abilities" provided by Norman (1998) suggest a wide range of compelling reasons for creating an electronic educational environment. Consequently, it is not surprising that for this and many other reasons, there is a rush to host not only some educational materials on the WWW but whole courses from beginning to end. The WWW solves many of the problems of distance education by facilitating dissemination of materials, enhancing communication, and increasing student-teacher interaction. The WWW is so compelling that instructors in classroom bound settings are also hosting both materials and interactions on the WWW (Hazemi, Hailes, & Wilbur, 1998).

In the midst of this mad rush to the WWW a number of fundamental, practical, and policy issues arise. The answers to these questions depend not merely on the instructional setting (distance education versus classroom education) but also on course ownership (individual versus institutional), course lifecycle (from initial development to repeated offering), and course appeal (from popular core courses to highly specialized seminars).

This chapter focuses on several of these issues as they revolve around decisions of where and how to host WWW-based materials. It is argued that these decisions have significant implications on the development of emerging instructional technology and the future landscape of education. As often happens with new technology, initial hardware and software designs tend to dictate application and use rather than vice versa. Such is rapidly becoming the case in software and system architectures for hosting courses on the WWW. Unfortunately, rapid development and premature implementation often has the effect of either a negative backlash (i.e., "Once burned, twice shy") or standardization on the sub-optimal. The latter takes the form of either accepting a less than optimal product or having to work around a poor interface to produce an optimal product. Unfortunately, human nature combined with institutional and economic constraints tends to produce a less than optimal product.

In the present case, we are concerned with emerging technological systems for education. The users are of these systems include instructors and students as well as instructional designers and administrators. Thus, the players have many different goals, perspectives, and abilities. In the area of WWW-based education, the issues revolve around not only pedagogy but around the human/computer interface and the implementation of complex systems. The purpose of this chapter is to lay out a number of these issues and then to illustrate and argue for an individualistic approach to WWW hosting of courses rather than an institutional solution.

WWW-based teaching involves a number of issues and requires a number of initial decisions on the part of faculty and administrators. A few of these decisions are listed below as questions:

1. Do we generate our own materials, contract someone to generate the materials, or acquire someone else's materials?

2. Do we host the materials and educational environment on our own system or on some commercial system?

3. Do we develop our own environment, contract someone else to generate the environment, or acquire a commercial system?

Materials developed for courses range from expensive professional efforts (as much at $40, 000 per course) to inexpensive homegrown efforts on the part of teachers and students. Many college courses, for example start with the syllabus on the WWW, followed by lecture notes and slides. Materials may be generated directly in html (hypertext markup language) or using one of the many commercial WWW authoring tools. Often materials previously generated in presentation graphics programs such as PowerPoint™ are simply exported into html. Instructors may also use listservs and threaded discussions for more interaction. At the institutional level, administrators may want to develop a course paid for and owned by the institution. They may employ instructional designers or even outsource development of the course. On the other side, publishers are developing both materials and, for that matter whole courses, that can be purchased outright or accessed on a pay-per-use basis by institutions.

The location of this course materials is an interesting and important issue. Presently, materials are hosted in several different ways. Some faculty put their materials on instructionally provided WWW central servers as freely accessible pages. One can find many such repositories across the WWW. The problem is that they are open to anyone are often indexed by search engines on the WWW.

Other faculty use various courseware shells that provide passwords for login and a number of tools for interaction. The advantages of the courseware shell are that it (a) manages organization of materials (indexes, hierarchies), (b) provides for navigation through them (menu bars and search tools), (c) limits access using authentication (passwords) and privileges (read/write), (d) provides for record keeping, and (e) provides tools for interaction (dialogues, chats, etc.).

One of the objectives of courseware shells is to try to make the development of on-line courses easy. A review of courseware shells indicates that they have a long way to go. One problem is that shells must strike a balance between ease of access and degree of security. In this vein, shells tend to be of different types, hard shell versus soft shell. Hard shell systems are more secure, hard to crack, but difficult to use. They require layers of interface to protect the contents. Soft shell systems are easier to use. One can get to the materials and change things faster and easier than in hard shell systems. They are also more vulnerable.

Either with or without a courseware shell, materials are located on an institutionally provided central server that is used by many different people for many different courses. Figure 1 shows a schematic of a centralized server. In this configuration, the faculty accesses the course materials either through a file transfer protocol (ftp) or a local area network. If using a courseware shell, access is usually provided via the WWW and a common gateway interface (cgi) on the server. Students either in class or at a distance access the materials via the WWW. No one except the system administrators who are responsible for the server have open access to the central server itself.

Figure 1. Configuration of one central server accessible only via the WWW to students and faculty.

Another group of faculty are hosting their materials on small WWW servers run from their offices. Figure 2 shows a schematic of a local server. In this configuration, the faculty have complete and open access to the server and shared responsibility over the system. These systems have the advantage of being hard shell to the world but soft shell to the instructor who has office access to the machine and ftp and WWW access outside the office. Again students either in-class or at a distance have access to the course materials via the WWW.

Figure 2. Configuration of many local desktop servers accessible directly accessible to the faculty and accessible to students via the WWW.

The final question to consider is to what extent the individual faculty member or the institution is going to be involved in generating their own courseware shell or modifying a commercial off-the-shelf courseware shell as opposed to purchasing a totally canned system. Reviews and comparisons of these shells are given by Gray (1998) and Hazari (1998). Some faculty and institutions have jumped into the game early and have developed their own systems. The University of Maryland, University College, one of the largest distance education colleges in the world, developed their own system, WebTycho. Some of these have emerged as commercial products that have been adopted in totality by others. WebCT™ is a good example of this trend (Goldberg & Salari, 1997). In other cases corporate training systems have been re-purposed for the education market. Lotus Notes™ is an example in this line. On the other hand, it is argued here that these systems are premature and develop a user base before all of the problems have been worked out. Furthermore, they tend to be institution-centered rather than either faculty-centered or even student-centered in their design. As such they tend to dictate the ways of doing things rather than allowing the faculty to develop instructional materials in their own way and the students to learn and to complete assignments in their own way. It still seems appropriate, for faculty and for institutions to take the lead in the development of the instructional systems and the human/computer interfaces that drive them.

Yet another factor to consider in courseware development is the level of effort and standard of quality that is demanded by some courses and instructional programs. At one extreme are professional courses, say in management or engineering in which the student pays for and expects a high degree of professionalism. At the other extreme are small college classes and impromptu seminars. In these classes everyone expects the materials to be generated on an expedient and ad hoc basis.

Table 1 lays out the two factors of development and location of WWW-based course materials and lists the resulting four cells. Professional development of courses by commercial publishers on centralized servers is expensive and requires a high level of training and maintenance. Professional development of training modules at decentralized locations is used in special training situations requiring high security such as in corporate and military training. Expedient development on centralized university servers is becoming popular today but tends to be hard to use due to interface and control problems. Finally, the expedient development of materials on decentralized servers relies on the emerging technology of desktop electronic publishing and is referred to here as "desktop distance education." The remainder of this chapter focuses on the last option.

Factors of WW-Based Courses

In desktop WWW hosting the instructor maintains his or her own course materials on a person desktop computer.

As such, desktop WWW hosting requires the following:

• a personal computer with sufficient memory, speed, and storage

• a persistent Internet connection with a permanent IP address and domain name

• WWW server software with password management

• html templates, a file structure, and/or a database system

• various plugins and/or programs for cgi applications

• other miscellaneous software for text processing, html code generation, scanning, and graphics.

These items are not expensive and are often available for free as shareware applications. Moreover, these programs are becoming more available, easier to write, and easier to use as will be seen in the case study presented below.

There are a number of advantages to desktop WWW hosting of course materials. These fall into four categories involving: pragmatics, academic freedom, intellectual property rights, and interface design.

First, in terms of pragmatics, there is a physical advantage to local hosting of materials. The instructor has direct access to files in storage and does not need to go through layers of security and communications. Local servers and direct access allows for just-in-time preparation of materials. Instructors can quickly generate and put up files for their classes without having to go through time consuming layers of menus, passwords, and upload processing. Moreover, central servers can be impacted by too much traffic, especially at times when one needs the most speed. A central server means that hundreds, even thousands of students will be accessing files. Peak times will swamp the server. Instructors authoring materials will overload the processor.

Distributed desktop servers are not subject to such traffic problems since only one instructor will be uploading files to it generally at times when students are not accessing the information. Reliability is always a question with computers. A central server may be more reliable than a personal desktop computer but this is generally offset by load and number of potential predators. Firewalls must be set up, but these limit access and control by instructors. Moreover, if the central server goes down, everything goes down. A central server crash can affect hundreds of courses and thousands of students. A distributed desktop server that goes down affects only two or three courses and at most a few hundred students. Many desktop servers distribute the load for both access to materials by students and the generation of materials by instructors. If a server goes down, it affects only class or set of classes. Complete access and control can be given to the instructor.

The second issue is academic freedom. Materials hosted on central servers may be vulnerable to institutional scrutiny and censure. The institution may in its best interest impose institutional guidelines on the courseware materials. While many of these may be well intentioned, they may also be construed as impinging on academic freedom. At best such rules come from committees and administrators with the purpose of maintaining institutional uniformity at the expense of healthy diversity. At worst, institutions may dictate a party line, political perspectives, and pet theories at the expense of alternative points of view. Materials stored on a server in one's own office are not as easily accessible to administrators. Furthermore, the administration is less likely to regulate what goes on in one's own course files on an office machine as what goes on in their central servers.

Related to this is the issue of intellectual property rights. The question is, "Who really owns the rights to the course materials?" If materials are developed professionally and paid for by an institution, the institution owns the rights to the materials. On the other hand, if a faculty member writes a textbook or develops lecture notes in the course of his or her teaching, it is generally assumed that the faculty member maintains the intellectual property rights of those materials. With new electronic media things are not as clear. However, the generation and location of the materials may play a part. If the materials are generated using a university provided shell, on the university central server, it may well claim the rights to those materials. However, if the materials are generated in the faculty member's office and hosted on a desktop computer, it is little different than typing the materials on paper and storing the document in a file cabinet in one’s office. Desktop WWW hosting may well give the faculty member the upper hand in disputes over intellectual property rights.

Last but not least is the issue of control of human/computer interface issues. Most of the courseware shells that have been evaluated to date leave much to be desired when it comes to ease of use. Part of the problem is the difficulty of generating a

"one-size-fits-all" shell. If the faculty member designs a course with certain objectives in mind, this may influence interface design considerations. For example, it is clear that material deemed important by the instructor should be presented up front in the face of the students. Ancillary material should be less accessible. In terms of human/computer interfaces this may translate into the number of mouse clicks necessary to display the information. The instructor should be able to control all aspects of the interface including navigation, not just the ones that a courseware shell may allow.

Table 2 summarizes these themes and the issues involved in desktop hosting of WWW based courses.

Issues and Implications in Desktop Hosting of WWW-Based Courses

Desktop WWW hosting is at present very rare and perhaps very intimidating. The reasons for this are many. It currently requires a number of technical skills on the part of the faculty and a number of new pieces of software listed above. In this section a case study of one attempt at desktop WWW hosting will be briefly presented. It will be argued that although it is currently difficult, in the near future electronic desktop publishing will be as easy as using a word processor and spreadsheet.

The HyperCourseware desktop system considered here is HyperCourseware™. Historically, HyperCourseware developed as a prototype electronic educational environment for use in the electronic classroom (Norman, 1993; Shneiderman, Borkowski, Alavi, & Norman, 1998). It consists of a number of linked hypermedia modules. Originally HyperCourseware was written in stackware using a card oriented program called ObjectPlus™ and resided on a local area network.

In its current form HyperCourseware is delivered on a WWW server and consists of a number of html templates that serve the same functions as the original version. HyperCourseware is currently running on a Macintosh G3 computer at http://cognitron.umd.edu/. The Web-server is WebSTAR™.

Figure 3. Cognitron.umd.edu opening screen and listing of courses.

A password is required to gain access to the course material area. This password is (a) to keep Web crawlers from indexing site for search engines, (b) to comply with copyright laws, (c) to limit the distribution of materials, and (d) to limit the exposure of student material to the rest of the world. However, access is provided for guests who fill out a request form to view course materials.

A second password is used by the faculty and the students to gain access to personal areas containing exams, assignments, and grades. This level also allows students to submit work, view their completed and graded work, and see their grades on file.

Figure 4 shows a home screen for HyperCourseware that acts as a bulletin board and navigational hub.

Figure 4. HyperCourseware Home Screen.

The home screen provides access to all of the HyperCourseware modules. These include the following:

Syllabus with links to notes, assignments, and exams

Readings index with links to on-line readings

Materials collection with links to class resources

Assignments index and with links to on-line submission of forms

Class roll with pictures and information about the students

Directions and help

Seating chart for students in class

Messages about the course

Discussions and indexes to threaded disucssions

Chat area for synchronous chat rooms

World with links to WWW resources

Scheduler tool for planning learning activities

Notes tool for keeping a file of notes on-line

Projects area for collaborative activities of teams

Exams on-line

Grades

Before discussing examples of these modules and how they are used, it is instructive to consider the file structure that underlies HyperCourseware and allows the instructor easy access to the material. A rather loose file structure is set up on the server to help the HyperCourseware templates locate course materials for the modules. It allows for easy access to the materials and organization of materials from type-to-type, year-to-year, and course-to-course. Files for a course are located in a directory, indexed by semester as illustrated in Figure 5.

Figure 5. File structure on the WWW server showing directory for course (psyc443), subdirectories for semester and year (f1998, and subdirectories within the course for materials (m44303) and for faculty (i3791), guests (g0800), and students (e.g., s0801).

Within a particular course, one directory contains course materials (directory m44303 in Figure 5) and the rest contain instructor and student files as shown in Figure 6.

Figure 6. Directory for a student showing files for completed assignments, exams, etc. and grades.

Finally, within the course materials directory, there are directories for modules such as notes, exams, assignments, etc. that correspond to the modules in HyperCourseware. The lecture notes directory is shown in Figure 7.

Figure 7. File structure showing directories for lecture notes.

This file structure allows the instructor to easily add and edit course materials. Instructors and/or course developers have complete access to the files and the file structure.

The first and most important module is the syllabus as shown in Figure 8. The syllabus module draws upon the traditional way in which college courses are usually structured. It lists the dates of the class meetings, the topic for each day, readings, and assignments. The syllabus also serves as a navigational tool to jump to lecture notes, readings, and assignment pages by clicking on the entries.

Figure 8. The Syllabus Module.

Most of the modules within HyperCourseware are designed using frames with a navigational bar at the top, an index at the right, and contents in the middle. The readings, materials, and assignments modules provide indexes to files that the instructor puts into those directories. For example, Figure 9 shows the Assignments Module. On the left is an index of the assignments with dates. When the student clicks on one, it appears in the central frame. For assignments, the student types into the form fields and clicks a submit button. Homework assignments are handled using forms and FormSaver™

.

Figure 9. The Assignments Module displaying one of the assignments.

Answers are stored in a text file and processed by a separate application that:

The Exams Module works in a similar way except that access is strictly controlled either by a date and time key or a by password protection. Exams are written in forms with multiple choice and essay questions. Grading of exams is done by the same program that does the assignments grading. Figure 10 shows a screen from this application. This program:

Figure 10. The Assignment and Exam Grader.

The Class Roll Module typically shows pictures of the class and a list of the students in an index at the right. Individual student pages with a picture and a short autobiography are displayed in the main frame.

The Discussion Module allows the instructor and/or the students to start discussion

topics. The module provides an index for the instructor to organize a list of discussions. In addition, discussion templates allow the instructor to insert discussions into the flow of the course materials either for use in class or out of class. For example, a discussion assignment may require the students to make two entries in a discussion about some topic distributed over the course of a week. In class, a discussion may be embedded in the lecture notes. The students are asked to input an idea, a definition, or an opinion. This are then collected and inspected in class for further face-to-face discussion.

HyperCourseware uses versatile threaded discussion program, ConferWeb™ to provide this interactivity.

Discussion files can be read by the instructor or they can be processed by an

Application shown in Figure 11 that:

• counts the number of entries by each student,

• counts the number of words entered by each student,

• lists the dates of the first and last entries by each student,

• pulls out the entries by each student to inspection by the instructor, and

• allows the instructor to record a grade in a master grade list for each student.

Figure 11. Discussion and chat file processor.

Synchronous chat sessions are provided by the chat program, Biap Chat™. The HyperCourseware Chat Module opens a window with the Biap Chat applet configured for the appropriate room(s) for each course. An easy to use administration program allows the instructor to create and configure chat rooms for different courses and different topics. The MultiChat Module (Biat Chat) allows for a large number of groups and rooms and participants. While it might be maxed out at the institutional level, it is perfect for the individual instructor.

Desktop/personal use allows the instructor to set up rooms and log sessions as

needed and on-the-fly. Chat sessions can be logged and processed in a way similar to the discussion sessions presented above. The MultiChat Module has been very reliable and versatile for both in-class discussions with 20 students (a bit too confusing) and out-of-class distance education chat sessions around the world (e.g., Australia, California, and Maryland).

Many collaborative projects have been conducted in WWW-based courses and much has been written about them (Norman, 1998). HyperCourseware provides templates for an individual or team projects area. This area provides discussion tools, links to project WWW pages, and even team evaluation forms. Figure 12 shown an illustration of the projects module used for collaborative group exercises and projects.

Figure 12. The Projects Module screen showing the index of teams on the left and one of the team pages in the main frame.

Finally, grades are accessed by the students through the Grade Module. Grades are displayed in the center frame of the HyperCourseware home screen. Grades files are accessed by the instructor through a separate application on the desktop computer. This program: are processed by an application that:

• keeps track of student grades in a master grade list,

• calculates grade distributions and saves an html file,

• averages scores and assigns letter grades,

• writes the student's grades to the student's file.

HyperCourseware provides a number of other facilities such as student note files, access to databases on the desktop computer, and demonstrations written in JavaScript. The open architecture of HyperCourseware allows changes to be made in the interface by the instructor as a function of need. New ideas and designs can be implemented immediately rather than having to work through a software vendor and wait for the next product release. For example, during the course of a semester students often have suggestions for improvements. Usually they can be implemented before the next class period.

HyperCourseware on the WWW has been used for four semesters and over ten courses by the author with over 250 students. The outcomes of this case study have been extremely positive. Experience, empirical data, and student feedback support the utility and user satisfaction with the system and serve to validate the feasibility of personal desktop course hosting. In general, students give positive ratings to all of the modules in HyperCourseware in terms of ease of use and functionality. Table 3 shows mean ratings on a 9-point scale of the extent to which students liked each of modules in HyperCourseware.

Mean Ratings of Course Modules Using HyperCourseware (n =29, 1 = dislike, 9 = like)

Complete courseware offerings have proven to be feasible from a desktop computer. It is quite possible and easy to set up accounts, passwords, exams, threaded discussions, and multi-chat sessions, etc. for any sort of course. All course construction, maintenance, and processing were conducted within the desktop environment. While it is true that it can be very labor intensive to set up a WWW course for the first time in this or any system, it is probably not that much more of an effort than preparing to teach a course for the first time in a paper-based format. The real savings comes in repeatedly teaching the course. Files can easily be copied, duplicated, and edited each semester that the course is taught.

Moreover, the system has proven to be very reliable. It rarely went down in the course of four semesters of use. And if it did, it restarted within a few minutes. No exams or assignments were lost in the course of teaching over 10 courses by the one instructor using the system. The server does not require constant monitoring and merely runs in the background.

Furthermore, the system has been very responsive and fast even with 20-30 students hitting on the server at the same time to access graphics and Java applets during classroom sessions in an electronic classroom.

Finally, courseware construction has been fast and simple. HyperCourseware templates allow for simple text input to update files for the syllabus, indexes for readings and assignments, etc. The templates and file structures allow for quick installation of the a new course and updating of a previously taught course. New courses are created by creating copies of the template. Previously taught courses are updated by copying an old version of the course and updating text files. It takes about two days to set up a previous taught course, modifying the syllabus, dates, assignments, etc. This is about the same time as it would with a paper based course. For new courses, materials can be created as the semester progresses by adding to the lecture notes and assignments, etc. from week to week. Again the times are comparable to materials generation for paper based courses. Efficiency is a function, however, of both the instructor’s proficiency with the technology and the ease of access into a desktop system.

The case study presented here represents one of a growing number of faculty employing individualistic solutions to WWW hosting of courseware. Others include Brad Cox (http:www.virtualshool.com) and Leon James (http://www.soc.hawaii.edu/~leonj/). In addition to others, the current case strongly suggests that desktop WWW-based courses are feasible. It can be done. Furthermore, it is quite likely that as software develops for the WWW, desktop hosting of courses will be easier and less time consuming in the near future.

Moreover, desktop electronic publishing has a number of practical and policy advantages over centralized, institutional hosting of materials. It should be done. In terms of policy, performance, and preference the desktop system is superior to the central system. However, these conclusions and recommendations depend on institutional goals and on the perspectives of individuals with different levels of computer expertise and investment in course development. In many cases, individual faculty members will find desktop hosting to be the ideal solution.

On the other hand, institutions may push for central server hosting of materials so that they can maintain control over these resources. While this is appropriate in government and military training, corporate training, and perhaps in junior and community colleges, it is less appropriate in higher education at the university level. When the development of WWW materials is for large standardized courses (e.g., Introduction to Psychology, Chemistry 101, Algebra 101) it is beyond the capability of any one faculty member. In this case institutional investment is required and institutional hosting of the materials is appropriate. However, when faculty have a unique sense of ownership of materials and personal investment, personal desktop hosting makes more sense.

Finally, it will be done. As WWW serving and courseware authoring become easier and

proliferate across office workstations, desktop distance education will pop up on the WWW as thousands of instructors go on-line with their course materials.