TCUK12 summary, likes & dislikes

This was my third consecutive year at TCUK, and I was surprised and glad to see how much I enjoyed it in different and new ways than before.

I mainly enjoyed seeing acquaintances and friends again who made me feel like I was part of the family. I was glad to help the conference organisers in a small way by facilitating two sessions. And it was great to hang out with the international tech comm “jet set”, whether they’re from England (hi, Alison, David, Elaine, Felicity, John, Jonathan, Robert and Sue) or from farther afield (hi, Charlotte, Diego, Janet, Karen, Leah, Maxwell, Morten and Ray).

I also felt more relaxed and less nervous, because my own session was a panel discussion which can only stand limited preparation. By contrast, my presentations in previous years were prone to overrehearsing… 🙂

The panel itself went quite well, even if Robert Hempsall had to bow out at the last minute. Karen Mardahl, Ray Gallon and I discussed how internationalization, specifically different language skills, different cultures and different technology affect accessibility. Thanks to our audience who contributed their own experience, it was a lively discussion and the 40 minutes went by very fast.

Likes

• Nice size. TCUK is small enough to have a very cozy, almost intimate feeling about it, yet large enough to be dynamic and diverse.
• Professional, constructive vibe. Whether they’re newbies or experienced, many delegates get involved and contribute their experiences and opinions in the sessions during Q&A and outside, in the foyers, over lunch or at the bar. I see a lot of communal participation and engagement and very little sit-back, entertain-me consumerism.
• Diversity and quality. I’ve been amazed once again at the wide variety of topics and the generally high quality of the programme:
  • The 3 keynote lectures by Leah Guren, Scott Abel and Karen Mardahl were excellent: Relevant, inspiring and entertaining each one of them! Their general upbeat tone pervaded the entire conference.
  • The 6 workshops on Tuesday (as far as I’ve seen and heard) were hands-on, very practical and applicable. Participants contributed interesting, sometimes provocative perspectives which added insights and reflection to the practical exercises.
  • The 30 sessions on Wednesday and Thursday (again, as far as I’ve seen and heard) were for the most part well-presented and an interesting mix of conceptual, high-level discussions and roll-up-your-sleeves practical advice.

Dislikes

• Sessions are too short.  At 40 minutes total, they often have 30 minutes or so for the actual presentation and some time for Q&A. I prefer presentations of 45 minutes plus Q&A afterwards, which can run for 5 to 15 minutes.
• Food. Personally, I didn’t care much for the food at the hotel, but that is a matter of taste, as always. Other delegates liked it just fine.
• No time to explore. Glancing at Northumberland from the plane, I regretted making such a tight schedule that I saw nothing outside the hotel and the airport. It looks like a beautiful area well worth exploring.

In-depth session reports

For more details about some of the sessions I have attended, see my previous posts:

• TCUK12, day 1: Workshops & company
• Leah Guren’s Fish Tale at TCUK12
• Ray Gallon’s Hairball of Content at TCUK12
• Scott Abel on Structured Content at TCUK12
• David Farbey on editing at TCUK12

– If you’ve attended TCUK12, feel free to add your impressions in a comment below. If not, you can still add a comment or ask a question… 🙂

Advertisement

David Farbey on editing at TCUK12

In his session Letters From The Editor, David Farbey talked about what editors do, what they can do and what they can do better.

What editors do

Basically, it is the job of editors to mediate relationships. They mediate the relationships between the writers, their content, their audience and their organization (such as a company or institution).

More specifically, they still do much of what Robert Van Buren and Mary Fran Buehler laid out in their seminal booklet Levels of Edit of 1980 (a PDF version is available online). Mind you, much has changed since, but many of the basic principles still apply. So David took his cue from the 9 levels of edit to propose 3 classes of edit today:

• The policy edit is for coordination and planning. It ensures that the content is appropriate to the organization and its audience, that it complies with the organization‘s policies and strategies.
• The copy edit handles all the technical issues of content, from spelling and punctuation to formatting and textual integrity. It ensures that the text is functionally correct and clear.
• The developmental edit addresses the content itself in the last and most important stage. It ensures that the language is comprehensible and presents the text’s substance appropriately and clearly, whether it is a concept or a procedure. (This is not the same as a content review! A subject-matter expert reviews whether content is correct and complete, while a developmental editor ensures that such content is presented in clear and comprehensible language.)

 All three classes of edit occur at the same stage in the content workflow:

1. Policy edit: Author and editor plan content production.
2. Author writes content.
3. Subject-matter expert reviews content.
4. Author corrects content according to review.
5. Developmental edit: Editor edits content.
6. Author corrects content according to edit.
7. Copy edit: Editor proofreads content.

Advice for editors

