James Griffioen, W. Brent Seales,
James E. Lumpp Jr.
Department of Computer Science
Department of Electrical Engineering
University of Kentucky.
This paper describes the educational opportunities and challenges of teaching in a realtime wireless classroom (WC) environment. The WC environment allows instructors to replace conventional blackboards and chalk with a collaborative, networked, portable computing environment. WCs provide a wide variety of new instructional possibilities, including collaborative presentations and whiteboard interaction, live audio and video, animated examples, independent and instructor-directed web surfing, and other powerful multimedia methods. However, making effective use of these realtime interactive capabilities is not straightforward, and there are many challenges involved with teaching in such an environment. This paper describes our practical experiences teaching in a WC the past academic year. The costs and effort needed to prepare course materials for a WC are discussed, and recent experiments that integrate the WC environment with a distance learning effort are reported.
There are several reasons why we feel the WCs will be the classroom of the future. First, the emergence of compact, portable, powerful laptop computers and wireless networks makes WCs possible and affordable. The compactness and portability of laptops makes them a suitable replacement for pen and paper, while the computing power and network connectivity open up whole new instructional opportunities. We envision every student having a wireless laptop that they carry with them to all their classes. Alternatively, wireless classrooms can be used as a replacement for conventional instructional computer labs. Loading laptops onto a mobile laptop cart and moving the cart to the desired location effectively allows any classroom to be used as a computer lab.
The second motivating factor for WCs is the expense of retro-fitting old classrooms with wired network connections. WCs can give network access in every classroom with no or minimal renovation costs. The WC requires only the installation of the access points, which can be placed strategically throughout the building and can usually be installed without interruption of the regular classroom schedule. In addition there is the aesthetic value of providing network connectivity without any modification (or visible wiring) to the existing physical structure/classroom.
A third motivation for WCs is the new teaching capabilities made possible by the networked environment. The details of how WCs impact all aspects of daily classroom teaching is the primary focus of this paper. Note that if we ignore the mobility, reduced cost, and aesthetic values of WCs, there are few differences between WCs and conventional (wired) instructional labs. Wired computer labs have existed in Universities and secondary schools for years. This raises the question ``What is the difference between teaching in a WC and a conventional instructional lab?''. The answer is in their roles and objectives. The traditional approach and objective of conventional computing labs is to use the computing facilities as an asynchronous, hands-on period that supplements a primary lecture but is not directly linked with the actual first-time presentation of the material. Our efforts have been directed toward the real-time, interactive aspect of WC environments and the integration of interactivity and immediate hands-on experience into the daily lecture.
The remainder of the paper discusses and evaluates two critical issues that will decide the fate of WCs. First, we describe new instructional opportunities that are facilitated by the WC environment and the ways they can be used to revolutionize the educational process. Second, we describe the challenges that face WC before they can begin to reach their full potential and the pitfalls to avoid when teaching in a WC setting. Finally we conclude with our thoughts on the future of WCs.
Each student was equipped with a 150 MHz Pentium laptop with 32 MB of memory, a 2 GB hard disk, CDROM, floppy drive, lithium ion battery, 11.5'' color screen, wireless network card, and built-in scratchpad, microphone, and speakers. The machines for instructors were a slightly larger (13'' screen, 3 GB disk, 64 MB RAM, and extra batter pack) but were otherwise the same. In addition, the instructor would also connect an artpad, video camera, possibly a microphone, and overhead projector to his/her laptop. We used WACOM  artpads as the writing device. They come in several sizes and each instructor had their own preference as to which size was the best. In general the larger pads were preferred since they provided better control. For video, we typically used a Connectix color quickcam, which draws its power from the external keyboard port. External microphones were only used if the internal mike was insufficient. Although the students disagreed about whether an overhead projection was necessary (since everything on the instructor's screen was already on their screen), we typically projected the instructor's screen using a Boxlight Projector.
The wireless network consisted of six access points covering the three main buildings in the College of Engineering. We used Lucent Technology's WAVELAN  wireless access points and pcmcia network cards. WAVELAN uses a direct sequencing spread spectrum technology to transmit data at a rate of 2 Mbps. Note that this is only one fifth the bandwidth of older 10 Mbps Ethernets and only a small fraction of the bandwidth of new technologies like fast Ethernet (100 Mbps), ATM (155/622 Mbps), gigabit Ethernet or Myrinet (> 500 Mbps). As we will see later, this affects the types of things that are possible in the classroom.
The wireless network supports mobility/roaming, so the students could move from class to class and remain connected to the network. The access points provide the connection between the wireless machines and the wired campus/Internet. Access points are not necessary for instructor-to-student or student-to-student communication. Thus if Internet access is not important the class can be moved anywhere, even outside the range of the access points.
The Databeam distance learning suite provides a collaborative environment via Java applets that run in a client web browser. We ran tests and found it to be the most stable in a Windows '95 environment (as opposed to Linux) using recent versions of Netscape and Microsoft Explorer. The Databeam product is constructed around a centralized client/server model, where collaboration and access to shared data is provided through connections to a common network server. The server is installed on a network-accessible machine running Windows NT, and connections to it are initiated and maintained by the Java applet which runs within each client's browser. All information is unicast through the server to each connected client. Special password-protected access to the server is possible for the instructor, who can configure course materials and enable access to those materials for the participants in any given session.
A different model for providing collaborative and individual activities is implemented in the MBONE suite of tools. The tools are based upon multicast technology rather than a unicast client/server model. We used the MBONE tools on both Windows 95 and Linux and multicast each session across the campus network. Network-connected machines with multicast capability can join a multicast session and participate in the collaborative environment using the whiteboard, audio and video tools. In this model, control is decentralized and although the instructor initiates a session, all participants can multicast data to the others. The instructor provides access to course materials by importing it into an MBONE-based tool such as a whiteboard, which then multicasts the materials to everyone who is listening to the multicast session.
Multimedia lectures can be realized by connecting a single machine to a projection device such as a Proxima or a Boxlight. In the worst case, if the network is down or the laptop environment is not functioning, class can still proceed in the normal fashion using the large screen and the instructor's material. In our tests, a fall-back position that still allows all material to be presented was very important because various glitches will arise in such a leading-edge hardware and software environment.
Our primary tool for class presentations was the whiteboard, implemented in both the Databeam and the MBONE environments. The particular options provided in each whiteboard implementation vary substantially, but the general idea of bringing the presented class material onto each students' platform is critical and the whiteboard approach successfully accomplishes two interesting things: dynamic presentations by the instructor, and ability of students to participate by taking notes on the whiteboard or answering questions and working problems on the fly using the whiteboard as a sharing mechanism.
While the whiteboard provides excellent support for the collaborative presentation of prepared materials, we found that there are at least three critical things that must be provided by the whiteboard tool in order for it to be usable. First, the whiteboard must allow the instructor to import prepared materials in formats that are easily produced by the typical tools that are used to prepare lecture materials, such as latex, Powerpoint, or web-based (html) tools. The Databeam whiteboard requires that course materials be converted to a specific format (Farsite  and uploaded to the centralized server for access by connected clients. This format is produced from any Windows '95 application via a virtual printer driver. The MBONE-based whiteboard wb imports postscript or compressed postscript. Materials in postscript are imported by the instructor to wb and can be augmented via wb's capabilities for adding text and drawing graphics.
The second critical component that must be supported by the whiteboard tool is a good interface and efficient display of pen-based markings. The high-resolution WACOM tablets allow for very readable hand-written annotations like text and figures to be added to the whiteboard during a presentation session. We found that students require some form of interaction during sessions; presentations using a whiteboard that are not dynamic are the equivalent of moving the overhead screen into the laptop, and this alone does not enhance the learning environment. In fact, completed notes that are simply flashed before the students are worse than a chalk-board environment because students tend to tune out and rely on after-class access to the on-line notes.
We found that class materials for whiteboard presentations should be incomplete, and that the instructor should fill in missing components dynamically during the presentation. Similarly, students should have the capability to take notes on the whiteboard, making individual annotations as the presentation progresses. The whiteboard tool must support this and the pen interface is critical for the instructor. We found the Databeam whiteboard to be lacking in two key ways: the interface for adding annotations is hard to manage with the pen, and there can be a substantial delay between making annotations and having them appear in the whiteboard. The MBONE-based whiteboard solves both problems and provides a very nice interface without any substantial delays, making pen control very intuitive and natural.
The third component that must be supported by the whiteboard is the ability for any participant of the session to save copies of all materials in the whiteboard, including public and private markings. Students want the ability to record the examples that are added to pre-formatted materials during a session, and also want to add and save individual notes. The Databeam whiteboard stores at the server all annotations made to the pre-formatted and archived notes. Although any changes to the notes are recorded, only one person at a time has the ability to write on the whiteboard. Materials can then me made accessible at the server, and each student can download separate copies for printing or browsing. The Databeam whiteboard does not give anyone in a session the ability to insert private annotations, although the instructor can pass control on to other session members if desired. The MBONE-based whiteboard provides a way to store individual annotations as well as complete sessions for playback. We have modified the original whiteboard package in order to capture complete sessions and play them back at original speed, showing all participants' contributions throughout the session. This has turned out to be a very valuable capability and students demand access to the recorded sessions because of the rich information there for review.
In-class student-to-student interaction is an area that has significant potential. Determining the correct amount of student-to-student interaction, however, and regulating that interaction, is difficult. Our experience in this area is still quite limited. One thing that was mostly successful was the use of a collaborative text editor. In addition to the MBONE whiteboard, students ran a collaborative text editor call ``nt'' (networked text). A chat-style program could also be used, but nt uses IP multicast and thus consumes less bandwidth than the chat tools. During the class, students could type messages using nt that other students could see and to which they could respond. In most cases, this turned out to be quite valuable. For example, if a student had a question about what the instructor just said, the student could enter the question into the collaborative editor such as ``did he say 15 or 50?'' and another student, seeing the question might respond with ``15''. However, students did not make heavy use of this facility and it presented them with the opportunity to use it like a chat-room when they became bored with the lecture. Other student collaboration, like having sub-groups work together on a problem, are possible, but we have not yet conducted experiments with it.
A collaborative environment alone does not provide the freedom that students need to tinker and experiment with examples and problems in their own way and at their own speed. While a collaborative presentation is synchronous and interactive, individual participation requires tools and materials that can be examined asynchronously.
We have found that basic network tools such as ftp, telnet, and web-browsers, together with individual packages like editing tools, compilers and visualization software, provide an excellent environment for students to work individually on examples and problems. We have used these tools as part of three major teaching components: modification of on-line examples, supplemental note-taking, and independent web-browsing.
On-line examples can be integrated into a presentation and are effective initially when presented that way, but can give a deeper view when structured as an individual exercise to be completed by each student on the laptop. Thus at certain points in a presentation, there is a scheduled break for students to access via the network a prepared example that can be downloaded to the local machine and then modified, compiled, executed or visualized depending on the nature of the example. This is a miniature version of a normal laboratory session that might be associated with a course which meets separately in a wired lab. Simple ftp access and the associate local software has worked well for these types of examples, and students have noted that many hurdles are cleared in the mini-session where instructor involvement makes it simpler.
Independent web-browsing gives students another way to explore data individually during a session. We have provided examples such as simulations and web-based documents that can be accessed at specific times during a session or asynchronously as students have an interest.
Interactive on-line note-taking is perhaps the area where we saw the most benefit. Students quickly embraced on-line note taking and many claimed it helped them understand the material much better. There are several reasons for this. First, all the instructor's notes, including all the markings the instructor added to the notes during the class, were immediately transmitted to the students' machines and displayed on their screens. Students claimed that this meant they did not waste time copying things the instructor wrote, as they would in a conventional classroom using paper notes. Freedom from recopying the instructor's markings allowed them to focus on what the instructor was saying and doing; thus they found they learned more during the initial presentation of the material. Second, by adding their own private annotations, they ended up with multimedia notes containing the instructor's pre-written material, the instructor's in-class markings, and their own annotations. Third, the notes could be recorded ``as they occurred'' and then replayed to see the order things were written or erased. This is particularly important when the instructor ``works through a problem''. Fourth, most students claim they can type faster than they can write. Fifth, on-line notes means they can access them anywhere, exchange or modify notes, correct them and add cross-references, etc. Sixth, students claimed that on-line note-taking was very effective because the focus-of attention could be centered exclusively on the laptop screen. They did not need to look back and forth between the instructor, the overhead projector, and the notes they were writing, and this attentional focus removes some of the effort required to understand the concepts being communicated.
This last advantage of students' attention being centered on the laptop screen initially was very irritating to us (the instructors). It appeared that no one was listening to us since students were all busily typing on their keyboards and staring at their screens. However, in our discussions with students (and from their reports on their experiences) it became clear that they were listening very closely and that we, as instructors, were just going to have to learn that looking at the laptop did not mean they were uninterested or inattentive.
The above lesson actually turned out to be very instructive. In particular, we learned that students do not need to ``look at the instructor'' to absorb the material unless the instructor is demonstrating something visually. This means that instructors need to gesture and point in ways that are visible in the collaborative environment, rather than in ways that draw attention away from the laptop screen. For example, pointing, highlighting, circling and overlaying things on the whiteboard are all methods that instructors began using to gesture. These techniques keep attention focused on the notes and collaborative examples unfolding on the student's screen. This phenomenon is particularly interesting because it implies that there is essentially no difference between the student sitting in the classroom and the remote student participating in the class from a distance (assuming the collaborative environment reaches to remote students).
To experiment with distance learning, we asked some of our students to intentionally skip class in order to participate from a distant location such as a computer lab on campus or home. The feedback was very positive. Students said they felt like they were in on the class.
There is significant training time involved with students becoming familiar with the hardware and software environment. Touchpads, flatpanel displays, different operating systems, new software interfaces, and unfamiliar network hardware all contribute to a confusing environment that students must learn to understand and manipulate. We have found that this is not insurmountable, but must be factored into the class material in order to decouple the material to be covered from the learning curve that will exist as students become familiar with the environment.
Devising new teaching techniques that include an interactive multimedia component is not as easy as one might think. The standard lecture-style educational model is deeply entrenched in most of us and it is difficult to break from this model. However, lecture-style teaching can be significantly enhanced with a cleanly integrated interactive component.
Our first attempts to include an interactive component to the class were often disastrous, or were at very best awkward. Asking students to work through problems on the whiteboard seemed contrived at the college level but might work at the elementary school level. In a lecture-style class, the instructor plods onward, not knowing whether or not the material was comprehended. But in the WC environment, an instructor can get immediate feedback. by asking students to all answer a multiple choice question with the tallied results appearing on the instructor's screen . The question is what to do with this knowledge. Should the instructor continue on? Go over material again for the two people that are lost? Identify the people who got it wrong and find out what the misunderstanding is (students don't particularly like this)? In time and with more experience, such issues will become clearer.
As another example, asking students to try running a program on their own quickly turned to chaos if meticulously clear instructions were not given. Such chaos or delays might be acceptable in a computer lab setting, but we found them unacceptable in the middle of a lecture period. However, if students were given very specific instructions, they found the hands-on experience to be extremely educational. For example, the request to ``use the ping program to see network delays to various machines'' is too general to be successfully completed by the students. Instead, asking certain students to ping specific machines and report their findings removes the uncertainty of the request and illustrates the concept without the chaos. Specific interactive instructions require forethought and planning on the instructor's part. Planning makes the difference between a smooth, well-understood and well-organized interactive lecture period and disruptive interjections in the middle of class.
The things we found the easiest to integrate into lectures were multimedia documents, videos, and animations. It was relatively straightforward to run an animation in the middle of a slide, explaining each step of the animation and then allowing the students to go back and rerun the animation on their own if they desired while the instructor progressed on to new materials. In short, more experience is needed to identify the best teaching techniques.
The drawbacks with existing collaborative tools are not insurmountable. However, existing software does not provide the features instructors need. For example, a practical, yet important, thing is the ability to work examples and integrate materials on the fly. For example, the Databeam whiteboard tool does not provide an easy way to insert blank pages or load new material into a prepared presentation.
Interactive application sharing is a nice idea but suffers severely in bandwidth-limited wireless environment. We have experimented with application sharing tools provided by Databeam for Windows '95 platforms, but they were unusable with more than a few students on such a constrained network. We are confident that the challenge of providing effective tools for application sharing in a WC context will be met by emerging new techniques such as multicast technologies.
Limited wireless bandwidth is a concern, and must be considered when preparing course materials. For example, pages of a whiteboard session that are very large take time to distribute to all participants in the session and saturate the network, causing some clients to request re-transfers. When a number of clients request re-transfers, a cascading effect can occur which swamps the network. We have found that individual whiteboard pages that are 1/2 Mb or less in size cause no problems (if multicast), and that 1Mb or larger can saturate the wireless network.
Audio and video are important for distance learning and we have experimented with sessions that broadcast whiteboard notes, audio and video all simultaneously using the MBONE tools. The primary problem is that the network bandwidth is completely consumed by the audio and video. This makes the interactive presentation using whiteboard sluggish, and can degrade the audio to the point of it being incomprehensible.
Although students preferred taking notes on the computer there are still several things that can be improved.
We originally planned to provide all students with a pen device for freehand note-taking, until we realized that (at the time) all high-resolution pen devices required an AC power supply. For instructor machines, which are already tethered to support cameras, projectors, etc., this was acceptable, but for student machines we were seeking true portability. The lack of pen-devices means that free-hand note-taking on the machine is basically impossible. Better note-taking software for students is necessary in order to substantially improve the WC.
Limited laptop screen real-estate is another problem. Applications and window managers are needed that make effective use of the limited space. Databeam's float option allows windows within the web-browser to be floated as separated windows, helping eliminate some of the constraints with running within a web browser. The X Windows system provides window managers that allow multiple workspaces, and this can help students toggle back and forth between sets of windows.
A variety of issues arose regarding how best to operate as a student in a WC environment. Problems ranged from how to best arrange the windows on the screen, to ways to convert the notes to the editor format of their choice, to not liking to study for test on a laptop, to getting access to color printing facilities to print the multimedia notes, to not being responsible for material if their laptop crashed or ran out of power during class. The list goes on, but some of these issues will have to be resolved before student whole-heartedly embrace the new technology.
Multimedia material to be presented in the WC environment must be authored or scanned, formatted, convert, and massaged to the point where large amounts of time can be spent without a significant gain in content. Through careful planning and the use of auxiliary materials found with primary and supplementary textbooks, the preparation time can be lessened. However, problems still remain.
First, there is little or no interoperability among software tools for the purpose of constructing materials for a WC environment. For example, Microsoft Word documents cannot easily be imported into Powerpoint to provide a common framework for both notes and whiteboard presentation slides. In the Linux environment, latex and public domain software such as latex2html can generate most formats but can be difficult for non-expert instructors to use. We have built a large number of macros for latex in order to generate a variety of formats for notes, slides, slides with sections deleted for the purpose of dynamic presentations, etc., but these tools are home grown.
Databeam uses the Farsite  format for whiteboard presentation materials, but this format is incompatible with other tools. The MBONE-based whiteboard accepts postscript, which is arguably as close to interoperability as one can get. But this brings with it all the associated problems of postscript, including large file sizes, which is inadvisable in a bandwidth-constrained context.
Second, the temptation as an instructor is to over-prepare, making on-line notes complete and perfect. Online notes that are too complete stymie interactivity and limit the dynamics of collaborative presentation. Over-preparation also exhausts the resources of the instructor before the actual presentation, which is still the most critical point in the process. In a different environment, such as the preparation of video taped courses, the advance production is everything. But in the WC there is much to be gained in the dynamics of the collaborative presentation itself.
Third, scanned data helps cut preparation time but is diametrically opposed to low-bandwidth organization of materials. We have addressed this problem with a variety of techniques, including presentation of lower-quality images with higher-quality versions available on a web-page or in notes that are available after class. This can help, but preparation time increases with the extra effort required to manage the resolution problem.
We have found that a interactive/collaborative component can be extremely effective at communicating concepts and information to students. The combination of collaborative, interactive presentations and individual participation supports a teaching style that is a mixture of lecture, student-teacher interaction, and individual problem solving.
We have tested two software platforms and have found strengths and weaknesses in both. In general there are no ideal software solutions available yet, and interoperability and materials preparation time can be difficult without proper planning and strategic emphasis.
We have found that the capabilities of the WC environment outweigh the difficulties and that adequate tools and techniques are certain to emerge to alleviate certain problems we have identified.