12 lessons learned & 3 unique features of tekom12

tekom, the world’s largest tech comm conference, ended today after three days with more than 220 presentations, workshops and tutorials in German and English. (More detailed numbers and much, much more conference blogging over at Sarah Maddox’ blog.) Here are 12 lessons that I learned and 3 ways how I think tekom is unique and different from other conferences I’ve been to, such as TCUK, the STC Summit or WritersUA.

What I learned

5 lessons about tech comm:

1. “Cheap documentation is expensive!” – From Sarah O’Keefe’s session on Transforming Technical Content into a Business Asset.
2. “Poor design costs!” – From Leah Guren’s Advanced Visual Editing.
3. Reuse or conditionalize complete sentences, no less. Else it becomes virtually impossible to translate in DITA or otherwise. – From Marijana Prusina’s tutorial Around the World with DITA (in German).
4. Cross-language documentation works. German and English are related so closely, you can successfully create German documentation for English interfaces. You will need to pay some attention to grammar, spelling and anglicisms, though. – From Marc Achtelig’s Do you speak Deutsch? (in German).
5. Cloud-based terminology is coming. The European Union funds a cloud-based Terminology as a Service project. – From Klaus Schmitz’ Terminological Information and Services for Language Workers (in German).

And 7 lessons about tech comm conferences:

1. Have business cards handy. Even “after-hours” over beer, they might just get you a cool free t-shirt by Atlassian that says “Don’t drink and write.”
2. Maintain a network. A good network of fellow tech comm’ers can help you in more situations than I imagined. – From the Strategic Technical Communicator panel. And from lining up a few more speaking opportunities by tapping my, uhm: network… 🙂
3. Have worthwhile content. High-concept talks will fail if the first half is trends and statistics which any listener will know who’s keeping up with industry news and the second half is about the great things your company does. – From a session I marked down on the evaluation sheet.
4. Unusual topics work. Presentations, such as how meaning works in tech comm, can succeed if you have a well-told, well-sourced story, even if the research is a bit farther afield, for example, from semiotics or psychology.
5. Know your audience. The rift between academia and tech comm’ers will persist if research feels like institutions and budgets trying to justify themselves. I think presentations of academic research will be more successful if they appeal to a common interest in how and why stuff works. German academic speakers, please know your audience and front-load the cool benefits you can bring, not your definitions and methodology.
6. Know time. Speakers, please practice and if necessary cut down your talk: Running late and then skipping over the last slides is doubly annoying. Unless you’ve been added to the program late, you’ve had plenty of advance notice!
7. Have some integrity. It’s fine to talk about yourself if you have a good story, but please don’t undermine your session title and audience expectations. “Be more like me!” is not a widely applicable answer to “How to do X?”

How tekom is unique

1. Size. tekom is first and foremost uniquely large, it is huuuuge! 2400 registered attendants attending 15 concurrent streams of sessions takes a convention center, not a conference hotel as I know it from other tech comm conferences. Because it is so huge, you need more planning to ensure you’re hitting the best sessions.
2. Global and bilingual. Even though it is predominantly a German conference, it is the most successfully international, multi-lingual conference I know. A quarter of all presentations, workshops and tutorials are in English. My personal impression is that attendees come from more countries than to any conference.
3. Variety in content. Because of the huge number of sessions, tekom affords more variety in sessions than I’ve seen elsewhere. Streams are dedicated to the usual suspects, such as content strategy, localization, mobile documentation, user assistance. Add to that more unusual, but valuable streams, such as higher education and academia, visual communication, personnel and cost management.

Thanks to everyone who helped to make this year’s conference a success, especially to tekom’s dedicated conference crew!

-Oh, and as it turns out: You’ve just reached the end of my 200th blog post… 🙂 Thanks for reading, thank you for your support!

Advanced visual editing with Leah Guren at tekom12

Leah Guren presented a fast-paced, entertaining session full of relevant tips to improve visual editing in documentation. While some of her advice refers to page-based deliverables, most of it also applies to online output styled by CSS.

First, Leah showed how good layout improves usability, while poor design actually hurts the success of your documentation:

• Good design means to apply layout that supports the document’s meaning. So use numbered lists for sequenced information, bullet lists for unordered information and tables to (visibly) structure information.
• Poor design means information is hard to find, hard to identify and simply looks unprofessional.

To apply good layout design, you can use 5 principles which make up the acronym PARCH:

1. Proximity.Ensure that items and information that belongs together appears together:
   • Place headings closer to the text they belong to below than to the text above.
   • Arrange list items in chunks, so each item is easily recognizable as a unit of its own.
   • Offset individual paragraphs to clarify paragraph integrity.
