ClassWise: Synchronous Internet Desktop Education

J. Mark Pullen, Fellow, IEEE, and Michael Benson, Member, IEEE





Abstract-- This paper reports the results of a five-year effort to develop an effective system for teaching distant students via the Internet, where the students are able to participate synchronously in class as contrasted to the more common asynchronous, Web-based "distance learning" approach. We have developed a system consisting of effective teaching practices and a practical family of software to support this approach within the context of computer and network resources that are available to average students at home or office. The system and the process that developed them are described in detail. We conclude with the outcome of a graduate course taught to three sections totaling 68 students (including a local control group) using our approach.

Keywords-- synchronous distributed education; multimedia networking
 
 

I. Introduction

This paper reports on an Internet teaching system based on the premise that today's Internet technology forms an adequate basis for synchronous distributed education, producing a net gain in learning efficiency over traditional classrooms. By system, we mean a coordinated collection of components (teaching practices and software) that have been developed to meet a range of instructional needs, taking as much advantage as possible of affordable, off-the-shelf computer and network technology. By synchronous, we mean the students and teacher are engaged in the class simultaneously in such a way that the classic teaching synergy of question-asking with immediate response is a fundamental part of the educational process. While our practices also make extensive use of asynchronous methods such as email, Web documents, asynchronous playback of classes, and browser-based file transfer for programs and bulky documents, the cornerstone of the teaching methodology and tool we are presenting here is synchronous distance education.

We will describe how this system has been developed experimentally, how the components work, why their specific features have been incorporated, and how they have been used to teach several courses. The software components we describe below reached their current usable state by commercialization of research software conceived in our laboratory. While we hope eventually to profit from sales of the commercial product, we are presenting it here as the results of our research, and as a basis for describing the innovations in pedagogy necessary to use such a tool productively.

Our basic orientation in this work has been that:

II. Background

The work described here was undertaken at George Mason University (GMU), a new (25 years old), large (26,000 students), suburban school near Washington, DC. Our location in one of the information-technology intensive areas of the U.S., combined with GMU's focus on information technology, has led to jammed classrooms and parking lots. These and the innovative atmosphere at GMU, combined with the drawbacks of extremely high commuting time due to constantly growing automobile traffic, gave us a strong motivation to explore affordable technology options for distributed education. In this regard we are among many who have a similar vision. Penfield [1] presents a compelling case, Carswell [2] sets forth conditions for success based on early experience, and Bourne [3] presents a complete model for a distributed technical education program. Others have built a strong case for expanding the role of distributed education, based on progress in distributed education in North America, Europe, and the Pacific Rim [4,5,6,7]. Sparked by widespread availability of Internet multimedia communication and growing numbers of working students, the time when a large fraction of post-secondary education will be accomplished by distance education appears to be nearing, if not already upon us.

As described below, we believe that synchronous and asynchronous methods for distributed education complement each other, thus we use both. However, the primary value of the innovations described in this paper fall within the synchronous paradigm. The value of a teacher/mentor who continuously interprets the material being taught to the contemporary needs of students is reinforced by centuries of educational tradition. Our work in the synchronous paradigm seeks to build on the effectiveness of this relationship.

A. The Case for Low-Capacity Connections

Our experience (described below) has led us to believe that present trends in networking technology will culminate in an environment where distributing classes over electronic desktops at offices and homes will become an important mode of education. Therefore we have created a synchronous distributed education environment based on off-the-shelf Internet technologies and moderately-priced workstations. The system also creates an archive of classes presented, which can be replayed from a server. Scaling to many students requires a system that can deliver effective education using limited network capacity ("bandwidth"). The hallmark of our approach is that it supports synchronous distributed education, using a minimal 28.8 kbps modem connection. There are three good reasons why a limited-bandwidth approach is essential to affordable distributed education today:

Developing a high-quality educational experience within a constraint of 28.8 kilobits per second proved challenging. We began by using available multimedia systems that did not meet that constraint, but did allow us to understand the nature of distributed education better. Pullen began using the Web and MBone to teach distant students in 1994. We describe next what we learned about using these multimedia systems from our teaching experiments.

B. Role of the Web

The distributed hyper-media system for sharing information over the Internet, known as the World Wide Web (or more commonly just "the Web"), represents a true breakthrough in networked information access for the masses. By combining the standardized HyperText Transfer Protocol (http) with easy to use, multi-platform, interoperable display clients or "browsers", the Web has overcome previous barriers to mass use of network-based multimedia [8]. There can be no doubt that the Web's new capabilities have opened a new and growing market for asynchronous multi-media presentation in education. No longer is any particular expertise required to obtain access via the Internet to a wide range of information sources. Text of all fonts, colors, and sizes can be combined with audio, compressed video, still graphics, and animation to present information in highly appealing ways at the click of a mouse. At GMU we have used Web browsers successfully for interactive education [9].

