Extending the Conversation:
Integrating E-mail and Web Technology
in CS Programming Classes

Introduction

Browsing through the various CS department home pages or looking over the most recent SIGCSE Technical Symposium program, it is apparent that web technology is rapidly becoming the vehicle of choice for delivering course material that augments the textbook. In some cases, the HTML documents are extremely elaborate and comprehensive [8, 13]. When used in this fashion, the web page becomes a valuable alternative 1 form of textbook or lab manual. Dazzling as this important development is, we should not be deterred from pursuing other applications of network technology in CS education. In this paper we describe a setting where the web is just one of several network technologies that are utilized to create an alternative form of the classroom itself. These other network technologies include email, remote program execution and automatic program checking.

Background

The anomalous lag of CS education in the use of computer technology is fast disappearing. A stroll through the web pages of the CS departments reveals that there are few departments without at least one pioneer actively developing web and related support for CS education. The most recent SIGCSE Technical Symposium includes no fewer than one seminar [6], one panel [14], and four papers [5, 8, 10, 11] reporting such developments. Most of these took the web-as-textbook approach, although Nishida et al [10] shared our view of the web as an alternate form of the classroom and provides an update of the approach taken in [2, 3]. Our work differs from Nishida's in at least two ways. First, and most important, our work is in part an outgrowth of the development of our own automatic homework program checker [1], which in turn bears relation to a number of earlier efforts [4, 7, 9, 12]. Second, as described below, our transformation of the email record is more automated and involves the generation of a KWIC index.

Our Physical Classrooms

Faculty make different use of their class sessions. Some start the semester with a completely prepared set of lecture notes. For those faculty, the classroom is a different form of textbook (or the textbook is a different form of classroom). Although we (the authors) do lecture considerably, our lectures are constructed between class meetings, and, while guided by a syllabus, are very much in response to the questions, reactions and insights contributed by our students in previous meetings. During our classes, in spite of their large size, we encourage discussion and questions and, in a controlled way, let the resulting conversation form the contour of our classwork. What takes place in our classroom, then, is a conversation and is dynamic.

We use the network to extend this classroom in space and time to increase the effective duration and the availability of the classroom. We also use the network to make it a better classroom-- at least in some respects.

Our Cyberclassrooms

The web pages that serve as an alternative to the textbook must have a source for their material-- the instructor or a surrogate. Similarly, the web pages that serve as the alternative to the classroom must have a source-- an ongoing conversation between instructor and students. This conversation must take place in some electronic medium. The available ones are: the web itself, local news groups or a bulletin board, and email.

We chose not to use the web as the primary locus of the conversation because HTML forms are too inconvenient and would inhibit the kind of quick give and take that we wish to encourage. Using the web directly would make instructor control difficult and, ironically, would make developing cross-referencing hyperlinks more difficult.

Local news groups (and bulletin boards) have many appealing aspects. For advocates of collaborative learning theory who desire to undermine foundational authority, an unmoderated group is quite desirable. We have not taken this approach, for the time being at least, because we use collaborative learning in our classes only occasionally and because converting to HTML with the desired cross referencing would be difficult, though of course not impossible. Ultimately, one constructs one's cyberclassroom with the same philosophy that one constructs the physical one. Faculty who can appreciate the apparent anarchy of collaborative learning might well opt to use a bulletin board model as the basis for the conversation.

As our project stands, the conversation in our cyberclassroom consists of private email sent by students to the instructor. The instructor responds to the mail either privately or publicly. A public response is mailed to all students and staff in the course, and usually includes relevant portions of the original mail and may, at the instructor's discretion, identify the student.

At the outset of this effort, several years ago, there was no more to the medium than this email. This was unsatisfactory because the emailed messages were often not immediately relevant to the majority of the students at the time of receipt. Students would either lose messages or find it inconvenient to periodically plow through old email messages in search of useful information.

Now, however, one of the recipients of the public response is a program that upon message receipt automatically strips of the mail header, and extracts the subject and message body. These are converted into presentable, though not very glamorous HTML. The subject is added to a chronological index which links to the message itself. In addition, for each keyword in the subject, the subject is entered into a KWIC index, again linking to the message. Finally, at the end of the message HTML, additional links to related messages are inserted. All of this is maintained in the web page for the course, along with other more "traditional" type of web information.

