Jim Duber, Editor
On the Internet
One potential advantage of networked computers is the 'paperless classroom.' It is now possible to pick up your students' assignments even if you happen to be halfway around the world. Similarly, students no longer need be physically present to turn in their assignments. No longer do you have to collect all of those sheets of paper, only to find that some of the students have forgotten to write their name on them. Instead, you can now receive files through your network, labelled
Joking aside, while we have come a long way toward the 'paperless classroom', currently there are probably few instances of a totally 'paperless' class. There are still places in the writing process where either the student or the teacher may want a print out. Note 
Even if a totally paperless class were technologically possible in a given learning environment, there is still the 'human element' to contend with. For every teacher who swears by electronic document submission, there are many others who prefer to things the 'old-fashioned' way. Revolutions in education, just as in many other aspects of society do not happen overnight.
Nevertheless, for those who are willing to attempt the novel, there are advantages to a computer-based approach to writing. First let us take a look at the pro's and con's and then look at some practical ways to implement a paperless system.
With today's concern for 'saving trees,' electronic submission looks very attractive. Nevertheless, paper as a medium has some distinct advantages. With paper, it is extremely easy to circle items, draw arrows and place comments wherever you find room. With an electronic document these become a challenge, and you might not find the substitutes wholly satisfactory.
With paper, you can spread out the sheets and flip back and forth between them at will. With a word processor, your vision is limited to what you can see on the screen at one time. This can force the reader to mentally retain much more since various parts cannot be simultaneously seen or quickly glanced at. (Some strategies for offsetting this problem are mentioned later in the article.)
Paper can be carried and viewed anywhere while electronic submission presupposes the availability of a computer. You can pull your students' papers out of your bag when you have a few spare minutes but, if the material is submitted over a network, it must be accessed over the network, or downloaded onto a floppy or other medium if portability of the data is desired. (Of course, with many networks now remotely accessible via the Internet, this is becoming less of a consideration.)
While it is easier to prepare and insert 'boilerplate' comments for frequently occurring items with a computer, simple one-off marginal comments, underlining, arrows, etc. are much easier to insert with pen and ink.
With electronic texts, submission need no longer be restricted to a specific time or place. Students no longer need to trek through the snow to drop a completed theme in your in-box; instead they might be able to submit directly from their home or dormitory, in the best of circumstances, or from the computer lab, for those not so blessed. Work can be returned in a similar fashion.
Unless copies are made, only one person can read a paper-bound text at a time, while electronic texts can be read by many simultaneously, and without having to be in the same room. Furthermore, everyone's writing is equally legible.Finally, paperless submission implies that the writing is never printed out, yet it seems that some types of problems, particularly ones of a global nature such as logic, coherence and consistency of style are easier to catch on a printed copy. A digital version can be easily checked for local errors (by spelling checkers, or even grammar checkers) but the naked eye seems to work better with paper than a computer screen. This might be a fruitful area for future empirical research.
The following table summarizes the various trade-offs between paper and electronic submission.
|Medium of submission:||Paper||Electronic|
|Submission & Return||Specified place or time||Via any networked computer, anytime|
|Reader of homework||One person (teacher or student) at a time||Multiple, simultaneous readers|
|Legibility||Varies from S to S,T to T.||Uniform appearance|
|Available information||Whatever you write||Can refer to 'linked' information|
|Comment type||Easy to insert brief comments, draw arrows, etc.||Easy to insert 'boilerplate' for frequently occurring comments|
|Feedback||Written comments anywhere, any type||Interlinear comments, End notes, Coding|
|Place for correction||Anywhere||Needs computer|
|Scope of visibility||One or more pages||One screen at a time|
|Boldface indicates the author's subjective opinion of the more preferable or convenient alternative.|
The ensuing discussion is divided into two main parts, 1) methods of submission of documents and 2) methods of providing feedback on them. The choice of method in both cases is highly dependent on your own computer configuration. Factors such as student access to the network, uniformity of word processing software, and the availability of news readers or web browsers constrain the options available in any given situation. Further, some methods are more suitable for intermediate drafts while others are only useful for publishing finished products.
This isn't much of an improvement over paper in some respects. Paper is certainly less bulky. Merely inserting the disk, finding the proper document to open, waiting for it to open, saving it with your comments and finally ejecting the disk can take considerable time, especially when multiplied by 20 or 30 students.Submission on floppies also assumes that all of the students are using the same software (or that the instructor has access to all types being used).
If you are receiving a considerable amount of personal mail or mail from mailing lists, It might be a bit imprudent to allow your students' submissions to arrive in the same account since they might be accidentally deleted or overlooked. It is therefore advisable to ask for a special account for your classes, or ideally one for each.
If this is not possible, consider specifying a specific form for the SUBJECT: line, for example, "THEME-1 xxxxxx" so that you can visually pick them out, and perhaps, depending on your software, save all mail containing a specified character string to a special file. For example, using the plain-vanilla Unix mailx program, "s /THEME-1 theme1" would save all documents containing "THEME-1" in a file called "theme1".
One drawback of this method, along with others that rely on standard e-mail transmission is that they require the students' work to be transformed into an e-mail compatible format. This normally means the following:
Many of these restrictions run counter to what we might be teaching our students as "good word-processing practice." Using spaces, for instance, in order to center items or to align columns could be considered fostering a poor work habit. Further, once the student has 'broken' the lines by inserting carriage returns, further insertion of text becomes extremely troublesome. See the document entitled Word Processor/E-mail Text Conversion Help for further discussion of this point.
If the mail software that your students use is 'MIME-compliant' then the problem discussed above can be avoided. The MIME protocol converts standard binary files, such as those produced by most word processors into code transmittable over the I-net. It does this transparently, so your students do not need to jump through yet another technological hoop in order to use it. Eudora, Lotus Notes, Netscape and Microsoft Explorer are some products that embody this feature.
With such a capability, students can send an e-mail message to the instructor with their word-processed file attached. The instructor can then read the file with the usual word-processing software and return the paper, with comments included by the same route.
Aside: MIME can also cause problems. If the sender transmits regular messages with "quoted printable" turned on, but the recipient's software cannot re-convert it, special characters in the text will appear as '=' signs followed by the ASCII value of the special character.
While it is easy to prepare a specially named directory for the students to submit their work into, unless special precautions are taken, what is submitted there could be read by anyone (which can be turned to advantage), or perhaps even deleted wittingly or unwittingly by other students.
"Drop folders" are one solution. These are directories that have had the "permissions" set so that students can 'write' into the directory but they cannot see what is inside nor read anything that is there. One problem is that students cannot resubmit a file without slightly modifying the title since otherwise, a second submission with the same title would overwrite (read "delete") the first. While this might seem permissible if the second theme were being submitted by the same person as a correction of the first, there is no way for the server to distinguish this case from that of a different individual submitting a document which happens to have the same name, such as "Composition 1" -- thus this restriction.
A separate article, The Class Folder Approach to File Transmission outlines the approach used at Kyoto Sangyo University for students to submit work and retrieve files made available to them by their instructor.
Newsgroups are one method of publicly posting one's writing. If your intention is for everyone to be able to see and comment on the writing, this is an excellent method. Naturally, your institution needs to have a news server for this to be possible.
Newsgroups and other means of public posting are normally only be used for completed work. Other methods of submission would need to be used for intermediate drafts, unless the students do not mind others seeing their works-in-progress.
An additional problem with newsgroups is concerned with the way most news-reader software works. Most software is designed for personal use and "conveniently" marks articles that have already been read so that the next time the same newsgroup is referenced, only new articles appear. This can cause problems if several students are likely to use the same computer to read the same articles, since 'read' articles will no longer appear.
A web page can be configured so that the students can copy & paste their compositions into a window and then click on 'send' to have composition sent to their instructor. Normally, this method involves that same restrictions as does the NetNews method -- each line needs to end in <CR> (or <LF><CR>) and all special formatting is lost.
Note that a simple clickable "mailto" on a web page may cause problems since the browser needs to be pre-configured with the student's own e-mail address before mail can be sent. Not only is this cumbersome for the students to do, there is always the chance that they will forget to remove their email address from the configuration once they are done. The next user of the browser will then end up sending e-mail with the previous user's e-mail address!
Jim Duber has come up with a solution which allows text to wrap normally on screen without the student having to enter <CR> at the end of each line. The returns are automatically inserted when the 'submit' button is pushed. This method, however, requires that a simple CGI script be written and installed on your server to process the submissions. It does, however, eliminate the problem of configuring the browser for each student since entries on the screen ask for the student's name and address and will automatically send the mail to the instructor chosen from the pull-down menu. (Note:  )
Note: The version on this web page is completely functional, and will send a copy of the message to you if you input your e-mail address (correctly!) below. Try it!
The html code for the above is available here.
There are a number of ways that you can configure your local e-mail system so that mail sent by one individual can be distributed to all others. As with newsgroups, these methods are mainly useful for the dissemination of final drafts.
The mail servers such as Listserv, ListProc and Majordomo can be brought into service to distribute messages and assignments to the entire class. This might also be a wise first step towards broadening your students' horizons through use of international e-mail lists. Through use of a local list they can learn the basic mail server functions which will stand them in good stead when you later ask them to participate on a more broadly-based list.
If a mail server is not available at your institution there is another simple way under Unix which requires a dedicated e-mail account. In the account, you create a file named ".forward" (read as 'dot forward') which contains the e-mail addresses of you, the instructor, and all of the students. For archival purposes the name of the account itself is also included, but preceded with a backslash. The backslash prevents the endless loop which would otherwise occur when the account sends mail to itself, which when received is forwarded to itself, ad infinitum. Here is a sample '.forward' file which assumes that the account (mailing address) itself is called 'esl001":
\esl001 johnteacher (the instructor's e-mail address) student1 (the e-mail address of the first student) student2 (...etc.)One copy of each message will remain in the esl001 account which the instructor can access as necessary. If all of the accounts are local to the same machine, (with the part after the '@' mark being identical) only the user names need be entered.
Yet another approach is to ask your network administrator to set up an alias<-- a fictitious e-mail address which does not actually have a corresponding e-mail account. A file is then maintained by either the administrator or you that is similar to the .forward account in form. Any mail set to that address is then distributed to all currently listed in the file.
Current methodology espouses delaying feedback on "local errors" -- agreement, verb tensing, spelling, word usage, etc. -- until the student's work has been fully developed structurally and argumentatively. (Note:  ) Feedback on such elements can often be done in comments appended to the end of the composition rather than written interlinearly. At some point, however, the instructor may well want to give feedback on specific problem areas, that is to "mark up" the text.
As noted earlier, providing feedback on electronically submitted work can be challenging. Below we will enumerate a number of methods that have worked for some instructors.
The first five methods below assume that the entire class is using the same word processor software. The final method "Interlinear Comments" will work with plain ascii text.
This approach assumes that your students are all using the same word processor, that files are submitted in the word processor's proprietary format (or RTF) and that all concerned are using color monitors.
Writing problems can then be color-coded according to a scheme such as this:
|blue||problems with coherence or logic|
|green||vocabulary or word-choice problems|
A problem with the linking of two sentences, for example, can be illustrated by coloring the end of the first, and beginning of the second in blue. If your word processor allows you to assign 'hot keys' you can configure your system so that highlighting and a special key combination is all that is necessary to mark an error.
This is similar to the above, but uses font styles instead of colors:
|italics||problems with coherence or logic|
|underline||vocabulary or word-choice problems|
|larger size||instructor's comments|
While font styles might not stand out quite as much as color, this approach has two distinct advantages: 1) it works on monochrome monitors and 2) you can use multiple marks on a single item. If, for example, the student wrote, "I then got up and alter the TV channel." when "changed the TV channel" would have been better, you could both underline it and set it in boldface. It would be impossible to color an item both red and green at the same time, unless you wanted to be cute and color it brown!
Microsoft Word has an 'annotation' function under the 'Insert' menu that allows a reviewer to insert comments which become visible in a separate window when clicked upon. It also includes a function which allows the original sentences along with the annotations, to be saved in a separate file. See Matthew Wagner's article in TESOL Journal, Vol. 6, No. 4 (Summer 1997) p. 26-27 for one illustration of this approach.
If your word-processor is capable of producing graphics which can lie transparently above the text, you can then mark-up a text in a similar fashion to the pen-and-paper approach. The current versions of many Word Processor products contain this function which allow the user to circle and link items, draw arrows, etc., albeit not with the same facility as the old-fashioned red pen. NisusWriter (Macintosh) is one word processor that has this function.
If your word processor supports hidden/invisible text, you can leave a visible mark,such as an asterisk, followed by text which you set to 'hidden' after you finish typing it. The student can then highlight the asterisk and the following character, and remove the 'invisible' by resetting the text style to 'plain.' Alternately, most word processors have an option for revealing all invisible text which can be used to alternate between the original, intact version and a version with all of the invisible text showing.
One common way to provide feedback is by inserting your own comments directly below the item to be commented on. If you follow the e-mail & netnews tradition of using '>' marks to indicate the original text, then their absence will offset your comments from the student's original text.
Yet another method is to use all uppercase for comments so that they can be easily distinguished, but this does, to some extent, MAKE IT LOOK 'LIKE YOU ARE SHOUTING.'
Problems: One problem with interlinear comments is that it is not readily apparent until the comment is read exactly which element in the line above or below is being commented on. Further if there are two or more comments to be made on the same line, the problem is further confounded. Yet another problem is the fact that the original text loses its continuity. The student therefore will most likely have to compare an unmarked copy of the text with the marked up one to make sense of it. Since most students will not have a screen large enough to view both versions simultaneously, one version will most likely end up being printed out, partially defeating the 'paperless' goal.
Some errors, particularly those related to basic grammar, occur perennially and can be stored in some sort of an "item bank" to be "popped" into the writing when needed.
Other errors may be specific to the assigned topic. This naturally means that the students will likely make similar errors in their writing. With the "manual approach", you would have to write the same comment repeatedly for each occurrence. Computers allow this kind of feedback to be automated which not only decreases your work load, it also frees you to pay more attention to other areas, such as the overall content and structure.
There are two main factors: where the boilerplate is stored and, how the boilerplate is inserted or accessed. We will not separate out these two factors below, but keep in mind that the use of one method of storage does not necessarily predicate a specific method of insertion.
While this method is 'automated' it does not necessarily have to be paperless nor does it have to involve the use of computers. Nevertheless, it forms the basis of some of the other methods to be discussed below. Vance Stevens reported on his approach to correction on TESLCA-L in March of 1996. Briefly, a separate paper list of common errors is distributed to the students and numbers are then used to indicate the type of error on the writing itself.
As you proceed through your student's paper, you register each comment which you feel will be needed again in your word processor's glossary. You then assign the entry a one-word code name which, in combination with a 'hot' key inserts the full text at the current insertion point. A different font, style or color can be used to offset the comment from the rest of the text.
Normally you can maintain an unlimited number of separate glossaries, each for a different use -- one for your correcting student's writing, another for a paper you are writing and yet another for your personal correspondence. Check your own word processor's help function or manual to determine how yours operates.
This approach presumes that you and your students have access to a web server. The first step is to convert the students' writing into an html document. This can be done easily by merely renaming the submitted text-only document as 'xxxxx.html' and inserting a ' <p>' code at the end of each paragraph. (All of the other codes stipulated for a well-formed html page can be ignored for this local use.)
The explanations reside in one or more separate web pages. When an item is found that requires feedback, a 'link' is set up between that item and the feedback, so that the student can click on any part of his marked-up text that appears in blue and the preset comment will 'magically' appear.
One advantage of this approach is that multiple links can be made to a single problem. For example, if the student makes an error using the English past tense instead of the present perfect, clicking on the error might bring up vague help like, "wrong tense." If the student can figure out the problem from this short comment, then she can correct it on her original and proceed to other problems. If, on the other hand, this is not sufficient information, then she can click on a 'further help' item which will take her to a clearer description of the condition for using various past forms.
Roy Bowers outlined this technique in a posting on Neteach in December of 1995 and it is incorporated into his demo page.
Martin Holmes, University of Victoria, has developed a sophisticated set of macros for Microsoft Word 7.0 and WordPerfect 6.0 for annotating writing which students submit to him via e-mail. See his article in the Internet TESL Journal for full details. More recently Holmes has developed a shareware program called "Markin" which runs under Windows and which automates the HTML linking process. The program allows instructors to code local errors and insert comments, the resulting document can then be converted into a WWW page with each of the local errors hot-linked to a description of the error type.
The screen may not be the best place to review a longish piece of writing since one's view is limited to what can fit on the screen. As stated earlier, most of us are considerably more adept at flipping back and forth between pages of paper than screens of characters. Here are some strategies which might help to make the navigation a bit easier:
Ron Corio reports that when his students wanted to send him their work, they had to plod through the following procedure until they acquired a system which allowed them to share binary text files:
Ron currently uses a locally developed system called "share" for teacher/student file transmission. See his comments here.
Many of the long-standing methods of text transmission work only with lower-ASCII code, which means that only numbers and basic punctuation, in addition to the upper- and lowercase alphabet sets can be transmitted. Characters with accents, 'smart' curly quotation marks, etc. can't go for the ride. This presents a serious problem for European languages which rely on special diacritics. Furthermore, each line needs to end in a <return> character to guarantee that the text arrives with the intended formatting.
File names can also cause confusion if not used judiciously.
Each of these considerations is discussed below.
Most word processor software has a method for placing a <return> at the end of each line. For many, this is done through the choice of 'Save as Text with line breaks'. For others, the text needs to be selected and then 'Break lines' selected from the edit, or perhaps macro menu. If the document had made use of its 'first line indent' feature, however, all such indentations will disappear -- or rather, all lines will become indented since each line now constitutes a 'paragraph'. Text intended for conversion should thus be typed with an additional line of space between paragraphs, or with spaces for indentation so that they are properly offset in the converted ASCII text.
There is normally a way to turn this feature off. If the text already contains curly quotes, they will need to be converted to their corresponding straight forms using the search and replace function.If 'curly quotes' were used
This "word" is quoted.
This RwordS is quoted.
Don't do 'this'.
DonUt do TthisU.
For languages other than English, this presents other serious problems since words cannot be accurately transcribed. The best solution here is to avoid lower ascii transmissions entirely. If both teacher and students use software such as Eudora, Netscape or MS Explorer which can encode and decode word processor files on the fly, there is no reason for using any other form of e-mail for teacher<-->student transmissions.
When returning work to students as a file, be sure to alter the file name of the originally submitted work. If you do not do so, the student will lose his original, unmarked up copy when the returned document overwrites the existing one. One method would be to add a "#" mark to the end of the filename. The student can then easily differentiate his/her original from the teacher's returned copy with feedback.
I would like to thank Ron Corio for allowing me to incorporate many of his insights, some of which originally appeared on Neteach, into this paper. Thanks also to the late Roy Bowers, Jim Duber, Bob Gettings, Martin Holmes, Nettie Tatum, Linda Thalman and two anonymous reviewers for their comments.
(See Note  below, as well)
 One instance, pointed out to me by Nettie Tatum <firstname.lastname@example.org> are distance learning courses which can be completely network-based, such as her Virtual Scholar program.
Another instance of a network-intensive application is "collaborative writing". Some useful 'starter' references are:
 There are some minor security concerns which are endemic to WWW applications of this nature:
 For an overview of current thinking, see Sharon Myers' article Teaching Writing as a Process and Teaching Sentence-Level Syntax: Reformulation as ESL Composition Feedback in TESL-EJ Vol. 2, No. 4. She, however, runs 'against the trend' advocating a return to more attention to local errors for her particular type of student.
© Copyright rests with authors. Please cite TESL-EJ appropriately.
Editor's Note: Dashed numbers in square brackets indicate the end of each page in the paginated ASCII version of this article, which is the definitive edition. Please use these page numbers when citing this work.