Nevertheless, we must characterize the predominant Web paradigm for distributed education as fundamentally asynchronous in that it expects all of this information to be stored prior to presentation, or in the most advanced form produced through preprogrammed technologies such as the Web's Common Gateway Interface (CGI) or Java programs. The Web's role in distributed education is to provide a set of interoperable multi-platform information sources and presentation systems that represent an Internetted advance on previous unnetworked repositories: libraries of books and, more recently, electronic storage. As such it also provides an advance on unnetworked asynchronous teaching systems exemplified by libraries, correspondence courses and, more recently, interactive computer-based tutoring systems. Simply put, even though it is possible to stretch the Web interface to real-time interaction, the basic Web paradigm is not optimized for synchronous activities where people learn from each other by intellectual stimulation, in real time.

Fig. 1. MBone Teaching Configuration

C. Experiments with the MBone

Seeking support for real-time interaction between instructor and student, we began our experiments in distributed education in 1994 using the Internet Multicast Backbone (MBone) [10], which offers a capability to hold a synchronous, shared audio/video/graphics session at multiple sites that are specially equipped to provide such services (typically universities and laboratories). Figure 1 shows the configuration used to teach with the MBone. As reported in [11], we discovered that the educational experience of remote students could be at least as good as that experienced in the local classroom, at some cost in additional preparation by the instructor. Because our sample was small we could not characterize the results statistically, but the students reported satisfaction with classes delivered. One student in particular, who easily could have attended class in person, chose to attend remotely because he found the workstation delivery to provide better focus than the classroom. The ability to record the MBone sessions for later playback also proved popular among working students who miss some classes to travel for their employers. [12] reports on a recent course in North Carolina that had similar success using the MBone.

While we found MBone distributed education very effective, it was also a very expensive solution in terms of the terminal equipment requirements (Sun or Silicon Graphics workstations) and even more so in terms of the quality of Internet connection. Typically at least a 1.5 Megabit per second connection with multicast capability is required. We were seeking a means of distributed education through desktop facilities at home and office. Therefore we needed a capability to deliver common platforms via network resources routinely available in these settings. Although the Mbone software recently has become available in pre-release form on Windows NT workstations, it still requires network facilities that rarely are available outside universities and laboratories. Furthermore, we were learning that the Mbone video we had assumed to be essential to distance education is not so essential after all.

D. Visual Presentation: Video vs. Annotated Graphics

An early step in our quest was to evaluate the role of video in distributed education. We found that because the camera in our MBone classroom was fixed on one position the video frequently delivered a picture of nothing, yet the students never complained. This led us to question the utility of a "talking head," especially since the video component is far and away the most expensive to deliver in terms of network capacity. Because television was for many years the only multimedia technology readily available for teaching distant students, it is common for educators to assume that video is a necessary component of distributed education. To the contrary, we have concluded that video is at best a marginal tool in delivering technical education to distant students. In fact it may be more useful for the instructor to see the students than vice-versa. What the students really need for learning is graphic presentation of the material being taught. Pullen discusses our extensive grappling with the value of video for teaching in [13]. In the end we focused on a solution based on delivery of audio, graphics, and text to the student's electronic desktop.

A key element of the MBone suite that we did find to be essential to effective presentations to distant students is annotation of graphics. The ability of the instructor to animate a presentation in real time by highlighting material, drawing on graphics to illustrate relationships and problem solutions, is central to technical teaching. We prepared slides in advance using commercial graphics software and displayed them on the MBone whiteboard (WB) as a slide show. The whiteboard allows the slides to be annotated in real time with any of several colors. We found this capability to be far more useful in teaching technical subjects than camera-based video. (We offer no judgement here about the value of video in distance education for other subjects.) The whiteboard also produces a much clearer graphic image than video, while demanding only a small fraction of the network capacity required by video.

III. A New Generation of Internet Collaboration Technology

Networked collaboration and distributed education have similar technical requirements, and thus generally can use the same supporting technologies. Recently a new category of conferencing/teaching technologies based on desktop computer workstations has begun to emerge. In [14] Dutta-Roy lumps all of these technologies under the category "desktop conferencing." This terminology is useful to contrast with the older meeting-room style of video conferencing. However we have found it is valuable to discriminate among the various desktop environments. We recognize the following four subcategories, each of which has different characteristics for distance education. Because the network capacity requirement drives scalability and is therefore a primary requirement for distance education, it will be addressed separately under each subcategory.