2. Alignment. Ensure that vertical alignment uses few, sensible points of reference, so bullets and numbers are indented to one vertical line, the list items introduced by bullets and numbers to a second vertical line. Also ensure that text flow in tables is clear and it’s easy to identify which table items belong to the same row.
3. Repetition. Repeat visual patterns to signal intent and to ensure consistency. This applies to how you use colors and icons and where you place items within a topic or on a page.
4. Contrast. Apply contrast to focus the reader’s attention. For example, use larger and/or bold fonts for headings.
5. Hierarchies. Use hierarchies of topics and sections to nest information. This also means to avoid single children of parent topics, because you logically cannot divide a chapter or section into just one sub-section. (As a solution, you can either move the child topic to the parent level, or if more child topics are on the way, have a placeholding topic that introduces or previews the forthcoming topics.)

Then Leah offered some additional tips:

• Use icons to allow for quick filtering. Like a Thai restaurant that marks hot dishes with icons of one or several chili peppers. Or vegetarian dishes with a leafy icon.
• Choose your fonts smartly and consistently.
• Don’t design for exceptions. For example, don’t create a standard table with wide cells, just because you may have one or two cases which otherwise need to wrap around.
• In headings and paragraphs, apply white space only above for consistency.

And as final recommendations:

• Learn about design – it’s pretty easy already with stuff you can find on the web or paperback books.
• Ensure you get and stay involved in the design of your documents.
• Experiment and try new things – be brave, but stay sensible.

Strategic Technical Communicator panel at tekom12

Marijana Prusina, Nicky Bleiel, Sarah O’Keefe and Dr. Tony Self pooled their experience in an interesting and versatile panel session about the more strategic aspects of our profession.

The Strategic Tech Comm panel (photo thanks to Axel Regnet)

It was not so much a discussion as a fast-paced session of the experts sharing their thoughts on strategic issues and problems, so I’ll simply list some of the insights:

• Domain knowledge for a certain industry (as opposed to general tech comm skills) can be a great asset that you can use to build a career on, but it’s not necessary to become an expert in any one domain.
• To get a mandate or money from management, don’t argue in terms of quality, but rather in terms of cost: Show how improving documentation will either reduce cost or create additional revenue.
• Freelancing can work well, but you will need some things which are less essential if you are employed:
  • Considerable project management skills – even if only for your own projects
  • A good network of satisfied customers, other people who know and like your work, and other freelancers with whom you can exchange tips and tricks – and maybe even projects if they’re better skilled to take them on or when you are busy.
  • A snappy definition of your core services, skills and profile.
• To improve the reputation of tech comm and exert influence in your company, try these strategies:
  • Volunteer, if you can afford to, whether in a professional tech comm association or a standards committee.
  • Underpromise and overdeliver on your deliverables – and meet the deadlines you agree to.
  • Write a book – but be aware that you’ll mainly do it for marketing and influence: It’s a lot of work, and it won’t make you rich.
  • Be the advocate of users, who are satisfied, more productive and less costly to your tech support thanks to good documentation.
• Take all the training that makes sense to you and that you can get. Don’t forget about domain skills and software-related skills, for example, for API documentation. When training, keep in mind your resumé and what value you will add to your customers or your employer by adding a certain skill.

First day at tekom12

This is my second year at tekom, the world’s largest tech comm conference held annually in Wiesbaden, Germany. tekom is nominally a German conference that coincides with its international sibling conference tcworld in English. As the hashtag confusion on twitter shows once again, the English tech comm scene tends to use both names. (Which makes me wonder why the organizers don’t simply use the tekom name for the whole thing which has sessions in English and German…?)

My session on meaning in tech comm

I skipped the morning sessions, since I was feeling a little under the weather. I didn’t even get to tekom until around 1 pm, but in plenty of time for my own presentation on How our addiction to meaning benefits tech comm. I had submitted two very different talks, and I thank the organizers that they picked the “wacky” one. And to my surprise, I had about 100 people interested in meaning, semiotics and mental models! I thought the talk went well. I had some nice comments at the end and some very positive feedback on twitter afterwards.

You can find my slides on Slideshare and on the conference site. Sarah Maddox has an extensive play-by-play write-up of how my session went on her blog.

Content Strategy sessions

Scott Abel has put together a very good stream of content strategy sessions, where I attended the presentations of Val Swisher and Sarah O’Keefe (I also blogged about Sarah’s presentation). I’m not sure if my observation is accurate, but it seemed to me that there was less interest and excitement about this stream this year than at the premiere last year. As befits content strategy, both sessions I attended were strategic, rather than operational, so they dealt primarily with how tech comm fits into the larger corporate strategy.

Marijana Prusina on localizing in DITA

Then I went to hear Marijana Prusina give a tutorial on localizing in DITA. I have no first-hand experience with DITA, but I use a DITA-based information model at work, so this gave me a reality check of what I was missing by not using the real thing. Seeing all the XSLT you get to haggle with in the DITA Open Toolkit, I cannot exactly say that I regret not using DITA.

Beer & pretzels

