 |
|
|
|
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
| Services | Tips | Theory | WebPoems | Workshops | Books | Articles | Lisa | Jonathan |
Our Articles ... |
On Complex Documentation |
|
On
Personalizing Content
|
Editing a Website: Extending the Levels of Edit (DRAFT for IEEE Transactions in Professional Communication. March, 1998. 47-57) (An alternative description of this research is available in Proceedings for STC Region 5 Conference, Fort Worth, Texas, February 20-22, 1998). By Steve Anderson, Chuck Campbell, Nancy Hindle, Jonathan Price, and
Randall Scasny This article describes lessons learned by an editing class at the New Mexico Institute of Mining and Technology when they attempted to edit a website created by others [1]. Far from being the simple text-editing project the students expected, their venture turned into a major overhaul of the site, dealing with screen design, coding, interface issues, and interactivity. The Levels of Edit concept, familiar to most editors, provided a framework to help the class organize the work. As used in this Elements of Editing class [2], the Levels of Edit look like this:
How the Project StartedMany first-generation Websites have been put up hugger-mugger, in a rush. Certainly that was true for the Humanities Department at New Mexico Tech. In 1995, Jonathan Price designed the site [1], calling upon his many years of experience consulting, writing, and teaching hypertext. The structure and text (much borrowed from the college catalog) were then converted into HTML and put up on the Web by Chuck Campbell, who also teaches the editing course in the Technical Communication program. A year later, Price and Campbell could see that the site needed work. Extra sets of pages had been attached to the site; the layout of some pages had been changed, sometimes dramatically; and with the addition of student and faculty home pages, the site had grown like a city without a planning department. Campbell decided that editing the Website would make a good project for his class in Elements of Editing, with students Anderson, Hindle, and Scasny. Campbell was looking for a group project like ones his editing classes had done in the past--projects that involved working together as editors and interacting with clients. Typically, the editing class [2] spends some time working individually on Level One issues (correctness and consistency) and Level Two issues (clarity and coherence). Usually, a group project provides most of the Level Three experience that can be packed into a sophomore-level course. Price agreed to act as client, and asked the class to consider four questions about the Website:
At first glance, the student editors concluded that the site contained enough information, in a few dozen pages; but as they explored more deeply, they discovered that there were actually 59 separate files, containing more than 8,000 words. The site looked simpler than it was. Contemplating the structure, the class spotted three interrelated problems. First, several new sets of pages had been added, dealing with a Writing Center, the student chapter of the Society for Technical Communication, plus student and faculty home pages. Second, though nominally the Humanities Department website, most of the pages described the Technical Communication program, which offers a Bachelor of Science degree. This program is the only major offered by the Humanities Department, which otherwise provides the liberal arts component (foreign languages, philosophy, history, and English) of science and engineering degrees offered by Tech's other departments. And third, the layout of pages varied in different areas, suggesting that the visitor had somehow left Humanities and entered whole new worlds. For these reasons, the editors felt that the structure was no longer entirely clear, and so navigation also seemed a bit uncertain. In addition, the tone, particularly of catalog entries, seemed too academic to the
class. Their concern provoked a discussion of audience, during which the editors decided
to expand the intended audience beyond current students and faculty to include alumni and
potential students, who might be cruising the Net looking at colleges. That change meant
that we needed to modify the tone throughout, to make it more informal, conversational,
and appealing. Given all the concerns about the site, we found that the Levels of Edit approach, familiar to editors of print documents, offered a way of organizing and understanding the work. The Levels approach helps editors define, ahead of time, the type of editing that is to be done. Levels may be described informally as "light, regular, or heavy," or elaborately, as with the nine-level structure developed at the Jet Propulsion Laboratory [3]. Three levels seem to provide the most widely used framework; for example, Donald Samson in Editing Technical Writing recommends three "degrees" of edit [4]. Likewise, the central communication group at Los Alamos National Laboratory has recently moved from a four-level to a three-level system [5]. The role of the Level Three editor, as presented in Campbell's editing class, is analogous to that of an architect on a remodeling project; of the Level Two editor, to that of framing carpenters and masons; of the Level One editor, to that of the finish carpenters and trim workers. For print documents, editing at the different levels may take place in different "shops." In the book publishing trade, for example, a general editor makes major design and content decisions; a developmental editor tends to work on the structure and prose, with perhaps a little attention to the use of visuals to augment the text; a copyeditor deals with issues of correct language; and a production editor confirms the correctness of format, ensures the integrity of text and art files, and coordinates the many overlapping tasks involved in printing. The half-life of a textbook produced by this process can be measured in years. Perhaps the print situation closest to websites is the manual set that comes in looseleaf form for easy updating. For the manual set, top-level decisions about design, layout, audience, and format tend not to change much over time, though change pages may be sent out several times a year. The structure and the page numbering scheme allow for additions, deletions, and substitutions. Most of the editing is at Levels One and Two. Though analogous to manuals, websites do not lend themselves so easily to this kind of compartmentalization. For one thing, a website is more evanescent than a book or a manual set. It is much easier (if not actually easy) to make major changes in structure and layout. Because websites are interactive, they can be changed more readily in response to needs expressed by visitors. Hence, a more appropriate paradigm for website editing would be interactive rather than production-line oriented. An interactive paradigm for design might be based on a work such as that of Kaufer and Butler, whose Rhetoric and the Arts of Design [6] theorizes interactive modules in rhetorical design space: plans, or underlying worldview; tactics, or the means for achieving objectives; and most importantly for the editor, events, response in real time to input from the environment. Kaufer and Butler's paradigm is intended for oral discourse, but websites resemble oral discourse more than books in terms of interactivity. This interactivity makes the style of working together very different. Publishing a book requires serial cooperation--different editors applying their particular expertises to a manuscript one after another, with discussion occuring mainly at the intersections of tasks. Website editing, on the other hand, requires that people with different expertises collaborate in real time: content is affected by design parameters; design is constrained by HTML coding possibilities; HTML and screen sizes affect content. In addition, because of this interactivity, when editors turn their attention from paper documents to screen materials on the World Wide Web, the nature of editorial work changes at each of the three main levels of edit:
Level Three EditingLevel Three editing of websites, we found, required us to ask fundamental design questions:
These design questions led in turn to implementation questions:
Design DecisionsRefining the audience definition. Redefining the audience may be the greatest challenge a website editor faces. In book publishing the audience is pretty well defined when the contract is signed by the acquisitions editor; all editors downstream need only follow that lead. But the Web beckons many unexpected visitors, some of whom must be reckoned with after the initial site has been created. For example, when the student editors reviewed the Humanities Department website, they sensed that it was intended primarily for current students and professors. The language emphasized the mission of the Humanities Department and its academic importance in a university curriculum. The pages looked formal--almost official. The student editors concluded that the website ought to extend its appeal to prospective students, most of whom are in high school or other colleges, business people who might be interested in hiring our graduates, and casual surfers. Rethinking the structure. Generally, in book publishing, the time for restructuring is early; a developmental editor may suggest changing the order of chapters, or the sequence of topics within a chapter, starting with the writer's outline, and continuing during the writer's first pass through the material. But with a website, the editor often faces a fait accompli, because earlier materials have been cobbled together and posted, just to "get something up on the Web." The result is not as carefully thought out as a book. In our case, the editors faced multiple page sets added after the original design (a writing center, a student society, and many individual home pages), plus an uncertain relationship between the Technical Communication program, which had more than half the pages, and its parent, the Humanities Department, which includes many other subjects. The editors debated how far to distinguish the program from the department. Should they be separate but equal, because the program is the only one within the department that actually grants a degree? Or should the program appear as a component of its department? As a compromise solution, the editors showed the program as part of the department, but created distinct page layouts, using different background colors within a similar frame structure. Hence, reopening the issue of structure led to reorganization of the items on menus, and redesign of the actual pages. Redesigning the layout. Editors used to working within a fixed corporate book design may be surprised to find themselves debating background colors, frames, and tables when the constant change of Web content explodes layouts that worked fine with fewer topics or less complex relationships between topics. In our project, layout turned into an ongoing discussion, revolving around the related problems of navigation, identification, and presentation of content. To provide constant access to a high-level menu, the editors decided to create a frame on the left (but what topics, exactly, would appear there?). To identify the site, the editors conceived a banner frame at the top (but should that always say "Humanities Department" or should it sometimes say "Technical Communication?"). And, for the text itself, the editors came up with a frame on the right (But that left so little room that some text had to be rechunked and reassembled). Hence user interface problems drove the team to a fundamental redesign of the page layout. And within this new frame structure, the editors chose a light-brown background and chocolate-colored text for the Humanities pages, to give it a somewhat warmer look, and picked a slate-gray background with black text for the Technical Communication pages, for a more professional look [1]. Hence, a concern for Level Two cohesion within each section resulted in a Level Three design decision to refine the page design even further. Choosing a version of HTML. A major difference we found between editing print and editing websites was the amount of technical knowledge required. Print editors even in the age of wordprocessors still tend to do their editing on paper; they may need computer skills only to the extent of being able to enter their edits onto a wordprocessor file. A website editor, on the other hand, cannot do without a working knowledge of HTML. Choosing a version of HTML may seem like an overly technical question for editors as a Level Three decision; indeed, it is a question that editors might not raise if they are accustomed to using a word processor or browser's automatic HTML formatting features. But it is important to consider because HTML is not the same from browser to browser. What looks nifty in one may not work on another. Though official groups have been propounding standards over the years, the "correct" version of HTML is often that used by the currently most popular browser. First there was Mosaic, propagated among the Unix community; then came Netscape and the commercial explosion of the Internet; now Microsoft's Internet Explorer is the up-and-coming browser du jour. With competition heating up, each software company adds its own special tags to make its browser better than the competition's. The result: some features that can be viewed in, for example, Netscape Communicator are not visible in Internet Explorer, and vice versa. Further, those who like standards insist that HTML follow a SGML document-type definition (DTD). SGML is Standard Generalized Markup Language, defined in ISO standard 8879:1986 [7]. It is a meta-language for defining document structures for the application of mark-up schemes. SGML itself is not a mark-up scheme--it does not define mark-up tags nor does it provide a template for a particular type of document; rather, it denotes a way of describing any mark-up scheme. HTML is one of the document types that have been defined using SGML [8]. So the question of what HTML version to use becomes a difficult one. The best answer is to balance the needs of a site with the desire for correctness. If adding the tag of the week does not detract from the re-usability of the site and it really adds to the effectiveness of it, then by all means use it. Be aware, however, that that tag may not work on all the browsers, and it may be phased out in the next release of the same browser, bringing up problems for future maintenance. Implementation DecisionsMaking a Site Map. As they began to think about editing individual sections, the editors realized that they did not know which files corresponded to which pages displayed in the browser. They had to find the right file by trial and error, which often took a long time. Also, several times, one editor would accidentally modify a file that someone else was working on. Such confusion would not occur in a well-run publishing house, because the production editor would have imposed discipline on the filenames, but in the wonderful wide-open world of the Web, many individuals can hook up to the site, without following any file conventions, and the result is a directory full of weird names in no particular order with no recognizable connection to the titles displayed onscreen. As an aid to the editors, Anderson created a top-level site map, showing the screens accessible through the top few levels of the menu and their corresponding HTML files. This tree structure was such a help that the editors longed for a complete one to locate every file quickly. Creating a style guide. As a new genre within a relatively new medium, the Web offers few established conventions, and even fewer usable styleguides. Perhaps the best to date is the one put out by Patrick Lynch and Sarah Horton, which approaches Web page and site design as "a challenge that combines traditional editorial approaches to documents with graphic design, user interface design, information design, and the technical authoring skills required to optimize the HTML code, graphics, and text within Web pages" [9]. Like the styleguides posted by Ameritech [10], Apple [11], and Sun [12], the Yale guide is generic. We needed one of our own. But we did not create it at the beginning of the project, and for that we suffered. As a team, the editors agreed roughly on many issues but differed when applying those decisions on particular pages; so variations appeared in graphics, frames, background and text colors, and titling. With a real styleguide, the editors could have avoided hours of guesswork and re-editing. Testing the Effectiveness of the Redesigned SiteTouring like a user. After some changes had been made, the editors asked Price, as client, to take a tour of the evolving site. Sensing that the editors, focusing on large issues of design and organization, had lost touch with the experience of a real user moving through the site, he reported as if he were a visitor in a foreign land. Without much regard for the editors' sensibilities, he wrote down how he reacted to the text, art, and layout, moment to moment. In essence, he recorded an emotional, intellectual, and entirely personal tour, very unlike the diplomatic queries most editors have been trained to raise with authors. The point was to shock the editors into recognizing the actual, felt experience a user might have moving through the online system. Looked at intellectually, the structure may be fine, but hell to go through. Price stressed the cycle of choice, movement, adjustment to the new location, exploration, and decision to move on. Many sites seem OK in terms of information, but give the user an experience something like going down a zigzagging tunnel with blinders on. No exit. Movement through is the defining experience for users, and the editors needed to get a sense of what their site felt like, to a user. Here's a sample from the narrative: When I click the link to Technical Communications within the text on the Humanities page, the Humanities banner remains where it was, and the yellow menu stays in place, but on the right I see a list of topics. The first one, Technical Communication, seems to be a title. Is it just a title for this list, or is it a clickable item that can take me somewhere else? If the text is a link to some other location, I wonder what information I will find there. So, like an idiot, I click it, and discover I have wiped out the banner altogether, and gotten rid of the lefthand menu. But I have not made any progress toward finding out about Technical Communication, because I am still looking at the same list. So I have gone somewhere, but I have gone nowhere; I have destroyed, but not made progress. Disconcerting! This review shocked the team into reconsidering its working methods, because the lack
of coordination was clearly leading to bumps in the road for the user. The editors found
that the personal narrative, internal monologue, and emotional tone of the tour made them
more aware of the confusion felt by a user. That discussion led to increased efforts at
improving clarity and cohesion, as well as simple consistency--in other words, to renewed
work at Levels Two and One. Level Two EditingAs in Level Three, we found that differences between print and website editing at Level Two put a premium on the visual. In print, Level Two editing aims to improve clarity and cohesion of prose. It also checks for overall document cohesion by verifying cross-references within the text. With a website, prose can be made clear and concise by familiar strategies: using direct, referential nouns and vivid verbs; avoiding sentences that sprawl across the screen so that they create a visual block, both literally and metaphorically. Text is made concise by dividing it into small units so that each screen contains one complete thought and relates clearly to other units on other pages. The pages of our site had been designed in small units in the first place, so we did not have to create many new pages. Our Level Two editing consisted mostly of making sure that links were meaningful, so that a user interested in finding more information could travel deeper into the site, or to linked sites, pursuing a line of thought. The ability to pursue a line of thought gives the users the impression that the site is coherent. Improving Clarity and CohesionEnsuring clarity and cohesion is a little different on a screen than on a printed page. We tend to think that words, more than visual attributes, dictate the message on a printed page, with each paragraph supporting the theme and providing a transition to the subsequent paragraph. Since a web page is more a graphical than a textual medium, website developers often use visual attributes to communicate information or tell their story at the expense of a textual narrative. While these visual attributes can add to the message, they can also detract from the clarity of the web page if they are overused or inconsistently applied, or if they overwhelm the screen. So whether an editor is working with text or visual attributes, the same kinds of questions apply to both:
Though these questions arise for printed pages as well as screens, readers have more tactics, such as skimming and browsing, for dealing with bad design in books than in websites. For the student editors in their initial visits to the Humanities website, many of the pages were difficult to read because each screen covered a lot of information. They found that what may be coherent on paper may seem overwhelming on screen. This effect may occur if the screen is thought of as equivalent to a paper page. A better way of looking at editing a screen is to think of it as a paragraph: only one main idea should be presented on each screen. Since there will be many screens to bridge these "paragraphs" together, cohesion devices must be applied to make a series of screens feel consistent and function as a group. For example, repetition of words on page headings helps users know they are still following a consistent theme within a group of pages: e.g., "What do technical communicators do?" linked to "Where do technical communicators work?" Transitions from one screen to another became the subject of debate. Traditional prose transition devices ("as we have just seen," "therefore") don't work on a website because the user may not follow the intended sequence. Prose transitions to subsequent pages will work if the user can be counted on to select the "next" button. But users (as opposed to readers) can't be counted on to follow the intended order. So named-topic links instead of "next" and "previous" were inserted. Modifying Style to Reflect New Audience DefinitionMatching style to audience is a task familiar to most writers and editors. However, we quickly understood that our audience was much wider and more diverse than the audience the students had inferred from browsing. After we had some long discussions about audience, with some reluctance by some members of the class, we made some choices about a style that would appeal to an additional target audience--prospective students. To make the website more appealing to prospective students, we changed to a more informal style. Here's a before and after look of a description of the purpose of humanities courses at a technical college on the Humanities homepage: Before As part of their college experience, students should grow toward critical awareness and broad understanding of the ideas and values that have characterized human history and experience. After Our students take Humanities courses to give them the ethical, historical and multicultural sensitivities to create technologies that people need, want, and can use for the benefit of all. Our client and the class agreed the style changes made the page more appealing to our audience. Changing the style to a simple, no-frills language also improved the clarity and the impact of the page. Compressing and Reducing VerbiageWebsite editors, more than editors working in print media, have to think about how the medium itself affects the way people read. If a book is interesting and well written, a reader can tolerate long paragraphs. Even if the pages on a website are well written, long paragraphs are likely to inspire surfers to go elsewhere because reading a typical screen is like reading a fax: the resolution, being lower than that of print, strains the eyes. While writers rely on their words and may fear that they are not being complete enough if they don't write detailed text, the reality is that if there is too much text on a screen, viewers just skip it. The point is not to delete important details, just to present them in a way that is visually appealing. It is better to write the minimum necessary on each screen, and if more is needed, to put it on the next screen or add another one. We did not learn these lessons without some trial and error. After updating our style, and our text, we viewed it. The first thing which came to mind was, "Yeah, it's better, but wow, there are so many words!" The screen communicates more graphically than textually. We concluded that we must tell our "story" with visual content and pare the text to essential information. Level One EditingIn print, Level One editing is concerned with correctness and consistency. With a website, editors must still scan for correctness in grammar, usage, mechanics, punctuation, and spelling. These issues did not take much time when we edited the Humanities website. Consistency issues, however, did loom large. Because of the relatively large number of pages, consistency in look was important. Once we had made Level Three decisions on page design and background color, we expedited the Level One work by creating templates and migrating the text onto them. Following a StyleFollowing a consistent style is as important in editing HTML as in editing print. One of the most commonly seen errors on a first-generation site is inconsistency of look and feel, caused by inconsistent coding in HTML. These lapses make the work appear either incomplete or unprofessional, just as in print media. Style guides and style sheets for the print media are used in situations that are rhetorically fossilized, situations where conventions are so well established that it no longer seems necessary to do any additional thinking about the nature of the print medium or the needs of readers. Since the Web has barely had time enough to develop conventions, let alone fossilize them, the kinds of issues that might be enshrined in style guides are likely to be less concerned with orthographic and grammatical correctness than with standardization. One such issue has to do with the kinds of equipment users have. A frequent complaint is that Web designers create sites that work very well for people with fast computers and direct links to the internet, but try the patience of those who must use older computers with slow modems. And in response, many sites are now designed with text-only options. As noted earlier, we did not create a style sheet at the outset but came to wish we had. Such a style guide would have described the layout of two template pages, one for Humanities and one for Technical Communication. It would have specified background color code, heading sizes, titling, and link-button placement. It would have named any graphic files we were using for backgrounds or bullets. And it would have formalized the site's file-naming scheme. Correcting to StandardsCorrecting to standards is the stock-in-trade of copyeditors in publishing; far too often, it is also the main work of technical editors. The standards are published in those style guides which are ubiquitous in editing for the professions. Not only does each profession tend to have its own style guide, so does each publication within the profession. The advantage of style guides is that they save much reinventing of wheels. Their disadvantage is that effectiveness-oriented editors find them picayune and tedious; they aren't much use beyond imposing conventions consistently. Style-guide standards for print may carry over into website editing for such matters as terminology and spelling. However, rules regarding the handling in print of tables, figures, and references may need modification, since a table on a website may provide a page's structure, figures are usually the dominant feature of any web page, and references may be handled by a link directly to the cited source. Web pages' prose should follow established conventions for spelling, grammar, and usage. For spelling, people seem to rely overmuch on spellcheckers, which are notoriously bad at selecting among homophones. ("Among the cites to be scene in Florida . . .") Editors still need word knowledge. For grammar, given that the Web as a whole is meant for browsing more than reading, it is best to use the natural, unforced constructions of common speech. Enforcing File-naming ConventionsFile naming conventions are commonly used in both print media and computer programming. However, they appear to be uncommon in most first-generation websites. This isn't surprising considering that many sites originate in a piecemeal fashion, creating a trickle of new files without any consistent naming structure or file organization. Once a site has been created this way, it is quite difficult to correct. The best way we have found to correct this is to create a mirror of the original site on disk and edit the mirror files, updating the file names and links from the planned site-map. Having this mirror image on disk also helps for version control and site comparison. File-naming conventions should be laid out in the style guide. A naming scheme should reflect the hierarchical structure of the site map. For example, in our site, we had two major divisions, Humanities and Technical Communication. Thus it was natural to begin filenames with either "hum" or "tc." Enforcing Layout ConventionsLayout includes the background color, font color, text placement, frames, headers, footers, and graphics. Our Level Three decision to use a similar frame structure to provide visual continuity between the Humanities and Technical Communication pages (we used two horizontal frames, the top one carrying the logo for each page set, but decided on a left-vertical frame with a Table-of-Contents look for the menu) resulted in our creating a template for each kind of page. The Level One work, then, involved transferring text that had survived the other two Levels to the templates, then renaming the resultant files according to the file-naming scheme that was already in place. The hardest part of the layout to enforce were the colors of background and text. Everyone was working on different computers, which translated HTML color codes into different visible hues on the computer screens. In print, it is possible to specify colors very exactly. In HTML, if the editor specifies a 256-color pallette, about 210 of them will be the same regardless of whether the viewing platform is running a Mac, PC, or Unix operating system. Still, no two monitors render colors exactly the same way. Editors can only try to look at the colors on as many different platforms and monitors as possible, then modify the hexadecimal color codes so the colors look reasonably close on most of them. Link checkingOne of the greatest advantages of hypertext is that it lets the reader choose his or her own path through a series of documents. But very few things are more frustrating than choosing a link and getting an error message or a page whose subject matter is different than what the link promised. Link checking ensures that these types of errors don't occur. There were several ways we checked links. We began with a computer-based link checker program called Linklint [13]. It is easy to use and quickly verified our links. But no matter how good a program is, a computer-based link checker cannot ensure the links point to the right places; it can only check to make sure that the destination of the link exists. For example, if a link to information about hiring practices at your company actually brings up a table of quarterly earnings instead, a computer-based link checker would say it was correct. Therefore, links must be checked manually for correct content and context. After manually checking our links, we then used a link-checking service available on the Web called NetMechanic [14]. Services like NetMechanic have an advantage over locally installed link checkers because they don't require users to spend the time installing and setting up the software on their computers. NetMechanic will check websites up to 250 pages for no charge. Both Linklint and NetMechanic found similar link errors on our website. After we made corrections, we used both techniques through several cycles to ensure that we did not introduce any new link errors. Correcting HTMLIt is now possible to do much editing with programs such as Netscape Gold or the HTML formatting features in WordPerfect 7 or MS Word 7. With the advent of these more graphical HTML editing programs, there is a tendency to dismiss the need to understand HTML. The results produced by the graphical editors are often acceptable, but when a page just refuses to look as the editor thinks it should, the editor still needs to be able to open HTML files in a plain text (ASCII) editing program to change the codes. In ASCII, the coded tags appear as text; any words that appear between arrows (< >) are read by the browser as commands to produce certain effects, as in this example: <strong>This is emphasized text.</strong> The browser boldfaces the text enclosed between the tags so that it appears thus: This is emphasized text Ensuring that such tagging is correct can be done several different ways. If the HTML is composed to work best on a particular browser, one obvious way to test is to look at each page in that browser to see that it displays correctly. Another way of checking HTML is to use a validating program, such as James Clark's SP [15]. Such a program checks the HTML against a standard. Also available for validating HTML are some on-line services as well [16]. However, even if these programs show tags to be invalid, pages may still display correctly. Not all tags produce visible effects. The DOCTYPE tag produces no effect whatsoever. Neither does the HTML, HEAD, or any of the META tags. If a validation program sends a warning about a page, it may be best to look at the page in several browsers to see whether it displays correctly. If a page does not display correctly, the editor may need to have a knowledge of HTML to diagnose the problem and correct the tags. On our site, very few pages validate without errors, but all of them display correctly in Netscape, Internet Explorer, and other browsers. ConclusionOur experience suggests that the original idea of Levels of Edit continues to be a useful way for editors to conceptualize the different kinds of work they must do, even when they are approaching a website. In this article, then, we have pointed out some of the ways in which website editing extends the responsibilities of the editor at each level.
When first exploring a website that has been cobbled together from contributions made by many different groups of people acting independently, editors may find themselves endeavoring to answer a bewildering variety of questions involving structure, style, and design, all raised by the electronic nature of the medium, the mercurial mutability of its audiences, and the breathtaking speed at which tools, tastes, and conventions change on the Web. In this mild chaos, the editor of a website may be reassured to know that by following the traditional Levels of Edit approach, sanity may be regained; and that the Levels offer a reasonable way to think about the work to be done on the website. Thus, the Web expands our definition of the activities at each level, allowing us to pursue the same ideals through a new medium. References[1] The "before" version of the site was temporarily available at http://www.cramer.nmt.edu/Fall95/ and the edited version temporarily appeared at http://www.cramer.nmt.edu/Fall96/ Please note: as of March 1999, I believe that this server may have been closed down. [2] Campbell, Chuck. Syllabus: TC 202, Elements of Editing. http://www.cramer.nmt.edu/~cpc/edit/ [3] R. Van Buren and M. F. Buehler, The Levels of Edit. 2nded. Pasadena, CA: Jet Propulsion Laboratory, 1980. In a July 1993 letter to Campbell, Buehler wrote, I am a little concerned that people will think they have to use the levels of edit just as we did . . . . People have been adapting the levels of edit for many years . . . and this is what we at JPL have encouraged people to do from the beginning. [4] D. Samson, Editing Technical Writing. New York: Oxford, 1993. [5] J. Prono, "Changing from Four to Three Levels of Edit at Los Alamos National Laboratory." Presentation for STC Kachina Chapter, Jan. 11, 1997. [6] D. S. Kaufer and B. S. Butler, Rhetoric and the Arts of Design. Mahwah, NJ: Lawrence Erlbaum, 1996. [7] For more information on using SGML see C. F. Goldfarb, The SGML Handbook. Ed. Y. Rubinsky. Oxford: Oxford, 1990. See also the SGML Web Page: http://www.sil.org/sgml/sgml.html [8] The DTD of HTML 3.2 was created and is stored at http://www.w3.org; the HTML 3.2 Reference Specification is at http://www.w3.org/TR/REC-html32.html. [9] P. J. Lynch and S. Horton. The Yale CAIM Style Guide, 2nd. ed. http:/info.med.yale.edu/caim/manual/ [10]Ameritech Web Page User Interface and Design Guidelines. http://www.ameritech.com/news/testtown/library/standard/web_guidelines/ [11] Apple Web Design Guide. http://applenet.apple.com/hi/web/intro.html |
Services/Tips/Theory/WebPoems/Workshops/Books/Articles/Lisa/Jonathan
Copyright 1998-2001 Jonathan and Lisa Price, The Communication Circle
Return to our site at http://www.theprices.com/circle
Email us at JonPrice@AOL.com