The paradigm for multi-site operation (one-to-one, few-to-few, or one-to-many) also will be addressed in each subcategory. This question can be a major driver of system cost because many products require a separate bridge or multipoint control unit (MCU) if more than two workstations participate in a session. In the absence of multicast network support it is also a driver of network capacity requirements. Without multicasting, with or without an MCU the network must carry a separate copy of each workstation's traffic to each other workstation participating in the session. Network loading is proportional to (N2-N)/2 with N sites. If N becomes large enough to cause network congestion, both video and audio will degrade due to packet loss. This limitation could be overcome if multicasting networks were available to most homes and offices, but that is not likely to happen in the next few years.

Desktop video conferencing (VTC) is an evolution of the older style of conference room VTC which uses custom video compression-decompression (codec) units and leased digital transmission circuits. The desktop form takes advantage of the higher levels of  integration which are now possible, miniaturizing the codec onto a circuit board that can be embedded in a desktop computer or reducing it to software for a high-performance desktop processor. (In some cases an electronic whiteboard also is included, allowing for computer-quality graphics that replace the lower resolution video-quality graphics of conference room VTC.) The resulting video image typically is on the order of 256 by 192 pixels. Under the best circumstances the video quality is similar to a home videotape playback and the audio quality is similar to a good telephone connection. However, acceptable video quality typically requires at least 100 kilobits per second of network capacity to be sent from each site. This normally limits desktop VTC to at most a few simultaneous desktops, placing it in the few-to-few category. An MCU normally is needed for more than two desktops. The CUSeeMeTM system is a well-known example of desktop VTC.

Desktop VTC with application sharing adds the important capability to share the graphic user interface. Some tools support sharing only of selected applications; at least one other (TimbuktuTM) supports sharing of all applications that will run on one of the desktops, but only in point-to-point mode. In conferencing this enables the conferees to share manipulation of software collaboratively; in education it allows one party to use the software to display graphics, and possibly program output, to the other party or parties. Some such systems work only on a point-to-point basis; others are capable of multipoint operation (using an MCU for the audio/video portion). Application sharing adds significantly to the network capacity requirements of desktop VTC, further limiting its scalability. The minimum application sharing network capacity is around 40 kilobits per second. This must be added to the video requirement. Some applications require considerably more than this for quick response. The Microsoft NetMeetingTM system is an example of desktop VTC with application sharing.

Streaming audio and video are technologies developed to supplement the Web. They present low resolution video, for example 128 by 96 pixels, and an audio quality similar to AM radio. Being designed for delivery by normal modems, the streams require only limited network capacity so scalability is excellent. However they cannot be described as truly interactive because there is a significant delay in the compression and delivery process, so the audience receives the program too late to ask questions in real time. Also there is no provision for computer graphic presentation, and the quality of the video is too low to support graphics. Therefore any high-resolution graphics must be provided asynchronously through associated webpages or other mechanisms. RealAudioTM and RealVideoTM are prominent examples of streaming audio and video.

Classroom conferencing is different from all of the foregoing in that it delivers audio, but no video, in order to allocate available network capacity in support of most effective teaching. The visual element of instruction is provided by graphics with real-time annotation, and the feedback element by windows where text messages can be interchanged between instructor and students. This approach demands the smallest network capacity of the four subcategories. It can be supported over a 28.8 kbps modem. Our ClassWise system is an example in this category.

TABLE I
Comparison of Conferencing Technologies for Synchronous Distance Education
 

 
Conference Room VTC
Desktop VTC
Desktop VTC + Application Sharing
Streaming Audio/Video
Classroom Conferencing
Video
good quality
limited quality
limited quality
minimal quality
not used
Audio
excellent
good
good
good
good
Graphics
low resolution

in video

whiteboard in some products
excellent
impractical
excellent
Text
not common
not common
share text application
not common
yes
Questions/ Interaction
spoken
spoken
spoken
impractical
typed text
Multisite Paradigm
one-to-one (few-to-few with bridging)
few-to-few (with MCU)
few-to-few (audio/video one-to-one without MCU)
one-to-many
one-to-many (no MCU) or few-to-few (with MCU)
Data rate
384-768 kbps
min 100 kbps
min 140 kbps
min 28.8 kbps
28.8 kbps
Scales to
a few rooms
a few desktops
a few desktops
hundreds of desktops
80 desktops
Example
PictureTelTM
CUSeeMeTM
NetMeetingTM
RealAudioTM RealVideoTM
ClassWiseTM

 

