General Considerations and Discussion

Step by Step Instructions for Some Common Activities

Classroom Troubleshooting Tips: Miscellaneous Glitches

General Considerations and Discussion Most computer composition classes are taught in the 241 and 247 Olson Hall Macintosh classrooms, although occasionally classes or workshops are scheduled in 307 Surge IV (a.k.a. "The Boxcar"), 21 Olson, or 1102 Hart; thus, this guide provides details on upstairs Olson, but the principles should apply elsewhere. As more classes are taught in Windows-based environments, appropriate parts of this guide will be adapted to the specific differences in procedure. Nevertheless, many of the principles apply no matter what platform is being used, and apply to all computer classroom environments.

Most of the computer labs used for classes are now configured in a modified multiple-horseshoe layout with wide aisles and relatively easy access between instructor and students[for classroom layouts seeIT-Lab Management]. An instructor's computer is near the front of the room, and the controls for the classroom projection apparatus are either here or in an obvious console. It's good practice to familiarize yourself with the layout of a classroom before the quarter starts, especially if you have not taught in that room before.

For further discussion, see "Some Notes on Computer-Classroom Design and Configuration," (June 1996).

Site attendants, employed by Information Resources and supervised by Lab Management, vary a great deal in their expertise and in their people-helping skills. Some are fantastic, and some you will want to throttle (like the kid who talked loudly on the telephone during classes in 1996-97). We have promulgated a list of what we expect site attendants to know, and the CAI Coordinator can make this list available to you; attendants tend to be more familiar with network applications and with restarting procedures than with Daedalus troubleshooting, or even pick-up / drop-off routines. It makes good sense to introduce yourself to the site attendant before class, and to be sure the lines of communication are open before problems arise rather than after.

Classrooms are equipped with dry-erase boards ("Whiteboards"), and a variety of colored markers; site attendants should be able to supply you with fresh markers if what's there is dried up or if markers are missing. Feel free to erase non-official notices if they are in your way, and recognize that the computer classroom's projection apparatus allows you to do certain things without scribbling on the board. Naturally, owners of missing diskettes and other lost and found can be notified on a side board, and referred to the site attendant's desk.

All the classrooms feature projection hardware allowing you to display your computer's screen in enlarged form for the class to see. Generally the controls for these projection systems are located in a console near the instructor's computer, and you should be able to rely on site attendants for help. The chapter on "Projection screens and demonstrations" has more details.

Although we teach students that drafts are an essential part of the revision process, the lack of printer resources (due to expense and other logistical reasons) can seriously cramp our style. As of this writing, printing continues to be something of a headache in the classrooms: printer queues can stack up dozens of files and a hundred pages, taking a significant amount of time to resolve. In a room like 21 Olson, without its own printer, students and teacher must go down the hall and wait for output shared amongst other rooms--a noteworthy waste of time and attention.

When a student uses the "Print" command, the document enters an electronic queue, and the functioning of that queue depends on the local network; with lots of traffic, the flow slows down to a crawl, and nothing may appear to be happening. The network-traffic indicator may blink (the arrows in the upper left corner of the menu bar), albeit slowly, but the usual temptation is to believe that the print command has failed. Unfortunately, many students (and some instructors!) don't realize that repeating the print command actually makes matters worse rather than better (these are the people who compulsively push elevator buttons to coax better performance).

The problems are exacerbated when certain types of documents are printed: pictures and graphics-intensive Web pages can take several minutes to produce, and Lab Management is working on ways for instructors to jump their documents up in the printer queue. On the bright side, word-processed files in common fonts can print very quickly--so encourage your students not to mix fonts too much. Be aware of margin defaults and line spacing, and be sure that students (and you) get into the habit of checking layout via "Print Preview," rather than printing and re-printing.

A quick way to make an exercise fit onto fewer pages is to use "Select All" and change to a more compact font like Times, and to shrink top and bottom margins slightly by using the Format and Document sub-menus. As a general rule: keep format simple, for yourself and for your students, so that you spend most of your time on content and style, not layout or formal considerations. A dumpster-dive into classroom recycling drums will show you how many trees get wasted on tiny and preventable formatting errors.

I often will have students turn in short exercises to a drop-off folder only, and then concatenate them myself after class into one long file for printing out, one page each, with a tight font. I've gotten this down to about a five to ten-minute job of opening and pasting blocks of text, and I don't have to put up with as much in the way of screwy fonts or formats when I do it myself. It's an easy chore even when I'm brain-dead after class.