Huge thanks to Atlassian and k15t who sponsored a reception with free beer & pretzels – and even t-shirts if you left them your business card. This coincided with the tweet-up. It was good to see tech comm colleagues from around the world (Canada, the US, Australia, France and Germany, of course). Some I had known via twitter or their blogs for a while, so it was a welcome chance to finally meet them in person.

– For more, many more session write-ups check out Sarah Maddox’ blog!

– So much for the first day, two more to come. I’m looking forward to them!

Turning tech comm into a biz asset by Sarah O’Keefe

Turning technical communications into a business asset, according to Sarah O’Keefe, is mainly about justifying cost; it is necessary, but possible. Her session at tekom12 was part of the Content Strategy stream, presented as last year by Scott Abel.

How expensive is your documentation – really?

Much progress in a tech comm department gets stumped when we, the tech writers, say: “Ah, that’d be great – but they’ll never pay for it!” What that really means is: “‘They’ don’t see the value (or the urgency).” So to prove the value behind tech comm, we need to justify how we can either save money (by reducing effort) or how we can generate additional revenue (by producing value that exceeds our cost).

Sarah points out several way to do this:

• Show how tech comm can address legal or regulatory issues. Avoiding lawsuits is a great way to save your employer’s money!
• Control the real cost of tech comm, because “cheap can be very expensive”: Yes, you may get something akin to documentation from a secretary or an intern, but…
  • Is your documentation efficient to maintain?
  • Does it scale or allow publication in other formats?
  • Does it actually satisfy your customers and support your brand – or does it stab your corporate value statement in the back?

Cost containment strategies

Sarah mentioned several strategies to control documentation cost.

The first bunch has to do with efficient content development:

• Reuse as much content as possible: Write once, use many times, either in different places of the same format or in different output formats.
• Automate formatting: Manually handcrafted formatting of deliverables can be a huge cost factor. It’s not uncommon for tech writers to spend 20% of their time (and hence a sizable chunk of money) on formatting output. Automate this, by relegating format either to templates or CSS.
• Localization scales content efficiencies: Localizing or translating your content will be all the more inefficient, the more inefficiencies you have in your original documentation processes. This applies to content reuse, inefficient content variants and formatting.

Then there’s cost reduction outside of the tech comm team, for example, in tech support:

• Consider whether your documentation is good enough to deflect the maximum possible number of support calls. Anything that users cannot find in the documentation, whether it’s missing or unfindable, drives up costs for your tech support staff.
• Ensure your tech support staff has access to your documentation in formats they can work with efficiently. Downloading and then opening a document of 10 or 20 MB, is not only clumsy in its own right, it’s also likely that it doesn’t present the required information in the most efficient way…
• Ensure your documentation content is actually useful to tech support staff: It must not only be accurate, but also up-to-date. Consider the nightmare in terms of costs and maintenance if tech support spun off their own documentation to augment the “official documentation”. Instead, invite them to contribute to the documentation you create.

Make documentation more strategic

Then there are a few strategies to make documentation more strategic, or rather, more strategically valuable:

• Ensure your documentation is not only searchable (so it’s captured by publicly accessible search engines), but also findable (so people know where and how to get to it) and discoverable (so people link to it, from blogs or forums or twitter or the like).
• Align tech comm to larger business goals: Find a corporate goal, preferable one that is tied to revenue to be made or cost to be avoided and show: If the tech comm team did this, it could contribute approximately that much money (in savings or additional revenue) to that larger corporate goal.

Conclusion

Sarah’s talk was geared towards the strategic angle of tech comm, but succeeded in making valuable points very clearly. Whether you can actually apply her advice in your situation may depend on how much managers with budget control feel the pain of improving tech comm.

How our addiction to meaning benefits tech comm

Join me for my presentation “Addicted to Meaning: How Good Technical Communication is Like Bad Magic Tricks” at tekom/tcworld in Wiesbaden on Tue 23 Oct at 1:45 pm.

In the session, I will explore how “meaning” works in technical communication, why it sometimes fails and how you can improve its chance for success. Being meaningful in your work is harder to measure than being correct, concise or consistent. However, it is just as essential: Understanding how and why communication is meaningful to your readers can help you to make your documentation more effective and to distinguish good from bad.

Using examples from topic-based authoring and minimalism, I will illustrate the underlying working of semiotics and mental models to show:

• Why minimalism works, but FAQ’s don’t
• Why asking a friend is effective, even when he doesn’t know the answer
• How readers create meaning from documentation
• … and how good documentation is like bad magic tricks 🙂

I will put our familiar tech comm tool box into a new context, so you can get a deeper understanding and a fresh perspective on tech comm and how it fits into the bigger picture of meaningful communication.

I’ve set up the topic in two earlier posts which give you an idea how I’ll tackle the issue:

• But do we create documentation with meaning?
• How meaning works in technical communication