I never quite finished what I had to say about open formats and new tools. A kick in the rear arrived a few days ago, masquerading as a rah-rah email from someone I respect. So let me keep going.
Seems to me some days that the way newer markup-authoring tools work today tells us a lot about how authoring wants to be done—if we listen. There is, for example, a widespread—I won’t say “delusion,” though I think it is—impression that markup is difficult or time-consuming to author. The more correctness (by several possible measures) required of the markup, the harder authoring becomes.
I think this is largely an artifact of how we have thus far been forced to author markup.
Take wikis, for a moment, and the several varieties of wiki- and wiki-like markup floating about. There is much and vociferous argument about what bit of text properly means what bit of markup—but look at the assumptions underlying. The one I find most striking is that authors want to determine what kind of a block they are about to write (a head, a paragraph, a list item) just as they start writing it. At that point, they are ready and willing to make a gesture to define the block structurally.
The same appears to be true of print editors, incidentally. Keymarking invariably targets the beginning of the paragraph. We might even learn one more rule from editors: the next block wants to be the same structure as the last block, unless we make an explicit gesture indicating otherwise. Keymarkers don’t mark every single ordinary paragraph in a run, just the first one.
What do a raft of GUI XML editors make us do? Write first, then do a lot of clicky work afterwards to determine place in hierarchy for what we’ve already written, when what we want to do is go on to classify and write the next bit. No wonder such editors seem awkward to use.
No wonder everybody hates end-tags, for that matter. They get in the way of the next bit.
Inline markup, such as emphasis, seems to work a little differently. Folks don’t mind defining both ends of it, but they want to make the same gesture both at the beginning and at the end of the range. Think about the gizmos that turn *asterisked text* into boldface. Same authoring gesture, beginning and end.
Also, defining the range takes priority over adding information to it, for any operation in which fully marking-up a range means more than slapping an element name on it. I notice that while blogging, I am fairly careful to add a elements properly as I get to the text of the link, but I invariably wait until I’m done with the post to slap the URLs in. (How much my long-form blogging affects this pattern is an interesting question; I know there are quick-link blogging tools designed to hand you the link right away so you can comment on it and post.)
A tool that won’t let me finish my sentence until that URL is added would drive me bats—and I suspect that all too many XML tools work on this principle with attributes, especially required ones. (IDs, for instance. I shouldn’t ever have to stop to figure out what something’s ID is. Yet I’ve never met the tool that let me define a template for IDs so that the program could autoassign them.)
Markup menus, such as most text editors sport, are evil incarnate for adding inline markup, because they force me to make two decisions every single time: what the range is, and what it’s called. That isn’t how I’ve ever worked. I have “painted on” markup after the fact, but what I do when I have to do that is pick a chunk of markup and apply only that chunk of markup all the way through the text, with as many passes through the text as I have markup chunks to apply.
The one XML editor I know of that accommodates this habit of mine correctly is Topologi, with its markup pens. Set up a pen with start- and end-tags, select it, and all I have to do from there is select text ranges. No scan-and-clicky-clicky on an interminable list of tags.
I even think the WYSIWYG tools have something to teach us, and I’m as rabid a WYSIWYG-tool hater as anyone. What they teach is simple: if we can see its effects, we’ll do it. Tree-based editing views are a travesty for several reasons, but a major one is that we can’t see any visual effects of markup on text—we only see markup to either side of text.
There’s no need for this. Tools as ancient as Panorama Pro or as clunky as Word let us correlate a name with visual distinctness, on any span of text we choose. I think the bright spot here is up-and-coming editors like Morphon that use CSS—which your average webmonkey these days can already sling about with some facility—as the styling language.
What may get lost in my advocacy of visual distinctiveness is that I am not advocating WYSIWYG. I don’t know a single publishing house or website in creation that would turn, say, in-text bibliographic references fuchsia, but if you’ve got to mark the darn things up, it’s vastly helpful to be able to see when you’ve done it. Your article hasn’t sprouted fuchsia text ranges? You forgot to mark up your cites. Simple as that.
None of this is rocket science. It’s just thinking about what people do when their tools let them do it. Insofar as open formats have allowed tools to blossom, we ought to be paying close attention to which tools people like, why they like them, and how they really use them.
