An interesting experiment in distance-independent education was launched in January 1999.Using a cluster of commercially available, Web-based technologies, a graduate level course entitled:  "Globalization and the Information Society" was delivered, simultaneously, to 35 students in 3 different locations: Ann Arbor, MI, Washington, DC, and Johannesburg, South Africa. Each Tuesday, students connected to a virtual auditorium in order to listen to a real-time lecture, interact with the professor and other students, ask questions, and make presentations to the class. During the rest of the week students engaged in a variety of asynchronous activities in their multinational teams: holding online discussions,  collaboratively creating reports and documents, exchanging project-related files. The article below gives a detailed account of this experiment.

Background

It would have been hard not to notice the opportunity that manifested itself in the two of us contributing the essential elements for making this vision a feasible one: energy, enthusiasm, willingness to take risks, flexibility, technological expertise. Moreover, Dr. Cogburn, with his various engagements and offices in multiple parts of the world (Cairo, Johannesburg, Washington, and now considering a guest faculty appointment at the School of Information in Ann Arbor), was already trying to achieve in the physical world what had been quite common in the virtual one: being present in multiple locations at the same time.., so it was hardly surprising that he embraced the challenge with much more hope than apprehension. Our discussion of tools that might help us reach particular objectives probably contributed to this hope.

We agreed to use a cluster of tools rather than a single, integrated package. There were two reasons for this decision:

1. Very few integrated packages would have all the capabilities we wanted to see included in the planned environment, and those that had, were not nearly as robust and powerful as a set consisting of several different tools, each one picked from among the best in its category.
2. The Alliance for Community Technology's servers were already hosting a number of "cutting edge" tools, so all that was required was finding the most suitable ones, upgrading them (if possible), and buying sufficient number of licenses (if needed).

1. School of International Service at the American University in Washington, DC
2. School of Information at the University of Michigan in Ann Arbor, Michigan
3. School of Public and Development Management at the University of the Witwatersrand  in Johannesburg, South Africa

Preparations

First and foremost: making sure that long-distance voice communication via the Internet was indeed feasible. The first few tests we ran exceeded our expectations: Derrick was able to connect from Geneva, where he was attending an international conference, with good audio and ample interactivity, via his decidedly not state-of-the-art laptop equipped with only a 33.6K modem. Although the audio was delayed by 10-15 seconds, the sound quality was surprisingly good, i.e. approximately that of an aging pay phone, and the delay caused problems only when trying to have a two-way exchange; in the lecture mode it was not noticeable at all.  Our optimism was further boosted by a small crowd of onlookers - apparently intrigued by someone having a lively conversation with his laptop - who gathered around Derrick in the foyer of the conference center, where this test was taking place... Derrick invited several of them to give it a try and the test evolved into a multinational exchange of greetings between Geneva, Switzerland, and Ann Arbor, USA...

Our subsequent tests involving computers in Johannesburg and Washington were also promising, although the sound coming from South Africa was of significantly lower quality than in our Geneva experiment (but still intelligible). These tests, however, were usually one-on-one affairs, and did not give us sufficient insight into the conditions of the multi-user environment we were planning to set up. Unfortunately, we did not have the resources to simulate a 30-user Placeware session, especially with all 3 locations involved; neither Washington nor Johannesburg could come up with sufficient numbers of properly configured computers and people familiar with Placeware technology to participate in such a test any time soon. However, I was not too concerned about it and figured out that even a much smaller size audience would provide us with enough reassurance for the Winter launch. And so a 6-client test between Ann Arbor and Washington was performed and went according to expectations.

Unfortunately, we were not able to do a similar test with our South African counterparts. This was a bit worrisome, as some of our earlier, small  tests have failed, either due to firewall interference or mysterious hardware incompatibilities that prevented the transfer of audio. We also weren't sure which of the computer labs at the University of the Witwatersrand would be made available for the students in the course, and whether the computers in there would be configured properly and on time.

Technology: Servers

• Machine 1 (donated by Intel, built by Dell):
• Dual-processor Pentium II at 266 MHz
• Operating System: Windows NT 4.0 Server with Service Pack 3
• RAM: 128 MB
• Hard disk: 4GB
• Hosts: Placeware Conference Center, O'Reilly WebBoard, Internet Relay Chat, Netscape FastTrack, Netscape Directory, Netscape Calendar
• Machine 2 (donated by Intel, built by Dell):
• Dual-processor Pentium II at 333 MHz
• Windows NT 4.0 Server with Service Pack 3
• RAM: 128 MB
• Hard disk: 4GB
• Hosts: Xerox DocuShare, Microsoft Internet Information Server

