This month I'll reverse my focus from inward to outward, from the detail of the work I've been doing, to the spectrum of related work I may someday do. The spectrum involves the MLs, or markup languages, including HTML, SGML, and XML. But first I want to wrap up the previous article with some final thoughts about WinHelp and several often overlooked topics.

FOUR YEARS AGO, when I began working with WinHelp, I was frustrated by the lack of control I had over the appearance of my final online product. No matter what font size or color I chose, or how I set the tabs and indentations, the software I was using had its own idea of what styles to use. To combat this, I formatted most of my work into tables. My present software, RoboHelp 5.5, Windows 95, and Word 8 (a.k.a Word 97), gives me considerable control. I'm still using tables, perhaps as a force of habit, but also because tables give me good control of spatial positioning. I suspect this use of tables helped lead me to the concept of designing my information centers as arrays of information and buttons. The one problem with my approach is that if I have a hundred information centers laid out alike, and decide to modify the layout, I have to manually change the hundred tables. It should be possible for the help authoring software to let me design each interface as though it were an input or output screen for a database. Then I would only have to change one interface instead of a hundred tables. Electronic documents, such as help systems, are usually structured as databases. Providing the added capability should therefore be possible. Most likely, no one has recognized the need.

There are two other areas of online help documents that are frequently overlooked but need to be at least touched on: animation (or video) and audio.

ANIMATION IN ONLINE HELP is something we don't see much of. It could be used to show interaction with the software interface or could be used to show the workings of complex machinery, for example. I learned the workings of the internal combustion engine as an adolescent when my father gave me a booklet created by General Motors. It showed the complete process step-by-step. Several years later, when I saw a real motor with its head removed and could see the speed with which the valves opened and closed in relation to the slower motion of the pistons (something that isn't obvious from illustrations without careful study), I formed an image that remains with me to this day. Animation or video can provide a similar experience. For the animation to be truly useful, however, I think the user should be able to control the speed of the motion, even reducing it to a stop-step process. We don't yet have this capability with WinHelp, but may get it someday with HTML-based help. (My understanding is that there will be no further development of WinHelp, so I look to HTML help for the future.)

AUDIO IN ONLINE HELP is something I haven't used because my products are intended for use in an office setting where sound might be distracting to others nearby but not involved. Still, audio capabilities should not be overlooked for certain applications. Wouldn't it be nice if, when we went to our auto dealer to complain about a strange sound in our car, we could select that sound from a collection of recordings that were keyed back to possible symptoms? That would be a lot more satisfactory than being told to come back when the car was able to repeat the sound on demand.

Now for the main feature.

IN THE BEGINNING (about seven years ago), I had more time than I do now, so I wrote a number of articles about trolleys - a hobby of mine. I was paid reasonably well for one article, miserably for two others, stiffed on a fourth, and abandoned on two others when the publisher went out of business. This got me thinking about self-publishing. The thought of having to print a thousand or more paper copies for a niche market caused me to wonder about electronic publishing as an alternative. The cost of a floppy disk is only about fifty cents. Copies can be made as needed. The problem was that a nonproprietary format (e.g., ASCII) didn't leave much opportunity to include the necessary visual material.

While I pondered my next step, Adobe introduced Acrobat, a cross-platform page description program with a free viewer. Unfortunately, I wasn't quite ready to spring for the cost of the developer's side of the package. There were competitors, but neither they nor Acrobat seemed mature or inexpensive enough for me to jump in. I continued to ponder.

Then, seemingly out of nowhere, the World Wide Web appeared. After using the Web for two years, it seems as though the Web has always been with us. Yet, there's no mention of the Web or it's underlying markup language, HTML, in a book I have on paperless publishing, copyrighted only four years ago in 1994. Suddenly my self-publishing problem was solved, thanks to HTML and the now-free browsers available. I don't even need a floppy disk - I can put my articles on the Web and let people download them. (Of course, now I'm too busy!).

