Development of an electronic classroom: the promise, the possibilities and the practicalities

Development of an electronic classroom: the promise, the possibilities and the practicalities by T. W. Shaw

The advent o f ubiquitous computing promised muchfor education, and indeed very powelflrl dmlopments, spurred on by the computer-supported co-operative working (CSCW) community, are now becoming available. H o w , ‘chalk-and-talk’ and slide sequencer still remain a signijcant putt ofthe pedagogical por@lio o f many tutors, moss all phases o f education. This situation persistsfor a number o f d i d reasons, including the cost and volatility ofthe support technoloo, not least that involved in courseware creation. The paper brigy reviews what is possible with current hardware and sofiware, but concentrates on the development o f a basic electronic classroom, designed as a human-tutor aid. Emphasis isgiven to the qualities ofportability, robustness and availability rather thanfirmtiomlity, but it is recognised that system extensibility is desirable when costs and technology allow

s soon as computers with visual display units (VDUs) based on the cathode ray tube became widely adable in teaching institu- A tions, their use as ‘electronic blackboards’

was recognised as potentially being of great value as an aid to the tutor. Furthermore, the enormous potential of using networked computers for the education, and hence benefit, of humankind was enthusiastically greeted’. With the innovation of real-time interactive computer graphics, their place in a range of differing educational support roles was assured.

Hawever, as with nearly all applications of computers, developments proceeded more slowly and unsurely than was prehcted, but the variety of uses in education and training was perhaps never even imagined. Today, ths range includes the stand-alone personal computer (PC) used as such by indwiduals €or administrative support, e.g. wordprocessing, of their personal education; the use of personal-computer- based multimedia systems with compact dlsc read-only memory (CDROM) courseware; and networked multimedia high-performance workstations in a computer-supported co-operative workmg (CSCW) environment. However, the provision of artificial intelligence (AI) to support individual learning in the

absence of a human tutor and the design of courseware are still active research areas. Furthermore thc cost of obtaining courseware of adequate quality and scope remains a problem for most United Kingdom teaching institutions, as indeed does the cost of niultimedia hardware. Also, success in providmg intehgent tutoring systems (ITSs) has been limited. On the other hand, the value of the general approach described in this paper, that is, the use of computer systems to support the human tutor, has recently been reconfirmed’.

This paper briefly reviews the development of the elecmnic classroom, describing what has been achieved. The d8culties of identlfying a single model for such a classroom, in view of the preferences of &&ring tutors, teaching/learning models, the diversity of subjects and the variabhty of available hardware and software in different institutions, is implicitly acknowledged in terms of the configuration described below. Thus the electronic classroom described here is minimal, but robust, cost-effective, portable and extensible.

Electronic classrooms

In recent years in the United Kingdom, and to some

ENGINEERING SCIENCE AND EDUCATION JOURNAL APRIL 1995

63

extent internationally, access to education, particularly higher education, for people with widely Mering educational histories and ages has sigmticantly improved.

Unfortunately, there has been a concomitant reduction in real resources to support this desirable process. In turn, this has concentrated the minds of teachers and lecturers on thinking again about their pedagogical slulls, and the potential of computers to support them.

It is perhaps an indication of the dlfficult nature of the problem that software products that provide the required capabilities have only recently appeared, in the guise of groupware-related products. Developments do exist to satis@ the functional part of the system described in t h s paper, typically in the form of teleconferencing/worlang so&are3, but these often require special hardware or uncommon networks, and are often unavailable for a number of reasons, e.g. cost. Potential ‘electronic tutors’ are still hard-pressed to find a complete, reliable, portable and affordable electronic classroom, even without courseware, as an off-the-shelf product. Thus the design ofan electronic classroom has been a fertile area for computer scientist teachers.