Table 1 compares the general situation for these four categories of desktop conferencing. It also includes room-style videoconferencing (typically using dedicated circuits) as a reference point that represents the current state of general practice for distance education. Data rates shown correspond to the lowest quality that, in our experience, can be used effectively for distance education. The data rates must be multiplied by (N2-N)/2 for N sites (desktops) participating, unless a multicasting network is used.

IV. Practical Software for Synchronous Internet-Based Class Delivery

ClassWise grew out of a research project at GMU. Benson [15] describes the system design of a distance education software suite that runs as an applique with readily available commercial software from Microsoft Corp. and provides the audio, graphics, and text interface we have found necessary to teaching. It does this using Internet networking technologies, and within the capacity of commonly available 28.8 kilobit per second modems. We describe below the software that follows Benson's design. The audio portion of the system grew out of "Internet Telephone" software that Magideas obtained under license from the developers of Speak Freely (see http://www.fourmilab.ch/#speakfree). The remainder was conceived in our laboratory, and subsequently commercialized by Magideas Corp. Product details are available through commercial sources; the focus of this paper is on the features needed for effective desktop teaching, and how they can best be used.

Our goal was to be able to teach students at home or office using only commonly available computer hardware and software with a "thin" client [16]. The necessary client and server software were developed in 1996. Since then we have used them to support distributed education to students at their homes within our Computer Science Master's program, and also for pilot distribution of professional education to students at their offices. They require only a multimedia PentiumTM-based computer with Microsoft WindowsTM 95, 98 or NT and PowerPointTM. Figure 2 shows the teaching configuration we have used, which includes a tablet for improved annotation and a separate Windows/Pentium system to record the class.

Fig. 2. Teaching Configuration for the Desktop System

As stated previously, a fundamental intention in our work was to create a system that relies as much as possible on commonly available computer hardware and software to achieve the functionality we have found to be required for synchronous Internet teaching:

Benson's client-server design enables the instructor's teaching server to transmit the necessary information to the student's learning clients so that remote students are not at a disadvantage for using this technology when compared to in-class students. The students hear the instructor as he/she illustrates the slides using annotations on the whiteboard. Students provide immediate feedback to the instructor through text messages indicating their understanding of the material being presented. Where needed the students can also participate by drawing on the instructor's whiteboard.

An additional feature that further enhances this teaching software is the ability to record the class for future use. Any information that the instructor sends to the students can be replayed through the same software client that is used to participate in a synchronous class. The student experiences almost everything that a student in the original class experienced. Although there is not any direct real-time interaction with the instructor during playback, interaction is possible through email and other asynchronous media. The recorded classes have proved particularly useful to students who normally attend class in person but must miss class for some reason.

The remainder of this section first addresses the technical architecture of our system, which is its most significant innovation. The section then provides descriptions of its software modules and user interfaces, revealing the design of the software in increased detail.

A. System Design

We took a systems approach to design of the ClassWise architecture, which enabled a solution to the technical challenge of building a distance education environment within a tightly constrained network capacity limitation. The primary challenge in the design of ClassWise was achieving the necessary quality of presentation at the client while restricting network capacity requirements to less than 28.8 kilobits per second. The solution to this problem lies in the architecture adopted, which transfers the minimum necessary amount of information in real time. As described under Background above, we determined that amount of information to be:

An advantage to this approach is that each mode of communication uses a compression technology specific to the presentation medium, resulting in highly effective compression. Our decision to omit video from the presentation media eliminated the largest data stream that might have been included, but still left us with the major challenge of transferring graphics in real time within the 28.8 kilobit per second capacity that was our design criterion. The data rate limitation also ruled out pure application sharing and dictated that we must develop another way to deliver quality graphics with real-time annotation.

The graphic subsystem design began with the concept of transferring graphics from Microsoft PowerPoint to a whiteboard. We chose to use Microsoft Object Linking and Embedding (OLE) technology within Windows and PowerPoint in order to preserve the high quality combination of vector graphics and raster graphics inherent in PowerPoint presentations. This also allows the whiteboard to be rescaled up to the full size of the screen with minimal distortion of the graphics, with other windows organized on the screen to suit the user's needs.

Using pre-loaded slides allows a dramatic reduction in real-time data transfer. As an example, a 640 by 480 pixel bitmap with 256 colors requires 307 kilobytes, which would require over 85 seconds to transfer with a 28.8 kilobit per second modem without compression. We could have used a standard graphic compression method such as JPEG, but we achieved even better compression by not sending the slides in real time at all. This approach had a corollary benefit in that the slides themselves are organized as graphic objects, with compressed bitmap where needed. As a result, asynchronous transfer of the slides can be accomplished rapidly in preparation for a class session, particularly if an additional file compression such as WinZipTM is also used.