Placeware Conference Sever 3.0 was used for delivering weekly lectures in real-time (with Internet audio and PowerPoint slides, live Web pages as visuals); student presentations to the class; real-time communication within teams; voting; comments and questions from the audience. Cost of license for this server can vary greatly, depending on the size and type of license needed (with or without Internet audio),  and individual negotiations with the vendor; approximately: $500 per "seat" (i.e. concurrent user) with audio capability. The most sophisticated and also the most expensive tool in our lineup. The initial high cost of this server can be somewhat offset by the fact that a single "seat" does not mean one login name and password: in fact, thousands of users can have accounts and participate in sessions on a 40-user server, as long as the number of client connections at any one time does not exceed 40.

Netscape FastTrack 3.01 provided Web access to course materials: syllabus, reading list, list of students, contact information, links to relevant Web resources. It also constituted the necessary ingredient of our Placeware installation, which requires the presence of a Web (HTTP) server. The list price of FastTrack is $295 for unlimited use, but educational institutions can obtain it at substantial discounts or even free.

O'Reilly WebBoard 3.5 served as a venue for online discussions (threaded), listserv activity, group announcements, brainstorming, and exchange of files (through attachments), while its built-in HTML chat added a synchronous (real-time) component. Later in the course we supplemented it with a more robust, Java-based IRC (Internet Relay Chat) server, which came as a free add-on to WebBoard. Quite possibly the best tool in its class - discussion group server - at a very reasonable price: $699 for unlimited use.

Xerox DocuShare 1.5 was used as a document management system and a virtual "teamspace" that supported submitting and retrieval of assignments, group calendars, collaborative (asynchronous) editing of documents, announcements. The beauty and power of this tool lies in the fact that a standard browser is all that's required to take full advantage of those capabilities... This comes at a cost of $695 (server and 25 user accounts) or $995 (server and 50 user accounts). Each additional 25 user accounts: $495. (15% discount is available to educational institutions.)

Technology: Clients

Therefore, in our selection of tools for the course, we tried to avoid those that required anything other than a standard browser (Microsoft Internet Explorer or Netscape Communicator) of 4.x vintage or newer, which could be downloaded for free from the Web. Even plugins and helper applications were frowned upon. With these self-imposed restrictions we were able to build an environment where a student at any location, in front of any computer equipped with at least a 28.8 kbps connection and a relatively recent Web browser, could:

• Read messages posted by other students on a discussion board and respond to them
• Submit an assignment to the instructor
• Download a paper or presentation being worked on by his group, contribute changes/additions, and upload it back
• Check the date and time of a scheduled, online meeting of his group
• Access recorded lectures
• Participate in real-time chat sessions with other students
• Check reading assignments and access some of the required materials
• Approach the instructor or the assistants with questions and comments

Another plugin is required for preparing and converting Microsoft PowerPoint slides for use as visuals in a Placeware session, but it is not necessary for every student to have it installed; if needed, the conversion can be easily done by the teacher or an assistant. Finally, a RealMedia plugin would enable the students to listen to a recorded session as a single audio stream with automatically advancing slides, but, as an alternative, each session's audio was recorded in non-streaming (AU) format, playback of which is a standard feature of every browser.

An important benefit of making all tools in our set rely on a Web browser as their only or, at least, primary client, were the relatively small demands placed on the client hardware. The course could have been successfully run, had the client machines consisted only of 133 MHz Pentium PCs running Windows 95, 98, or NT 4.0 and outfitted with 32 MB of RAM, sound card, speakers (or headphones), and a microphone. In reality, all our students had access to computers with significantly better specifications, ranging from 233 MHz Celeron-based machines to those equipped with 266 MHz Pentium II.

Internet access for bandwidth-intensive Placeware sessions was provided from LAN-connected computer labs with T1 (or better) lines, although on some occasions the instructor, individual students, and assistants would connect - with varying degrees of success - via 56 kbps modems. Other tools (WebBoard, DocuShare, etc.) were decidedly less demanding, requiring only 28.8 kbps connections.

Application

Most lectures consisted of the following eight elements:

1. Real-time broadcast of the instructor's talk via the Internet to all connected Placeware clients
2. Microsoft PowerPoint slides converted to the Placeware-compatible GIF images
3. Live Web pages as illustrations of certain points in the talk
4. Instant feedback given to the presenter by students changing the colors of their "seats"
5. Voting with the aid of multiple-choice, interactive slides
6. Blank slides serving as virtual chalkboard, on which the lecturer would type ad-hoc comments and questions
7. Typed questions submitted by the students to the presenter
8. "Giving the floor", whereupon a student's spoken comments could be heard by the entire connected audience

