I confess - I avoid writing in this blog because I am concerned that I have nothing of value to offer. I worry that the only people reading it are people I work with out of some misplaced feeling of obligation. And, I worry that everyone is thinking this:

….some people have a desire for an audience in advance of their ability to provide that audience with something of value.

Oh God! Not that! Please don’t read my blog and think THAT!

That comment was a response to Mike Hughes’ post, Why do people listen to me? I was fully prepared to dislike the guy that wrote the comment, since it hit way too close to home. However, the guy, Milan Davidovic, also wrote a followup post on his own blog, which I found quite encouraging.

Milan thinks writers should practice out in the open, for themselves, not for the sake of an audience. He believes that if a writer just happens to produce something people can use, the appropriate audience will find it. And, if a writer never produces anything “worthy,” so what? It’s their blog, or podcast, or twitter feed, or whatever. That’s a powerful thought and it’s exactly what I had in mind when I started this blog, before I became paralyzed by fear and overly worried about every post being “good” according to someone else.

That “build it and they will come” attitude seems to be the philosophy of all my favorite bloggers too. They seem to be okay making mistakes, admitting weakness, or just blogging about what they don’t know and wish they did. They are fearless. And, I love that! So, I’m going to try being more like that from now on.

The projects I worked on at the end of last year required a lot of face-time with coworkers and a lot of thought. I worked on a use case approach to move documentation up in the development cycle. I also worked on improving the user experience with embedded assistance. These were the type of projects that expand my role as an information developer. And, they required a lot collaboration with other departments. But, despite all the work I did, I produced very few actual results. And, when my suggestions couldn’t be implemented or the use case approach couldn’t be carried out due to scheduling, I felt that I had been left empty-handed.

I now realize that these projects are actually investments. Over time, I believe they will pay off. And, to be fair, there were several small successes along the way. With our first attempt at the use case approach, we did write a lot of conceptual information early. Plus, we now have embedded assistance recommendations that are firmly grounded in customer data, which is good.

However, I recognize that to be happy at work, I need more clear successes and I need better measures for success. So, this year, I plan to diversify.

In 2009, I’m going to:

• Pursue projects where I have more control over the outcome

  I plan to work on technology and process problems that only affect the documentation team. For example, I am working on setting up a lab environment for my product and I am documenting the process of installing new builds of the product.

• Focus on personal growth

  I want to get back into self-education and start learning for the sake of learning, not just for the sake of doing. I also want to invest more energy into improving my work habits and professionalism.

• Document my efforts on “investment” projects as a measure success

  I think if I create a running log of my efforts, I can look back and say, “Sure, the outcome is not what I had hoped for, but I made a good effort, and that effort is valuable in itself.” My coworker, Mark Wallis, pointed out that you cannot rely on success as your only measurement, because you cannot guarantee success. I think he’s right and I’m going to work on that.

I don’t want to stop working on “investment” projects, because I think they are important. But, collaborative efforts are not always comfortable and the results of an investment project are not immediately apparent. So, to protect myself from cynicism, and to get back in tune with the optimism I first felt when I started this career, I’m going to give myself more opportunities to succeed.

I recently learned about a DITA specialization for contextual help. Being a good little information developer, I decided to give a whirl.

I immediately got this message:

This DITA specialized document type is not supported by the Authoring Tools development team.
Press the F1 key for online help on the tags and see the DITA XML Guide and Reference for how to use this document type.
For support please see: https://intranetlink

Um. No.

I didn’t have internet access when I got the message, so I couldn’t follow the link. And, I wasn’t sure I even wanted to follow that link. Why do I need even this specialization? The regular ‘ole concept, task, and reference topics had served me just fine in the past. If my tool won’t support it, isn’t that a sign?

It seems we spend a lot of time and energy creating and learning new tools and methods on the premise that we’re getting back to basics. We’re going to get everyone on board. Everyone is going to start speaking the same language – finally! But, “don’t worry, it’s extensible,” we say.

We immediately create a butt-load of specializations, fragmented guidelines, and workarounds so that we can force our newly-adopted way of doing things into the work patterns we already know. Then, we excuse ourselves from sticking to the basics, because, well, they’re too basic. And then, our tools stop working.

Web syndication is a great example of this. The whole point of RSS (Really Simple Syndication) was to have a standard format for syndicating content on the Web. However, we now have a dozen or so flavors of RSS, plus a totally different format called Atom. We have different groups that manage “standards” for these various syndication formats. And, of course, we have compatibility issues in the tools, all for the sake of a format that was supposed to be simple and, well… standard.

Is this where DITA is headed? I hope not. I think not. We currently have just the one standards committee, the Oasis DITA Committee - that’s a good sign.

I suspect that when I do figure out what’s so special about the contextual help DITA specialization, I’ll be singing a different tune. But, I couldn’t help but be reminded of this phenomenon that seems to send us all drifting towards chaos and comfort, even when we’re trying our best to get on board and get organized.

I’m not advocating that we let loose the hob goblins of styles, standards, and rules. But, I do wish we could all be a little more diligent about keeping exceptions as exceptions, and stop making every exception a rule.