• Check the text and the publication, not the product or the facts that are described in the text, that’s the task of the reviewing subject-matter expert.
• Offer constructive criticism, don’t evaluate or grade the text.
• Mentor the writer, if necessary, don’t manage the writer. If you are his or her manager, put on your editing hat, not your managing hat.
• Create and apply guidelines and policies:
  • Create and comply with a corporate style guide as a searchable collective memory to guide the work of writers and editors alike.
  • Agree on who has the last word.
• When editing topics in structured authoring:
  • Edit in chunks
  • Add a step in the workflow before the copy edit: Editor or writer compiles document
• When editing in an agile environment:
  • Consider when a content item is shippable
  • Consider when the document as a whole is shippable
  • Change the workflow so steps 2. through 4. above become: Write and review in sprint.

Scott Abel on Structured Content at TCUK12

Scott Abel delivered his keynote It’s All About Structure! Why Structured Content Is Increasingly Becoming A Necessity, Not An Option in his usual style: Provocative, but relevant, fun and fast-paced (though he said he was going to take it slow). He even channeled George Carlin’s routine on Stuff: “These are ‘MY Documents’, those are YOUR documents. Though I can see you were trying get to MY Documents…”

His style doesn’t translate well onto a web page, so I’ll restrict myself to his 9 reasons Why Structured Content Is Increasingly Becoming A Necessity:

1. Structure formalizes content, so it can guide authors who need to make fewer decisions when writing it. It also guides readers who can find more easily where the relevant information is in the whole documentation structure or within a topic. And it guides computers which can extract relevant information automatically and reliably.
2. Structure enhances usability by creating patterns that are easy to recognize and easy to navigate with confidence.
3. Structure enables automatic delivery and syndication of content, for example, via twitter – and you’ll be surprised occasionally when and how other people syndicate your “stuff”.
4. Structure supports single-sourcing which means you can efficiently publish content on several channels, whether it’s print or different online outputs, such as a web browser, an iPad or a smartphone.
5. Structure can automate transactions, such as money transfers, whether they are embedded in other content or content items in their own right.
6. Structure makes it easier to adapt content for localization and translation, because you can chunk content to re-use existing translations or to select parts that need not only be translated but localized to suit a local market.
7. Structure allows you to select and present content dynamically. You can decide which content to offer on the fly and automatically, depending on user context, such as time and location.
8. Structure allows you to move beyond persona-ized content. This is not a typo: Scott doesn’t really like personas. He thinks they are a poor approximation of someone who is not you which is no longer necessary. With structured content (and enough information about your users) you can personalize your content to suit them better than personas ever let you.
9. Structure makes it much easier to filter and reuse content to suit particular variants, situations and users.

Ray Gallon’s Hairball of Content at TCUK12

Ray Gallon‘s session The Hairball of Content was a high-level tour de force where he argued that we technical communicators do much more than just technical writing. However, we rarely get credit for all the other work we do in tasks such as content strategy, user interface design, information architecture, etc.

Assisting the user

Our overarching task is to assist users by translating the functional thinking of engineers into something that users can act upon and experience. That means our content is not just in the documentation, but it’s also in the user interface, in the error messages, etc. So technical communications accompanies the complete design process – and we tech comm’ers need to be involved from day one.

If we take our role as the users’ advocate seriously, we need to tweak some of our dogmas a little to ensure that users get the maximum benefit.

Embedding fosters knowledge

Concepts as documentation content are not an end in itself, but they need to offer decision support to users. A concept should tell readers whether they are looking at the right tool or function at the right time. That means such conceptual information needs to be available right where it matters. Even if it means to give context with conceptual information inside a procedure topic, either in the introduction or even as a short sentence in the individual step.

Yes, such mixing of topic information goes against the rules of topic-based authoring, but it will actually help users: Offering such mixed information in context transforms the sheer information of how to do a task  (which is hard to remember) to knowledge of why and how to do a task (which is easier to remember.)

Context is everything

Ray said: “Context is everything” – which applies across the board:

• User assistance needs to be available in the context of the user’s workflow. Embedding contextual information in layers, from GUI labels via tooltips to full-blown help topics, will support users accomplish their tasks faster and more easily without taking more of their attention than necessary.
• Each piece of user assistance also needs to offer sufficient context to be meaningful and “learnable” for users: Only offering steps 1 through 5 in a procedure usually doesn’t offer enough context for users to actually learn how to use a product or a function, if we omit the “when” and the “why”.
• User assistance also needs to offer enough context to allow users to navigate easily and with confidence through the product and the documentation. Specifically, we need to offer users an easy way back to where they’ve come from and a way back to the product and their task.

Offering successful user assistance isn’t a question of offering more at all costs, because more information isn’t necessarily better for the users. Instead, we need to stimulate cognitive demand, the will to know and learn, in the user by offering the right information at the right time.