Another key development in limiting the data rate requirement of the graphics was a macro language that provides a concise way to transfer graphic presentation requirements between server and client based on instructor inputs. The commands of this language form a shorthand notation for the instructor's graphic actions. Related commands are broken down into sets, each set having a prefix destined for a specific element. For example, whiteboard elements begin with "WB". This simplifies parsing and reduces network traffic. It is also human-readable which facilitates software debugging, and it allows easy expansion for future commands and capabilities.

Compression for text transfer was not implemented in the program, because the amount of text to be sent is small, and in any event the class of modems used includes a form of text compression.

A final architectural insight that was critical to achieving the functionality required for teaching was the method of recording classes for asynchronous transmission. The recording program behaves like a student client, receiving the audio, graphics, and text streams as they are transmitted and recording them in disk files. These files become input to the playback server, which parcels out the same information at the same rate and therefore is able to drive the same student client program. The architectural simplicity of this design reduced development effort considerably and also helped us to keep the client "thin".

Fig. 3. Software System Structure of ClassWise

B. Teaching and Learning Modules

The architecture described above was implemented in the software design shown in Figure 3. The figure identifies the major software modules of the system, along with their functional relationships.

Instructor modules: The graphics and audio teaching servers are used by the instructor to transmit classes (which may require a password for reception) to the students in real time. Voice is delivered from the instructor's server to the students' receiving clients via a stream of packets. Annotation of the slides is accomplished through the whiteboard. These features help prevent the data channel from becoming congested, which would destroy the effectiveness of real-time voice transfer. They also allow the instructor to present classes effectively while managing the students' questions and comments. Using a typical Pentium system with a 100 MHz clock, many simultaneous student sessions can be supported. The server allows up to thirty simultaneous connections, and has been tested successfully up to eighty.

Student modules: Separate audio and graphics clients enable students to receive classes in real-time and to play back recorded classes. They receive slide control, whiteboard annotations, text messages, and voice in real time. The same clients also support playback of classes from a server, presented from the viewpoint of a student who attended class.

Record Client and Playback Server modules: another client module records classes from any instructor server connected to it. The resulting files are transferred to a playback server that allows students to receive classes that were previously recorded.

C. User Interfaces

Instructor interface: When ClassWise is loaded, the teaching windows appear on the computer screen. Before the class begins, both audio and graphics modules must have been configured with instructor and class information. This is done once for each new class taught by each new instructor. To start a class, all that is necessary is to establish the connection between the instructor and the students.

The main window of the teaching interface consists primarily of the text "chat" area. This allows the students to interact with the instructor and offers an additional way for the instructor to communicate to the students. Any message received from a student is only seen by the instructor, not by the entire class, and is identified with a short name provided by the student during configuration. This allows the instructor to maintain the flow of the class and respond to questions at an appropriate point. Text sent by the instructor is received by all students. Students see each others' questions only when the instructor chooses to copy the received text back to the class. The text interface is typically used in a window of reduced size so the instructor can manipulate the whiteboard in highest detail.
 
 

Fig. 4. Instructor software control graphical interface

The instructor's whiteboard is launched from the main teaching window. Slides selected by the instructor are selected in PowerPoint (which runs in minimized state so the instructor does not see it) and displayed on the whiteboard by using their OLE objects. It is possible for the instructor to select any slide in the slide file directly, or to step through the slides in sequence. Slide changes and annotations from the instructor are sent to all students who have joined the session. Possible annotations include lines, ellipses, and rectangles in ten colors, six line widths and five line styles (solid, dashed, etc.) and QuickSymbolsTM such as arrows. The annotations can be erased individually (starting from the most recent), or by clearing all of them.

Students also may be allowed to draw on the instructor's whiteboard as needed to elaborate on their questions. The instructor can see the students' annotations, but other students can only see the instructor's annotations. The slide may be printed from the student's computer, including any annotations that are in the whiteboard area.
 
 

Fig. 5. Whiteboard slide/annotation graphical interface used by instructor and students

The teaching servers work together so that, as the instructor's speech is communicated, graphics from the PowerPoint slides are displayed on the whiteboard with instructor annotations added in real time. Voice transmission control consists of a single window with various pull-down menus from which broadcasting to the students is activated and various server options can be selected.

Student Interface: When the student client is loaded, the audio and graphics windows appear on the computer screen. Both of these modules must be configured before use. This is done once by each student for each course taken. Connecting to the servers normally happens with one click. The two modules together provide all information needed by a remote student. They also can be used to receive a playback of previously recorded classes that are available on the playback server.

