The need to write this article occurred to me after reading a report on the course prepared by an external observer. What we were trying to do was not well understood. When I say we I mean the group of people who were creating and managing this experiment. I believe this experiment has taught us many valuable lessons about the "culture of the Net". Since this "culture of the Net" is foreign to many people and the Internet is getting considerable attention from many groups of interest that have little to do with this culture, it would be a valuable service to explain what we have done and the lessons we have learned.
Since this paper is written from the perspective of an insider, I would like to tell you a bit about myself and how I got involved with this course. I am an Assistant Professor of Mathematics and Computer Science at Mount Allison University in Canada. At the time I learned about this course (March '94), I was on leave of absence. After "meeting" (in quote because we never actually met, only virtually) Marcus Speh, I decided to volunteer as a consultant for the course. At the time, Marcus had a group of volunteers students helping out with the conversion of an ASCII tutorial to an hypertext book that would form the core of the course. The course started May 2nd and finished Aug 15th. We started with 60 students and 6 consultants and it eventually increased to 80 students and close to a dozen consultants.
The subject of the course Object-Oriented Programming using C++ is very popular in the computer field right now. There is a great demand for people skilled in this technique and programming language. On the other hand, Object-Oriented Programming requires new ways to approach software development and C++ has gained the reputation of being difficult to master (mainly because of its size and the, sometimes, subtle interaction between the different features of the language). That is to say that the course was about a technical and difficult subject and trying to teach it in a new environment would be a real challenge. Given what we had to start with and being able to say today that it was a success is no small achievement. (I will try to qualify this success in the rest of this paper).
GNA Introduction to OOP using C++: What is it?
The Globewide Network Academy Inc. is a non-profit corporation whose long term goal is to become a fully accredited online university. In this organization I found a group of young, talented people eager to push the limit of the technology and to exploit the wealth of the Internet to try to lay the foundation of what will become education and learning in the 21st century. Since this is a virtual corporation and the course was also a virtual one, some people had a hard time believing it was real. Only after the official kick off and having mailboxes full of surveys, replies, questions about the course material and compilers problems, did people realize this was a `real' course. During this time, the consultants were wondering how to teach the subject with the tools available. The consultants had a mailing list set up to discuss issues related to the course. We also held a weekly meeting in our virtual classroom which is located in the Diversity University MOO.
The subject matter of the course was to be studied by going through a chapter of the hypertext book and asking questions of a consultant during his online office hours or sending questions to a mailing list available to all the students of the course. Early on, people were asked to work on a project and it became an integral part of the course. An excellent and much more complete description of the course was presented at the 1st International Conference on the World Wide Web in Geneva by the course coordinator Marcus Speh.
While none of the consultants had ever met in real life before the course began, we got sufficient information on the group from the mailing list and virtual classroom interactions to know vaguely what to expect from the group. The situation was very different concerning the people who registered for this course: the "students". When the course started we had very little information on them and even after a couple of surveys, most of the consultants felt we did not have adequate information to make good judgments when decisions had to be made. This lack of information made the running of this course much more difficult. Moreover, everyone involved in this enterprise was doing it on a voluntary and part-time basis (even though part-time involvement became less and less true for many of us as the course evolved). For this reason, we didn't have the resources required to prepare assignments, send them to students, mark and return them, for example. Even if we had such resources, it is not clear that we would have used them. Some of us wanted this course to be an occasion for people to be responsible for their own learning process. It is for this reason we have tried to keep to a minimum the distinction between students and consultants in the course.
As just described, the course was built around four main components: the hypertext book, the mailings lists, the projects and the MOO interactions. Now, I would like to describe how each of these has evolved during the course.
The Hypertext Book: The decision to convert an existing ASCII (text) based tutorial to an HTML document was made by the course coordinator, Marcus Speh, very early on. This decision is going to shape the rest of the course and turned out to be one of the best decisions taken during the course. The advantages of an hypertext document over a traditional text document should not be argued here (this is a conference about the World Wide Web). Even though a textbook on computer programming does not exploit many formats other than text (a C++ program is a text file) the flexibility and ease with which the user can access the comments on a particular piece of code, the glossary of C++ terms, and download the source of a program to its machine, for example, let the user concentrate on understanding the material. This integration of all the information required by a user to learn a topic has proven very popular and is an excellent example of the power of the Web technology. I will be coordinating the second version of this course and one of the main goals in this second course is to expand the hypertext book to cover more advanced material. Although the hypertext book was "under construction" during most of the course, it had the positive effect of ensuring that people were covering the material at roughly the same pace. Even though, the course was an introduction to the subject, many students were not beginners and the consultants worried about the pace of the course. The extreme diversity of the student population mirrors (on a small scale) the diversity of the Net itself. The consultants realized early on that we didn't have much material to offer to more advanced people. Projects were introduced, partly as an answer to these needs. Before leaving the hypertext book discussions, I would like to add two more points. First, the whole hypertext book was available at all times to anyone on the Net with Web access. I mentioned earlier the hypertext book was very popular and a witness to this popularity is the constant stream of messages sent to the consultants mailing list by people not related to the course in any way saying how they appreciated what we have done. The second point is more technical. All the information needed to use the C++ programs from the hypertext book was reached using one hyperlink (entitled Compilation Notes). This is a good example of what computer scientists called encapsulation where all the platform dependent information is hidden in one place. This brings us to the question of how to gracefully grow a large collection of HTML documents related to a single topic. It is not as simple as it looks.
The Mailing List: Originally, it was proposed that we set up one mailing list for the consultants, one for the students and one for students needing help and wanting quick "relief". Then a "student" volunteered to take care of the students mailing list and started using hypermail a little later. This last mailing list became the central resource available to the students to discuss anything related to the course. At the beginning of the course, we thought that having a central location to discuss issues related to the course would be adequate. We were quickly proven wrong and realized the limit of email technology. When you receive twenty or more messages a day, and there is no way to figure out if a particular message needs your attention urgently or is junk-mail without reading completely, you are likely to spend a good part of your working day dealing with these messages. There are jobs that require this but teaching a programming course is not one of those. If you are teaching a computer programming course and you are spending more than half your lecture time on answering students questions then you are not left with much time to cover new material. What was wrong with this course's mailing list was that it served too many purposes. Some used it to clarify the hypertext book material, some used it to discuss more advanced materials, the consultants used it to enquire about students progress, etc. People might argue there is nothing wrong with this and a teacher using students' questions to introduce new materials is a good teaching practice. These people are right but I believe that using email to do this in a virtual environment turned off many people. Several low volume mailing lists with well defined topic discussions, archived in HTML format (hypermail) would have been much more effective than one big mailing list.
Another problem with a single mailing list were messages where students are asking questions on material that was supposed to cover in a week or two. Admittedly, given the course structure, trying to enforce some kind of synchronization was difficult and, maybe, a bit artificial. Nevertheless, many of us believed that it was important to do. There is a certain body of knowledge that students of such a course should go through. This implies certain dependencies between certain subjects to be covered. The course presented the material in one particular way. We might argue that this was not the optimal way, etc. But students who start such a course expect to go through the subjects in one well defined way. Having students asking questions about Chapter 5 when we were supposed to cover Chapter 3 is disruptive. Given the great diversity of the student population, this was difficult to avoid. At the moment, the only serious proposal to fix this problem has been to split the students into beginners, intermediate and advanced groups.
The Virtual Classroom: Rereading some of the earliest transcripts of the weekly consultants meetings, I noticed that, early on, we gave some thought to actually lecturing in the MOO environment. We quickly dropped the idea because of the user unfriendly interface. Moreover, it would have been difficult to fix a schedule to accommodate everyone and it was far from clear that the people who registered for the course had the interest and the will to get comfortable in this environment. On the other hand, the people courageous enough to overcome these difficulties preferred the MOO interaction to the mailing list. Since most people here might not be familiar with MOO technology, let me briefly describe it. The Diversity University, where the virtual classroom is located, is a MOO (Multi-user dungeon Object Oriented). This is a text-based virtual reality software developed at Xerox Parc. It allows users to create an environment with objects that can be programmed to do almost anything, in a textual environment. Moreover, people can interact in these environments. A short example of MOO interaction can probably best illustrate this environment.
The consultants fixed office hours during which they would connect to DU MOO and go the the virtual classroom to answer students questions. If a student had a question on a particular topic, he could pop up the consultants office hours schedule and connect to the MOO at the given time to ask his question. In reality, these office hours turned out to be very much like real life office hours: few students showed up and always the same one. Besides these office hours, the consultants held a weekly meeting to discuss course matters and there were also a few special events held on the virtual campus. Personally, since I am comfortable in the virtual classroom, I find MOO interactions stimulating and, even, enjoyable. I think this environment has great potential; it is simply not ready for mass acceptance. Since you are typing what you want to say in real-time and people cannot type very fast, it is better to use short sentences. If you want to lecture, it is better to have a few more "facilities" like a slide projector, for example. Also, interaction involving more than six or seven persons can be difficult and needs extra discipline. On the other hand, I believe this environment is particularly well suited to computer software collaborative development. It lacks the tools to access relevant materials easily, but we can expect this will be solved in the near future. It has, in my opinion, the right "bandwidth"; it is slow to use, you have to think before writing. But if you look at how computers scientists work on a hard problem on a black board, there are few things said, few things written but a lot of thinking is going on. This is precisely what the MOO interaction encourages. If there would exist a few good tools to implement the blackboard (above) and to facilitate access to source code, libraries, etc, we would see collaborative software development as a viable alternative and possibly with remarkable implications. For example, the problem of software documentation becomes clearer. If you are not documenting your software well, your collaborators will let you know because they would not be able to collaborate! Many groups of research are working on the interface between the WWW and the MOO technology. A GUI for the MOO with WWW access looks like a very interesting possibility (in spirit very similar to General Magic's Telescript technology with the added benefit of being non-proprietary and using the TCP/IP protocol).
The Projects: Some students asked for working on projects as a way of learning the material. The consultants thought it would be good if most students could be actively involved in a project they were interested in. Given the very diverse background of the students, we decided against assigning every student to a consultant in an arbitrary manner. But as the idea of introducing projects came about, we thought that grouping students on a project of their choice would be much more natural and most aspects of the course management would become issues in the management of projects. People started discussing projects on the mailing list informally. Students were asking when they were going to start work on them, some projects were proposed and discussed. At one point, I thought people were "buying" into this project idea, and, as just said above, the whole course management (or most of it) would be handled in the context of a particular project. It is not what happened. After the official call for project proposal was sent out, we noticed that most projects (all, except one I think) had been proposed by one of the consultants. If people had "bought" into the project idea, they were not spending a lot! The most active project set up their own mailing list and each person participating in a given project contributed according to its availability. I think that the most successful project worked out because a particular individual was really committed to it and managed to generate enough interest to accomplish something. Another project that produced something valuable was, essentially, a one-woman show working on a more advanced subject. Looking back into the projects aspect of the course, it is clear there are obstacles to having a group of people, who have never met, working together closely to achieve a definite goal in a virtual environment. Moreover, it is not clear what are the incentives for doing this. While a group of people can certainly accomplish more than a single person, the effort needed to express the precise requirements for a software development in a totally virtual environment might be too large to be attempted in the framework of a course like this. Because of this situation, we have proposed to separate the projects from the course so people can work on them without being students of the course and, as a consequence, the projects continue to exist after the end of the course.
Given all the course events described above, I would like to say why I consider the course a success. First of all, I believe that none of the people who got involved in the course knew clearly where this entreprise would lead us. Those of us who have devoted a considerable amount of time to this course would have given up a long time ago if there wasn't any satisfaction along the way. Personally, I hoped this course would have been an even more radical departure from the traditional education where the "teacher's" role would have become a learning tool provider. Many of my earlier comments can be understood with this perspective in mind. While this reduction of the teacher's role to some information-theoretic activities might be popular in today's parlance, it leaves aside a critical aspect of a typical classroom activity: the participants' interactions. A teacher encouraging or challenging its students, for example, will not be replaced by some sophisticated software anytime soon. On the other hand, the traditional role of the teacher as the main source of knowledge in a typical college course is seriously threatened when everybody has access to tools like Mosaic and the Web. The consultants told the students that our role was to organize the course not necessarily to run it. If someone had good ideas that might interest others, we were glad to hear them and we would try, if possible, to implement them. As I said earlier, we've tried to minimize the distinction between consultants and students. We felt that it would more interesting this way and since all of us were doing this on a voluntary basis, we couldn't take all the responsibility involved in setting up and teaching an advanced subject like Object-Oriented Programming in C++. The individual contributions to the course have been excellent. I have counted more than thirty persons in the "Contributions to the Course" (Web) page. This course kept improving following a pattern similar to the development of the Unix system, or the Internet itself: by having volunteers adding very good enhancements constantly. Also, in common with these developments, is the technical nature of the project. This probably explains part of its success: it appeals to the more sophisticated members of the Internet community, those who feel more comfortable with the culture of the Net.
I have proposed to separate the students of this course and its future versions into two groups: the learners and the adventurers. The learners are those who want to learn bits of C++ (maybe all the bits) but are not necessarily willing to participate in improving the course itself. The adventurers are those who are happy being part of an exciting new development. The course was a success for the adventurers; it was a limited success for the learners. The future versions of the course should be more successful for the learners because we have a much better idea about how to manage such a course, also the breath and depth of the hypertext book will be increasing and will allow us to cater the needs of a much wider audience (the actual hypertext book is as its title suggests: an introduction). The more advanced students were left on their appetite but we never promised that we would cover much more than an introduction to the subject. I like to imagine an ideal environment for the learners where an ubiquitous mentor, a benevolent expert, is always present when the person wants to learn C++. The mentor is watching over the person's shoulder and is ready to explain, warn, highlight any particular point. From the present situation, where someone who wants to learn C++, picks up a book and sits in front of a computer, to the ubiquitous mentor there is a world of difference. But I hope the facilities and tools that we will continue to develop will make learning OOA,OOD and C++ closer to the ubiquitous mentor metaphor. This should give the adventurers work and food for thought for awhile. Nevertheless, the needs and aspirations of the adventurers should not be taken for granted because they are the "movers and shakers" of the information age. This is the lesson learned the hard way by the executives of Prodigy (online services) as candidly explained by Prodigy CEO "The sophisticate, we think is going to lead the way in how we and other online services look at communications. We built a service for the novice... and we've been doing a lot of catch up on it ever since." (Wired 1.6) Thinking about this, our course, the Internet, I realize that the Information Superhighway is not about information or technology, it is about people.
As a conclusion, I would like to give my personal explanation of the Internet phenomenon. Some business people believe that the I-way will be this huge mass of consumers eager to order their marvelous products at the touch of a remote control. I don't share this view. Some more knowledgeable people talk about share understandings and the fundamental need to communicate. This is closer to my perspective but not quite. My explanation is simple. Developed countries have succeeded to a large extent in satisfying our basic material needs, a roof over our head and some food on the table. Beside these needs, do we want to have three cars or a Mercedes instead of a Topaz? I don't think so. Observing my young daughter growing up, two basics needs were brought back to my attention: to be accepted as we are and to have fun. A large part of the Internet popularity comes from fulfilling these needs. I would like to give two short examples to illustrate this. Jeanne Butler McWhorter, the founder of Diversity University MOO and a social worker, repeatedly told us how important the Internet was to some blind, deaf or dumb people. The Internet is one of the those rare environments where these handicaps are completely invisible. On the Internet, you are what you write. For the second example, there are a lot of technical people on the Net and for a technical person working on a technical problem is akin to having fun. I said that the subject of the course was very technical, and I can say one thing of this course, it was fun. I believe this perspective might help us understand many of the future developments on the Net. A simple example, most people don't know how to type, therefore they want Mosaic :-).
PS This is a further remark for the technically oriented reader (those for whom the acronyms OOA, OOD and C++ are as familiar as the names World Wide Web or Mosaic are to the readers of these proceedings). I love C++ very much and I think that Stroustrup has done a great job. I also believe that a learning facility on the Net, where people can learn C++ programming (and the related activities), is badly needed. Toward this end, I have mentioned to the people of the course a project which is close to my heart: the Virtual C++ Laboratory. Similar in spirit to this course (moreover, we accept everyone and we want to have fun!), I see it as an outgrowth of this course. It is at an embryonic stage but I would like it to become the central resource on C++. Also, I would like the members of this virtual laboratory to form one of the most active and flourishing virtual communities. If you have suggestions on how to achieve this, please drop me a line at: dperron@mta.ca
PPS I would like to thank all the people involved in this course who helped making it such an interesting experience.
About the author:
Daniel Perron is an Assistant Professor of Math and CS at Mount Allison University in Canada He obtained his PhD in Mathematical Logic from the Universite de Montreal in '89 Since then he has taught a bunch of courses in computer science and mathematics. He is the course coordinator for the second "edition" of the GNA C++ course. He had resident status in the US, France and Hong Kong.
Correspondence about this paper should be sent to dperron@mta.ca