Back to the Basics: a First Class Chalkboard and More
Institute of Industrial Science
University of Tokyo
7-22-1 Roppongi Minato-ku
Tokyo 106-8558, Japan
Whiteboards, unlike their physical counterparts (i.e., chalkboards), have found very little use in electronic courses. In this paper, we present an extensible framework that we have developed to make whiteboards more suitable for distance education use. A prototype written in Java™ is now being evaluated. Our solution aims to promote the use of whiteboard as an authoring tool for producing quality lecture contents in a format that can be delivered in synchronous or asynchronous mode over a network. We believe that a solution based on the chalkboard metaphor will provide teachers, especially those who are new to information and communication technology (ICT) with a natural and easy transition toward integrating ICT in pedagogy.
Online authoring system, whiteboard, distributed Java™ application.
The Internet and in particular the World Wide Web is becoming increasingly attractive as a viable medium to deliver courses online. There are numerous ways to produce lecture materials suitable for distance education on the WWW. With the emergence of multimedia streaming (or so called view-while-loading) technologies, a fast-growing trend has been to provide distance learners with the gfeeling of the classroomh by broadcasting live scenes of the classroom or video recording gwhat happened in the classroomh.
Chalkboards are by far the most widely used medium for lecture presentations in the classroom. They allow teachers to directly communicate all or part of the course material with little effort using handwriting during the lecture, without having to pay special attention to the details related to the
use of a chalkboard. This is in part due to the fact that most teachers are already accustomed to it and new users get quickly acquainted with the interface of a chalkboard.
Although audio and video recording of a classroom presentation constitutes a quick way to provide a fast copy of a lecture for students, the video-recorded content of a chalkboard is too hard to read. Hence, in an electronic course, lecture presentation materials are almost always prepared in advance using authoring tools.
Authoring tools assume that there is a person talking about a set of slides and they are mainly designed to assist the authors of course materials before the presentation. But, there is very little support for online authoring, i.e., authoring during the lecture presentation similar to what a classroom chalkboard offers. More precisely, we define online authoring as the ability to support rapid preparation of course materials in parallel or in sequence with a live video and/or audio narrative in a format that is suitable for synchronous or asynchronous distribution over a network. Roughly speaking, it is similar to sharing the view of an offline or regular authoring system among distance students in real time or playback mode, plus some additional requirements (see below).
In practice, we observe that when presentation slides are available, the use of a whiteboard is significantly reduced during the course of a lecture presentation. Teachers tend to use it only for further clarification of a point, such as when answering a question from a student. Annotating directly on a pre-developed slide is often the way to accomplish this.
The main aim of this paper seeks to improve the applicability of whiteboards for distance education use through extending whiteboards with better online authoring features. Because of their similarities with chalkboards, we believe they have the potential to be a catalyst for increasing teachersf willingness to explore computer applications in pedagogy. The problem of adding authoring features to a whiteboard was first discussed in , but at that time the target was to produce lecture materials for asynchronous delivery. Moreover, our approach is unique in the sense that it provides an extensible framework for developers located anywhere on the Internet to add new features to the system.
In the rest of the paper, we describe the requirements of an online authoring system and the design of a new breed of enhanced whiteboards that we have begun to develop towards meeting these requirements.
2. ONLINE AUTHORING REQUIREMENTS
The low utilization of whiteboards in distance education can be attributed to a combination of issues in human computer interaction and limitation of technology. We have identified three major deficiencies.
· First, using a keyboard and a mouse to unfold the parts of a lecture content on a computer screen is not as easy as using a chalk or a pen, like when writing a mathematical proof.
· Secondly, although the electronic boundaries of a whiteboard are only limited by the available amount of memory, at any given moment it cannot display more information than what can be fit on the computer screen, which is normally not as big as that of a chalkboard. Some people might find it troublesome to scale down their handwriting and work in a space-compressed environment.
· Third, current implementations of whiteboard do not offer enough features to support online authoring.
Before we examine the requirements of an online authoring system in detail, some remarks about the first two deficiencies are in order. Ideally, all three deficiencies need to be addressed at some point, but as we shall see, some of the online authoring features are in direct conflict with the first deficiency - freehand style of input. The effects of the second deficiency could be ameliorated by an intuitive interface that allows users to easily navigate within and access to the parts of a whiteboard. Our main focus here is to enable a whiteboard to function as an authoring tool. We will pick up the interface issues in the future. Meanwhile, we hope that the enhancements introduced by the authoring features will be usable enough to appeal to users.
As noted earlier, the requirements of an online authoring system are similar to those of a regular authoring system, but because the content that is being generated gon the flyh needs to be made available to distance students over a network, additional levels of support are needed. We distinguish three kinds of requirements:
· authoring features: the characteristics that are proper of an authoring system,
· delivery features: the tools and services needed to make the contents accessible online or offline in a networked environment, and
· group features: floor control and management support.
Conceivably, there can be many levels of sophistication in each of the above requirements, we focus on the essential ones.
2.1 Authoring Features
Currently there are a quite a few commercial and freely downloadable authoring tools. They exist in many forms and provide different levels of support for authoring depending on the type of media (e.g., WWW, CD, book) and type of content material (e.g., text, drawing, animation). The variety ranges from general tools (e.g., HTML converters, WYSWYG editors) to education-oriented tools (e.g., mark-
up languages for rendering mathematical formulae  and for authoring questions , visual tool for authoring Java applets like Jamba™). But regardless of the type of authoring tool used, the end result is a document that presents usersf content in a particular format that ensures a good degree of readability. Thus, unless handwriting recognition technology is used, it should be clear that if a whiteboard were to mimic the freehand strokes on a chalkboard, content readability would depend greatly on the teacherfs ability to write clearly. Unfortunately, handwriting recognition systems are still not perfect and they are mainly designed for translating handwritten texts to characters or symbols occurring within natural languages. Systems that can handle notations used in such fields as chemistry and mathematics are not widely available yet. On the other hand, using a mouse and a keyboard is still the most efficient way for authoring non-trivial contents like 3-D graphs and animations. Hence, within the reach of todayfs technologies at best we could only settle for a compromised solution that favors the use of computer rendered or printed representations where handwriting recognition fails or does not fit.
Readability is even more critical when the content is intended for asynchronous delivery. Since, unlike the synchronous mode, the teacher might not be online to answer any questions that could arise during playback. Moreover, for retrieval purposes, text data can be more easily indexed than image data.
2.2 Delivery Features
The idea behind online authoring is that the lecture materials need not to be made available in advance. They can be improvised or created on the fly as needed during the lecture. Hence, all participants must have the same view of the whiteboard of the teacher or at least students should see what the teacher wants them to see. In addition, latecomers if they are allowed to join should be able to see the most current view of the whiteboard.
In the asynchronous mode, viewersf whiteboards must be able to play back the input actions (e.g., pen movement, mouse clicks) of the teacher at the original speed and in sync with the video and/or audio narrative.
2.3 Group Features
In the synchronous mode, it is not sufficient to just have a common view of the teacherfs whiteboard. We also need to provide students with shared access to the whiteboard. For instance, a student may want to use a tele-pointer to identify a focus or write something on the whiteboard. This suggests that a floor control mechanism is needed to coordinate the access to the whiteboard.
3. A WIDER FRAMEWORK - WHITEBOARD AS A FIRST CLASS CITIZEN IN THE VIRTUAL CLASSROOM
In this section, we describe the details of our approach and the features that we have implemented so far in our prototype.
3.1 Design Philosophy
Not a single set of features can provide a teacher with all the functionality he or she needs for authoring online. Nor a single institution can have all the expertise or resources needed to implement all the desired features. Recognizing these limitations, our design is centered on extensibility and employs a collaborative and open-source approach. In this way, the solution is extensible, open-ended – new features can be incrementally added to increase the system utility and can be used to catalyze the efforts of a wider external research community of developers. Based on this design guideline, we have developed a prototype of an extensible, enhanced whiteboard called First-Class.
First-Class is part of a larger project, Classroom Anywhere – a Java-based distributed multi-modal learning environment under development. In a nutshell, First-Class is based on a family of servers executing various services on behalf of remote clients. The code in conjunction with the data that implement a service is installed on demand on the client like a plug-in, i.e., the downloaded code becomes part of the execution code of the client. The plug-ins in turn can call other services. In this sense, the servers form a cooperative computing environment. Furthermore, any update on the service introduced by the server is automatically reflected on all clients that require that service. First-Class is written as a Java application because of the need for loading plug-ins into a client computer at runtime, which requires read/write access to the clientfs file system.
In what follows we describe the software architecture and facilities of the current system.
3.3 Software Architecture
Figure 1 shows the six main components of the software architecture.
· Client whiteboards allow users to access to the local and distributed services. The local services support the typical features of a regular whiteboard like shape drawing and text input, whereas the distributed services can be just about anything that conform to the plug-in interface (described in section 3.5) like rendering a math equation and an interactive animation. Client communicates with any of the servers by sending messages.
· The Reflector server provides message replication services, broadcasting an incoming message from a client to the remaining clients. In addition, it maintains a history of all the messages produced in a lecture and stores timing information that can be used for video/audio synchronization with replay of input actions occurred on the whiteboard.
· Feature servers operate as repository of plug-ins and/or service providers for remote clients. A plug-in is the implementation of a feature, which can include both Java classes and data that are downloadable as a single jar file. HTTP is used as the common networking communication protocol between clients and feature
servers. Each of the feature servers is independently administered and maintained.
· The Directory server keeps a list of the available feature servers and meta-information specific to each feature and plug-in, such as location (URL) of the feature and the required arguments, and the name of the jar file.
· The Control and Coordination (CC) server supports access control to plug-ins and validates view synchronization requests. The client that is registered as the lecturer can grant or revoke access to a plug-in for each client. Changes in the access control configuration are broadcast to all clients. Local input actions to a plug-in from a non-lecturer client are not propagated to other clients unless it has been given the permission to do so. In the current implementation, the access control works only at the plug-in level, i.e., it does not extend to anything running inside a plug-in. In section 3.7, we show that this level of granularity is appropriate for interactive animations.
· The Timeline Server controls the time synchronization between audio/video and whiteboard playback.
Figure 1. Architecture of First-Class, showing the interconnections between the components
3.4 Initialization and Plug-in Loading
The diagram in Figure 2 shows the interactions of the various parts of the system during startup and when a plug-in is referenced. Clients can connect to a lecture in progress after registering with the Reflector. The Reflector sends the message log to the newcomers, from which the latest state of the whiteboard can be assembled. Clients contact the Directory server to get a fresh catalog of the available plug-ins and install the additional plug-ins needed to stay in sync with the rest of the system. From the catalog, users can conveniently select up to 10 plug-ins, which will be used to populate a menu that pops up for easy access during a lecture (see Figure 5).
Figure 2. Diagram shows what happens when a client joins
Plug-in loading is based on the class loader architecture of Java Virtual Machine . We have developed a custom class loader that enables First-Class to download the extra classes it needs across a network as it runs. Each plug-in is associated with a version expiry timestamp. The classes and data that comprise the plug-in are downloaded if either of the two following conditions is true: (1) the plug-in is not installed yet, or (2) the plug-in is found to be outdated when it is needed. In this way, the behavior of the plug-in can be dynamically extended at runtime.
3.5 Overview of Plug-in Interface
The integration of authoring features into the system depends on a common Java interface that every plug-in must implement. We will publish the complete set of specifications later this year. The following gives an informal outline of the main methods of the common interface and their usage:
· addFeature. Adds a feature to the whiteboard.
· input. Collects plug-in specific user information from the user (e.g., a Latex expression). This is the first interactive method launched by the system on behalf of the plug-in.
· render. Displays a feature directly on the whiteboard or on a separate window.
· size. Returns the coordinates of the bounding rectangle that completely encloses a feature.
· deleteFeature. Removes a feature from the whiteboard.
· inputCompletionCheck. Supports asynchronous replication of newly instantiated features. The input( ) method above may or may not block while it is running. This method provides a mechanism to check for the completion of the initial input.
· upLoadData. Supports asynchronous replication of features already in execution. It is the responsibility of the plug-in to signal via this method when new data are ready for replication (e.g., interactive animation or simulation).
· downLoadData. Support asynchronous replication of features already in execution. This method forces a plug-in to reload its input data.
· update. Supports asynchronous replication of features already in execution. This method forces a plug-in to recalculate the result and revalidate the presentation of the result.
3.6 Delivery Process
Figure 3 shows the basic hardware setup for the delivery of a live lecture. The live video/audio is captured and real-time encoded, then passed through a hardware reflector to distribute the video/data to remote clients. In parallel, the captured signal is encoded using streaming technology and archived.
Figure 3. Hardware Configuration for Synchronous Delivery
To facilitate the automated conversion of a live lecture given using First-Class into a replay format the system records the time in two instances:
· at the instantiation of each plug-in, and
· at the time of a request for update (e.g., restart of an animation with new parameters) via the plug-in interface
Figure 4 shows the process for supporting asynchronous viewing. In the playback mode, users download a jar file that includes a simplified version of First-Class and all the plug-ins referenced during the lecture. RealSystem G2™ broadcasts the video streams to users. The video presentation is assembled using the SMIL (Synchronized Multimedia Integration Language) format. SMIL has a mechanism to produce a trigger based on timing information. The trigger is intercepted by the Timeline server, which coordinates the timing for the replay of the next action on the whiteboard.
Figure 4. Setup for asynchronous viewing on the client
3.7 Prototype Feature Servers
Figure 5a through Figure 5c illustrate the current set of features in First-Class. We describe these features below. From the implementation point of view, the features can be
server-based (i.e., plug-in acts as an interface to some services running on a server) or client-based (i.e., plug-in runs entirely on the client).
· Latex. Renders Latex expressions. This feature demonstrates the use of a scripting language as the interface for entering commands and expressions.
· Japanese Text Input. Renders Japanese characters.
· Online Handwriting Recognition. Recognizes handwriting in English based on PenOffice™.
· 2D Plot. Renders up to two mathematical functions simultaneously.
· Towers of Hanoi. An example of an interactive animation.
It is interesting to note that each client can independently interact with the control parameters or any part of the graphical user interface of the animation. This is because the access control does not extend to the graphical user interface of a plug-in. At the same time, two modes of view synchronization are supported to add extra flexibility to animations and alike: (1) one-time synchronization, and (2) continuous synchronization. These modes are only accessible to the lecturer client that created the plug-in. In the first mode, synchronization only occurs once - at the first view update of the plug-in. In the second mode, synchronization occurs every time there is an update. This implies that other clients can experiment with different parameters during the period between the previous update and next update.
Figure 5a. First-Class in action – some sample features, the input dialog windows of 2-D plot and Towers of Hanoi are not shown.
Figure 5b. Recognizing handwriting using PenOffice™
Figure 5c. Latex input dialog box
4. SUMMARY AND FUTURE DIRECTIONS
We have examined the requirements for online authoring (broadcast as you type), which have additional requirements with respect to offline authoring (play back what you type). To realize online authoring we have developed an open, extensible framework for cooperative development of any number of features useful for, but not limited to, online authoring use. The features are dynamically loaded into an executing program and their behavior can be changed on the fly. Moreover, the meta information associated with each feature, in conjunction with the text entered in the system using facilities like handwriting recognition and scripting languages can be used to automate the creation of a table of contents and an index for the lecture. Based on this framework, we have built an enhanced whiteboard called First-Class. First-Class aims to provide an extensible set of online authoring features, including such options as adding interactive animations to the whiteboard.
In the future we plan to integrate First-Class into a learning environment, evaluate its usability and develop more comprehensive group control, and coordination facilities to support multiple styles of collaboration.
Sakauchi Laboratory (Institute of Industrial Science, University of Tokyo) provided equipment grants and additional support for carrying out this work. Last but not
least, several colleagues contributed to the implementation of First-Class, including, Panrit Tosukhowong and Vuthichai Ampornarameveth.
Java is a trademark of Sun Microsystems, Inc., Jamba™ is a trademark of Tria M Europe BV, RealSystem G2™ is a trademark of Realnetworks, Inc., PenOffice™ is a trademark of ParaGraph, a business unit of Vadem.
 Bacher, C. and Ottmann, T.: Tools and services for authoring on the fly. Proc. of ED-Mediaf96 – World Conference on Educational Multimedia and Hypermedia, (Boston MA, 1996), AACE, 7-12.
 Hubler, A. W. and Assad, A.M.: CyberProf: An Intelligent Human-Computer Interface for
Asynchronous Wide Area Training and Teaching. In Proc. of 4th International
World Wide Web Conference (1995),
 Brown, D.J.: Writing Web-based Questions with Mallard. In: Proc. of FIEf97, Frontiers in Education Conference, (Pittsburgh PA, 1997), Stipes Publishing L.L.C., 1502.
 Lindholm, Tim and Yellin, Frank.: The Java Virtual Machine Specification, Second Edition, Addison-Wesley, ISBN 0-201-43294-3, (1999).