Augmentative authoring
- a different look at "graceful degradation" in Web authoring

The phrase "graceful degradation" is often used to describe the idea that a Web page that uses special technologies for presentation enhancements, animation, interactivity, etc., should "degrade" to a simpler, yet fully functional page in circumstancies where the technologies are not applicable. This document takes a somewhat different view: instead of considering how to provide "fallbacks" for various advanced constructs, we consider how to create first a robust document that works always, then augment it by providing optional alternatives to the simple constructs. We'll discuss the different techniques that are needed for different enhancements.

Web authoring is more than writing structured texts. There is a wide range of techniques that can be used to enhance pages with other media and possibilities. Given the fact that the Web is a many-faced world where very different devices and environments are used, the key question is how to design pages so that they always work somehow and appear with the enhancements when possible. The key to that is to consider structured text (text with HTML markup indicating its logical structure) as the immutable core of a page, as the solid basis upon which various optional augments can be added. That's my reason for coining the word augmentative in the Web authoring context. In a sense, the point here is that Web pages can be more than text, but they should not be less than text.

Excellent advice on designing Web pages which "degrade gracefully" can be found in the following documents:

• Hints for Web Authors by Warren Steel
• Graceful Degradation by Daniel Tobias
• HTML (etc.) Tips and Issues by Alan Flavell
• Web Design Hints and Tips by Paul Rundle, Pankaj Kamthan and Martin Webb
• Standards for HTML Authoring for the World Wide Web by WDG

My point of view here is somewhat different, though certainly compatible with "graceful degradation". I'll first try to explain the idea with a small but important example: images. An image is a graphic enhancement to a textual document, and in good Web authoring, all image elements have adequate alt attributes specifying textual replacements for them. (For specific reasons to this, as well as technical issues on it, see my Simple guidelines on using ALT texts in IMG elements.) But the augmentative authoring approach means that instead of first embedding an image and then wondering (if we remember to do that) what alt attribute to use as a textual surrogate for it, we first write the text, later build an img element around it, providing an optional graphic alternative. Simple as that. There's a very practical benefit: the document will be functional from the very beginning. Generally, the enhancements take more work and time to implement, like scanning images, processing them for better quality, etc. (Admittedly sometimes it takes more work to write a textual replacement for an image than to put the image onto a page.)

The essential point is that the page can "work" in two modes. For images, this simply means that the page can be viewed so that an image is displayed, or so that some alternative text is presented (displayed or spoken) instead. For a Java applet, it could mean that the page can be used so that the user interacts with an applet that illustrates things dynamically or sees just a static image that illustrates things to the extent that a static image can. For frames, this means that a site can be viewed either using frames or without them, typically using the equivalent of the content of a navigational frame as a main page. And so on. As a special case, one of the modes can be "something extra" like beautiful coloring of a page or checking form data before submitting it whereas the other alternative is simply lack of the extra feature. Quite often style sheets and client-side scripting can be used for such purposes, so that no special "fallback" is provided, since the feature is strictly optional as far as basic functionality is considered. (Note that form data checking must be done server-side in any case, so client-side checks should be just extra comfort.)

The more enhancements you have, especially when you use different technologies like frames and JavaScript and style sheets, the more important it is that you realize that each enhancement could be separately turned off. Do not assume any coupling between them unless you absolutely need to. For example, do not assume that JavaScript is enabled if Java is, and do not assume that anyone using a frames-enabled browser sees your images. Do not assume that if someone sees an image on your page he sees all the other images too. (It's quite possible and often useful to view a page with automatic image loading turned off and load images individually.)

This can be characterized by two basic ideas:

duality principle

An enhancement introduces an ingredient which can have two different manifestations, "simple" and "enhanced", typically according to the characteristics of the browsing situation.

orthogonality principle

The enhancements should be orthogonal to each other so that each of them can individually be "on" or "off" without affecting the basic functionality or the other enhancements.

The duality principle does not imply that the "enhanced" alternative is to be used whenever possible. There can be reasons why users select a "simple" alternative even if an "enhanced" alternative would work too. A simple example is turning image autoloading off on a graphic browser (typically, when using a slow connection). Similarly, a user might have JavaScript routinely disabled but enable it when there is a reason.

Should the "simple" version then mention the availability of the enhanced version? Generally, no. It is reasonable to assume that the user who sees the simple version either has no choice or has specifically chosen the simple alternative. In exceptional case, when there is a special reason why someone might wish to consider changing his choice temporarily, or even switching to a different browser if needed, a note could be made. The note should make it explicit what might be gained by using an enhanced version. See e.g. remarks on suggestions to enable JavaScript.

The following table tries to summarize the usual methods for implementing the duality for various enhancements. Note that several possible enhancements are not mentioned at all, since they need no special treatment; for example, using style sheets should cause no problems when style sheets are disabled, if the HTML markup of the document is adequate. For details on the HTML elements involved, please refer to HTML 4.0 Reference by WDG. For features not in the HTML 4.0 specification, such as embed, see e.g. HTML Tag List by Rob Schlüter (also available as a version which uses frames) or Miko O'Sullivan's excellent HTML Quick List.

As the table demonstrates, there is great variation in the ways in which the duality can be implemented, both syntactically and as regards to practical flexibility.