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
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:
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:
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.
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
in video |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
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:
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:
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
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.
Class structure: We have used this distributed education environment in multiple modes:
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:
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.
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.
[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.
Michael Benson
Magideas Corp.
P.O. Box 2250
Centreville, VA 20122-2250
USA
Phone: 1-703-830-4700
E-mail: mbenson@magideas.com
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.