Many ofthe early electronic classrooms were used by computer-literate tutors, ofcen computer scientists, to help in the delivery oftheir own subject material. Such tools were based on conunand-line interfaces, and were used until the advent of graphical user-interfaces (CUI) with more intuitive operation. With the early systems, all the teaching material usually had to be prepared beforehand and, as a minimum, stored in a computer file, either as encoded alpha-numeric characters or, for pictures, as pixel maps. Point-and- click graphical user-intedaces, however, give greater scope for live interactive worhng, as greater hnctionahty releases time for this. Now, these more sophisticated systems can interface to compact-disc- read-only-memory storage, possibly remotely located, to recover static and video picture images and sounds, but it is unusual, in t h s country at least, to find such equipment widely avallable and with a range ofrelevant courseware.

A typical computing configuration in modern educational institutions is a &stribwed computing environment (DCE) with clusters of workstations and/or clusters of personal computers in laboratories, with indvidual units in offices. Where clusters are housed in reasonably private areas, they can potentially be used in an electronic classroom configuration.

The necessary communication channel for an electronic classroom is typically provided by a local area network (LAN) with a suitable messaging protocol, e.g. TCP/IP (Transmission Control Protocol/Internet Protocol), but the future perhaps lies with broadband integrated services digital networks @ISDNs)‘, whch promise to operate at interactive speeds over large &stances, e.g. internationally, so that opportunitiec for very large classes can be imagined. For a localised classroom, this is of course not necessary, but with

rumoured class sizes of 400 in some universities, perhaps it is no longer valid to assume that lecturea d always be working in a single ‘room’ or lecture theatre.

State of the art

The potential features of an electronic classroom are now quite impressive and powerful, the momentum for the current developments coming mainly h m a more general interest by developers of computer- supported co-operative working for industrial and commercial application.

Multimedia technologies available include video, auclo, shared drawing/editing, decision support, distributed databases, window management, large- screen sketchpads, specialised input devices, virtual reahty (VR) immersion technologies, and electronic- conferencing support sofnvare.

As already intimated, such comprehensive systems are generally far too expensive and unnecessary for a local classroom, but perhaps a good example of what may be conl~nonly available in the near future is a further development of a presentation system that uses a virtual reality ‘dataglove’ as a control device. This effectively instruments hand-motion and thereby can capture fairly sophisticated gesturing. These gestures can be dfierentiatcd to control the presentation or have their normal meaning in face-to-face communica- tion6. A major advantage ofsuch an approach is that the difficulty speakers (tutors) have in managing a multi- plicity ofinput devices in a multimedla presentation are largely eliminated. Although this development was not conceived primarily as a tutor aid, it does demonstrate the potential of some recent developments for educational purposes

‘The Teacher‘s Pet’ electronic classroom project

This project aimed to provide a basic, but reliable, delivery vehicle for computer file-based teachng material, which is becoming increatingly common, using a UNIX/X-MOTIF workstation dlsiributed computing environment. It required pointing facilities, a drawing area and a ‘chakpassing’ facility. Also, it was desired that a limited range of existing programs, such as file-browsers, could be uthsed, which would additionally be of value to the students in their own, unsupervised work. A very reliable registration and deregistration facility was found to be essential; hs is discussed later. An early decision in the spechcation was that students should be either ‘in’ or ‘out’ of a session, not temporarily withdrawn. This decision was taken in anticipation of major complications with saving state information for subsequent session rejoining. Software to manage this problem is still a development area’, but does exist for recording a lesson for later playback in a suitable multimeha environment.

Another requirement was that the tutor should


64

slaves master

student interface

CLASSROOM

I ' I

Fig. 1 The electronic classroom

remain firmly in control of a teaching session: there was no intention that this system was to be primarily a self-teachmg/learning tool, although the addition of multimedia hardware and courseware for this application is straighdorward in principle. Ths suggested that the shared windows of the electronic classroom should be 'tiled' on the participating screens (see Figs. 1-3) and t h i s in turn facihtated easy pointer referencing when the tutor needs to highhght spec& screen locations in a lesson, for example.

