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:

– 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… 🙂

Advertisements

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.

Leah Guren’s Fish Tale at TCUK12

After opening remarks by conference organizer David Farbey, Leah Guren‘s keynote relevant and entertaining keynote address presented several lessons from the animal world:  A Fish Tale: Improve your Career by Watching Fish!

  1. Take a leap of faith – like salmon. It simply takes some guts and a little bit of faith that tech comm is here to stay, else you won’t be able to make a long-term plan and get behind it.
  2. Stay in school for better chances of survival – once you took that leap, keep honing your skills, keep developing. There are lots of ways and many don’t require the same amount of time and money as going to a conference, whether it’s e-zines, forums, user groups or webinars (some excellent ones are actually free!) Be sure to make your professional development part of your regular work schedule.
  3. Invest in better PR – the difference between a carp and coi is mainly the prize tag – which is thanks to better PR for the coi. Communicate your value that you bring to the company and to its customers. We know how much words matter, so we can do better than calling ourselves technical writers. “Information architects”, “content strategists”, even “technical comunicators” can make more money.
  4. Find the right stress – (sorry, I forgot how this related to fish… 😉 ) Tackle your fears, get a new challenge and pick the kind of stress where you’re still in control, feel stimulated and can grow.
  5. Active swim in a larger pond – because like a carp you will grow (professionally) in relation to the size of your “pond”. Find opportunities for growth how you can be the expert in your environment.

I’m sure I forgot a couple of Leah’s lessons. Nevertheless, I want to add an additional lesson that I’ve found important: Know the secret of the birds. That means know how your enemies tick, so they don’t eat you. Or if they’re not threatening: Seek heroes outside of your immediate field. Sure, you won’t be able to fly like a bird, but you can still find birds inspiring.

TCUK12, day 1: Workshops & company

The first day of the ISTC conference TCUK12 offered workshops and great opportunities to meet tech comm’ers from all walks of life and many corners of the earth.

When I arrived late on Monday evening, I promptly headed for the bar and joined the advance party for a last round – which lasted so late that I’m not even sure in which timezone it was 2 am before I turned in…

Robert Hempsall: Information Design 101

Robert Hempsall offered a great and engaging hands-on Information Design 101 workshop about information design. The workshop focused on the five key areas of content and structure, language, layout, typography, and lines and spatial organization. Using a formal application to vote in English elections by mail, Robert led us through the process of designing the form to maximize clarity and usability.

Thanks to our versatile and engaged group of delegates, our work on the form was not only lively, but showed how different disciplines contribute to the solution of better information design, from tech comm (with its principles of minimalism and parallelism) via user interface design (with its emphasis on making completion of the form as easy and painless as possible) to graphic design.

In this sense, the workshop presented a good example of “design by committee” (which is usually a terrible idea): We discussed the most intuitive and user-friendly sequence of the form’s elements and how best to phrase the section headings, as questions or as imperatives. A seemingly innocuous “all of the above”  check box also caused a debate: Should it precede the individual options, to make completing the form quick, easy and painless? Should it come last, so users hopefully first read and reflect on the options? Or should it be omitted altogether, so users have to think about each option and select all that apply.

Form design is maybe not among the core tasks for many tech writers. Yet I’ve found several challenges in it that are strikingly similar to getting a topic structure just right, whether it’s a consistent, indicative heading, good, clear instructions or logical structure.

Rowan Shaw: Quality Across Borders

Rowan Shaw‘s workshop Quality Across Borders: Practical Measures to Ensure Best-Value Documentation in Global Technology Businesses focused on creating documentation both with authors and for users who have English as a second language (ESL).

As in introduction, Rowan presented us with 10 sentences each of which had some element that can create a problem for ESL readers, ranging from “10/03/12”, which could mean 3 October or March 10, to metaphors and slang.

If you need to hire ESL authors, it can be helpful to ask applicants to sit for an exam which tests skills such as procedure writing, fluency of expression, structuring, detail, consistency – but also their motivation for applying, to spot those candidates who want a foot in the door, but might not be interested in tech comm in the long term. We discussed a sample test, whether it was applicable and appropriate in all cultures.

Rowan suggested that, given the practicalities of global ESL authors, you might have to settle for less than perfect profiles in candidates. Then it is important to know which skills are easier to teach someone on the job, for example, grammar, structuring, capitalization, punctuation and how to use a style guide. Other skills are harder to teach, such as an eye for detail, audience orientation, logical thinking, but also more intricate language skills, such as prepositions and correct modifiers.

Again, this workshop benefitted tremendously from the diverse talents in the room and the experiences delegates brought to the topic.

The right company

I keep harping on how much I enjoy and benefit from meeting other tech comm’ers. Just on the first day:

  • I found that several other doc managers are also wary to hire subject matter experts, who are less committed to tech comm, because they might just want a foot in the door (see above).
  • I had an immensely helpful conversation with someone who’s a visiting professor and who could give me tips and ideas that I can try as I consider teaching as a future path.

So day 1 was very fruitful already, and I’m looking forward to more sessions and conversations to come.