At the end of most lectures students were given time to converse with others in their virtual rows and discuss their group assignments, distribute responsibilities, or setup a meeting time. Team work constituted a very important element of this course, whose aim was not only to teach students about globalization but to allow them to experience working in a global environment first hand. Not surprisingly, most tools deployed in this course were selected for their ability to support group work. And support they did, for example: 11 conferences (discussion topics) were established on our WebBoard:

• a private conference for each of the 5 teams (or Global Syndicates, as they were called in the course), accessible only to the team's members, the instructor, and assistants
• 4 course-wide conferences that accepted students' personal introductions (with optional photographs), current news relevant to the course's topic, questions and answers regarding all aspects of the course (technology, assignments, subject matter, etc.), and suggestions on how to improve it.
• 1 private conference for those responsible for the technological side of the course
• 1 private conference for the team of researchers studying the experiment

A folder for the course was created on the DocuShare server and access to it restricted to those associated with the course. (It remained invisible to all other visitors to the server.) It became a container for dozens of nested folders and files, some accessible to all participants, while some open only to specific teams or subgroups. This is where the teams and the individual students uploaded their assignments, either to make them available to other team members, who could then contribute changes and additions, or to submit them to the instructor for grading. Although similar functionality could be achieved with the use of file attachments - either to e-mail messages or WebBoard postings - DocuShare provided enough value-added features to make its deployment worthwhile:

• All versions of a document were preserved under a single entry
• Common document formats (MS Word, MS PowerPoint, Word Perfect, etc.) were converted, upon request, to HTML by the server, for instant viewing in a browser window. Although they could not be edited in this state, this was a significant time-saver for users who only wanted to read the documents and thus avoided downloading them and opening their native applications.
• Documents were placed into a meaningful, familiar hierarchy of nested folders
• Files (documents) could easily be relocated between folders, their ownership changed, and access to them determined on a file- rather than collection-level
• New folders could be created by any student, whether for group or individual use

Challenges

Not surprisingly, the crown jewel of our tool set - Placeware Conference Center - was the source of our biggest concern. IP-based conferencing, especially involving audio or video communication, is hardly a mature technology. Being bandwidth-intensive, it is highly sensitive to network conditions, most of which are beyond any single webmaster's or LAN administrator's control. It has difficulty negotiating with firewalls (although its capabilities in this area are quickly improving). Its hardware requirements are often quite high and involve the use of non-standard peripherals such as video cameras, good quality microphones, headphones, and specific sound cards. Hardware and software incompatibilities tend to make the experience of setting up and using Web conferencing clients a rather frustrating one. So much so, that some of the vendors of Web conferencing software - including Placeware, Inc. - gradually shied away from advertising the IP-audio capabilities of their solutions, to the point of practically hiding those capabilities from potential customers, and instead promoting audio via phone conferencing.

Given the number of variables that can make or break a conferencing session, having control over as many of them as possible becomes truly crucial. In an ideal world, one should be able to allow students to connect to a virtual auditorium from a variety of locations, making it a convenient alternative to a trip to campus; after all, this is what "distance-independent, online learning" is all about. Unfortunately, with the current state of technology, this would mean spending more time helping students setup their computers and troubleshooting a plethora of problems than actually teaching... That's why we decided to go with a much more controlled environment of three computer labs, one at each of the participating schools. Our basic assumption was that once the computers in those labs were outfitted with necessary software and peripherals, their performance would stay consistent and predictable.

Alas, this assumption was proven false. For a number of reasons, including lack of sufficient funding, overcommitted technical support staff, and delays in administrative decision-making, the labs were not fully prepared when the semester started. Some computers were waiting for ordered headsets to arrive; some were not adequately tested for firewall interference; some did not have the necessary plugins installed. On top of that, huge interest in this course at American University prompted us to admit more students than initially planned and thus purchase additional licenses for some of the tools to be used in the course; the needed licenses for Placeware Conference Center did not reach us on time. In effect, the first two lecture sessions were an exercise in creative workarounds: one computer in each lab was connected to a set of speakers, so that students still without headphones could listen to the instructor, and an image of the audience console was projected onto a screen in front of the lab, so that students unable to connect due to insufficient number of licenses could see the visual part of the lecture as well.

