Day three was an interesting one, if only because I attended a very good session and a pair of keynotes, and missed one or two sessions that I wanted to attend in order to do a couple of podcast interviews.

Bob Glushko on document engineering

Bob Glushko‘s keynote was interesting in a number of ways. First, he really brought home a number of good points about what documents really are. He also brought that idea together with user experience design. On top of that, it looked like he was using HTML Slidy for his slides. Well, that’s interesting to me …

Glushko pointed out that documents are everywhere. They’re not just the piles of paper or the electroni files that many users look at. Documents also drive transactions behind the scenes. It’s up to us to find ways to create, reuse, and assemble documents of all types. One of the keys to doing this is designing information models and repositories. Glushko noted that we need to move from being simply writing documents to doing information choreography.

According to Glushko, new business processes are driven by the exchange of documents — many of these documents are hidden in the processes. The overlapping information various documents in various places are the glue for those processes.

In the larger scheme of things, document design and behind-the-scenes choreography of the documents in a process radically improves the experience of the user. Most user experience focuses on what happens on the front end. But the back-end document processes are just as important to user experience, if not more so.

Traditionally, front end and back end documents have contrasting design goals. Glushko asked if a system has these distinctions, is it properly designed? Chances are it isn’t. What’s needed is a methodology that melds all the stages of document use seamlessly. This involves using modular and configurable data files across both the front and back ends.

Glushko’s overall conlusion? The future of document design balances the front and back ends. Both make up the user experience.

Everyone’s a technical writer

Next up was Darren Barefoot. His keynote discussed how users are now our partners in creating effective documentation. Aaron and I have discussed this in the past, but Barefoot pulled a number of the threads together.

Social media creates a nexus of support. User to user support. And a lot of the documentation that users write is covering topics that few of us really consider. Barefoot offered a few examples from the popular online game World of Warcraft (WOW). Using the API that WOW offers, users have extended the game in ways that the developers may never have.

Documentation and supplementary information that’s found in wikis, forums, and elsewhere is a great adjunct to the documentation that’s created by professional technical communicators. The next step, though, is to work with those users to meld the information into the official documentation set. Or maybe not …

Writing a book using a wiki

It seemed like I was stalking Stewart Mader during the conference. But Mader told me that he was happy to see many of the same faces (probably not mine, though!) in all of his sessions. It showed that he had something interesting to say, and that attendees wanted to hear it.

This time around, he talked about how he wrote his book WikiPatterns using a wiki, and the workflow that he and this editors followed to produce the book.

Mader started out by saying that the workflow he used could be used for both print and online document publishing. And, from Mader’s experience, using a wiki streamlined and improved the publishing process from end to end.

Mader’s key point was that with a wiki, you can focus on context and content, and not have to worry about whether or not you properly marked up a section of a manuscript using a potentially complex Word template. As well, Mader’s editors were able to keep up with his progress. They didn’t have to stay up at night wondering whether or not he was writing; progress was there for all to see.

On top of that, having the information in a wiki makes it portable. Mader mentioned that no matter where he was he could work on a chapter as long as there was an Internet connection. And if his laptop died or was stolen, then he wouldn’t lose much information. Aaron and I will be talking about that point in the near future.

The writing and review process — from proposal to finished manuscript — was faster with the wiki than using a word processor. The biggest hurdle seemed to be getting the XML output from the wiki that Mader uses into a format that could be imported into QuarkXpress took a little doing. They had to create a script do that. That’s probably a bit more techie than many authors are capable of, though.

The changing role of the technical communicator

The final keynote of the conference was given by Noz Urbina. He discussed the new life of the technical communicator, and how new technologies and methodologies are changing how we work.

Urbina pointed out that users are demanding concise communication for increasingly complex products. To make that a reality, he said that we need to not only profile the needs of users, but also rebuild our workflows to accomodate new authoring methods like creating modular content.

He also stressed the need to do more than write manuals. Technical communicators must:

• Create instructional and informational documents.
• Combine text and static graphics with multimedia.
• Use Web 2.0 technologies to deliver documentation.

Urbina also mentioned some organizational changes that could be made to make the creation of documentation more efficient. He seemed to be advocating applying people differently and putting them into specialized roles — for example, template designer or procedural writer. I’m not sure I agree with this. It seems to be turning the process of technical communication into an assembly line.

Urbina closed with the following thoughts:

• Assess your needs and the needs of your users first, then think about the tools.
• Develop use cases to determine whether or not modular documentation and XML are right for you.
• Avoid migrating your old documentation problems to XML.
• Remember that there are more conversations about your products or services happening between customers than there are to customers. Try to tap into those conversations.

Interviews, interviews

I was also able to interview Stewart Mader (on using wikis), and Teresa Mulvihill-Talbot and Fabrice Talbot (of LiveTechDocs. They gave some great answers to my multitude of questions, and probably could have gone on much longer if not for my Eee PC almost running out of disk space. Maybe another time …

Check our podcast site in the next couple of weeks for these interviews.

Related posts:

1. DocTrain West 2008 recap
2. DocTrain West day 2: all wiki, all the time
3. DocTrain West 2008: day one