ADMINISTRATIVE NOTES NEWSLETTER OF THE FEDERAL DEPOSITORY LIBRARY PROGRAM Vol. 19, no. 11 GP 3.16/3-2:19/11 September 15, 1998 READERS EXCHANGE CONVERTING A DOCUMENTS PROCESSING MANUAL TO HTML by Anne L. Noss Government Documents Assistant Drew University Library Madison, NJ 07932 anoss@drew.edu Drew University Library has been a selective (36%) depository library since 1939. As Documents Assistant, I supervise the processes which take our item selections from the mailroom to the stacks. This work requires the annual hiring and training of about four student employees, who must learn how to check, mark, sort, enter, and shelve the incoming documents and how to troubleshoot any complications which arise. To help the students learn and perform these duties, I wrote an office manual in 1991. Entitled "Procedures for Processing Government Documents at Drew University Library," it proved to be a successful training/reference aid and was singled out for commendation during our last depository inspection. Nonetheless, early in 1998 I converted the manual from its print (WordPerfect 6.1) format into HTML, and since that time our students' access to it has been entirely online. In the hope that our experience may be helpful to other depositories, this article will discuss how and why that decision was made, what was involved in the conversion, and how the change has affected our work thus far. The Problems With Print The paper manual went through many changes over the years. It served the office well, but it also had some fundamental problems. First, revisions were both frequent and time-consuming. Student feedback, and my own observations, often prompted new or clarified material; there were also many changes in the DLP's products, procedures, and services. The manual grew to some 85 pages, and almost any revision involved reprinting quite a few of them. Reprinting, in turn, meant extended use of a cranky, noisy dot-matrix printer, made more onerous by our need to maintain two copies. Revisions were nonetheless done when needed; but the experience didn't inspire further development. Second, while the manual was a good training tool, ready reference was an ongoing challenge; again, due to the volume of material. We eventually settled on an intricate I/A/1/a/1)/a) format throughout the text, with a correspondingly intricate table of contents. This did the job, but hunting for such headings as "II/B/4/c/1)" certainly fell short of optimal ready reference. Third, some procedures were so complex that they were difficult to make "friendly" in this format. The process for troubleshooting "missing documents and mystery documents" was presented in flowcharts; certainly an improvement over text, but admittedly rather alarming to navigate if you'd been up all night preparing for a Psychology exam. The Case for HTML In writing the first version of the manual I'd experimented with WordPerfect's hypertext function; its benefits for relating material and providing quick access were obvious. But hypertext documents required a computer, and our office had one desktop. (The students had their own computers, issued to all freshmen since Drew's Computer Initiative in 1984, but these, too, were desktops.) With up to four possible employees, we needed multiple copies of any office manual; and since it would be consulted in many locations--on the students' work desk, near the shelflist outside the office, up in the stacks--it also had to be portable. Putting the tentative idea of a hypertext manual aside, I proceeded with the most appropriate format, print. But by 1998 the situation had changed. There was a Web and an HTML standard, I had become comfortable with basic HTML while working on the library's home page, and--most crucially--Drew University's students were now being issued laptop computers with modems. Moreover, the library had its own server where files could easily be uploaded and revised. The world of Documents had changed, too; although processing had become increasing complex, it had been greatly facilitated by online tools such as the Item Lister, the MOCAT, and the List of Classes. I'd been teaching our advanced students to use these tools, but they couldn't be seamlessly integrated into a print manual. Considering all of these factors and our intractable problems with the print version, it seemed to me that we'd reached a point where our student employees would find an HTML manual more accessible than print and no less functional, and that its revisions/expansions could be carried out far more efficiently. Our Documents Librarian, Jan Wanggaard, gave her support to the project. Somewhat over a month later, the manual went online. Creating the Online Manual To anyone considering such a project, I would say: don't try this without a good HTML editor! Without the capability of inserting tags, doing multiple find-and-replaces, and easily creating tables, frames, and links, the job would have been impossible. My editor at that time was Brooklyn North's "HTML Assistant Pro 97," which automates the above-mentioned processes but allows work directly with the code. I like this sort of editor because it helps in learning HTML, but there are many fine Web editors which minimize contact with the code and are more like a word processor. Follow your own personal preference. The important thing is to find an editor which suits the way you like to work, supports the HTML functions you want to try, and has help that's appropriate for your level of experience. Most editors have downloadable demo versions which you can test. This may take a bit of trial and error, but for any major project the investment of time will be repaid many times over. The first step in the conversion was developing the online manual's design and format. Since improved navigation was a major objective, it had to be addressed in the basic layout. So I decided to display the manual in two frames; that is, two sections of the screen. The smaller frame, which would always be visible to the user, listed the main Contents; the larger frame would display whichever section of the text had been selected by clicking on a Contents link. This is a widely used, practical approach to navigating a large online text. Aesthetic concerns were addressed next: freeware graphics such as buttons, a background, an "up" arrow, and the FDLP logo were located and used to help create a simple design. At that point, I was able to create a template file with all the design-related HTML codes; the template would provide a time-saving starting point for all the pages yet to be created, because the design elements would be common to all of them. Content was the next issue. The general plan was to maintain the subject sections of the print manual, and set up each as a separate HTML file, with the section's topics as internal links at the top of the page. This continuity was intended to ease the students' transition from the print manual. Fortunately, although some of the sections were rather long, their HTML versions all loaded at an acceptable speed. As for the text itself, it soon became clear that to simply import or copy/paste from WordPerfect into a template and add formatting codes was only a start; a true conversion required more than that. The online environment provided new ways to present the same information, and for the conversion to be successful we needed to take advantage of whatever possibilities I could identify. Accordingly, the existing manual would have to be critically reviewed and substantially rewritten. At the most basic level, it became clear that paragraphs which seemed of reasonable length in print appeared interminable on a monitor, particularly since they were displaying in only part of the screen. They had to be "chunked" to remain palatable, which provided an opportunity to condense and clarify the content whenever possible. But beyond that, there were many instances where the information could be structured differently for more efficient use. For example, our students had always checked the item numbers on every Shipping List against our depository selection list, about 20 annually printed pages with pencilled-in adds or deletes; the same list in columns on a single scrollable page not only allowed much faster scanning, but could be easily updated throughout the year whenever we revised our profile. Another example of reformatting was the "troubleshooting" procedures which had previously appeared as complex flowcharts. Here, the online environment provided two major advantages. First, the if/then steps could be displayed one at a time, in different files (or widely spaced sections of the same file), so that students were not intimidated by the complexity of the process. And second, the text could include links to the online tools essential to the troubleshooting: the Item Lister, LOC, and MOCAT, making the process a seamless one--even, as events proved, an engaging one. A final example of restructuring for the online environment was the crucial matter of ready reference. The print manual's detailed table of contents was replaced by a variety of search options in the online version. First, as mentioned, the main sections of the manual appear at all times as content links in the smaller frame. Second, one of those links is for a site map, which allows a student to scan the entire structure of the manual at a very detailed level and access any topic of interest with a click of the mouse. Third, each section has all of its topics listed as links at the top of the page. Finally, the section called "About the Manual" asks students to use Netscape's "Find" for locating specific text on any particular page. These combined options would, it was hoped, give our students the quick ready reference that print never adequately achieved. As the files were developed, another step was checking how they would look online. Tests showed differing displays in Internet Explorer and Netscape, because of the choice to use some Netscape-proprietary coding. For instance, our item selections list--which displays neatly in multiple columns in Netscape--forms an extremely long single column in the tested version of Internet Explorer. Additionally, the choice to use frames meant that the manual would not display at all in a text browser such as Lynx. If the manual was intended to be a public-access document, these would have been very significant concerns. But since it was planned as an in-house reference tool and Netscape is our campus browser, I kept to the design. However, testing with multiple browsers is generally a good idea, even if the results are disconcerting! The occasional innovations notwithstanding, there is no denying that much of the "creation" process was simply work, neither creative nor exciting. A lot of HTML coding is repetitive and all of it has to be checked. To speed things up a bit, I created a "coding" page containing all the lines of codes which were used repeatedly, such as

, which inserts an "up" arrow after each topic. With the coding page loaded at all times in a separate window, I could just copy and paste as needed. To complete the manual, every link was tested for accuracy and every page went through a spell-checker; finally, it was ready for the upload. Using the Online Manual Our student employees can access the manual either on the Web, using a modem jack in the Documents office, or from two floppy disks kept at the work desk. The floppies provide a backup for the rare network downtime; the only tradeoff, of course, is access to other online resources. The "new" manual was in use throughout the Spring 1998 semester, when we were retraining two new students and had two returning students. In theory, this provided a perfect environment for its evaluation. One snag was that our experienced students (who have older computers) needed some software installation before their laptops could access even the floppy disks, although they viewed and used the manual on the office desktop. Fortunately, one of these experienced students stayed on to work during the summer, by which time his notebook was up to speed. All the students were aware that they were, in a sense, "beta testers" for this format, and they were encouraged to share their reactions. So both their comments and my observations can be reported at this time. The new trainees used the manual easily from the outset, and were soon carrying out some sophisticated procedures (i.e., guessing an item number might be a new one because it didn't appear in the Item Lister) which their equally capable predecessors hadn't mastered until much later in their training. One trainee reported finding troubleshooting distinctly enjoyable! The most experienced employee, a graduate student who is older than his co-workers, did not come to Drew with a background of computer use. He told me that although abandoning the print manual was difficult for him, he felt the online version was easier to use in every way. He particularly liked the integration of online Documents resources. In fact, he suggested that I set up a page listing those links (at that time all embedded in the text) so that he could go to them directly. This was a great idea, so I created a page called "Other Useful Links for Documents Work" which is now heavily used. In the electronic version, as in the print version, student feedback makes the manual more useful to all of us. "Other Useful Links" was just one example of what to me, as the author, is a tremendous benefit of the HTML format: the capability for easy, quick revisions and additions. All that's involved is typing up the text in the HTML editor, perhaps making changes to the Contents and the Site Map, then uploading the file to the server and copying it to the two floppies. Jan Wanggaard and I agreed that this opens up all sorts of possibilities for expanding the scope of the manual, as well as improving its present contents. Indeed, some of the design elements of the manual have already been totally redone, again incorporating student feedback. So, although time may further disclose both benefits and difficulties with the new manual, its initial utilization has been entirely positive. But I'd emphasize that this conversion would not have been feasible until the students' laptops made electronic format as portable as print. Given that development, it appears that having an online procedures manual will streamline our students' training, provide fast ready reference, and facilitate development and revision. For those depositories where the infrastructure is suitable, it may be an option to consider. Procedures for Processing Government Documents at Drew University Library is located at .