As a result, though students are informed of each new addition by receipt of email, they may choose to ignore the email and when convenient or useful access the ongoing conversation on the web either chronologically or through a chain of associated links.

Motivating the Conversation

Conversations don't just happen. They must be sparked. In the physical classroom there are many motivations-- natural curiosity inspired by the lecture, a desire to show off before instructor and classmates, a fear of not sufficiently understanding something that "will be on the exam". Since we don't lecture in our cyberclassroom, there must be a different impetus.

In our courses, the primary impetus is the way homework is handled. All homework is submittedvia a script that wraps any number of files of any nature and e-mails them to a special account that uses a .forward file to pipe the mail to a program checker. The nature of the program checker varies with the course being taught. In Operating Systems, where the assignment is to write a kernel device driver, the checker executes on one rather isolate machine, and maintains a queue of submitted drivers. The drivers are used, in turn, to generate new kernel images and the resulting system is booted for testing-- the outcome is then reported to student and instructor.

In our early programming classes, the checker runs as a distributed program, executing on all the machines of the network with the intention of spreading the load as evenly as possible. In each run, a temporary testing directory is created where the checker analyses the student's submission. Within minutes a response is sent to student and, if successful, to instructor.

The checker and its overall impact on the course is profound and is described in (Arnow, 1995). What is relevant here is its stimulation of conversation. Partly this is simply a result of the increased number of programming assignments the checker permits, partly it is a result of the greater focus on specifications, correctness testing, debugging. Although there can be no such thing as a fool-proof checker, the level of checking is quite thorough and the rejected homework submissions often send students scrambling back to the homework specification or to a substantial review of their code. All of these lead to requests for advice and often interesting questions from the students to their instructor.

Implementation

As the email broadcasts from the instructor are made, they are automatically appended to a file that is a collection of all such broadcasts since the term's start. The file gets rather large and it would be inefficient to reconstruct the web page with every broadcast-- it would also be unnecessary since the students for whom the broadcast has immediate relevance will pay attention to the broadcast anyway.

Every eight hours, a cron job is invoked that, among other tasks, runs a ksh script to recreate the web pages, taking into the saved broadcasts. The script breaks down the broadcast file into individual files, scans their subjects, tagging them with keywords. A file containing "trivial" words is maintained to avoid indexing on articles, prepositions etc. These files are turned into HTML by enclosing their contents with preformat tags, and inserting an intra-file reference tag at the beginning and inserting links to related items at the end. The KWIC index is constructed from the keywords, anchored to the intra-file reference tags. The index and the other files are then combined, with the appropriate tags to form the final HTML file. A single HTML file is desirable to facilitate web client search capabilities

More Better Classrooms?

Is the resulting cyber-conversation of ours better than the traditional one that we continue to use in our conventional classroom? No-- not better, but different and offering some distinct advantages. Some of these are inherent in any cybertool:

• asynchrony: especially important for the commuter student, this means that each student can join in or listen to the conversation when he or she needs to or is able to;
• recorded conversation: the network technology records the conversation with perfect accuracy-- quite different from the notes students take in class

Other advantages derive from the web technology that is used to store and organize the final form of the conversation:

• non-linear text-- the links between related parts of the conversation are far more traceable on the web than they are on blackboard or in the student's class notes

Still other advantages stem from our use of email as the medium for conducting the conversation:

• privacy: the shy student who is reluctant to raise questions or make comments in a large class often is quite active in the electronic conversation-- our protocol permits students to request anonymity in our public responses
• greater instructor control of conversation: in the physical classroom, the desire to answer fully all questions and not deter questions by deflecting the less relevant ones must be balanced with the recognition that not all questions are relevant to the class at large. In the electronic conversation, these are no longer conflicting goals.

All this is not to say that there are no limitations or weaknesses. The electronic conversation here is driven by the automatic homework checker and focuses on specific points relating to the homework assignments for the most part, although there are welcome digressions. It is not used to present fundamental information, which still comes from the text, the physical class and various other material that is posted on our web page. One ongoing concern is our seemingly never-ending quest for better, more intelligent indexing and linking.

Conclusion

Educational technology such as the textbook developed slowly over many years. In contrast, the application of internet technology is growing at a phenomenal rate. As CS educators, we ought to use these opportunities to extend not just our textbooks but our selves-- as instructors-- as well.