Printing multiple copies is against lab policy, and it's a waste to make slower laserprinter engines work overtime when fast photocopiers are designed to handle such loads cheaply and efficiently. This goes for Departmental printers as well. If you find a student abusing these rules, printing lots of resumes or multiple copies or flyers (it happens!), do not hesitate to see the site attendant and to note the date, time, and machine number of the user. Lab Management has developed ways to track printer abusers, and will probably institute a rationing or quota system in the near future. Site attendants are responsible to ensuring an adequate supply of printer paper, but you can check before class if you know you are assigning an exercise that will need to be printed.

Though it seems unfortunate to have to bring up policing matters such as these, they have become necessary: as more and more non-computer classes integrate electronic communication and Web research into their curriculum, the computer classrooms (with their relatively fast, reliable Internet connections and up-to-date equipment) compete favorably with the most budget-minded students' home computers and modem connections. This means that you will have more and more competition from people who are not enrolled in your class--either sitting at computers when you arrive and refusing to leave, or interrupting your class period and importuning you to let them sit and work at an "unoccupied" computer.

The latest IT-Lab Management policy allows three different signs to be posted outside labs: a red stop sign saying "class in session," a green "open lab" session, and a yellow yield-like sign allowing access during a class. The policy used to be a flat-out "Do not allow non-enrolled students to use computers during class time," but this three-tiered approach is at the discretion of the instructor, and recognizes different ways of teaching. Keep in mind, though, that there have been serious incidents in the past where an argument disrupts a class because "some other teachers" let people in to work, while others don't. Things can get very ugly, as end-of-quarter panic and guardhouse-lawyering habits converge, and all your forensic skills cannot recover the time and energy you lose in these encounters.

Part of the problem stems from the dual usage of the rooms: because they revert to general-access "labs" when not used for classes, the perception is that the computers are there for the using. It is for this reason that administrators are trying to fill the 241-247 Olson classrooms with scheduled classes, to confirm that these are places for classes, not for checking e-mail or surfing the Web. Be sure to report incidents to the Coordinator and to site attendants, as convincing documentation will be essential in future unfolding of the instructional-space debate.

Getting campus administrators to appreciate the gravity of this problem, or to allocate the space for computer classrooms truly dedicated to writing and critical-thinking instruction, has been a continuing struggle. Fully Internet-connected rooms will continue to offer pedagogical advantages and disadvantages for composition instructors, and better compromises may eventually be reached. As policies evolve, the CAI Coordinator should circulate updated advice and procedures at beginning-of-year meetings. With more on-campus Internet access, wired and wireless, through ASUCD and other entities, we are hoping that the pressure on classrooms will decrease. Some clarification of these issues is available in a February 1997 report to the Instructional Space Advisory Group, http://wwwenglish.ucdavis.edu/compos/compcai/isag.htm  and on the "Publications" pages of the Lab Management site at http://lm.ucdavis.edu/pubs/english/.

Another seemingly minor detail involves lab / classroom maintenance: the official rules prohibit food or drinks in the computer rooms, and I feel it is a good idea to set a good example in this regard, even if it means leaving the double-cappuccino in my office to get cold. A spilled soda can destroy the circuit board of a keyboard, and if the keyboard is on a laptop, a serious spill means a dead machine. Likewise, crumbs and grease can wreak havoc with delicate mechanisms, so no matter how careful you think you are, don't risk disaster. More and more of our students (and instructors) are carrying squeeze bottles of water for that vital hydration fix; while these are less likely to spillage, the risks are still present.

We are not allowed to enroll more students than there are computers--though early in the quarter you will probably have to juggle more students if you are teaching a popular class or convenient section. I often do a first-day diagnostic and expect it to be turned in on the file server, but I bring paper forms for all students just in case of problems and overflow. Recognize that people sitting at the computer may not be on your roll list, and that the access issues discussed above can contribute to beginning-of-quarter overcrowding and tension.

Students should acquire their own diskettes so they can save their work and bring it to and from home; instructors should put this admonition in writing, as part of their beginning of quarter information sheet. However, students do not need a disk to use the classroom: if they want to take the chance, they can save files temporarily to the individual hard drives, and come back later in the day to retrieve their work. Recognize, though, that the machines are rebooted and cleared every night.

A safer way to ensure that work is not lost is to set up one folder in your class folder for temporary storage, a folder with access privileges such that students can place a copy of an essay and still retrieve it later. This folder is not confidential, naturally, but this should not be a great issue for occasional use.

The key to making the classroom servers work smoothly is to remember that dragging is key: have your students (and you!) save files to a local disk (diskette or hard drive), and then drag them to the appropriate drop-off folder--saving directly to the file server will not work. See the discussion in the Classroom Network chapter for details.