I’m the official grunt in a new initiative to adapt use case methodologies to DITA - compliments of Dr. Mike Hughes. And, I must say, this is a really cool project.

Sections in a use case line up pretty nicely with DITA tagging available in task topics. Our plan is to fill in all the sections that answer why, when, who, and what. We fill in the “how” when developers actually create the UI. Okay, I admit, when I explain it here, it seems obvious to do it this way. But, it also seemed obvious to ask “why did the user click help?” Yet, I managed to reliably mess that up.

So far, this project is going great. I already have two fleshed-out topics, which is significant considering that my development team just scheduled their first stand-up meeting and release is expected to be a year away.

I feel very committed to the best little helper I can on this project. I think the more I can write in this UI-agnostic environment, the less stress I will have near release time, when everything is “nailed down” and then changed three times for good measure.

You can read all about this cool new approach in Mike Hughe’s article, Use Cases for User Assistance Writers, on UXMatters.com, at http://www.uxmatters.com/MT/archives/000329.php.

Collaborative walkthroughs are a technique that my team used while rewriting our Help and adopting DITA. We believe that we were able to improve the user experience by improving the collaborative experience. Here is my presentation on our use of this technique.

Dr. Mike Hughes’ article, which I reference in the presentation, is available at UXMatters.com: http://www.uxmatters.com/MT/archives/000211.php

You can download a PDF of all the slides in my presentation here: Collaborative Walkthroughs Presentation Handout.

You can also download a higher quality version of the video presentation in ZIP format here: Collcaborative Walkthroughs Video.

I apologize for the bad sound quality in some places. I think replacing my soundboard might improve the quality of the voice over, but I want to share this with you now.

The third writer says, “You know, they really should write a warning on that.”

This joke is courtesy of my friend, a developer (of course).

I’m currently investigating the translation process at work, which for some reason reminds me of the Underpants Gnomes (see video below - it has cursing, so beware). I’m still at a high level view, where I’ve learned helpful tidbits, such as that in order to have docs translated, you need money and a plan. Well, duh. But, what’s coming up, and I find this extremely promising, is the terminology process.

The terminology process is all about sorting out the words. You know, putting the dark words with the darks and the light words with the lights? Well, not really.

As far as I can tell, the process goes like this: I find words specific to the product. I fence off those product words to protect them from the translators, who would no doubt ruin them. Next, I find words that aren’t specific to the product, but are used a lot. I investigate whether these non-product-but-still-used-a-lot words have company-wide synonyms that are better. I report my findings to . . . someone. Finally, I find all the words that are “bad” and replace them with shiny, new, morally upright words that we can all be proud of.

At least that’s how I imagine the terminology process to work after marking up four documents with pink highlighter. Or, I could just be high from highlighter fumes.

Nothing is more exciting than meeting that one person that instantly “gets you.” They know where you’re coming from. They know what drives you. And, their stories captivate you. It’s magic! Or, if you’re a technical communicator, it’s an STC conference!

I really enjoyed myself at Currents this year. Currents was the first professional conference I have attended. The crowd was small, but enthusiastic. Jean-luc Doumont was an absolute superstar. His presentation, Road Signs, was entertaining and thought provoking. I really hope I get see it again. Dr. Mike Hughes gave a great demonstration on comparative data, which turned out be the ultimate Cliff Notes to statistics. At least know when not to get excited about statistics now! And, then there was Margaret Cekis’ presentation about getting information you need, which I really needed, and would have loved to have, when I was the lone writer.

It was so exciting and validating to hook up with other professionals in my field. Granted, I’m luckier than some writers. I’m part of a team of technical writers, so I enjoy the privilege of working with people every day that “get me.” But, it is a little like living on Gilligan’s Island. We all like each another well enough but, we still want to get off the island from time to time.

I’m presenting at STC currents this year on the topic of collaborative walkthroughs. Collaborative walkthroughs are a holistic approach to peer review that my team used during the implementation of Darwin Information Typing Architecture.

The conference is on March 14-15 and is being held on my old stomping grounds - Southern Polytechnic State University. I will be presenting Collaborative Walkthroughs at 10:00 a.m., my room assignment is TBD.

My coworker, Mike Hughes, is also presenting Which was Better?, a demonstration on assessing comparative data. Mike is presenting at 1:30 p.m. Another coworker, Mark Wallis, is presenting How to Run a Successful DITA Pilot User Assistance Project at Writers UA in Portland a few days later. IBM ISS information development will definitely be out in force in March!

Here is the description for the conference from Atlanta chapter’s Web page (http://www.stcatlanta.org/currents.htm):
This two-day conference includes:

• A Friday workshop by Jean-luc Doumont, who will present his popular “Visual Structure” lecture
• Information-packed Saturday sessions, featuring keynote speaker Mark Clifford, First Vice President of the STC, and Jean-luc Doumont’s “Road Signs” presentation
• Industry leading vendor exhibits, on-site technical bookstore, door prizes, and much more

Hope to see you there!