Many of the well-known advantages of tutoring by computer have been anticipated by suitable software design in the system. For example, a secure write-only common directory is provided for students to submit coursework exercises in computer files rather than as paper copies, and universally accessible &rectories of example material and course notes are avdableE. Addtionally, a facihty to prepare 6les for and to receive them from alien computer operating systems, such as DOS, is available9.

In anticipation of the classroom being used for general teachng and tutorial work, possibly by a population of tutors and students without computer operating skdls and, indeed, with some potential for being intimidated by computers, the provision of a

suitable user interface, providmg virtually all required interaction by pointing to clearly labelled functions, was considered essential.

Many of the problems of sharing existing single-user teaching utilities and demonstrating concepts can, of course, be handled with the use of a large-screen projector, or a liquid crystal &splay (LCD) tablet, coupled to the tutor's computer". However, another basic design requirement here was that the classroom should require no addtional hardware other than that normally found in a computer laboratory (mainly because of the expense). Also, no additional software other than the development described here was allowed. This has the great advantage that the classroom can be 'created wherever there is a cluster of networked workstations, i.e. it is portable.

The electronic c l a m o m structure The application consists of a number of separate

computer programs. On the tutor's computer these are all controlled by the tutor interface. Only a single program, the student interface, is required on each slave machine. A list of the elements constituting the electronic classroom is provided in Table 1; the itenis are easily related to the following subsections, which


65

Table 1: Programs, windows and control worhng community Here, the 'electrok blackboard' refers to Programs Student nodes Tutor node

Program Window Control Program Window Control a drawing 'pace, where, under tutor control,

Electronic Classroom: students can draw and write. Tutor interface N N NIA Y Y Student interface Y Y WO N N WA The tutor can therefore 'pass- Electronic blackboard N Y PI0 Y Y VO the-chalk' without students Protocol multiplexer N NIA NIA Y having to leave their seats,

whch is alwavs a msruotive Pointer slaving N Y I*/O Y Y

I/o

'Io

Utilities: activity in a conventional Browser N Y 0 Y Y classroom when several students Editor N Y 0 Y Y iz in sequence are involved. All Terminal emulator N Y 0 Y Y drawing and writing must use etc. N Y 0 Y Y

the standard kevboard and 110

+When enabled by tutor N/A = not applicable I10 = inpuffoutput

describe them in more detail. Fig. 1 provides a dagrammatic representation of the

electronic classroom. It shows the placement of the windows corresponding to the programs and includes a representation of a remote node, where the only communication possible is via the electronic blackboard. Ths typc of usage relates to the screen shown in Fig. 2, where the system was used in an experimental manner to group-review this paper.

A pointer, rhown in Fig. 1 as a north-west arrow, can be slaved to a participant's mouse pointer and can be positioned anywhere on the screens.

7'he electronic blackboard The window for ths is shown in the top-right half

of all screens, and can be seen in Figs. 1, 2 and 3. The terms 'blackboard', 'whiteboard', 'chalkboard'

and others have tended to acquire some proprietorial significance in the computer-supported co-operative

mouse. Clearly, the expressive and creative power in teachmg sessions is limited, but can obviously be improved ifthe expense of addxional devices such as styli and graphics tablets, and the consequences for portability, are acceptable.

The electronic blackboard functions available to students are only a subset of those available to the tutor; for example, only the tutor can enable/disable students' access to the electronic blackboard, or clear the drawing area.

Finally, a limit is fixed on the number of participants using the electronic blackboard at one time, because interactive drawing per6ormance can suffer otherwise.

Multicast utilitia The left-hand half of the tutor's screen and the

corresponding part of the students' screens are shown with multicast utilities. These are applications used to demonstrate file-based courseware, and typically include text editors, t e d emulators and file


66