The student client's main window is identical to that used by the instructor as described previously. A button on the main window launches the student client whiteboard feature. It is the same whiteboard that is used by the instructor, but its semantics are different in that only the instructor receives annotations made by a student.

Record and Playback: The record and playback interfaces indicate the session being recorded, and the session(s) being played respectively. The recorder can only capture one session at a time, from which it writes a folder of files on disk. The playback server supports thirty outgoing sessions at the same time, including multiple sessions from the same class, started individually.

V. Synchronous Desktop Teaching Practices

Despite having developed considerable experience and success with desktop teaching, we are still learning effective teaching strategies for this environment. Student-instructor communication is reduced, particularly "body language" feedback to the instructor. Also lack of group rapport make the distributed teaching environment sufficiently different from that of the traditional classroom that the distributed education instructor must employ some new techniques. Further, substitution of a high-quality computer graphic display for live motion video requires some different presentation skills. In this section we describe techniques we have learned to be effective pedagogy in the desktop teaching environment.

Class structure: We have used this distributed education environment in multiple modes:

Click here for an example class segment taught by Pullen in the professional education course, using ClassWise. Slide preparation: The biggest single impact of desktop-based delivery on the instructor is the need to have all material prepared as slides in advance. While it is possible to use the electronic whiteboard dynamically, for example to solve problems, we have found that for best effectiveness the core material of each class must be formatted such as to guide the flow of the discussion. This implies a level of structure that is not present in most "chalk-talk" classrooms. The preparation process is simple enough that to date our faculty have elected to prepare their own slides. It is however time consuming, particularly when mathematical notation is required (we have used MathcadTM to generate symbologic text for input to PowerPoint). This is especially true for the first offering of a class in desktop mode, but it also remains true for later offerings of technology topics where the state of the art is changing rapidly enough to require an update with each presentation of a class. An effective slide set typically will consist of a text outline of the material to be presented, interspersed with graphic depictions of the material (format dictated by the topic), and blank spaces for annotations and problem solutions. Because some students never see the instructor in person, including his/her photograph in one of the introductory slides appears to be useful in breaking down the social distance between instructor and student.

Annotations: The whiteboard can be annotated with lines, ellipses, rectangles, and other graphic symbols such as arrows. The geometric figures may be in any of several configurations of dashes, line widths, and colors. When placed on the instructor's whiteboard these are transmitted to the student's whiteboard in real time. In addition to allowing dynamic creation of simple figures, the annotations are useful in drawing the students' attention to the part of the slide the instructor is discussing. This results in a higher quality of graphic presentation than is possible over normal video teaching channels. Instructors quickly gain facility with this capability and use it to enhance their presentations.

Student questions: It is our observation that student questions are more rare from any remote group, whether in remote classrooms or at desktops. Part of the reason for this appears to be that the higher level of organization of the classes, coupled with the fact that the slides are available to students before class, leaves fewer points on which the students are in doubt. However, we suspect that the greater psychological gap between instructor and remote student may contribute to this situation. We find that the practice of sprinkling a class session with questions, customary among many instructors of in-person classes, also works in the distributed education environment to engender better dialog and also to give the instructor feedback as to how well the material is being assimilated by students. Pullen has adopted a practice in desktop teaching whereby a set of questions is prepared in advance, to be pasted in the outgoing text window at intervals during the presentation. Typically the students will respond after a few seconds of "think time." It is possible for the instructor to continue talking while the answers are being submitted. This sort of "mini quiz" engages the students in the class more fully, in addition to helping the instructor pace the presentation for best comprehension.

Potential value of video: Most distance education today is carried out over an audio/video link, usually augmented by a document camera to enable slides and graphics to be represented over the video system. Having elected to forego video in our teaching, we are nevertheless led to consider how it might be useful if available. We see three ways in which video could be useful:

Use of recordings: Recording of classes allows a student who is pressed for time to turn a synchronous session into an asynchronous one. Recordings have proved popular for this purpose since we first offered them when teaching with MBone. Under the ClassWise system they receive frequent use. At the students' request our professional education pilot was taught synchronously on Tuesday afternoons so that students could participate during work hours. For some class sessions less than half of the students participated synchronously, choosing instead to take advantage of the class recording on the server. We have come to understand that this freedom to participate asynchronously is one of the features of distributed education that students value highly. The asynchronous mode also has made possible professional education delivery to smaller groups that would not justify formation of a new class. However, it has been our consistent experience that most students prefer the interactivity of synchronous presentation when conditions make it feasible.

