Is structure about code or about content?

Here’s a short one, cause I’m writing on a train to Nuremberg…

When writers are not used to structured authoring and have to adopt a standard like DITA, they tend to blame DITA and the new tools for complicating their lives. In the new process, the first thing writers notice is that they have to use elements they are not familiar with, and that there are various ways to use them.

Unless they go through training on structured authoring, they start with the wrong plan, that the unstructured text (and thinking) would just have to be mapped to the new structure, as “structure” would be about code, not about writing.

Indeed, the XML code sets a valid structure to the topics, but there is more to structure than applying DITA elements. Documentation can benefit from the principles of structured authoring even without adopting a certain standard. You can do your project research and information model, define your own house rules and styles, to provide consistent, minimalistic, reusable documentation, in almost any authoring environment.

Do not blame DITA or the tools, that you have to structure your procedures or your lists of parameters in a certain way. Ideally, you would have seen the need for that structure before, and thanked Heaven (or the DITA committee) when the standard came and you rushed with the business case to your team and managers.

Happy DIT’ing!

My DITA backlog

lists collage

Are you the list type? I know I am. I have all kinds of lists with things to do. I use Post-Its, note-books, cards, envelopes, apps, email tags… whatever comes in handy when the muse strikes, so every once in a while I need to aggregate the lists, categorize and check priorities.

It feels good when I can draw a checkmark next to a method or tool I tried, a book I read, a webinar, a workshop or conference I attended, but my DITA list is never shorter. Could be that I’m a DITAholic.

I’m surrounded by notes with things I have to research and try out in DITA, and while I try one thing, I think of two or three further issues to add to the backlog.

What’s your “DITA diet”?

The DITA Architect’s role

What does it take to be your team’s DITA Architect? Naturally, you have to thinkDITA, understand Information Architecture, use DITA for some time and know what you can do with it.

If in addition to being a DITA Author, you find yourself addicted to it, like there were no other way to do technical communication, if you read and try out all ideas you can find about DITA and related tools, then… you’re on the right path to being a DITA Architect.

There is one more thing, though. As I learned from Eliot Kimber (@drmacro), there is a difference between a geek and a nerd: the geek likes to talk about his nerdiness.

If you’re serious about the Architect role, you know it’s not enough to set up the authoring environment for the Writers in your team, especially if they are new to DITA. Apart from someone dealing with tools configuration, XML, XSLT, XSL-FO, CSS, jQuerries and Ant scripts for them, what the team needs, is answers to their questions, assistance, guidelines, code reviews, and even more answers.

You may thinkDITA and breathe DITA, but as an Architect, you have to lead and inspire DITA.

Happy DIT’ing!