what i s the compile l i n o ----I- -. - _. __I_ l - ~ l m / = . ” m 1.c I . ... . . . . . . ..,I for the program i n the

cc -0 async-io auync-io.c

what about if you didn’t want to link, only checksyntax7

Flg. 3 The tutor‘s screen in a software development class

browsers. Also, static picture dumpers can be used. Only the tutor is able to control and provide input for these applications at present.

The electronic classroom sobare handles full Internet addresses, and participants do not have to be in the same room, or even on the same site, although it has not been tested over large &stances. It should be emphasised that more powerid (and expensive) systems exist to achieve group w o r h g , with full video-conferencing features. However, the approach here is easily augmented with separate video channels. As it stands, it remains marginally useful in this mode for h t e d types of workmg amongst expert participants.

Tutor it&jhce This window is fixed in the bottom-right of the

tutor’s screen, and its appearance is detailed in Fig. 4a. It is divided horizontally into four fields, the menu row, the push-button row, the upper list window and the lower information window. The major features are a registration/deregistration system, a means of selecting and preparing lesson files, a means of launching the electronic blackboard and the protocol multiplexer, selection of shared ublities, and pointer slaving.

Table 2 lists the menu items and their functions. The project was not conceived to provide

courseware developments for any subject. It is essentially a delivery system for any material that can be stored in a file as text or image, or for material that is generated on-lme during a lesson. Indeed, the latter feature is one of the most valuable concepts in an electronic classroom. Thus, the COURSEWARE menu gives access to facilities which assemble existing

indvidual courseware files into lesson files, which consist of a list of individual courseware files. For a particular session, the constituent files of the lesson can be written to the upper list window, from where they can be selected indwidually”~’*. The material can then be viewed, edited or browsed in a shared window.

The CONNECTIONS menu allows students to register, and can enable, disable or re-enable t h ~ s hnction. When the class members have all registered, the electronic blackboard and protocol multiplexer can be started. As mentioned earlier, the design phdosophy in this classroom is that students are either in or out of a session, with a limited facility for rejoining after deregistering. The problem oflate joiners can be a major one, and is the subject of research in the computer- supported co-operative worlung community, partly because the computers of such registrants need to capture the current state of the lesson. However, this is a very limited application in this context, with all participants in one room (known as a ‘same place, same time’ application), and late joining is not a real issue. Such students can simply preregister and look over a

Table 2: Menu items in the tutor interface

QUIT Terminate session, removing shared windows and tutor interface

COURSEWARE Prepare and select lesson sequence files

CONNECTIONS Control registration, launch electronic blackboard and protocol multiplexer

TESTS Functions for software debugging: temporarily retained

UTILITIES Editors, terminal emulators, browsers and other utilities for multicasting


67

Table 3: Push-buttons in the tutor interface

LIS Switch ‘listening for registration‘ on and off (not used)

RFRSH Repaint all participating screens

PING!

SOCKT

Check if particular node is still connected

Used exceptionally to clear a nonresponding (dead) connection

Switches pointer slaving on and off

Paste student names to list window

CUR

QUERY

neighbour’s shoulder until such time as it becomes convenient, at a natural break in the lesson, for the tutor to relaunch applications with the new list of participants.

The TESTS menu items are not part ofthe electronic classroom, but include development and debugging aids for the sohare.

The items avadable from the UTILITIES menu are not part of the electronic classroom software development, but include all the applications that are multicast, e.g. the file browser and the terminal emulator.

It is possible to launch the utihties in a ‘managed’ form, implying that they no longer occupy fixed positions or have k e d sizes on the screens. This is useful for tutors who intend to conduct the main part of their work with one type of u d t y only, say the terminal emulator, and to use the whole of the screen space for this.

The functions available from the second row of push-buttons are described in Table 3.

The thd field, the upper list window, can receive courseware items for selection, as discussed, or it can display longer-term information. For example, it can hold the list of all participating student names, their workstation names, and whether or not they are enabled to use the electronic blackboard.

