Saturday, August 4, 2007
Dancing on the head of a pin
Yesterday, someone asked me how I had time to do all the things I do. I don't. I don't have the time to do all the things I think of doing, plan to do, expect to do, or want to do.
More and more, I'm finding that I perform a triage on my ideas. And to make getting there easier, I've set aside time slots in my week to make things happen the way I want them to happen.
I've been involved in two huge projects at work, aside from keeping up with my work, and I have finally realized that I need a schedule. Not a schedule in the sense of milestones and deadlines, but a schedule in the sense of Monday afternoons I study cardiology and Friday afternoons I work on my Six Sigma projects. In between, I have a half day on Wednesday that is devoted to research (either Six Sigma or technical writing). So, that means I have to be more productive during the other 3.5 days.
So far, I've found that setting aside specific times for research and specific project tasks, I am not disrupted during the rest of the week.
That said, here's what I've learned this week:
Not everyone can write to a specification. This great epiphany arose out of a discussion with some folks about DITA. During the conversation, I was asked several times questions that sounded remarkably like: what if I want to stand on my head in the corner. I found myself asking in return, why on earth would you want to do that? What if my audience wants it? Pretty strange audience; you're essentially saying that years of research done by people who sit around thinking about this stuff, who get paid a great deal of money to understand the theory and practice of communication, that research is useless because on some whim of some marketing department you're going to deliver your content in iambic pentameter (which, by the way, you can do while conforming the DITA architecture).
People who can't understand the product, the audience, and the purpose of the product are found bounding about in the field of dreams chasing the perfect user manual. And that means that they can't be constrained by a structure that provides a consistent organization of information. And, you can write content in the DITA structure that does not conform to the rules of the context tags; I can write whatever nonsense I want inside the <cmd> </cmd> tags.
I find it a relief to open up a fresh page and have sign-posts appear that say, for a task, you want to follow this order of things. And, seriously, if I really wanted to mess with the structure, I could. But, I like to share and to share, I need to consider others.
DITA gives us a nice structure to push content into. The writers that come and go at my job tend to be the ones that want to tweak the presentation of the content as they're writing. The rest of us rely on the templates and the process to handle the layout for us, we focus on what we're saying and that's good enough for us. In fact, it means we go home at the end of the day having produced content that routes through our DTP process without hairballs.
Having content that gets through a routine publication process without challenges means that I spend more time understanding my work and doing real work. The work I like to get paid for.
Also, moving to DITA has meant that we writers get to content experts. Instead of knowing a little bit about all the features in one product (which, by the way, in my case tend to be features that show up in other products... maybe with a different UI, but the same feature) I now get to delve into understanding a set of features and I document those for all our products. I find it satisfying to get to a level of understanding that could provide better content for the end users (mythical as they sometimes seem).
As happy as I am to be using DITA in this time and place, I am not a flag-waving DITAite. In our case, DITA is a great solution to a problem. It expands our sharing and is projected to improve our level of production to keep pace with the drive of the company's goals. Our products share enough common content to make our concept topics transportable. Our reference content may be tailored to each system, but it's derived from a core set of feature names and functionality. Our tasks vary the most, with the different UIs on each product presenting the biggest hurdle to simple single-sourcing of step-by-step descriptions of processes.
More and more, I'm finding that I perform a triage on my ideas. And to make getting there easier, I've set aside time slots in my week to make things happen the way I want them to happen.
I've been involved in two huge projects at work, aside from keeping up with my work, and I have finally realized that I need a schedule. Not a schedule in the sense of milestones and deadlines, but a schedule in the sense of Monday afternoons I study cardiology and Friday afternoons I work on my Six Sigma projects. In between, I have a half day on Wednesday that is devoted to research (either Six Sigma or technical writing). So, that means I have to be more productive during the other 3.5 days.
So far, I've found that setting aside specific times for research and specific project tasks, I am not disrupted during the rest of the week.
That said, here's what I've learned this week:
Not everyone can write to a specification. This great epiphany arose out of a discussion with some folks about DITA. During the conversation, I was asked several times questions that sounded remarkably like: what if I want to stand on my head in the corner. I found myself asking in return, why on earth would you want to do that? What if my audience wants it? Pretty strange audience; you're essentially saying that years of research done by people who sit around thinking about this stuff, who get paid a great deal of money to understand the theory and practice of communication, that research is useless because on some whim of some marketing department you're going to deliver your content in iambic pentameter (which, by the way, you can do while conforming the DITA architecture).
People who can't understand the product, the audience, and the purpose of the product are found bounding about in the field of dreams chasing the perfect user manual. And that means that they can't be constrained by a structure that provides a consistent organization of information. And, you can write content in the DITA structure that does not conform to the rules of the context tags; I can write whatever nonsense I want inside the <cmd> </cmd> tags.
I find it a relief to open up a fresh page and have sign-posts appear that say, for a task, you want to follow this order of things. And, seriously, if I really wanted to mess with the structure, I could. But, I like to share and to share, I need to consider others.
DITA gives us a nice structure to push content into. The writers that come and go at my job tend to be the ones that want to tweak the presentation of the content as they're writing. The rest of us rely on the templates and the process to handle the layout for us, we focus on what we're saying and that's good enough for us. In fact, it means we go home at the end of the day having produced content that routes through our DTP process without hairballs.
Having content that gets through a routine publication process without challenges means that I spend more time understanding my work and doing real work. The work I like to get paid for.
Also, moving to DITA has meant that we writers get to content experts. Instead of knowing a little bit about all the features in one product (which, by the way, in my case tend to be features that show up in other products... maybe with a different UI, but the same feature) I now get to delve into understanding a set of features and I document those for all our products. I find it satisfying to get to a level of understanding that could provide better content for the end users (mythical as they sometimes seem).
As happy as I am to be using DITA in this time and place, I am not a flag-waving DITAite. In our case, DITA is a great solution to a problem. It expands our sharing and is projected to improve our level of production to keep pace with the drive of the company's goals. Our products share enough common content to make our concept topics transportable. Our reference content may be tailored to each system, but it's derived from a core set of feature names and functionality. Our tasks vary the most, with the different UIs on each product presenting the biggest hurdle to simple single-sourcing of step-by-step descriptions of processes.
Subscribe to Posts [Atom]