HTML (Hypertext Markup Language) is platform-independent and requires only an ASCII text editor to create and a browser (at least three important ones are available free) to read. Its system of tagging is so easy that a person can learn enough to create a simple document in minutes using the editor that came with the computer's operating system. For any serious work, of course, you will want to use a program designed for HTML authoring and invest in more learning.

A markup language relies on tags to associate structural or other information to the text or graphic that is tagged. In HTML, tagging something typically means preceding that something with an opening tag, e.g., <title> and following that something with a closing tag, e.g., </title>. Any text included between these two tags in the example is the document's title and is appropriately displayed by the browser. It's really as simple as that.

Initially, HTML supported enough tags to facilitate text messages on the Web, and included such things as several levels of heads, paragraph indicators, lists, horizontal rules, tables, ways to emphasize, such as bold and italics, and hypertext links to let you jump from one place within the document to another place within the document or to another document or place within that document. It wasn't long before Netscape, by way of its browser Navigator, and Microsoft, by way of its browser Internet Explorer, added enough tags to make HTML the electronic presentation tool it has become. Standards, set by the World Wide Web Consortium (W3C), generally come after new tags have been in use, so there is some inconsistency between Netscape's and Microsoft's efforts. In time the inconsistencies get resolved with add-ons or with each browser's update.

For industrialists and information providers, there is much more that can be done with electronic documents. This is where SGML comes in.

SGML (Standard Generalized Markup Language) is the omnipotent progenitor of markup languages. It has developed over several decades and was given official status in 1986 as ISO 8879. Unlike HTML, SGML is rigorously controlled. An SGML viewer (browser), for example, will not process an SGML document if it finds an error in the document's markup. An HTML browser, by contrast, simply ignores errors and keeps going.

Technically speaking, SGML is not a markup language but rather a meta language, which means it embraces other languages - in this case, other markup languages. HTML is an example of a markup language embraced by SGML. There can be any number of such embraced languages. You can even create your own!

Acceptance of SGML gained a great impetus from the U.S. Government's wish to go paperless. The first big-time users were the armed forces. SGML provides flexibility not possible with HTML by letting you (actually, requiring you to) define your tags at the start. Of course you can define basic tags by reference to established standards, so you can be off and running fairly easily. After that the going gets rougher. But the value of being able to define your tags is that you can now add "intelligence" to your markup. For example, in HTML, there's only so much you can do with the words Boston Red Sox. You can assign structural characteristics, such as title or head 1; and display characteristics, such as bold, italic, red, left-aligned, and so forth. With SGML you can also identify Boston Red Sox with professional sports, baseball, Boston, or anything else you like. Now imagine the information displays you could generate on the fly if your data was so marked. Your tagged text is now part of a free-form database. Your tagged text is said to be "intelligent." It knows what it is. For industry, tags like part number and price are obviously useful. Not only can SGML manuals display instructions, but they can also be tied to inventory modules, repair records, maintenance statistics, and so forth.

The tag definitions at the start of an SGML document constitute what's known as the document type definition (DTD). In practice, a carefully developed and agreed-upon DTD can be created and identified as a standard. Such standards are being developed along industry lines. For example, the airline, railroad, publishing, and pharmaceutical industries, among others, are developing DTDs suitable to their specific industry needs. HTML is an SGML DTD particularly suitable for display of information on the Web. It's strength - simplicity - is also it's weakness - simplicity.

The company I work for has been involved with SGML for a number of years. Our customers are the military and big industry. Some other companies making SGML products include Adobe, Corel, Softquad, and ArborText. You can easily find more about these companies and their products on the Web. You can also find on the Web information from independent sources such as the Washington SGML Users Group and Seybold Publications.

SGML represents the ultimate in capability and flexibility. It makes possible multiple data views, collapsible tables of contents, robust client-side processing, and complex interrelated applications among other things. These capabilities come with a cost, however. The learning curve can be steep (though programs such as Adobe FrameMaker+SGML do much to shield document authors from the underlying complexity) and the editing and browsing software can be expensive. SGML has also found only limited acceptance on the Web, mainly because the widely used browsers don't support it and SGML documents need to be converted or translated for these browsers. There appears to be an answer to SGML's slow Web acceptance in the form of XML, sometimes referred to as SGML Light.

