A "unified network presence" is taken to mean that the bulk of current online communication tools are consolidated for use by the major groups involved in the university academic process. A wide range of network services would be presented as selections within customized "desktops" created for students, faculty, and student support staff. These desktops would be structured to expedite the day-to-day functions of members of each target group: instructor/student contact, classwork assignment distribution and submission, test distribution and submission, etc.
Behind such a desktop presence is a collection of databases and activities that support academic communication. Such a system would require access to student enrollment information, at least in abstracts, and would create Usenet newsgroups and listserv lists for every class included within its structure. It would create accounts for instructors and students, if necessary, containing conferencing and assignment/test storage areas as required by class activities.
To help guide discussions a (non-working) prototype for a desktop presence has been prepared, based on the World Wide Web. The Web may not provide an adequate foundation for such activity, but it offers a powerful option. Another strong alternative would be to build a free-standing custom desktop client, able to provide desktop functions and interact with Web-based servers. A third option would be to build a Java-based client offering the flexibility of a free-standing client with the ease of management of Java applications.
Here is an EXAMPLE desktop, a "KUdesktop", designed for use by a student:
In one model, each student would have a KUdesktop like the one above created upon enrollment, and this desktop would continue through enrolled semesters for review of class materials, though probably not for use of e-mail and Usenet news groups.
In this model a student's KUdesktop would be kept in a centralized location accessible to server scripts, rather than being kept on a student's desktop computer system. Such an arrangement would allow a student to access his/her desktop from any computer system (even from text-based systems, given care in design).
Note that this page would be modifiable by each user in a variety of ways. First, the "Update Desktop" button would present screens with redesign options. Second, selected KUfacts pages would be enhanced with buttons offering to add themselves in one or more "form-factors" to a student's desktop. Different form-factors appear necessary to enable "embedding" KUfacts information and/or forms within other pages. (This is a feature that should be supported within KUfacts regardless of the "unified approach".)
For example, in the following screen-shot, the "Searchable database of events" does not fit in the activity window (the large window, blank at startup), unless the header is scrolled out of the window (as shown). A smaller form-factor could obviate or attenuate this problem.
This menu provides links to services related to a class involving most network facilities (such as e-mail and Listserve lists) and several University databases of potential use to the student (e.g., the Course Catalog and Timetable databases).
Other links could be added. For example, an instructor might want to communicate with audio or video information and provide links for those purposes, or provide a link into KU library databases listing materials on reserve for the course, or relevant to the course material.
Here is the menu in vivo:
Suppose that the user here selects the link to "Check course catalog entry". The relevant course description would appear in the activity window. Here again there is a something for a form-factor problem, but it is minor.
A virtual office allows an instructor to conduct "virtual office hours". A student clicks a link in a Web page to approach the office and, if the instructor is not available, will see a screen announcing current office hours and links to helpful information. The virtual office capability shown here was developed by ACS independently of this Virtual KU prototype, but is Web-based and easily integrates with the current prototype.
If the instructor is available, the student may join an ongoing discussion and will be able to type comments and read responses in a manner similar to Internet Relay Chat:
Assignments could be submitted by using the "Assignments" button, which would present a form that would allow a student to identify the assignment being submitted, its storage format, and upload the assignment to a storage area associated with each class where it could be accessed by the instructor. Alternatively, student's running their own Web servers could provide a Web Uniform Resource Locator (URL) identifying the finished assignment. An instructor could simply load the assignment directly from the student's Web site, or read it in place.
Each instructor would be provided with a similar interface that mirrors the student interface and allows the instructor to manage the resources provided through the student's desktop for a particular course. An instructor who wants to use only his/her own Web page to manage a course could simply invalidate all fields seen by the student, except the instructor's e-mail address and home page URL.
The system would, however, provide directories for storing student assignments and tests and an interface for access by the instructor, should it be deemed useful.
A system like this should provide a simple method for inexperienced faculty to use network communications facilities without intense training. Also, even if some capabilities are omitted, this approach would provide a platform for informing students of facilities available for each class.
A typical ACS student currently uses our multiuser systems for e-mail and is allowed to use less than 2MB of disk space continuously. The proposed virtual campus could easily require five times as much computer power and 100 to 1000 times as much disk space per student. Since ACS currently operates 3 or 4 DEC workstations ( at approximately $25K per system) to accomodate student, faculty and staff e-mail needs, one might reasonably expect to add 15 or 20 such systems to accomodate online activity at full University scale.
Over the course of earning a degree, a student could easily utilize 200MB of disk space, keeping all homework assignments, papers, outline and tests online. In a highly graphical environment (which may include mathematical formulae), a student might use 2GB of disk space over several years. Keeping all materials online over a four-year period would then require several terabytes of disk space. While data storage of such magnitude is becoming manageable, policies guiding the persistence of assignments, tests, listserv archives, etc. would have to be adjusted to reflect University resources.
Perhaps the most demanding hardware resource is simply availability of desktops and network connections. If, say, 7,000 students and faculty have their own systems, another 18,000 do not, and would have to share public systems. Since use would be much more common than it is now, we might aim for a ratio of 5 students to each PC, suggesting the need for 3,000 to 4,000 systems in public labs. Each system would require network connectivity and extra connections would be required for students who bring their own systems to campus.
In addition, relying on online communcations for day-to-day education raises security and reliability issues. In terms of computational infrastructure this might require the use of tandom multiuser systems and RAID disk storage. In addition, students will want to have access to media upon which they can backup and archive their work. The ability to burn CD-ROM disks on a commodity basis would be a possible solution.
The magnitude of computational resources required to move all of KU online, appears to dictate a phased implementation, and adds more uncertainty to estimates of computational and staff resources required. However, to give a rough estimate, it appears that a system of this similar to the one described above is not a gargantuan task, by contemporary computing standards. A well-developed prototype of such a system targeted to a small section of the KU population could possibly be implemented in 6 months to a year by 3 to 6 FTE staff, given open access to necessary student record databases and adequate database management software.
Some alternative implementation schemes have been mentioned, namely a short comparison of custom desktop applications and Web-based pages, but more investigation would be required to choose the most beneficial approach.
Another significant issue is the abilility to integrate data management systems developed by commercial vendors with the KUdesktop (or other integrated tools). A commercial library catalog system and enrollment and/or student records systems would be examples of systems that manage information vital to the academic mission. We must be careful to chose systems that offer convenient "hooks" into their databases and functions so that we can seamlessly integrate individual services offered by those commercial systems with local systems.
For example, one might want to provide a small form-factor list of students in a class derived directly from a student-records database, or we might want to provide a list of books on reserve in the library linked from each class description and taken directly from library databases. A commercial product must provide a way to satisfy such a direct requests without invoking the full-featured student records or library search shells.
Such a framework can be built to serve the needs of resident as well as remote members of the university community. In fact, members of the two communities should be able to use the same interfaces irrespective of their location. Such a framework could thus serve traditional Continuing Education students as well as resident students and anticipated remote education students.
Academic Computing Services
The University of Kansas
The author wishes to acknowledge suggestions, urgings and incorrigible
optimism of
Lynn Nelson
Professor of History
The University of Kansas