Though the computer revolution has been going for almost two decades, and most students are hip to the benefits and risks of magnetic storage media, it's worth pounding a few more times: diskettes fail. While we're at it, hard drives fail. The electronic age gives students another whole category of "The dog ate my paper" variations, and you can inoculate yourself from some of them by stressing the importance of NASA-style redundancy for critical files. Make a habit of carrying two diskettes with you, in hard plastic cases and not flimsy sleeves, so that your students see you modeling the backing-up behavior you're hoping to teach. This may sound incredibly basic, but wait until you've had your schedule thrown off trying to accommodate some distraught student who's had an encounter with the end-of-quarter gremlins.

Diskettes and Zip drives are cheap compared to the time you'll take to re-type or scan in a file lost in a diskette error. If you or your students do experience a problem reading a diskette, don't panic: sometimes a particular disk drive won't align with your diskette, and sometimes a minor problem can be fixed with a rescue utility like Norton Utilities. See a site attendant or your department's Technical Services Coordinator before you despair about recovering lost data!

Furthermore, be aware that new generations of computer viruses are a real threat to your office system and to home computers, even if the classroom computers are protected by whatever the Lab-Management pros think is adequate. Recently some nasty MS-Word macro viruses slipped through a lot of people's virus checkers--mostly Windows and not Mac--and caused serious havoc.

Beware of word-processed files attached to e-mail: an MS-Word for Windows macro virus transmitted this way last year infected several dozen Mrak Hall PC's, embarrassingly enough for the administrators who unknowingly spread them. I keep e-mail correspondence short anyway, preferring paragraph-length exchanges, and I tend to have my students send me this draft material as text within an e-mail message, not as an attachment. I can make my primitive equipment the excuse as well, arguing that simpler is better.

Handy hint: Our campus has a site license for "Dr. Solomon's Anti-Virus," downloadable from the Web. This program allows you to scan particular files or folders before opening them and unleashing their nasties. For more info see http://eclipse.ucdavis.edu/slc/content/drsolavtk.html. Use it, don't lose it!

As of this writing, the Lab Management technical folk are re-evaluating the specific means by which instructors can view, display, and control student computer screens. For many years the program of choice has been Timbuktu, by Farallon Systems; with Timbuktu installed an instructor could launch the program, select a computer to observe (say, "247 Olson Mac 11"), and voilà, that screen would appear on the instructor's machine. Observing was not the only possibility: enter a security password, and the instructor could actually control the keyboard of the other computer, albeit in a slightly slow-motion fashion due to network traffic.

However, this power had several potential drawbacks: with Timbuktu installed on all computers, a student could "spy" on a fellow student or on the teacher, whether the unsuspecting user was working on an essay or reading personal e-mail. Moreover, due to the architecture of the classroom networks, students could actually spy on students in the classroom next door, and the possibilities were slightly frightening.

Other, less invasive or more consensual alternatives are being evaluated as this manual goes to press, including Look@Me, which does not incorporate "control" functions, only observation, and notifies the potential "viewee" that an observation is about to occur, and offers a chance to reject the request. Additional, up-to-date information should be available from the CAI Coordinator and from Lab Management.

Why so much trouble with converting files from one format to another? The problem has many origins--the increasing complexities of formatting, the challenge of combining pictures and graphs with text, and the perceived need for word processing packages to make every document Web-browser accessible--but to some cynics the answer is one word: greed. For much of the microcomputer era, billions of dollars have been made in software and hardware that rendered predecessors obsolete, for no good reason. "Backwards compatibility"--the ability of one version of a piece of software to interact successfully with earlier versions of that software--and "cross-platform compatibility"--the ability of a program to deal successfully with similar files created by another brand of software or type of machine--are sometimes difficult to achieve, but in a culture of obsolescence and predatory marketing these virtues are eclipsed by the brutal realities of what the big players can do to dictate who buys what when.

Some versions of MS Word are transparent to each other: for example, within the Macintosh world, Word 4 could read files created by Word 5 files, and vice versa, but Word 6 files are not ordinarily readable on a machine running Word 5, unless that machine has a conversion utility or "translator" installed. When Word 6 came out, serious problems ensued as users realized that they would have to upgrade their hardware to run it, and would have to put up with slower speeds and a new "look and feel" compared with the earlier version. Unfortunately, most software manufacturers do not bother to maintain translators for versions more than one production cycle old, meaning that, typically, any system more than two years old--or any file created on a new machine and opened with such a system--is likely to pose problems.