XML (Extensible Markup Language) is also a meta language, not a markup language. In reality, it's a version of SGML optimized for Web use. It was created by SGML proponents to fill the perceived need (I'm sure there are some who would disagree that there's a need). Version 1.0 of the XML specification received official approval from the W3C in February 1998. Early indications are that Microsoft, Adobe, Corel, Softquad, Xerox, and others will be actively involved.

XML is intended to easily provide Web capabilities to traditional SGML while embracing HTML. Look for future browsers, such as Microsoft Internet Explorer 5.0 and Netscape Navigator 5.0, to add XML capabilities. Do not look for XML browsers, or XML-enabled browsers, to fully support SGML. Some things from SGML have been left out of XML to achieve ease of use. Do not look for any of these three MLs to go away - each has its place. Do look for XML to become an important part of a tech writer's vocabulary before long.

AN ESSENTIAL CONCEPT OF SGML is that it is concerned only with structure and semantics. It is not concerned with appearance or delivery. In other words, an SGML document is universal, platform-independent, and potentially usable by paper or electronic delivery systems. Questions such as what font is to be used, or what size and color the font is to appear as, are answered by others when the document is printed or displayed, and are not answered by the document authors unless the authors are also asked to prepare the accompanying style sheets that govern the document's delivery.

Every SGML document has an accompanying DTD and style sheet. With HTML the DTD is hard-wired in the form of the standard/browser-recognizable tags and the style sheet is built into the browser. Web designers have been inventive in circumventing HTML's original display limitations and have been aided by tags created by the big-name browser companies. I expect XML and its supporters will be equally inventive and accommodating.

Does the nature of SGML, and to some extent the similar qualities in XML, alter my original hypothesis about imagining ourselves within the document and organizing the document into information centers? Not at all. My hypothesis is structural in nature, so it is fully supported by the MLs - SGML, XML, and HTML. I do have some concern about the separation of content and presentation. Much of my striving as a technical communicator has been to combine content with presentation. For me, this separation becomes another obstacle to overcome. I understand industry's wish to mine the data included in documents, but I also believe communication is a marriage of content and presentation. The two can and should influence each other. Count on me to continue looking for ways to enhance my communications by using whatever capabilities my software permits.

Another concern I have with the MLs, though it applies to all electronic documents as well, is that they entice us to think of the electronic document as a universal, "one size fits all" document. A document that can be used many times, in many formats, for many purposes. Among the first questions a technical writer asks when beginning a new project are: who is it for? what is its purpose? and, what format is it to be delivered in? We've already seen from this series of articles that the optimal electronic document is structured differently from the optimal paper document. It would be easy to show that a document whose purpose is to teach (e.g., a tutorial) should also have a different structure from one whose purpose is mainly to inform (e.g., a reference guide). Similarly, the intended audience for our document can have a significant influence on the document's structure and content. My presentation of an internal combustion engine, for example, would be quite different for adolescent, aspiring engineers than it would be for experienced mechanics. If I had to address multiple cultures, I would have additional problems. The lure of multiple document reuse offered by the MLs is not unfounded - it's just limited. If we restrain the scope of our multiple reuse ambitions, and recognize the limitations and compromises that come with multipurpose applications, we will find the MLs to be very valuable.

I've barely scratched the surface of the MLs. The Web offers a wealth of information on the subjects, as do a host of books available in bookstores that carry technical books. If I've perked your interest, I've succeeded.

Happy exploring!

This is the fourth in a series of four articles. A variation of the first article was published in the Nov/Dec 1998 issue of Boston Broadside, newsletter of the Boston Chapter of the Society for Technical Communication.

Related to Thinking from within the box:

    Making the connection: a virtual journey.  Click

    No (single) entrance for this complex.  Click