The final field, the lower dormation window, receives all status and error messages, to keep the tutor informed, e.g. if a student is withdrawing from a session.

Student intetfare This program replaces the tutor interface on the

student screens, i.e. its window is 6xed in the bottom- right corner and is depicted in Fig. 46. It was designed to be very simple and intuitive in operation. Apart from the Quit menu item, only Register and De-reg menu items are included in its upper field. The student can select a named tutor, and ifthis tutor is running the tutor interface program, the received request d be echoed back to the student’s workstation. Ifthe echo is accurately matched, the successful registration is confirmed in the lower dormation window, and a title bar is drawn across the top of the student’s screen. This signals the student that the full screen is shortly to be tiled with windows from the tutor. The tutor’s machine is then ‘hosted’, which enables access by the tutor to the student’s screen. Also, the RPRSH (reksh) push-

I

Fig. 4 (a) The tutor interface window; (6) the student interface window

button (second field) is armed i d highhated. This can be selected if the student’s screen becomes ‘smudged’ at any time. The refresh action is actually initiated by the tutor, so that accidental or multiple requests can be ignored. Thus, the student interface is simple and uncluttered. At various times during the development of this interface, many other features have been tested; for example, menu items to acquire example material €mm the tutor’s directory space. It is planned to reincorporate such features progressively as their real utility is established.

A student can be part of only one class at a time, for obvious reasons, but can deregister and select an alternative tutor, who must be running another class concurrently on a different node and in a Merent place.

If ‘De-Reg’ is selected, the interface is left on-screen, whereas ‘quitting’ signals a deregister before restoring the student’s workstation to its initial state.

In order to achieve all the above, the student interface transmits account name, personal name and workstation node name to the tutor. All of this takes place automatically, h m any networked workstation in the domain. On deregistering, all multicast windows h m the tutor are erased, and the tutor’s workstation is ‘unhosted’. The tutor becomes aware of a de-


68

registration because all references to the student on the tutor’s screen are masked. As ducussed, this takes place quite automatically and causes, at worst, a barely perceptible delay to the other activities in the electronic classroom. Again t h ~ s would appear to be a fairly simple requirement, but in practice took sigdicant programming effort to make it work acceptably.

Pointer slaving In order for participants to accurately

indicate spec& locations on all the screens, a ‘pointer’ symbol whose position can be accurately controlled is required on the screens.

The method employed to acheve ths Fig. 5 The simplified tutor interface

consists of drawing on all the screens a small window which contains the name of the participant who lact ‘selected’ it. The tutor controls which student(s) can position this pointer window, and it is shown in the same position in Fig. 46 and Fig. 5 (the simplified tutor interface, which is discussed later). The pointer can he dragged to any position on the screens, as it is always visible unless turned off by the tutor.

Softwaresngineering the electronic classroom

This project was developed in a university environment and the soh-engineer ing fiamavork was inevi- tably a judicious mixture of exploratory programming, protowing and incremental development, not forgetting signhcant re-use. The author was learning many of the more advanced aspects of X-MOTIF and UNIX along the way, and this approach was therefore inevitable. The separation of this project into distinct programs greatly facilitated the incremental sofiware development approach, which often mirrors the electronic classroom in operation. There was no real possibility of all the constituent programs being developed h m scratch, nor was it a sensible approach.

Electronic blackboard and protocol multiplexer development Clearly, a means of selectively multicasting existing

applications to the registered class was required. The X-Window system, being based on the client-server model, is intrinsically suited to this purpose, but it is not easily achievable in practice.

With this starting point, there are two technical approaches available to realise this requirement, each with its own advantages and disadvantages. The first is so-called ‘centralised architecture’, and the alternative, ‘replicated architecture’. More details of the relevant issues are covered in References 3 and 13, but the problems for an electronic classroom are fortunately only a subset of those in general computer-supported co-operative working. In the case of an electronic classroom as defined here. the tutor remains for all