The firewall in place at the University of the Witwatersrand was also a source of grief. At one point it simply collapsed without warning, cutting the Placeware session off. To make matters worse, all the technical support people capable of restoring the firewall had left for the day... This time sheer luck rescued us from a very tight spot: Derrick, who happened to be lecturing that day from this very lab, was able to use his laptop to connect to an ISP outside of the fatal firewall and continue broadcasting to the labs in Washington and Ann Arbor, while students in Johannesburg, who experienced him "live", did not really miss a whole lot by not having Internet connectivity at that time.

Bandwidth fluctuations constituted yet another significant challenge. Despite the fact that the real-time sessions were held on Tuesdays and always at the same time of day, network conditions would differ considerably at times, affecting the quality of the audio by introducing delays, choppiness, and "static", sometimes to the point of making it unintelligible. On those occasions we would resort to using a speaker set rather than having students listen to the lecture on their headphones and it usually did make enough of a difference. Twice, however, we were forced to use a speakerphone to deliver the audio portion to a lab affected by a drop in available bandwidth, and at one time the solution we came up with was quite creative: Derrick's voice was transferred, via telephone, from the lab he was in, to a speakerphone in the second lab, where it was captured by a nearby microphone and relayed to the third lab, this time via the Placeware server.

In the middle of the semester, Netscape released a fairly minor update to its Communicator suite, whose browser was our browser of choice for the Placeware sessions. This update, which fixed a number of bugs discovered since the last release, was promptly installed on all the computers in the School of Information. However, as it is often the case with software updates, while fixing a number of known bugs, they tend to introduce a slew of new ones. To our dismay, this update had the unfortunate side-effect of making the Placeware application unusable. Of course, this was a relatively small problems, easily dealt with by bringing back the older version of Communicator, but I decided to mention it here as an example of totally unforeseeable developments that may appear out of the blue and wreck instant havoc, forcing us to react quickly to a new set of circumstances.

Interestingly enough, Placeware turned out to be much less of a problem that we had feared, possibly because our fears forced us to predict what could go wrong and devise countermeasures. Instead, it was the textual chat, an infinitely simpler tool with much longer track record, that failed us completely. The troubles started with the abysmal performance of the WebBoard-native HTML chat, which had the habit of slowing down to an unbearable crawl as soon as the number of participants exceeded... three. Prodded by students' complaints, I switched to a more robust Internet Relay Chat server and a Java-based chat client. The performance improved dramatically, but now the firewalls in place in South Africa prevented students there from participating in chat sessions. To add insult to injury, the Java foundations of the client caused it to behave somewhat unpredictably, especially on Macintosh computers. One of the better ways out of this no-win situation was to use the chat feature in the Placeware console instead, and, indeed, students often resorted to this method of holding online group meetings.

I do not have hard data to confirm my suspicion, but my conversations with several students seem to point to the patchwork nature of the learning environment as a source of considerable frustration. Although the various tools deployed in the course used Web browsers as their only (or primary) clients, they remained different tools, with more or less varying interfaces, separate user databases, and serving different purposes. Aside from the minor nuissance of having to log in separately to each of these tools - somewhat mitigated by our efforts to keep user IDs and passwords the same - their functions were initially somewhat confusing to students, especially those, who had little experience with Internet technologies beyond basic Web surfing and e-mail. The distinction between WebBoard (discussion tool with file attachment capability) and DocuShare (document management system), was particularly perplexing; some students simply chose to stick with the classic method, i.e.  using e-mail for both discussion and file exchange, thus shifting the burden of archiving and storing on the instructor and assistants.

For several reasons, including - but not limited to - the lack of sufficient technological and human resources, our South African students found themselves struggling to keep up with their colleagues in the United States. At the start of the semester, the computers in the lab designated for the course were not prepared to meet the requirements of the Placeware sessions. (With the grace-saving exception of a single workstation, around which the students would gather.) No training was offered and the technical support was spotty at best: for the first few sessions it was not unusual to start the lecture with the Johannesburg node still off line and the students frantically looking for the one person capable of troubleshooting Placeware problems, who, incidentally, was in high demand in other areas as well. The firewall in place at Wits (short for Witwatersrand) University and maintained by a unit separate from the School of Public and Development Management, contributed heavily to the problems, culminating in the previously mentioned collapse, which nearly took one lecture off the schedule.  A few weeks into the course, Derrick's personal intervention and soliciting the help of a new, private ISP in Johannesburg, which let us use its state-of-the-art and firewall-free lab, turned the situation around and made the rest of the semester much more satisfying for our students there.