Network support: We have used ClassWise successfully over great distances, using lightly loaded parts of the Internet. In one case, Pullen taught over a U.S. Department of Defense network from Germany to students in Virginia. However, we must emphasize for those planning to begin synchronous distributed education activities over the Internet that even the lowest capacity requirements cannot be met consistently on a congested network. As the commercial Internet often is congested in our region, most of our students find it is advisable to connect by dial-up to GMU. This works well because GMU's Intranet between our teaching servers and the dial-up ports is not congested.

Hands-on component: Students learn most effectively when they actually work with an example of the subject material. This is the basis for the time-honored use of laboratory exercises in teaching. Simulation software, which increasingly is used as a basis for engineering laboratories, also can be used remotely. [18] provides strong arguments in favor of integrating networked simulations into engineering and applied science courses. We have found that, at least for computer networking courses, simulation makes it possible to distribute the laboratory as well as the classes. Pullen has created a simulation environment that provides a controlled framework within which students program network protocols and observe them in operation [19]. The simulation, called the Network Workbench, can take place on a laboratory computer over the Internet, and also is available for installation on the student's desktop computer (see http://netlab.gmu.edu/networkbench). The Network Workbench effectively takes the place of a laboratory component for both undergraduate and graduate courses in computer networking.
 

VI. Quantitative Outcomes

In Fall, 1997 Pullen taught a graduate course in computer networking to a group of 68 students. Forty students attended class sessions live at our main campus. The remainder were split between two satellite campuses. All students had the option of participation from home or office, and also of asynchronous playback. At course end a distance education survey was administered anonymously along with the regular GMU course evaluation. Although it was generated in an ad-hoc manner by the instructor, the survey turned out to be a useful opportunity to obtain feedback and statistics on our desktop teaching.

Student survey. Figure 6 shows the responses to the survey questions. A total of 39 out of 68 enrolled students responded, on a scale of 0 to 5. Results generally favor distributed education, with those students participating at a distance slightly more favorable than local students. As the distant students had self-selected into the course, this is not surprising.

Fig. 6. Results of student survey, Fall 1997 (number of responders for: black - local; striped - distant)

Student evaluations: GMU collects a course evaluation from students. Participation is anonymous and voluntary. A total of 41 out of 68 students participated. The average of overall evaluations given by remote students was 4.12 while the average for the local class was 3.91. Compared with a possible maximum of 5 and a department-wide average of 4.09, we interpret this as showing no significant difference between the two groups, or between the whole class and a typical class.

Grades awarded: Grades in this class were assigned on a uniform point scale against objective criteria. On a four-point scale (A=4) the local students' average was 2.98 and the remote students' average was 3.07. Grade distribution was virtually identical in both cases. Based on grades there was no indication that distant students learned more or less than local students. Our observation at the time was that the remote students represented a typical cross-section of the class, however we have no additional details to support this and in any case a larger sample would be needed for statistical significance. These results are consistent with Russell's "No Significant Difference" finding [20], which indicates that the medium of teaching does not make a significant difference in students' learning, all other factors being equal.

VII. Conclusions and Future Work

Over the last five years we have synthesized and demonstrated a new paradigm for distributed education, which makes delivery via Internet technology to the home or office both economically viable and educationally attractive. In this process we have demonstrated a system consisting of tested, effective teaching methods and a practical family of software, with the following major attributes: Clearly the era of Internet-based distributed education is just beginning. Based on evidence presented in this paper, we believe that a significant portion of this education will be conducted in synchronous mode. Based on evidence presented in [9] we also believe that in the near future an expanded Web browser paradigm will become the most common interface for multimedia Internet-based software. When the basic multimedia interface is a browser, a wide range of asynchronous and currently emerging synchronous applications will be reachable through the same, integrated paradigm. We are therefore basing our new research products on the Web interface. A successor to the current ClassWise will feature a wider range of media in the same interactive, instructor-led paradigm we are using today. This will include a wide variety of web-enabled graphics and recorded media such as MPEG audio/video. It will also include more generic media for student interaction, such as multi-user text, multi-speaker voice, and ultimately multi-user virtual environments, and will support multiple operating systems and hardware platforms when and if that is economically feasible. Server architecture will mature to allow the instructor to use a thin desktop client, providing the freedom of location that the student has today. We look forward to pursuing information technology research, pedagogical developments for better teaching, and commercial product development in this rich environment.

References

[1] Penfield, P., "Education Via Advanced Technologies," IEEE Transactions on Education, Vol. 39, No. 3, August 1996

[2] Carswell, L., "The 'Virtual University': Toward an Internet Paradigm?" ACM SIGCSE Bulletin, September 1998

[3] Bourne, J. et al, "A Model for On-Line Learning Networks in Engineering Education," Journal of Engineering Education, Vol. 85, No. 3, July 1996

