William W. WRIGHT Jr. <firstname.lastname@example.org>
International Telecomputing Consortium
Scott A. GUNN <email@example.com>
Massachusetts Institute of Technology
This paper describes some of the successes and failures of a global education project. The project that we discuss here is called Junior Summit 98, hosted by the Massachusetts Institute of Technology Media Lab. We want to make it clear that our comments are not based on an analysis of data. We are quite sure that professors and graduate students involved with this project will carry out a complete evaluation and present their findings when the online forum is complete.
What we learned about the infrastructure and content of an online event for education should, however, be valuable to those who might like to do something similar. Scott A. Gunn, who was technology director for the project, has written sections I and II. William W. Wright, Jr., who worked on the project as connectivity manager and manager of the online forum, has written sections III and IV.
Isao Okawa, chairman of SEGA Enterprises, Ltd., attended the G7 conference of world leaders in February 1995. Leaders from many countries gathered to talk about the Global Information Infrastructure (GII). Okawa felt that children should be involved in the discussion because today's children will be using the GII in the future. He decided to find out what children think about how the GII needs to be designed and how it can be used. In eight months, Okawa organized and hosted the first Junior Summit in Tokyo, Japan.
At the 1995 Tokyo event, 500 children from 12 countries participated in discussions about education, the environment, peace, and world communication. They communicated by computer -- in English -- for several months. Forty-one children from 12 nations attended the four-day face-to-face meeting in Tokyo, Japan. These children summarized the discussions of the online forum and presented their ideas to world leaders. For the children, it was a wonderful experience to have their voices heard. Indeed, the project was a success by almost any measure.
Nicholas Negroponte, director of the Massachusetts Institute of Technology (MIT) Media Laboratory, attended the Tokyo summit and was impressed. Negroponte and Okawa decided together that the Media Lab would host the 1998 summit. While a clear continuity was evident in the overall structure, several elements were quite different. Like the first summit, the Junior Summit was to consist of a six-month online forum and a face-to-face summit. The scope of the second summit was larger, however. Corporate sponsors and partners funded the project. Major corporate sponsors were Citicorp, Lego, and Swatch. Additional partners included Sybase, Real Networks, Kodak, Polaroid, Lyris Technologies, WorldPoint, Chatspace, Africa Online, and others.
The organizers wished to expand the forum to reach children around the globe. Diversity was essential. In addition to involving privileged children who were well versed in technology, the organizers hoped to involve the "have nots." In order to reach a large number of children, application forms were mailed to every UNESCO (United Nations Educational, Scientific & Cultural Organization) national office, every UNICEF (United Nations Children's Fund) national office, national ministries of education, many embassies, and several thousand middle and secondary schools. In addition, the staff sent e-mail postings to many relevant education and children's discussion lists. Application entries were accepted via e-mail, Web, and post. Children could write essays, poems, or submit artwork. The judges were looking for children with a unique idea, the passion to implement it, and the ability to articulate it.
From 9,000 applicants, Junior Summit 98 selected 3,300 children from 139 nations for participation. Based on the demographics of the accepted children, discussions took place in five languages: English, French, Spanish, Portuguese, and Chinese (Simplified). These languages covered virtually all accepted children.
The primary technical objective for the project was to make its content available to as many people as possible. In terms of the public website, this meant using HTML (hypertext markup language) that could be read by legacy browsers, as well as translating the content into many languages. The online forum had several criteria: First, we sought to make the content available to kids with low-bandwidth connections. This meant having all important content available by e-mail, as well as by Web. For those with Web access, we wanted lean pages, easy to download and able to display correctly on many browsers. Second, we wanted a private space so that children would be free to express themselves, without concern for adult eavesdroppers. Third, we wanted an easy-to-use but powerful system. Despite our best efforts to find an extant package that would serve our needs, we found it necessary to write custom software.
When it became clear that we would need to develop our own software, we considered two options. We could either write everything from scratch, or bind existing commercial products together. Because of constraints in time and resources, the latter choice was our best option. We began to spec out our design requirements and decide what our core requirements were. By late spring 1998, we had selected several commercial products for our use; we immediately began negotiation with vendors for donation or reduced cost.
William Wright addresses the content of the forum below, but we should briefly highlight design requirements here. The goal was to build a system with an e-mail core, so that those without Web access could participate fully. E-mail messages were displayed on the website, and responses could be made using a Web interface or a standard e-mail client.
We selected several commercial products:
The forum ran on six servers:
The Digital Unix machines (numbers 1 and 2 here) were 150 MHz Alpha processors with 128 MB RAM. Three of the Windows NT machines (numbers 3 to 5) were Dell servers, with dual Pentium II 400 MHz processors and 512 MB RAM; the last machine (number 6) was a Digital PC with a Pentium II 333 MHz processor and 128 MB RAM.
Essentially, the forum worked like this: Incoming mail messages were routed to the Lyris mailing list management software. Lyris handed them off to a Perl script, which requested translation into the appropriate languages and stored the original message and all translations in the database. The messages were then sent out to mailing lists, so that, for example, an English speaker would see an original Spanish message followed by a machine translation into English. We felt that it was important to emphasize the utility as well as the pitfalls of machine translation, so translations were always displayed beneath original texts. Participants could view original messages as well as translated messages on the website.
In normal performance situations, the full turnaround time for individual message processing was about 10 seconds. During this time, several things happened: the message was received by our mail server, translations were requested, the original message and all translations were stored in the back-end database, the message and its translations were sent out to the appropriate mail lists, and the message became available on the dynamically generated website.
Reliability was a concern, and we never fully reached the reliability levels that we wished to attain. There was a predictable shakedown period, lasting about a week into the forum, when things were touch-and-go. Users did things we hadn't predicted, and the system crashed frequently. In addition, we encountered obscure bugs with one of our commercial products, which could not run under the version of Solaris that we had selected. After considerable efforts to diagnose the problem, we finally did so, and decided to migrate to Windows NT for that product. Then our reliability improved. In the end, system uptime was over 95 percent.
Of course, problems in reliability were to be expected, since we were building a system unlike others that we had seen. Passing double-byte (Chinese) characters though systems designed for single-byte characters caused anomalous behaviors. The software engineering team worked close to 24 hours a day, 7 days a week during the first few weeks of the forum. After that, we used server monitoring software to notify us of problems, and someone on the team attended to the problem at hand.
Had we been blessed with more time and resources, we would have preferred to use more open-source software and fewer commercial products. Indeed, our original goal was to produce a modular system that other projects might fully reuse.
Scott Gunn has described the technology used in this project and has made comments about what he might do differently if we were to take on a project like this again. I had two roles in the project and will comment on those. My first job was to get computers out to those who were accepted -- and who had indicated on the Junior Summit application that they needed a computer in order to take part. I was also asked to direct the online forum from September 1 through late November. I will start with comments on the latter.
As we planned for the online forum, there was a healthy exchange of ideas that one will always find in a planning group in any academic setting. Of course everyone did not always agree. An important part of the online forum's structure that was accepted at an early stage was the use of online facilitators or moderators. But even this decision was not unanimous. Some of the planners felt that the use of moderators -- especially adult moderators -- might diminish the creativity of children. One strong argument for having moderators was put forward by those who managed the first Junior Summit in 1995. The 1995 event had fewer participants, yet those who managed it felt that more structure would have improved the project. The 1998 forum had 1,000 participants -- and some of the participants represented a team of children or a classroom. So there were sometimes over 3,000 children participating. How did we break into small groups? My experience with online education projects since the early 1980s taught me to have a moderator for every 8 to 25 participants. Funding constraints forced us to expand the size of the small groups for this project (we had around 40 participants in each small group) -- and we had to give each moderator two groups. A few of the moderators were MIT students who, because of course loads, took just one group each.
In the early phase of the project these groups were called "homerooms." Later, when participants moved to "topic areas" each moderator had responsibility for only one online discussion group. We hired 23 moderators who each made a commitment of around 15 hours a week. Most had experience working with online education projects. Annette Tonti, the project's executive producer, wisely made sure that we had some moderators who could speak either French, Spanish, Portuguese, or Chinese -- the four languages (other than English) that were most common.
Before the online forum started we mailed packets to moderators giving them the list of participants in their homeroom. A couple of weeks before the September 1 start date we also sent them a packet that helped them understand the history and goals of the project -- and presented some guidelines for moderators. An online mailing list for moderators was put in place.
A couple of months before the start of the online forum, Junior Summit staff assigned participants to homerooms (asynchronous online mailing lists also archived on the Web). Most participants in a homeroom spoke the same language and tended to be in the same region of the world. Of course if most of the participants in a homeroom spoke French, the moderator in charge of the group also spoke French. A few weeks into the project participants chose topics that they wanted to discuss and moved to what were called "topic areas." Participants suggested topic ideas in the first few weeks. A list of almost 60 topics was posted and participants voted on the ones they wanted. Twenty topic areas were set up and participants were assigned to their top choice (when possible).
Here is an outline of the schedule for the Junior Summit leading up to the meeting in Cambridge, Massachusetts:
Week What happened 1. 9/1 intro question: Tell everybody about yourself... 2. 9/7 intro question: Tell everybody about your community 3. 9/14 intro question: How are computers used?... 4. 9/21 begin to suggest topics 5. 9/28 select topic area; move to topic area 6. 10/5 topic area 7. 10/12 topic area (by 16th choose topic delegate) 8. 10/19 topic area 9. 10/26 topic area (finish draft of position paper) 10. 11/2 send position papers to another topic group for review 11. 11/9 revise position paper 12. 11/16 week of summit 13. 11/23 wrap-up from summit
Of course we gave participants more details than you see here. We tried to make it very clear what we wanted participants to accomplish each week. E-mail "broadcasts" to the online community went out in five languages each week and were also put on the forum.jrsummit.net website.
What lessons did we learn? While it worked fine to give moderators two rather large groups of 40 participants in the first few weeks (homerooms), this size was just too large when active discussions were under way (in topic areas). One topic area ended up with 45 participants. This number, as we anticipated earlier, was just too many. The traffic was too heavy and many were left out.
We also learned lessons about the time needed to shift between homerooms and topic areas. Since some of the participants were limited to a few hours of access each week, it was simply not possible to call for a vote (for topic area choices in this case) one day and have all participants respond right away. A more realistic transition time would have been a week or 10 days. For example, when we asked participants to give us their top three choices for topics -- such as "child labor" or "environmental issues" -- by September 28, some replies did not arrive until two weeks later.
We did anticipate this time lag, especially since the organizers of the Junior Summit emphasized the recruitment of participants from underserved countries, places with limited access. One father of a child in Nigeria, for example, said that he and his son would go to a community access center twice a week and put e-mail from homeroom and topic room discussions on a diskette. They would take this diskette to the father's office computer and prepare comments. There were other children who had daily access at a fast speed. Many of them were pushing for more real-time communication.
As manager of the online forum I felt that it was difficult to keep the project at the lowest common denominator (limited e-mail access) when kids in more developed countries were pushing to use the latest tools available and pushing for a faster pace. For example, many children and some of the adults involved wanted a real-time chat system early in the forum. We resisted, because it would have left many people out; time zones and expensive telecom charges conspired to make chat less feasible for kids in developing countries.
As I mentioned earlier, we made a couple of mistakes with traffic control. One topic room had 45 participants when it should have had half that number. Another problem was that outside time constraints forced us to make the migration from homerooms to topic areas happen too quickly. Finally, some suggested that the project might have done a better job of providing post-Summit support for the ideas that emerged from the Cambridge meeting.
But we also did many things right. Giving participants specific actions to take each week --actions that might take a couple of hours -- was the right thing to do. For example, as the schedule above shows, we asked participants to answer one question in week one, one in week two, and one in week three. Because some had limited access, this was the right pace during the start-up phase. Because many students were also in school and involved with other projects, they could not give much more time than this.
Letting those with "e-mail only" access take part in all activities put more pressure on the technical team in Cambridge, but it was the right thing to do. A participant from India contacted us and said that he did not have Web access, but was pleased that he was able to keep up with everything. When children voted on delegates to Cambridge, they chose a large number who had participated by e-mail only. Two girls from Niue, a small island in the Pacific, had only store-and-forward e-mail at their school (no Web access) yet they became key players and were chosen as topic room delegates.
Running the online forum was not my only job with this education project. My task in the summer leading up to the online forum was to get donated equipment to those who were selected to participate yet had no access. The Junior Summit '98 application stated that equipment would be provided for those who did not have it. MIT's Media Lab had acquired, at a discount price, 200 StarMax computers from Motorola, which had left the Mac clone business. Media Lab director Nicholas Negroponte generously made about a hundred of these available to those selected to be part of the project. We also got help from Internet service providers such as Africa Online.
By sending out a form requesting more information, I was able to determine which sites really needed equipment and which had checked the "I need a computer" box on the application merely hoping for a free upgrade from MIT.
I was able to come up with a low-cost shipping solution -- and we had a number of volunteers willing to help set up equipment at the 80 or so sites that needed hardware. I was not new at this since I had set up Internet-for-education projects in China and Vietnam and had started two projects in Africa (see http://itc.org). I was very much aware that the MacOS is not what most of the developing world is used to. But you don't look a gift horse in the mouth. The training provided by MIT volunteers (in setting up e-mail and using the Web where it made sense) was extremely valuable. Many of these sites might become community access centers in the future. Furthermore, the StarMax, while it is a Mac clone, uses a standard PC monitor and modem (also donated by the project). Places that wanted to upgrade to a more appropriate central processing unit had -- after the Junior Summit project -- a good monitor, modem, and introduction to e-mail and the Web.
We mentioned several "lessons learned" earlier in this presentation. If we shaped an online forum again we would make sure that the traffic in small discussion groups was more limited so that those with only a couple of hours of access each week could keep up. But much of what we did, such as being clear about action items each week, was about right. We were pleased that so many with only e-mail access could take part, but a few were just, as one teacher in Africa put it, "not in the game."
The shipment of computers to the developing world is something that I would not recommend to others who carry out projects like this. Of course there were benefits to the approach we took, but hiring local trainers and buying equipment locally is what I prefer in other projects in developing countries.
We have presented some of the successes and failures of an online education project. This project was distinguished by its pioneering use of real-time machine translation. While this technology is in its infancy, we began to see some of the possibilities that machine translation creates for global learning environments.