For those who ponder the question of why a computer classroom should tie itself to a full-featured word processing package like MS Word, subject as it is to market forces and industry standards, I refer you to a curmudgeonly meditation on the subject at Computers in Composition.

If the only issue were Macintosh upgrades, our file compatibility problems as writing instructors would be relatively easy to deal with. The Macintosh operating system has been relatively adaptable to other systems, and it's easy to read DOS diskettes on Mac drives. Unfortunately, by design and by accident, the worlds of Macintosh and Windows have become even less consumer-friendly, especially with the advent of the Windows 95 operating system and the programs customized for it. Because of the way Windows 95 and its successors store filename information, for example, some files don't translate well, or don't open the way they should, even crashing the Macintosh system on which the attempt is being made. Files created by WordPerfect can also cause crashes and problems, sometimes because of hidden temporary files that are mysteriously bundled along with the visible file.

Sheer numbers bear out the seriousness of the problem posed by running Macintosh classrooms in this climate: a recent Lab Management survey showed that of the 80% of UCD students who owned a computer owned a Windows machine, and that percentage probably will rise if public opinion of Macintosh continues to fall--despite the institutional commitment to Macintosh and despite the Mac OS' edge in certain key respects. It is thus very likely that your students and you may be running Windows applications and then carrying DOS-formatted files to the Mac classroom for manipulation, and some problems will inevitably occur.

Here are some ways to minimize the hassles caused by file incompatibility (and recognize that future developments may render these unworkable or (I hope) unnecessary):

This means learning about the "Save-As" option offered on every modern word processing package, and having the discipline to remember to use it. Because nearly every manufacturer dances to the Microsoft beat, you can expect every word processor to offer some early version of Word as an save option, and office or classroom Macs will be able to read these files; your students can flag these specially saved versions with a suffix or extension so that "psmith" becomes "psmith.mac" for your convenience. Because we are more interested in text than in formatting niceties, text-only versions or RTF (Rich Text Format) versions can also provide usable files for you to work with.

Students who forget to convert files should not expect you or even the site attendant to solve the problem, especially not during class time. I have suggested that if the file-conversion problem becomes too great, and if the price of Windows machines continues to drop, Lab Management should install a Windows machine in each classroom, dedicated to use as a conversion station only. Until that happens, remind your students that downstairs Olson has fine PC labs in which they can open their files, save them as something readable, and bring them back upstairs.

The Information Resources computers have a "shell" program ensuring that only users with valid UC Davis usercodes have full access to the classroom servers and network software. This means that students and faculty should log out at the end of a class session, returning the computer to the login splash screen. Otherwise, someone else could sit down for unauthorized use, and if that unauthorized use brought in the electronic detectives, the tracking after-the-fact might point the finger at the wrong person. Quit any applications you may have launched, and choose "Logout" from under the Apple menu.

[Please note that the look and feel of these routines will inevitably change in the coming months and years! ]

On first sitting down to a Macintosh in one of the classrooms, you and your students can expect to see a splash screen like this:

This is the standard lab and classroom login screen (as of 9/97). Lab Management activates temporary usercodes early in each quarter to accommodate new arrivals without usercodes; see beginning-of-quarter memos for details.

If you type your usercode and password correctly, the following reminder will appear:

If you make a mistake in typing, or if your usercode is not valid, discouraging news will appear, after which you can try again:

Please note that Lab Management sets up temporary class usercodes and passwords each quarter, allowing you to bring along new students or accommodate people who have forgotten their passwords. (Those in the latter category can get back up and running with a visit to IT-Express.)

Logging in as "Mac-guest" instead of using the temporary class usercode and password brings the following warning:

It's vital to understand that a Mac-Guest user will still be able to launch certain programs, but will not have access to the classroom file server--and thus, will not have full functionality of the machine.

For example, launching Daedalus without access to the file server will prompt the following warning--but the program seems to launch afterward!

You can click on "Open" and the normal Daedalus entry prompt will appear, but do not be

deceived. Because the "Daedalus Preferences" file is obtained only from the file server, the program tries to find it, can't, and opens as best it can.

Unfortunately, a student who has launched the program this way will not be able to join an InterChange conference. Attempting to do so will bring only a plaintive Mac error beep and a message like the following:

This is one fairly frequent explanation for "disk error" messages, and it's worth understanding. The more of these problems you can quickly troubleshoot yourself, the more confidence your students will have in you, the less you be dependent on site attendants, and the more you will control the rhythms of your class.

IT-Labs will be adding a "Programs" pull-down menu under the Apple icon, which will allow users to launch commonly used programs (including Daedalus) without having to look on the hard drives....