intents and purposes in control, and the student participants remain in sensible contact with the tutor, i.e. within a single room or teaching laboratory The somewhat balancing advantages of the two approaches make it difficult to identlfy the best compromise, as neither is ideal. For example, with replicated arch- tectures, where a separate instance of an application runs on each workstation, the system performance in terms of response speed is potentially better, because of lower network &c: output is generated locally But t h is unhkely to be a problem in a single laboratory Potentially the best reason for using the replicated architecture, however, is that many of the problems associated with a heterogeneous arrangement of nodes of workstations are solved each local &splay is already matched to the local processor. However, the not inconsiderable problem of synchronisation of these separate processes remains. Replication therefore means that ‘collaboration-aware’ application code to run on all the Merent hardware must exist, and this may only be practically achievable for certain types of application. With the c e n d s e d approach, only one copy of the application to be shared need be adahle , for the tutor machine. Problems can still arise, however, since issues such as Mering &play hardware can cause differences in window appearance, and network delays can be disconcerting. Provided that simple applications using limited colour and sindar workstations are available, and that some limitations on student screens in accepting fixed-size windows are acceptable, this is generally the simplest approach.

This project used two different centrahsed architecture applications and its success depended critically on a variety of facilities provided by Xhb, X-MOTIF, C and UNIX system calls. A popular well structured X-protocol multiplexer called ‘XMX’ was modified to improve its robustness in the face of untimely exits by students from a teaching session, and to cope with graceful withdrawals as well. Also, a public-domain shared drawing tool called ‘WSCRAWL’ was industriahed for the same reasons as above, but also its ‘floor policy’ had to be mod6ed by providing differentiated menus for the tutor and


69

students. This modlfied shared drawing tool consti- tuted the electronic blackboard for the system and was a major devclopment in itself. Modlfying the existing X-protocol multiplexer and shared drawing tool for robustness was not a trivial task, and of course depended critically on the source code being available with some (very limited) documentation.

Tutor and student inteface sojwarc dcvelopmcnt Unllke the above, these two programs had to be

developed from nothing. The overridlng aim was to provide intuitive and reliable operation, especially for the student.

The user interfaces are based on X-MOTIF widgets (software user-interface components), as these are conmionly available on UNIX systenls.

Clearly, the tutor interface is much more complex, and many subwindow layouts and functions were developed and partially evaluated. This is an ongoing exercise. AU communication with the studcnt workstations is

routed through t h s program, and various methods to implement the registration feature were tested. In particular, there were unacceptable delays caused by X-MOTIF work procedures and application time- outs“, which were mainly evident on the electronic blackboard. The method finally adopted, and one that is reasonably portable, was the use of asynchronous input/output. This involves an interrupt using a UNIX ‘signal‘, in conjunction with an application time-out, so that the X-protocol sequence is not corrupted. Ths method is ideal, as it allows the vital requirement of continuous listening to be implemented.

Unlike the v a t majority of applications based on widgets, where style-guides dictate that users must be able to resize and reposition windows, this application must give virtually all control to another user: the tutor. This is consistent with a student either being ‘in’ or ‘out’ ofa session. Therefore, the windows were created as ‘override shells’, and they cannot be moved or resized by any window manager running on the student workstation. However, in common with all X-Window applications, both interfaces can run acceptably, without the presence of any configuration file.

The tutor interface software also has to provide communication channels to the electronic blackboard and X-protocol multiplexer on the tutor’s workstation, so that when a student deregisters, these separate programs are informed, to remove any window they are responsible for on the student’s screen and to ensure that their workstations receive no subsequent messages.

When a student switches a machine off without properly deregistering, the potential to lock-up applications on the tutor’s workttation exists. Interrupt procedures therefore have to detect ths condltion, dxover the identity of the errant node, and make any necessary corrections to the current registration list. It was in these areas where most of the software developnient work occurred.

