graphein: Principles

1. Principles

• Be Boring: Build simple, read-only texts; eschew interactivity and glitzy dangers.
• Be Archaic: Long for the intellectual scope of SGML, not the alphabet soup frothing around XML.
• Be Lazy: Let the software do it, (only) if possible.
• Be Pedantic: Select and use tools based on conceptual clarity, not popularity.

Be Boring. These are tools to support writing by me, for myself. Even though I may publish parts of it on the Web, the audience is still me. I don't like flashy, showy, glitzy websites propped up by special technologies (animations, background music, etc.) used simply to attract attention. Good visual composition might be nice, but that's really something more related to traditional book design and to art than to contemporary website practices. The content is, in the end, all that matters.

As a related organizational principle, for published material I think a sort of "rule of three clicks" might be useful. It's been my experience in other contexts that most people, hasty people, stop looking at a website if they can't find what they want in a hurry - usually after two clicks. Curiously, as I was writing this in January 2006 the BBC reported a new Canadian study published in the journal Behavior and Information Technology which indicated that web viewers actually made up their minds about websites in 50 milliseconds - which would have to translate to no more than the single, initial, click. Often, therefore, I'll put things three clicks in.

Be Archaic. The Web is supposed by many to be cutting-edge technology. It is not. There have been no innovations in software technology in at least twenty years. None. Really. Think about it, and learn the history.

XML was originally a good, if limited, idea: "SGML-Lite," a cut-down proper subset of SGML. Then a babel of ill-conceived standards arose around it either to put back in things which SGML had originally, such as simultaneous documents (see XML "namespaces") or to add things which shouldn't be in a markup metalanguage at all such as data typing in XML "schemas." (Compiler designers learned long ago not to mix syntax and semantics, and classical scholars have struggled with this issue for millennia. This is, once again, very old technology).

Barring a complete rewrite of the whole toolset from scratch, which is something I don't have an extra lifetime to do, I'm stuck with the tools that are out there. But nothing stops me from attempting, in some necessarily limited way, to use them as if they were the older tools that they ought to be.

Be Lazy. This is just the good old nix-style "software tools" mindset from the 1970s, but known to every good toolmaker since the paleolithic.

Be Pedantic. When possible I choose tools because of their well-conceived underlying theoretical or scholarly qualities, not their trendiness. The TEI is a good example of this. It's by no means the most popular choice today for text markup (outside of scholarly circles), but it is the one which best reflects scholarly concensus about the characteristics of texts. VARKON is another good example. Few people use VARKON (more's the pity), but it is, conceptually, the most beautiful (meta-)CAD system ever written.

At times of course I fail in this practice, usually because of the availability of tools. TEI P5 is now defined in XML rather than SGML for no good reason I can see other than the trendiness of XML. I use SVG as a standard for storing non-CAD vector drawings simply because it is common, even though it is a component of the XML babel.