| Previous | Table of Contents | Next |
XML promises to transform the basic structure of the Web, moving beyond HTML and replacing it with a stronger, more extensible architecture. It promises to return the Web to content-based structures instead of the format-based structures imposed by designers frustrated by the immaturity of Web design tools. It may also free the Web from the tyranny of browser developers by ending their monopoly on element development and implementation.
The World Wide Web Consortium (W3C) has moved ahead of the commercial browser developers with a very promising new approach to markup. XML, the eXtensible Markup Language, makes it possible for developers to create their own mutually interoperable dialects of markup languages, including but not limited to HTML. This could bring about a cease-fire in the browser wars between Netscape and Microsoft as added features shift to a component model from browser code. More immediately, it allows developers to create markup structures based on logical content rather than formatting. That will make it easier for humans and computers to search for specific content-based information on pages instead of just searching the entire text of a page. XML, in concert with Cascading Style Sheets (CSS), should allow developers to create beautiful pages that are easily managed.
The first word processor I used was a very simple text editor. I thought it was really amazing how the screen could move around my cursor point to make my 40-column screen display most of an 80-column page, but for the most part it was only good for doing homework and writing other similarly boring documents that I printed out on my lovely dot-matrix printer. After working with computers for a few years, programming them and cursing them, I gave up and bought an electric typewriter. It let me do some pretty fancy things, like underline text without having to enter bizarre escape codes. There wasn’t a good way to type boldface text, but I didn’t have to worry about wasting acres of paper because of a typo in code. The typewriter gave me what-you-see-is-what-you-get (WYSIWYG) in a classical ink-on-paper kind of way.
I stuck with my typewriter for a couple of years, until I discovered the Macintosh. I’d hated the Mac when it first came out, because every magazine I got covered an expensive machine I didn’t own. It didn’t even have a decent programming package. But when I encountered the Mac again about four years later, I was thrilled. It was actually fun to write papers, because I could toggle all the style information, write in multiple columns, and even use 72-point type once in a while. It didn’t look very good on my Imagewriter, but it was pretty amazing compared to my old dot-matrix computer text. I turned in papers with headlines, bibliographies that used proper italics, multiple columns, and even a picture or two. Writing wasn’t just about spewing out sentences anymore. I could create headlines, subheads, tables, footnotes, and use all kinds of other formatting to give even a short paper a set of structures that made it look smart. Using styles made it even easier: apply a set of formatting tools once, then call it up as a named set. It seemed like magic.
Ten years later I still format my documents with headings and subheads. Fortunately, I’m not as concerned about footnotes, but I’ve developed a new problem: it’s hard to reuse my old documents. When I was writing papers for a grade it didn’t matter very much—I wrote the paper, turned it in, and never thought about it again. Now I spend my days working with piles of information written years ago by people thousands of miles away, and converting the files into the same word processing format is the least of my worries. Instead of editing material, I frequently find myself spending hours reformatting it, and not because I love doing so. A whole generation that grew up abusing tabs and spaces has created documents that can’t be cut and pasted into other documents because everything breaks. Line breaks come out totally wrong, text gets shoved to the left or right, tables collapse, and even simple things like spacing cause problems. The same magic formatting that made it so easy to create documents that looked exactly the way they should is now creating massive problems.
There are other, more subtle problems as well. All those years when I thought I was creating headlines and subheads, I wasn’t really. I was creating text that was formatted like a headline. I might even have called the style “headline”, but to the computer it was just another collection of letters with no intrinsic meaning. WYSIWYG changed people, too. People who probably shouldn’t have been allowed to graduate from a fifth-grade art class started using 30 fonts on a page. After the novelty wore off, many of them adopted a more conservative approach to formatting but always with the declared intention of making their documents look precisely the way they wanted them. Designers became accustomed to specifying placement to thousandths of an inch—as though anyone can see differences measured in such a small increment.
Before WYSIWYG, documents were undoubtedly ugly, but they had a few other virtues that went unnoticed. There were moves afoot to create document management and document markup systems that would allow computers to efficiently manage large libraries of documents. Plain text, dull though it may be, is much easier to manage than the output of the average word processor or desktop publishing program. These document management tools were also very new in the early days of WYSIWYG, and they didn’t become affordable or readily available until long after users had become accustomed to systems based on paper-based media. The final printout of a document always remained the final goal of most of the design programs on the market.
| Previous | Table of Contents | Next |