This article reports on the experience of using the WorldWide Web to support the teaching of a distance learning course presented simultaneously at the University of Michigan and the University of California at Berkeley. This course used generic tools (such as commercial Web browsers and standard Unix file systems) to deliver course material to students in both sites. Paying particular attention to methods for making curricular support material stand on its own without the presence of the instructor, the article outlines a wide variety of issues, including: design concerns, technical limitations, and privacy issues. Concerns of ongoing maintenance of a WorldWide Web site are dealt with in detail.
"Impact of New Information Resources: Multimedia and Networks" was an experimental, graduate-level course taught simultaneously in the Schools of Information and Library Studies at both the University of California at Berkeley and at the University of Michigan. (For further information on the course and technological delivery methods, see Besser 1995.) The course content aimed to critically examine the new information landscape and was essentially a communications course.
In addition to standard class attendance and readings, students were expected to join a focus group which paid special attention to issues related to the course, such as information retrieval, technology and creative arts, critical theory, or the possibility of virtual communities. Each of these groups met weekly and created and maintained an online news group, as well as a WWW page for their group. Students also created a Web page for themselves individually, reviewed a multimedia program and an online service provider, and did a major project or paper on some topic related to the class.
The instructor had taught the course in Berkeley three previous times without the distance aspect. Each time the course was taught, student work from previous terms was used as readings and other resource material, essentially building up a set of resources in this domain. And each time the course was taught, more automation and online resources were added to those of the previous term.
Papers reviewing various aspects of the course, as well as most of the WWW documents that students used in the course are available at http://www.si.umich.edu/impact/Winter95/ .
The WWW Site
Logistical problems in maintaining identical sets of class handouts and reserve reading materials at both sites created a strong argument for distributing these materials online instead of in print. The topical nature of the class also made it nearly impossible to distribute print versions of reading materials to both sites in a timely matter. (Frequently the class would discuss articles from that day's or the day before's newspaper which the instructor would post online.) Providing online course materials also immersed the students in the subject of the class -- the impact of new information technologies.
Course materials were all posted as WWW documents and linked on a class HomePage (figure #1). These materials included the instructor's and students' HomePages, the syllabus, a course description including major themes and questions of the course (figure #2), assignments (figure #3), information about guest speakers, readings (updated weekly) (figure #4), materials from earlier versions of the course (figure #5), and, as the semester progressed, Discussion Group HomePages (Figure #6) and student essays (figure #7) and projects (figures #8-10). The site served both as an online coursepack (facilitating both instructor and student access to readings and assignments), and as a repository of information about the course for outsiders.
WWW Management Issues
The construction of a WWW site for this class exposed a wide variety of problems inherent in maintaining an ongoing WWW site with multiple contributors. This included issues of permission control, physical arrangement of files, ownership and maintenance of files, and presentation to end users.
Because the content for the WWW site was generated by over 40 different users, it was difficult to maintain a constant "look and feel" between the different student contributions. Pages on the same subject often appeared to come from different WWW sites because their authors gave them such individual looks. This created a jarring impact on the end user. The instructor had intended to develop extensive guidelines for the students to follow, but the person in charge of this never followed through.
This experience made clear the necessity of guidelines for collaborators on a WWW site. Important features for such guidelines include layout, font and sizing, expression and placement of a variety of document parts (site title, links to other parts of the site, document title, document author, etc.), citation formation, etc.
Another key area that requires guidelines is that of filenames and links. Collaborators must agree on file name conventions. The problem of inconsistent naming becomes more acute as sites grow in size and management functions (such as updating, distinguishing file-types [including image file types, compression, etc.], grouping files by contributor, etc.) become more difficult.
Due to restrictions on intellectual property rights, access to many of the files for the course had to be limited. Restricted material had to be identified and isolated into directories which could then be permission controlled.
Common WWW software permits two types of control: by user password or by the user's IP address. Password restrictions posed management difficulties: handing out individual passwords to 40 students and noting all these in each restricted WWW directory created too much overhead; having all students share a single password was deemed too insecure (including the fear of a student posting the password on a bulletin board or newsgroup). Restrictions by IP address faced the problem that many students used a variety of different workstations, many of them in public areas.
A decision was made to control access by IP address, but this approach provided access to a broader population. Approximately 3/4 of the students were served by granting permission to IP domains of commonly-used public terminal rooms, as well as to home accounts. But providing access to the other 1/4 of the students required a lengthy list of IP addresses (including individual workplaces, spouses' and friends' workplaces, other campus departments, off-campus dial-in services, etc.). In may of these cases a single IP address was not enough (such as for students who didn't have their own workstation at work, and had to rely on borrowing workstations from several different colleagues).
Granting permission to students who dialed in from home was quite different at each of the two campuses. The Berkeley campus gives each student their own personal Home IP address, making it easy to create a list of permissible addresses. On the Ann Arbor campus, on the other hand, IP addresses are assigned dynamically at login. This makes it impossible to create a list of IP addresses for students in the class; instead it was necessary to allow access to all IP addresses that can be assigned by each Ann Arbor dial-in number.
Physical arrangement of files
Directory structures -- how the sets of WWW files are grouped and organized -- is of critical importance. Once a WWW site is established, it is extremely difficult to reorganize the relationship of files to one another, as this will require resetting every link in every file that refers to a document that is moved. Any complex WWW site needs to develop guidelines to indicate how files should be grouped.
It is advisable to express hyper-links as relative rather than absolute pathnames wherever possible. (A relative pathname shows its location in relation to the current document [filename defg within the directory abcd in the current directory]. An absolute pathname explicitly states an Internet address [via a URL].) Relative addressing of links allow one to change the site node-name or higher-level directory names without having to update hundreds of links. It also makes it possible to create a mirror site, or to move the entire site to a new location.
Ownership and maintenance of files
This course exposed several short- and long-term maintenance problems with dynamic collections of digital information. Because most WWW sites are constantly updating and changing, how do we provide a "snapshot" of 1995 information resources to future generations? A key problem the class experienced was that the systems manager was unable to archive the extensive netnews discussions, and the only remnant that now remains is the printed copies of a few discussion fragments.
Another key problem faced by any WWW site is the maintenance of hyperlinks to resources (particularly those at other sites). Any time someone changes file or directory names or rearranges their site, all hyperlink pointers to those files or directories become outdated. From the experience of this class, it is advisable that all links be checked on some kind of regular basis, and some effort must be made to update dead links. Eventually, work on Universal Resource Names (URNs) and Universal Resource Citations (URCs) (see http://www.ietf.org/) will make this job much easier, as links will reference documents rather than locations.
Collaboratory work on a WWW site poses the question of where files should reside. Files located in personal directory space allow the individual who owns that space to continuously debug and make changes to those files. But files within personal spaces are inaccessible to others, and any collaboration on these are forced to go through the directory owner who must act as a gatekeeper.
Files stored in group or central locations (in theory) permit equal access for all group members, and should encourage greater collaboration. But because most current software does not allow the tracking of individual contributions, collaborations can lead to contentious arguments (particularly when one person edits portions of what someone else has done -- and the previous work disappears). Furthermore, current Unix permission structure does not handle "group" permissions very well; each time one edits a file in a group area they must be very careful to avoid the permission for the entire directory reverting back to their own personal account (thus locking out all other group members from being able to write on any file within that directory).
The experience of this class has shown that much work must still be done on operating system and word processing software before collaboratory work can become widespread. Most needed are developments in the areas of permissions, ownership, and tracking of individual contributions.
Presentation to end users
A key reason for the explosive growth of the WorldWide Web is that this service is available from a wide variety of machines using software that can be obtained without charge. But even though access to the WWW is relatively ubiquitous (at least among computer users with modems or Internet connections), this does not mean that all users can access it with equivalent capabilities or ease. Individual user environments differ in capabilities of displaying graphics or images, compression, and bandwidth.
A good WWW site design must take into consideration the differing end user environments. Users without graphics capabilities should be able to access information in a pure ascii format. This means providing alternate routes to ISMap navigation -- navigation where one clicks on an image such as a map to indicate choices. Design for users with low network bandwidth requires avoiding the delivery of large image files without first warning the user. If one doesn't include warnings such as these, users with low bandwidth connections may wait hours to download an image. Finally, it is also wise to include an indication as to storage format and compression scheme for an image; without this users who do not have the software needed to view these may wait a long time for an image to download before they find out that they cannot view it.
Another serious presentation issue involves what version of the HTML markup language one chooses to use. A number of WWW browsers (most notably Netscape) have implemented interesting features which can only be read by that browser. The temptation is great to employ these features, but doing so could be dangerous. These non-standard features will not be viewable by people using other browsers. And these features may change in future editions of the same browser. When considering the employment of such a feature, it is advisable to (1) determine the likelihood of its inclusion in future standards implementations (which today would mean looking through the emerging HTML 3.0 standards documents); and (2) carefully noting any use of non-standard HTML commands so that one can replace these with standard HTML commands when they become available.
The presentation of such a WWW site also raises a variety of social and policy issues. These include concerns over maintaining currency vs. archiving, over privacy, and over developing a dependence upon a set of technological tools.
This WWW site served a myriad of functions. It was an archive of previous versions of the course (including student papers, course resources, and the tools and interfaces that students from previous terms had used to view course material). It was a teaching tool for currently-enrolled students (and had to evolve over the course of the semester according to changing student needs). And it served as a guide to the general public in the area of the "Impact of Multimedia and Networks".
The different functions often posed conflicts in deciding how to present the information. For example, the archival function (which seeks to preserve things the way they were) often conflicts with attempts to make information more up-to-date or easier to navigate for current students.
Future versions of this course will probably lean away from the archival function and try to excerpt the most relevant and up-to-date (approximately 50%) of material from previous terms. This would involve an editorial function, and probably follow a traditional "publication" model, where items are reviewed for relevancy and currency.
But this raises a more serious issue whenever the Web is used as a primary publishing medium. Today historians can look back at print publications that reflect outmoded ideas or the changing views of an individual. But in the future that may be very difficult. Because the tendency is to update and replace outdated portions of Web documents, we may soon lose the historical records which will allow future scholars to view the evolution of ideas within a field. It may be possible to use recent developments in versioning (see for example Haake & Hicks, 1996) to help us view changing ideas within a particular field, but it would be adbantageous for versioning systems to be able to generate a kind of "rollback" to an earlier time period, complete with links to the earlier versions of documents that existed at that time.
In an attempt to provide an intimate picture of the class to interested parties (both currently and in the future), students were asked to post all coursework in public spots where others could read them. Most students appreciated the ability to review coursework from prior terms, and many said that this helped them gauge course requirements, find readings and citations relevant to the course, and inspire selection of project topics.
At three points during the term students were required to post their personal impressions of the distant learning experience, and these essays were immediately moved into central storage so that they could be publicly accessed but couldn't be altered (as the students' impressions changed). Again, this provided a valuable resource in reviewing the changing impressions of the distant learning experience. But it is likely that students were less frank in their criticism of the instructor, RAs, or fellow students than they would have been if the essays had been less public.
All these activities raise serious privacy questions. Is it an invasion of privacy to force a student to electronically publish their work? What about their personal impressions of a course? Future versions of this course will probably continue to require public postings, but experiment with masking identities.
Reliance on Technology
Surprisingly, the more common ("lower level") technological tools employed in this course posed far more problems than the "more advanced" tools. Classroom and student-to-student video connections were extremely reliable (the classroom video connection only went down twice). Clear audio was a little more problematic. But what posed the greatest technological challenge for this class was the maintenance of the WWW site. Network sluggishness and server downtime caused occasional problems.
File permission control problems plagued this course. Systems administrators could find no way to conveniently allow the instructor and 2 research assistants to all have write-access to the same set of central course files. As mentioned earlier, each time a person would edit a file, all the files in that directory would revert from group ownership to personal ownership by that individual (preventing the others from writing to that file in the future). We can't expect group work to become widespread until operating system level tools for collaboratory access are developed.
Because virtually all course materials were available online (and most of these only available online) the course was dependent upon guaranteed online access. Though online systems are quite reliable, they have not yet achieved this degree of reliability. Today's systems are reliable enough for searching for a book or sending email (activities that can be shifted around in time), but they cannot guarantee a decent level of performance every time a student wants to verify an assignment or interact with a student 2,500 miles away. Until our systems can achieve the reliability level of fault-tolerant systems (such as those used by the automated teller machines at banks), placing all access into an online environment will only encourage resentment among the people who must use it.
Maintaining a WWW site for a distance learning class revealed a number of serious concerns that need to be dealt with in any robust WWW site. This course employed generic tools (such as the Netscape Web Browser) to support Web access, and it is clear that such tools are not yet capable of handling such problems as those outlined in this article. But as the features of specialized Hypermedia tools migrage into commercial Web browsers, we should see some improvement in this situation. In any case, the issues reviewed here should be useful for anyone planning to mount a WWW site.
The course was funded by a grant from the Kellogg Foundation to the University of Michigan School of Information and Library Studies for the development and redefinition of Information Studies curriculum. Research Assistants Maria Bonn and Sara Ryan (Michigan), and Alex Sutton and Natalie Zee (California) helped coordinate both the class and the Web site.
Howard Besser. Multimedia and Networks Teach about Museums in David Bearman (ed.), Multimedia Computering and Museums (Selected Papers from the Third International Conference on Hypermedia and Interactivity in Museums) Pittsburgh: Archives & Museum Informatics, 1995, pages 124-140
Anja Haake and David Hicks. VerSE: Towards Hypertext Versioning Styles in Hypertext '96 (Proceedings of the Seventh ACM Conference on Hypertext, Washington DC, March 16-20 1996) New York: Association for Computing Machinery, 1996, pages 224-234
[+] Portions of this article originally appeared in a paper entitled Multimedia and Networks Teach about Museums in David Bearman (ed.), Multimedia Computering and Museums (Selected Papers from the Third International Conference on Hypermedia and Interactivity in Museums) Pittsburgh: Archives & Museum Informatics, 1995, pages 124-140
Last modified: 9/7/1996