Some experiences in using the system

An early trial with the u n m o a e d shared drawing tool in a real teaching laboratory demonstrated in no uncertain terms that modern students are quite rightly unforgiving of inadequate technology: when one of the group switched off his workstation, a class was unceremoniously terminated! It was thus decided fairly early on that robustness, responsiveness and at least some benefits for the students over and above those avadable in a conventional lecture had to be demonstrated. This was necessary notwithstanding the fact that the development is primarily a tutor aid.

With this problem solved, students responded positively to using the electronic blackboard. From the tutor’s point ofview, the ability to put selected students on-the-spot by passing the chalk proved a very effective way of monitoring and maintaining attention. It proved particularly beneficial for a forgetll lecturer to have an on-screen record of the students’ names, autoniatically extracted from a system datahase, and this was received positively by the class. Simple psychology such as ths should never be underestimated.

The original software was developed and tested on ‘DECstation 5000’ and ‘3100’ workstations running the ‘ULTRIX operating system. This nonetheless conttituted a homogeneous environment of computers. It was found that network delays could become unacceptable if more than about four students were attempting to write to the electronic blackboard at one time. However, this was not perceived to be a major problem, as it does not constitute good pedagogy to have more than one person ‘&ng’ at one time!

For more creative group workmg, where several participants need concurrent access, a hgher performance host for the ‘tutor’ at least is required.

Subsequent testing of the electronic classroom system was conducted across a mixed or heterogeneous environment of ‘DECstation’ and ‘DEC ALPHA’ machines, the latter running the ‘OSF 2.0’ operating system.

Only a few minor changes to the s o h had to be made for successful operation, and these were due to poor programming practice in the original source, which does tend to creep in when the ‘C’ programming language is used in an experimental project.

The only remaimng problems were associated with the well known limitations of the X-protocol multiplexer in dealing with colour. By h t i n g the choices to one background and one foreground colour, the problem largely &appeared. This was perfectly acceptable for the utilities in use in the electronic classroom. The electronic blackboard, whch is based on a different software architecture, ported with no changes.

Some problems of response speed remained, even with the faster host for the tutor, codrming the suspicion that the network was responsible for most of the delays. This does suggest that, until faster networks


70

are commonly available, the h t a t i o n s for group worlung with this type of system remain very lirmted. In thls connection, integrated services digital networks, whose usage is now expanding, would provide a faster and essentially deterministic response.

Following successful testing, three reasonably computer-literate tutors d be using the system in the current academic year to teach computer-related topics, but they will be provided with a simplified tutor interface, shown in Fig. 5. The new interface also provides for any window, except the tutor and student interfaces, to be positioned anywhere on the screens. UNLOCK replaces SOCKT, POINTER replaces CUR, and REFRESH replaces RFRSH in the old tutor interface. When a utihty menu item is selected, the tutor has the option of where to place the corresponding utility.

A class registration list is held in a temporary file in the tutor’s &rectory space in the event of exceptional loss ofthe tutor interface, but this has never been used. It would enable a h t e d recovery, in that the existing class would not need to reregister, but all state information is lost. Although there are possibilities for saving the state, the programming effort could not be jusdfied for this application.

As soon as the electronic classroom had proved reliable and useful, the student interface was incorporated as an application selectable fiom the window manager root window menu, and therefore became avadable across the university domain. The putative benefit ofthis is a small time-saving in running up the application for the students. However, this was greatly exceeded by the publicity factor within the university, including a perception of the development as a generally useful tool.

A set of five named tutors is built into the system sofware, and each of these tutors can run concurrent classes. However, there is no practical limit on this number and moacations are being investigated to enable any user with a system account to pass their name as a command-line argument, so that it is built in to the Register menu of the student interface.

As students increasingly work on computer-based information, the facdity of being able to seandessly continue work on their own, on the same machne as the one on whch they are being instructed, is proving to be a valuable and popular feature.