[4] Harris, D., "Online Distance Education in the United States," IEEE Communications, Vol. 37, No. 3, March 1999

[5] Chiricozzi, E., F. Mancini, G. Paladin, and M. Ruggieri, "Procedures and Classroom Architectures for the Development of Tele-Teaching Activities," IEEE Transactions on Education, Vol. 38, No. 1, February 1995

[6] Brofferio, S., "A University Listance Lesson System: Experiments, Services, and Future Developments," IEEE Transactions on Education, Vol. 41, No. 1, February 1998

[7] Sun, C. and Chou, C., "Experiencing CORAL: Design and Implementation of Distant Cooperative Learning," IEEE Transactions on Education, Vol. 39, No. 3, August 1996

[8] Schulzrinne, H., "World Wide Web: Whence, Whither, What Next?", IEEE Network, Vol.10, March 1996

[9] Pullen, J. and E. Norris, "Using A Multi-User Virtual Environment As A Synchronous Teaching Tool", Proceedings of the Western Simulation Multi-Conference 1998, Society for Computer Simulation, San Diego, CA, January 1998

[10] Macedonia, M. and D. Brutzman, "Mbone Provides Audio and Video Across the Internet," IEEE Computer, April 1994

[11] Pullen, J., "Synchronous Distance Education Via the Internet", Proceedings of IEEE/ASEE Frontiers in Education '96, November 1996

[12] Brawner, S., North Carolina State - Fujitsu Network Based Education Project Course Evaluation Report, North Carolina State University, Raleigh, NC, 1997

[13] Pullen, J., "Synchronous Distance Education and the Internet," Proceedings of the Internet Society Annual Conference 1998, Internet Society, Reston, Virginia, July 1998

[14] Dutta-Roy, A., "Virtual Meetings with Desktop Conferencing," IEEE Spectrum Vol. 35, No. 7, July 1998

[15] Benson, M., A Distance Education Environment Using Multimedia Conferencing and Internet Based Delivery, Master's thesis, George Mason University, Fairfax, Virginia, 1996

[16] Golick, J. "Network Computing in the New Thin-Client Age," ACM NetWorker, Vol. 3, No. 1, March 1999

[17] Denning, P. "Professional Software Engineering Education," Annals of Software Engineering (special issue on software engineering education, N Coulter and N Gibbs, eds.), to appear in 1999

[18] Arden, B. "The Synthesis of Computers, Communication and Engineering Education," Journal of Engineering Education, Vol. 83, No. 1, January 1994

[19] Pullen, J. "Discrete Event Simulation of CSMA/CD Local Area Networks in the Network Workbench,"  Proceedings of the 1999 Western Simulation Multi-Conference, Society for Computer Simulation, San Diego, CA, January 1999

[20] Russell, T. The No Significant Distance Phenomenon, North Carolina State University, 1999

Magideas, ClassWise, CWTeach, CWSpeak, CWLearn, CWListen, CWRecord and CWPlayback, and QuickSymbols are trademarks of Magideas Corporation. Other products and companies referred to in this paper are trademarks of their respective companies or mark holders.

Author Contact Information

J. Mark Pullen
Dept. of Computer Science/C3I Center
MS 4A5
George Mason University
Fairfax, VA 22030
USA
Phone: 1-703-993-1538
Fax: 1-703-993-3692
E-mail: mpullen@gmu.edu

Michael Benson
Magideas Corp.
P.O. Box 2250
Centreville, VA 20122-2250
USA
Phone: 1-703-830-4700
E-mail: mbenson@magideas.com

Biographical Sketches of Authors

J. Mark Pullen is an Associate Professor of Computer Science and a member of the C3I Center at George Mason University, where he heads the Networking and Simulation Laboratory. He holds BSEE and MSEE degrees from West Virginia University, and the Doctor of Science in Computer Science from the George Washington University. He is a licensed Professional Engineer and a Fellow of the IEEE. Dr. Pullen teaches courses in computer networking, and has active research in networking for distributed virtual simulation and networked multimedia tools for distance education. He also serves as Vice President for Technology at Magideas (see below). Dr. Pullen recently received the IEEE's Harry Diamond Memorial Award for his work in networking for distributed simulation while in U.S. government service at the Defense Advanced Research Projects Agency (DARPA).
 

Michael Benson is president of Magideas, a software development company specializing in distributed education applications. He holds the BSCS and MSCS degrees from George Mason University, where he won the Computer Science Outstanding Academic Award at both undergraduate and graduate levels. He has been a software developer and technical manager in multiple startup companies, and has worked as an independent consultant. He is a Member of the IEEE.