Crritics and Receptionists: Students as Knowledge Providers by Susan Schreibman University College Dublin Currents in Electronic LiteracySpring 1999 (1), <http://www.cwrl.utexas.edu/currents/spr99/schreibman/>
	Introduction Examples of digital resources created by undergraduate students as part of their course requirements now abound on the Internet. It seems that the most successful of these are offered at institutions which have extensive support systems for humanities computing, where hardware is plentiful and students can sign up for optional web authoring courses offered by support services. They can even register for complementary courses in hypertext theory and web rhetoric. With such supports in place, it is relatively easy to take students to the next phase in which they become the content providers. But even at institutions that have little support for (or indeed interest in) humanities computing, it is possible to design technologically and pedagogically challenging courses for these students. There are two basic models for humanities computing courses which have as their primary objective the creation of content. In both models, students must choose topics, research subjects, create and/or digitize existing resources, and encode in HTML. The more common one has been that students extend a web created by the instructor. Working within broad design limitations, students create pockets of information (text, graphics, sound, video, etc.) which can be linked hypertextually. The advantage of this model is that the stress is laid on the creation of content. While students do need to make design decisions, these decisions are made within a limited framework. Another advantage to this approach is that it is possible for students to work individually on a small set of nodes, yet have their work appear as part of a more substantial archive. Another model which is possibly more challenging, both technologically and spatially, is for students to design their own sites. Given the pressures of time in traditionally-structured courses, it is extremely difficult for students working individually to wear the caps of researcher, designer, and techie at the same time and create comprehensive archives. Because of the competing demands of this approach, it is best for students to work as part of a team. In the autumn of 1998 I developed and taught a final-year seminar entitled Manuscript/Text/Hypertext/Crritic to a group of twelve students in which I adopted the latter approach. It was the first time that a course had been offered in the Department of Modern English at my university that utilized computers in the classroom. The goal of the course was to have students construct HTML archives that demonstrated the reception of a particular text or group of texts, charted the growth and development of a poem or group of poems through versioning, or annotated a particular text or group of texts. M/T/H/C was designed to give students the opportunity to present established theoretical modes through the medium of hypertext, engaging with both the technology and the rhetoric of the web. It was an opportunity for students to extend their writing space by becoming conscious of how the medium in which we write influences style, mode of expression, and expectations of the writer in relation to reader behavior. Part of the rationale for this course was to make students more discerning readers as they became providers of knowledge. During the course, they learned that not all texts are created equal. And as they donned the cap of content providers, they grew to appreciate the meticulous scholarship of those who have been the traditional providers of knowledge. The course was also designed to allow students a range of choices in which they had to confront a variety of issues including their own critical stance, the presentation of their ideas (both textually and visually), and their ability to work as part of a team to deliver a product enriched by an exchange of ideas amongst colleagues. Although I had few preconceived notions of what to expect from the students' final projects, I was quite unprepared for the time, effort, and seriousness that they put into them, in many cases creating archives which far exceeded what I thought they could achieve in a mere nine weeks. Yet this approach severely tests the limits of what can be achieved by combining so many different skills, and many of the archives suffered in some aspect of design or the provision of content. Course Aims, Goals, Objectives, and Minimum Requirements The stated goal of the course was for students, working as part of a team, to produce a piece of interpretative scholarship using advanced technology. This was to be done by adapting primary and secondary sources (as well as their own ideas) to create a unique and valuable resource which suits the medium. The course also had several secondary objectives: to introduce students to humanities computing issues; to familiarize students with issues of contemporary editing; to give students the theoretical background to understand and evaluate hypertext theory. By and large, Irish students in the humanities have had less exposure to word processing and computing than their American counterparts. At my university, arts students cannot take elective computing courses. In addition, the only courses offered by Computing Services in such common programs as Word, Access, and Excel are, by and large, geared for staff. Computer courses outside the college are extremely expensive, with the result that few students have any formal training in the use of computer software. In addition, far fewer families have home computers in Ireland than in the United States: 22% in 1996-97 (the last year for which statistics are available). And at UCD the ratio of public access computers to arts students is even lower--1:18. With these facts in mind, the course's technological prerequisites could not be too stringent. The minimum requirement was that students be at least familiar with Microsoft Word. As it turned out, several of my students had never been on the Internet before. And the three most experienced Internet users were the three foreign students: two Americans on a Junior Year Abroad program, and one New Zealander living in Dublin. Seminar Structure The weekly seminar was divided into two discrete blocks: a one-hour seminar and a one-and-a-half-hour lab session. Luckily, our computer center made a mistake in our favor by allocating us a two-hour lab session. Students were given the option of leaving a half hour early, but most of them stayed. As it turned out, they needed the time. And on the final feedback forms, several students suggested that they would have welcomed even more lab time. For the first five weeks, seminars were used to provide students with the tools they would need to design their archives: HTML basics, theories of cyberspace, and principles of website design. No less importantly, students were also introduced to the basics of reception theory, annotation theory, and versioning. To complement the material in the seminars, the first few lab sessions were used to familiarize students with Netscape, the Web, and what I called a "rhetoric of the Web" through a series of exercises. For example, during the first lab session students visited a number of sites in which students, mostly undergraduates, had completed projects similar to ones they were expected to pursue. The rationale for this was that I wanted my students to see just how much could be accomplished in a term, and that although at the outset their task might seem gargantuan, it was certainly within the realm of possibility. Phase I In week two of the seminar, I began discussing hypertext theory and introduced students to HTML. Students were asked to speculate on what they felt constituted good websites. In the lab session later that week, students were asked to evaluate one site out of six to which hyperlinks had been provided. Selected sites were very different: one had excellent content, but was visually uninspiring. Another was terrific to look at, but lacked content. Another was a very interesting translation from the Irish, with Irish and English versions in side-by-side frames, but with little accompanying bibliographic information. Students were asked to send their evaluations to the Discussion List, paying particular attention to the following in their responses: visual impact of site; readability; navigability; usefulness of information. This was the students' first on-line feedback and their responses were very impressive. They gave quite detailed, measured, and fair responses to the sites. They were already becoming quite sophisticated Internet consumers. I felt that the students were more forthcoming in their e-mail responses than they would have been in class presentations. And it was a lot more fun to send responses to the Discussion List while toggling back to web sites than writing out their responses to submit to me. In addition, by having students send their responses to the Discussion List, all of us became equal: I was not the only person to whom students were responding, and students took quite a lot of time to read others' responses. Lab sessions were delivered through TopClass, a class-management system that runs as a plug-in to any web browser. And while it does have its idiosyncrasies, it provides a very secure environment for both lecturer and student. For the first few weeks of class, before projects had been chosen and teams established, students knew what to do when they arrived for lab sessions. In TopClass's CourseWork section I provided several pages of text to work through involving one exercise per week to be sent to the Discussion List. I had been advised the previous summer by Dr. Maria Economu from The Humanities Advanced Technology and Information institute at University of Glasgow to structure lab sessions carefully. This advice was invaluable because it is easy for lab sessions to turn into one big surf-session. During the initial weeks of the course it was important for students to have a focused environment. At 11:00 each Thursday they came into the computer lab, logged onto TopClass, went to CourseWork, and got down to business. They were never at a loss as to what to do when they arrived; they never had to wait for me to tell them what to do while I was helping another student. And when students finished early, most stayed to surf the Internet for resources that might be useful to projects they were considering. The last component of the course was handouts. I submitted about twenty articles to our photocopy library, each labelled as to the area of the course the article addressed (such as hypertext theory, electronic archives, versioning, reception theory, editing theory, etc.). Students were encouraged to read as many of these articles as possible, although they had the option of only reading in areas which interested them, further reinforcing the de-centered classroom. Course Requirements During the first seminar, students were advised of what was expected of them. This consisted of: A 500-word report describing the primary and secondary text their group had chosen and some indication of how they planned on approaching its design in HTML; A Story Board, which consisted of the basic presentation, design, and primary material to be included in the site; A team project consisting of a digital archive which would be uploaded to the UCD server; A 4,000-word essay on some aspect of Humanities Computing. The 500-word report and the Story Board were due in weeks five and six respectively. In practice, I was lucky to receive a 500-word description. Students found it difficult (and understandably so) working within such a tight time frame to pull their ideas together. When I realized they were having so much difficulty writing a 500-word report because they were not entirely clear on how they would design their archives, I did not press for the Story Board. The next time I offer the course the Story Board requirement will be dropped. HTML, WYSIWYG, and Web Design That none of my students knew anything about HTML or web design at the outset of the course was turned into an advantage rather than viewed as a liability. Their ignorance of such things as WYSIWYG editors allowed me to fool them into thinking (at least initially) that the only way to encode in HTML was to do it by hand. The rationale for this was that I felt students needed to have an understanding of the back end of their sites so they would have the ability to understand what had gone wrong when viewing source code. Thus during the second seminar I introduced them to the basics of HTML and explained the hierarchical structure of mark-up languages. In the lab session that week they were given a block of digital text, and a paper handout of how the text should look, which they encoded using Notepad. Some had, obviously, more difficulty than others, but eventually they all got their texts to look like my example. During this week the term "WYSIWYG" was never uttered in class. And when one bright spark asked about WYSIWYG editors, I said that the server at UCD did not support them (I felt a little white lie was worthwhile in the circumstances). At the next lab session they were introduced to Netscape Composer. The look of relief on their faces was palpable. This week they were provided with several blocks of digital text, as well as several images, and were asked to link everything together as well as to make it look attractive. This time there were no expectations as to how the site should look (the only direction they received was at what point on the home page links should be created). The results were amazingly diverse: one would find it difficult to believe that they were all working from the same set of texts and images. This two-phased strategy paid off. As students got more proficient encoding, and their sites became more complicated, their initial introduction to HTML proved invaluable as we sat peering at the screen trying to figure out why something had gone awry. Understanding HTML encoding empowered them to fix their own mistakes, or at least to take a stab at it. And being confident in working with a text editor like Notepad allowed them to undo undesirable or unwanted WYSIWYG encoding. Getting Students into Groups, or The Great Push One of the elements of the course I was most unprepared for was the difficulty of getting students to work together. I knew that arts students at my university had virtually no experience of group work; nevertheless, I never expected the reticence with which they approached this part of the course. I don't think that they were opposed to the idea of working together, and when they finally got into groups they enjoyed the experience. What they were reticent about was putting their ideas into the public domain. Rather than use valuable class time for students to tell the others of their ideas for projects, I suggested they send their ideas to a folder I had created in TopClass entitled Matchmaking. I thought this somewhat anonymous approach was easier than face-to-face encounters. Although they were amused by my rhetoric, it was a struggle on my part to encourage students to post their ideas. It became clear that many of them felt that the others might consider their ideas stupid or uninteresting. Worst of all, they were afraid of getting no response. Finally, with a bit of encouragement, a few brave souls put project proposals into the folder--and lo and behold, there were positive responses. Other students almost had to be bullied into groups--I finally sat down at the beginning of a lab session with all the stray students in a semi-circle, playing the part of matchmaker myself. Although the students who took advantage of the electronic facility had a week or two head-start on the students that I had to cajole into teams, they were by no means the only ones who submitted good projects. Phase II Once everybody was working within a group, the dynamic of both seminars and lab sessions changed. During lab sessions CourseWork was no longer provided; instead, students used lab time to implement their projects. This they did admirably. During seminars we turned our attention to theoretical approaches to hypertext. The textbook I had chosen was George Landow's Hypertext 2.0. In retrospect, I think this text was too difficult for undergraduates. Probably a better alternative is to create a virtual textbook through freely available resources on the Internet. From the beginning of the course, students were encouraged to question what they were reading, including Hypertext 2.0. Often I came into class playing devil's advocate, taking exception to one of Landow's arguments. The strategy paid off: my students began to posit their own theories of hypertext, many of them equally as plausible as Landow's. Unfortunately, this part of the course lasted all too briefly. In future, to allow more time for this part of the course, the only theoretical mode the archives project will utilize will be reception theory. This change will have the double advantage of freeing up valuable seminar time to discuss hypertext theory, as well as providing a similar point of departure for all the archives. Although the idea of allowing students freedom in choosing the underlying theoretical basis for their archives is a valuable one, in practice we had too much theory to cover, and several students felt that we covered too much too superficially: It was an extremely interesting introduction to hypertext and other textual theories, although I felt that I learned a little bit about a lot, when I would have preferred a more thorough understanding at times. Other students wanted to see a greater linkage between theory and practice: from week to week using the text [Landow] alongside our projects as "Work in Progress" might make the connection between theory and practice of Hypertext a little more accessible and comprehensive. Others just wanted more of everything: I would have liked there to be more emphasis on specific works/authors and maybe some more technical information. Other than that I found the course to be very good. Lessons Learned Manuscript/Text/Hypertext/Crritic was an extremely positive experience for both the students and myself. These responses to the final feedback form were fairly typical: Overall, I really enjoyed the course, learnt a lot, and increased my confidence and knowledge of computers and how to work them. It was very innovative and interesting . . . The hypertext theory & the book itself was very interesting, as was the course. One student even suggested extending the seminar to an hour and a half (this was in addition to the hour-and-a-half lab session a week). Their willingness to put in nearly three times as many contact hours as students in other seminars testifies to the return they felt they were getting (seminars are normally nine contact hours a semester: my students put in on average 22-27). About 3/4 of the class had joined the NetSoc (the Internet Society), a startlingly high percentage for any arts group. One student who did a superb job on site design told me after the term ended that he now realized he had a talent in this area and was contemplating it as a career. Two others are applying to do Diplomas in Computer Science next year. I learned that students really blossom with this kind of course. Their feedback was positive: 100% of the students felt the course material and seminar lectures were interesting and/or challenging. Most felt the amount of work covered was "about right," although one felt it was "too little" and two "too much." Although I had planned on covering rather more literary theory, I found that the course increasingly veered towards the technical. For without a thorough grounding in HTML and web rhetoric, it would have been impossible for students to achieve their goals. Nevertheless, several students felt that they would have liked the emphasis tipped even further in favor of the technical. When I asked on the final feedback form, "How could lab sessions be improved?," these were not atypical responses: extra sessions for those unfamiliar with computers /HTML More emphasis on teaching programming codes & mark-up languages When I asked "How could seminars be improved?," these were common responses: I would have liked to have looked at editing more closely. I found there was not enough emphasis put on the different theories, eg. versioning, etc. as these are important for the final project. What I have learned from this is to separate the technical from the theoretical fully: seminars should be used for the theoretical aspects of the course, and lab sessions for the technical. This would have the added benefit of allowing students to practice technical aspects of what they had learned immediately (rather than the delay between seeing it on Tuesday and implementing it on Thursday). In addition, separating the teaching of content from form, coupled with restricting the course to one theoretical approach (in addition, of course, to hypertext theory), would allow more time for students to come to grips with theory. In several cases the weakest aspect of students' archives was the theoretical underpinning, which I suspect might reflect the emphasis on the more technical aspects of the course. The optimal team size was three people. Two groups had two participants each, and they shouldered a much heavier burden. I also noticed, much to my regret, that in several groups, the division of labor fell along gender lines: the females did the research, the males did the hypertext design and encoding. Students were introduced to HTML basics: how to manipulate text, how to insert images, and how to hyperlink. I did not show them how to use tables as I felt they might feel technologically overloaded. This proved to be a mistake, as many of the projects ultimately used them. I still feel introducing tables too early might result in overload. Thus the next time the course is offered I will adopt a multi-phased approach. After students get an initial grounding in HTML, I'll put a series of exercises on TopClass (one per week) introducing them to more advanced aspects of encoding. This might also help to counter the feeling that two students had: Sometimes it seemed like there was no real objective in the lab sessions. If there were more exercises I may have grasped it more clearly. Although I repeatedly advised students to think small in terms of what they could accomplish, they were quite unprepared for the amount of time creating digital archives necessitated. Yet this had very interesting consequences for site design. One group who had worked on a reception theory archive of Dubliners were initially going to put the entire collection on their site. They found a copy of the stories on the Internet and were going to copy them to their own archive. I objected: had they compared the hypertext version which they had found against a reputable print version? Were they planning on asking permission of the person who put up the original site if they could copy the material? Would they be breaching copyright of the Joyce estate if they put up the texts in their entirety? And even if the version they were planning on using was meticulously transcribed and they were granted permission to use it, did they feel their readers would appreciate the whole of the text in hypertext form? These questions raised several others: Who was their audience? Would all their readers have access to the original text? What was the purpose of the archive? These questions brought home real issues which are faced not only by my students, but by all of us engaged in the creation of digital resources. They considered my points, particularly those relating to copyright, and eventually decided only to quote relevant extracts. Several students pointed out that they put an enormous amount of work into their archives without receiving credit for them. In fact, they received virtually no credit, as a result of a very rigid way of apportioning marks in the UCD system. Nevertheless, the dedication, perseverance, and time invested in their archives demonstrated they were engaging in that rare phenomenon of learning for learning's sake. My only regret was that none of my students guessed the referent from which I derived my atypical spelling of Crritic. (This did, however, save me money, as I had promised a book prize to the student who guessed correctly.) So for my students who periodically asked me for the answer all semester, and especially for the student who wrote on his/her feedback form "Still don't know what the 2 r's are for in crritic!," here it is: Estragon: That's the idea, let's abuse each other. [They turn, move apart, turn again and face each other.] Vladimir: Moron! Estragon: Vermin! Vladimir: Abortion! Estragon: Morpion! Vladimir: Sewer-rat! Estragon: Curate! Vladimir: Cretin! Estragon: [With finality.] Crritic! Vladimir: Oh! [He wilts, vanquished, and turns away.] from Waiting for Godot by Samuel Beckett