As expected, things may look slightly different from the way they are depicted on the following pages, after these changes are instituted.

Currently, the most common applications are launched from under the Apple menu, in the upper left-hand corner of the screen. Launch MS-Word by pulling down the Apple Menu and selecting the appropriate choice. With the mouse button still down, you can move the pointer to the right of the black triangle and highlight the choice you want:

Users logged in as Mac Guest will not be able to access the file server, and thus will not be able to use certain vital parts of server-facilitated programs.

Use the Apple menu to launch Web browsers and Telnet sessions. selecting "Network Utilities":

Users logged in as Mac Guest will not be able to access the file server or the network, and thus will not be able to surf the Web.

As of Fall 1997, the Lab Management group is still supporting the Timbuktu screen-sharing program by Farallon Systems. This package allows an instructor with a password to look at students' screens, or display another computer's screen on the overhead. The Timbuktu password is changed periodically for security reasons, and if you want to use this program you must get the password from the Computer Coordinator or from Lab Management supervisors.

To launch Timbuktu, pull down the Apple menu and highlight Timbuktu. The following dialog will appear:

To observe a computer, find the number of the computer (be sure to select the proper classroom--it's easy to confuse "241 Olson Mac #6" and "247 Olson Mac#6"); the previously grayed-out buttons will appear, as below.

Click on "Observe." The password dialog prompt will appear, with your password echoing as dots:

If you have typed in the password correctly, a somewhat surreal version of the student's screen (with an inverted-video white-on-black border) will appear on your screen. If the student moves the cursor or entry point, you see it:

You can use Timbuktu to "Control" another student's computer, but the results are not always satisfactory: the cursor movement is jerky, and seasickness is a real problem until you get used to the lag.

In addition, there are security issues and privacy concerns surrounding any such "spying" program, and last year a student with the password was caught peeking at an instructor's screen while she was reading her e-mail. Lab Management is currently evaluating alternatives to Timbuktu, especially those that require an acknowledgment on the part of the "viewee."

This section contains various warnings and describes minor problems that don't fit neatly into other categories. Some of them stem from peculiarities of the Macintosh operating system (MacOS), some of them from IT-Labs' configuration of the classroom machines, some from mechanical issues that seem to arise in all multi-user environments.

Problems with network or file server:

If a student (or teacher) seems to be having inexplicable problems connecting to the network, make sure that the File Server icon is visible on the desktop. If it isn't, there are several explanations: the server may have crashed (rare), the network connector cable may have been jostled loose from the back of the computer (pretty rare), or the machine may not have been fully logged in in the first place (most likely).

Note: some notebook computers "go to sleep" and lose their network connections when their covers are closed. DON'T have students shut their PowerBooks during discussions. 

"Screen saver blips out everything"

Usually at least one student reports a distressing and frustrating syndrome, wherein the screen is continually reverting to the screen saver (in the classrooms, a dark screen with a white clock face dancing around). They try to type, and the screen goes dark. What this usually means is that the mouse pointer is pushed all the way to a corner, triggering the screen saver to come on (the classroom computers generally have been configured so that hackers cannot sabotage computers easily--it used to be easy to reset things so that a five second pause without a keystroke would trigger the screen saver). Have your victim move the mouse pointer into the middle of the desktop somewhere and see whether this alleviates the condition. If not, get the site attendant.

Windowshading

The first time I experienced this weird phenomenon, I thought I was going crazy. I had double-clicked on what I thought was a file icon, but suddenly the window in which I was working rolled up into itself leaving only the title bar! There was nothing to grab to open the window again (the size box had disappeared as well), but luckily a site attendant was familiar enough with features of the then-new MacOS System 7.5 to tell me that this was a feature, and not a bug.

With this feature activated, double-clicking in a title-bar rolls the window up, and another double-click returns it to normal size. Unfortunately, in certain applications (including Word), double-clicking in the title bar is the same as sizing the window, and in some classroom settings the windowshade "feature" isn't activated at all.

Too-many-people-opening-Daedalus

The most common problem one encounters with the Daedalus package is that there are two Daedalus application icons that can be double-clicked, one on the hard-drive or apple icon (the correct one), and the other on the file server. The file server does have a Daedalus folder, and there is a Daedalus application in it; however, if a student tries to launch the program by double-clicking on that icon, the following message appears:

As with other error messages of this type, be prepared to deal with an attitude problem as well: "I tried to launch the program, but it says there are too many users." Gently remind the frustrated user that launching from the hard drive is not the same as launching from the server. Murphy was an optimist.