Friday, January 11, 2002

"Pride goes before a fall." Knowing your weaknesses is a key business skill; honestly assessing to yourself the weaknesses in your position gives you the opportunity to protect yourself. It sounds obvious to say it, but the casualties keep piling up. It's been my experience that the most common symptom is getting too far ahead of yourself, looking too far past your current challenges, and so missing some key detail in the environment. I'm trying to keep my eye on the ball.
What does it take to create a powerful yet usable editing tool for natural-language semi-structured XML? Based on an email conversation between Dethe Elza (Chief Scientist at Burning Tiger) and I. Previously published, in part, by my favorite minor celebrity Stewart Butterfield . We humans spend most of our time classifying and constraining: This is a fax number and not a cell phone; this is a press release and not an airplane manual. Our free-form, semi-structured world is made up of primitives that we assemble together to construct more complex systems. The challenge, as I see it, is that these primitives are themselves made up of yet smaller things, and so forth, fractally. You could go to the nth degree of detail (and XML can let you go there), but that's not how humans work. We get to an acceptible level of detail for our current purpose, and then approximate the rest. For any given actor in a particular context there is a level of detail that is acceptible, and that level can be substantially different given a different actor or with even subtle changes in context. The model (schema) and view (interface) should be flexible enough to allow for different levels of approximation. On the other hand, if you were exchanging address listings with the others in your company and you arbitrarily changed the way you describe phone numbers (to remove the area code, because you didn't really need it at the time) you would potentially be hampering, rather than aiding, communication. The fact that everyone agreed on a common set of constraints is itself useful. Consider this example: Jane, the Lead Technical Writer for SpamTastic! Corp has a dual role: she creates the body text for SpamTastic!'s mailings, and she also is responsible for approving the work of other writers before it is released to publishing. When she opens a particular document for editing, does she want a full editing interface, with the ability to add and delete markup, or does she want simply to see checkboxes beside blocks of content, to indicate her approval for publishing? Does she always need to see the metadata that indicates the date and time most recent edits to a document? A smart authoring system would take into account the task at hand (editing or approving), the workflow state, the capabilities of the author (say, expert or novice), in addition to the document type being edited when determining what editing capabilities to provide, and what content to expose for viewing or editing. It would give the actor the ability to "blur the edges" where necessary and not overwhelm with complexity, while being tolerant of the errors of approximation likely to result.