It is worth mentioning that these problems are not South African problems - they are truly universal and can pop up anywhere, including the United States. However, there are identifiable challenges that are specific to environments that spread across geographic regions, political borders, cultures, time zones, etc. In our case, the most important of those was the 7 hour time difference between our two American universities and Wits in Johannesburg, which limited our students' ability to get together without it being too early in the day for some or too late for others. Matters were made worse, when, towards the end of the semester, Michigan and D.C. switched to the Daylight Savings Time, decreasing the difference to 6 hours. This relatively small shift had significant implications for our South African students, many of whom held full-time jobs and now were forced to cut their Tuesday workdays by an hour to make it to the lecture on time. (Changing the time of the lecture was considered but rejected as impractical.)
 

Recipe for success

The importance of sufficient testing cannot be overemphasized and the need for it increases as we climb the ladder of complexity and/or novelty. Unfortunately, it is often impossible to recreate the exact conditions under which the system will eventually work "for real", but even a limited test is better than no test at all, as it can give us very valuable information about the system's performance and help uncover potential vulnerabilities, especially when the tests are repeated over and over.

But why repeat tests? Isn't it just a waste of time? Certainly not and there are several good reasons for doing it, such as changing network conditions, variations in the load placed on the server, different skill levels among testers, modifications in the client environment (e.g. software installations), etc. Before the "official" launch of the course we ran tests involving various: locations (Geneva, Ann Arbor, Cairo, Johannesburg, Washington), computers (from laptops, to low-end desktops, to high performance workstations), peripherals (several types of headphones and microphones), and human testers. Do I need to mention that even that did not wholly protect us from surprises?

Murphy's Law stating that: "If something can go wrong, it will" applies to all kinds of human endeavors, but those involving computer technology seem to have a disproportionately large share of its effects. (Or is it only my subjective misperception?) No matter how many tests have been conducted and how confident we feel  about our hardware and software performing as expected, it is never a good idea to be without a contingency plan. Yes, schlepping the speakerphone to the lab before every lecture can become a minor pain, especially when there never seem to be any use for it, but the one occasion when having it there will save the session from a total disaster will more than pay for all the carrying back and forth. And believe me, the very day when you decide to slack off a little and do without it will be the one when you'll need it the most...

Luckily, most technological mishaps can be predicted quite easily - I wish I could say that about human errors - so having a few contingency plans for several possible scenarios does not require a crystal ball or even a supercomputer simulation, and most solutions are decidedly unsophisticated, e.g.

• establishing a procedure that the assistants could follow when faced with a total lack of connectivity, so as not to waste valuable class time waiting for directions from the instructor
• using e-mail as the document delivery mechanism to substitute for DocuShare
• using e-mail as a discussion tool instead of WebBoard
• faxing assignments
• relying on a long distance phone call to make up for failing IP audio

On those relatively rare occasions when the unpredictable happens, a healthy dose of creativity and resourcefulness will not hurt. I sometimes joke that it may be helpful to have someone from Eastern Europe  on staff, as the decades of fluctuating shortages of everything have forced people there to resort to do without or with very little in situations when citizens of more affluent countries would feel quite helpless. (Russian cosmonauts on board of the "Mir" space station have for years improvised various repairs themselves and kept their mission control in the dark about the actual state of the spacecraft for fear of losing substantial bonuses.) But all jokes aside, being able to quickly switch from one technology to another, from one approach to a totally different one can be extremely valuable. Unfortunately, this ability tends to be inborn rather than acquired.

"Cutting edge" technologies are hardly ever cheap, as the cost of licensing our Placeware "seats" clearly illustrates. Spending several thousand dollars on software for a course may be less of an issue at some institutions of higher learning than at others, but it is always an issue. Therefore, having a good estimate of the costs involved, supported by a reasonable amount of research into alternatives, can provide quite an advantage, especially when one can also point at readily availabe, substantial funds to tap into. The good news is that the pool of alternative solutions keeps expanding at a dizzying pace; a little time spent investigating the current software market and a bit of skill in combining different tools into one package of complementary functionalities will almost certainly result in bringing the cost down.
 
 

Appendix A: Screenshots

• Presenter console
• Audience console with seating arrangement and feedback
• Audience console with chat
• Questions to the presenter

• Conferences
• Viewing threads and postings
• Composing new message
• Java chat

• Files and folders
• Adding new file
• Calendar (week view)

Appendix B: Links

• Lecture session in the SI DIAD lab (photo)
• Lecture session in the AU Hurst lab (photo)
• Recorded Placeware sessions
• Alliance for Community Technology
• School of Information, University of Michigan
• School of International Service, American University
• School of Public and Development Management, University of the Witwatersrand
• Placeware Conference Center
• O'Reilly WebBoard
• Xerox DocuShare
• Netscape FastTrack
• Derrick L. Cogburn, Ph.D.
• Vlad Wielbut