Conclusions

The basic electronic classroom as described above has been completed and a full evaluation is underway By h t i n g the functionality to a basic level and thereby e h n a t i n g any dependence on ‘special’ or better, uncommon hardware, wider usage should be encouraged. The need for robustness was established early on, and it is expected that h s feature will assume even greater signhcance for the nonspeciahst tutors.

Any further developments in extendmg this electronic classroom may well be at the cost of portability, especially if multimedia hardware is

required, but this functionahty could be added as a ‘bolt-on’ facility, just controlled from the electronic classroom rather than integrated into it. In this way, the system may have a longer lifetime than ifthese powcrfiil educational tools were just ignorcd.

Acknowledgments

The author would like to acknowledge support from systems staff at the Cran6cld University Computer Centre, who provided programming support and campus-wide access to the electronic classmorn.

The electronic blackboard software is based on Version 1.0 of WSCRAWL, by Brian Wilson. The protocol multiplexer used is XMX Version 1 .O, written by John Bazk Both packages are now being, or have been, updated and are freely available over the niternet.

References

1 DAVID, A.: ‘The electronic blackhoard: potentid for developing world’s education’, 4 Edirc. ‘?hdinol. Sysl., 1983-84, 12, ( I ) , pp.8594

2 CREWS, E; ‘Instruction: an unfulfilled pmmisc of expcrt system technology’, Eng. Syst. Driign G Analysis, ASME 1992, PD-Vol-47-4.4, pp.257-263

3 AHUJA, S., et al.: ’A comparison of application sharing mechanisms in real-time desktop conferencing systcms’, Commun. ACM, 1990, 33, (5), pp.23&248

4 JOSELYN, L.: ‘Standards delay inhibits niultlmedia‘s potential’, New Elecrronirs, Ssptcmber 19 93, pp. 14-1 5

5 HOSHI, T., ef al.: ‘Broadband ISDN multimedia workstations and group tele-workmg systems’, Hitaclii Review, 1991, 40, (3), pp.217-222

6 BAUDEL, T., et al.: ‘CHARADE: remote control of objects using free-hand gestures’, Corrimrrri. AC.ZI, July 1993,36, (7), pp.28-35

7 UALDESCHWIELER, J., et al.: ‘A survcy of X-protocol multiplexers’, Cornput. Comm~m. Rev.. April 1993, 23, (2). pp. 16-24

8 H D L Y D. W: ‘The electronic classroom’. Prnc. 1‘191 C o d . ASEE, Vol. 2, New Orleans, pp.1485-1487

9 UEASLEY, N.: ‘X-Motif interfncc to CBT courseware for computer programming’. MSc Thesis, Cranfield University, 1993

10 RAYMOND, J., et al.: ‘Software tools for coniputcr aidcd lecturing’, IEEE Zatir. Educ., February 1991, 37, ( I ) , pp.23-29

11 HUME, A.: ‘A CBT package for the “C” programming language’. MSc Thesis, Cranfield Univer\ity, I992

12 STLJBBS, G.: ‘Development of a CBT aid for computer programming with X-Motif? MSc Thesis, Cranficld University, 1993

13 LAUWERS, J,, el al.: ‘Replicated architectures for hared window systems: a critique’, Cornmurz. ACM 1990.33, (j), pp.249-260

14 HELLER, D.: ‘Motif prograninkg manual’, Vol. 6, O’Reilly and Associates Inc., 1991, ISBN 0-9371 75-70-6

D IEE: 1995

Dr. Shaw is with the School of lndustrlal and Manufacturing Science, Craiifield University, Cranficld, Bedford MK43 OAL, UK. He is an IEE Member.


71

Development of an electronic classroom: the promise, the possibilities and the practicalities

Documents

Transcript of Development of an electronic classroom: the promise, the possibilities and the practicalities