I’ve spent the last four days at the STC 2012, the annual conference of the Society for Technical Communication. What an amazing conference, and what great people! All the sessions I attended were of an excellent standard. I learned a lot, as you’ll find out if you read my notes. 😉 The people who came to my own presentation were responsive, appreciative and engaged. I met so many technical communicators who are enthusiastic, friendly, professional and skilled. This conference is a must.
There were around 750 attendees at the conference this year. A big vote of thanks to all the conference organisers who worked so hard to make this event a great success. Special thanks to Paul Mueller and Lloyd Tucker for piloting me and the other speakers through the preparations with such style. To all the attendees: I loved saying hallo to everyone that I met, I wish I’d managed to meet everyone, and I hope we all get a chance to meet again soon. Roll on #stc13. 🙂
This post wraps up a series on the conference, with links to my previous posts and a couple of photographs. I hope the posts are useful and the photos fun!
These posts contain my notes from the sessions I attended:
- Lightning talks
- Introduction to Global English
- Mobile app design
- Rough Drafts at a technical writing conference (an after-hours music jam)
- Progressive disclosure
- Using DITA
- Publishing to mobile devices
- Global, mobile, social: Surfing the perfect storm
- Modeling Information Experiences
- What is the role of a technical communicator when everything just works?
- Getting started with HTML5
- Building a developer documentation wiki (this is my own presentation)
- Why not DocBook?
Kai Weber has written some great summaries:
- James Conklin, Overcoming Change Resistance at #STC12
- Neil Perlin, Developing for the Unknown at STC12
- Things I learned at STC12 on Sunday (about arriving in Chicago for the conference)
Let me know if you see any more bloggers writing about the STC Summit!
A few of us went on a tour of the Frank Lloyd Wright museum before the conference started. Here’s a picture of Barrie, Gina, Ellis, me, and Peter at the Wright home and first studio:
Technical writers tangoed while the Rough Drafts jammed on Tuesday night:
I’m at the STC 2012, the annual conference of the Society for Technical Communication. One of today’s sessions was devoted to 5-minute lightning talks from 10 people. Here are some sound bites from those talks.
Robert Rhyne Armstrong was the moderator of this session. In his introduction he said, “This session is for fun. It’s meant to entertain you, in the same way a train wreck does.” It did.
The presentations were excellent and thought-provoking. And very fast. Instead of taking detailed notes, I jotted down a sound bite from each person. They will probably mean most to people who were there. 😀
Ray Gallon: Today, knowledge is power by sharing. The more we give away, the more influence we have. [Twitter]
Robert Rhyne Armstrong: I love each and every one of you. [Twitter]
Al Martine: Look at the horizon [to find your destination]. [Twitter]
Connie Giordano: It’s about camaraderie.[Twitter]
Kelly Schrank: You’re probably not going to get a standing ovation from your managers, but [they’ll be] appreciative. [Twitter]
Rick Lippincott: We [technical communicators] have always been there and we always will. [Twitter]
Richard Hamilton: If you have a hammer, everything looks like a nail. [Twitter]
Paul Mueller: [Speaking of himself] I use the term “presenter” in the very loose sense. [Twitter]
Paul’s session was hilarious. He had to talk through slides that Rhyne had put together. Paul hadn’t seen them until they appeared as he spoke.
Were you there, and do you have any sound bites or other impressions to add? Maybe you’re one of the speakers, and would rather be remembered by something other than what I’ve written. 😀 Feel free to add a comment!
John is the author of the book, The Global English Style Guide: Writing Clear, Translatable Documentation for a Global Market. His aim was to come up with a set of guidelines that help us avoid the type of language that makes translation difficult, without being as prescriptive or complex as Simplified Technical English.
In this presentation:
- Selected guidelines
- Benefits of developing Global English skills
- How will you implement Global English?
For non-native speakers, we need to simplify our language as much as possible, and avoid unusual terms. On the other hand, we want to keep native speakers feeling comfortable.
The use of translation memory underscores the importance of consistency. For any kind of translation, but especially machine translation, consistency and clarity are very important. We need to avoid ambiguity.
John took us through some selected guidelines, and gave his recommendations on each.
Guideline 1: Conforming to standard English
Don’t just blindly apply the guidelines. Think about whether there’s a better way of achieving your purpose.
If something doesn’t sound quite right, it probably isn’t standard English. John recommended a book, against which you can check your assumptions: The Bbi Dictionary of English Word Combinations.
Guideline 2: Simplifying your writing style
- Use short sentence
- Avoid passive voice
- Avoid unusual constructions.
Following these guideline also helps you to avoid inconsistency in your language usage. Also be careful about constructions that may be read ambiguously.
Guideline 3: Using modifiers clearly and carefully
- Be careful where you put the word “only”.
- Be sure that it’s clear what each prepositional phrase is modifying. Example: “Only 17 characters are available for the table name on a standard tape label.”
Guideline 4: Making pronouns clear and easy to translate
Make sure it’s clear what the pronoun is referring to. Even if native English speakers may correctly deduce the correct meaning, the translator may not. This is especially important in languages where the gender of the pronoun must reflect that of the noun.
Guideline 5: Eliminating undesirable terms and phrases
Why use words like “albeit” and “extraneous”, when simpler ones are available?
Avoid abbreviations, as they are difficult to translate. An abbreviation can stand for more than one thing. Also avoid truncated spellings. But note that there are exceptions, such as the word “app”. Consider what is in common usage, and what will be familiar to the audience.
Guideline 6: Punctuation and capitalisation
Often there’s no right and wrong. It’s a matter of consistency.
Guideline 7: Using syntactic cues
A syntactic cue is an element of language that helps people identify parts of speech and analyse sentence structure.
For example, see the Jabberwocky poem by Lewis Carrol. It’s full of syntactic cues that help you make sense out of nonsense.
John recommends adding more syntactic cues than are strictly required, such as adding the word “that” to make the structure of a sentence more clear: “Ensure that the client computer is still connected.”
These cues make the sentence more readable for non-native speakers, and even more native speakers. They also improve the result of translation, by removing ambiguities.
Two cardinal rules of Global English:
- Don’t make a change that will sound unnatural to a native English speaker
- Don’t insert a syntactic cue without considering whether some other revision would be even better. (Remember that these cues will increase the word count.)
Benefits of developing Global English skills
These guidelines help you, as technical writer, make sense out of nonsense. You can add value to the content by clarifying it.
They also provide explanations and justification for changes that editors are naturally inclined to make anyway. You can tell the writer, “It’s a translation issue.”
Perhaps one day this will become a marketable skill: You’re more up to speed with translation issues than other people.
How to implement Global English?
John has tried running workshops and training sessions. They don’t help much.
John recommends the use of controlled-authoring software, which issues a warning when it finds an error. This allows the editors to spend more time on other important aspects, such as reducing the volume of existing content. The software checks grammar, spelling, style and terminology. It gives instant feedback, and is quite customisable.
John recommends we call the software “language quality-assurance software” rather than “controlled-authoring software”, as the first characterisation is more acceptable to writers. Sometimes writers love it, sometimes they don’t. Writers enjoy that they get consistent feedback, which is not necessarily the case from a human editor.
Examples of tools:
- Acrolinx IQ – this is the one John recommends
- SDL Global Authoring Management System
- And more
John’s presentation includes a number of references. He highly recommends Multilingual magazine.
John recommends TextSTAT, a text analysis tool.
Thanks to John Kohl for a very informative and enjoyable presentation.
Joe has been working with mobile apps for quite a while. He thinks that we’re at a really interesting point, a time that will change the way we do things. He compared this period with the arrival of the mouse in 1989, and the way that changed what we do.
Mobile means widely different screen dimensions (mostly small) and touch interfaces. People are using new interactions with the UI. We need to look at software in a different way.
The interactions are changing very quickly. There are very few explicit standards. We need new techniques and processes, to deal with proprietary interactions.
We need a different vocabulary. Instead of “click this”, it’s “touch this”, “tap that”. But even more, we need to understand the full environment. The person is in motion when working with their software.
One technique that may be useful in this area is conditional processing. This is something we must look at in our tools.
Joe predicts that Apple will announce something new to do with touch interfaces in their upcoming conference.
Examples of touch devices:
- Tablets: iPad
Writing help for user interfaces
Joe showed us the Chicago Tribune mobile app, which overlays a layer on the screen showing you how to use the touch interface. A member of the audience mentioned that the USA Today app does the same thing.
Joe thinks that all mobile apps need some form of user assistance. He works for clients that develop mobile apps. For example, a mobile app that works with payrolls on the move. The mobile app is a “sidecar”, in that it provides some of the functionality of the desktop app but not all. The users already knew how to use the desktop app. The challenge was to bridge the user’s existing knowledge and transfer it to the mobile app.
Some interesting facts and tidbits:
- A member of the audience mentioned that you need to be careful when showing pictures of hands, or pointing fingers, as different gestures are considered rude in different countries.
- Tablet dimensions allow more interactivity, which can mean a more complex UI to document.
- An easter egg: Go to Speedtest.net on a mobile device, and pull the speedometer down and you see the person’s cat. Keep pulling down too see him in various positions. This is a hidden gesture just for fun.
The language of gestures
Finding the best word is very important. Work with your thesaurus and test the candidates with your users, to see which words work better for your customers.
It may take several days to design 4 words!
For example, the use of the word “hide” dramatically changed the way users thought of the interaction.
Remember that the choice of words may need to change depending on the mobile device in use.
Joe showed us some examples of gesture language in user assistance:
- AutoCAD gives short textual instructions in a banner across the top of the screen. This is guided help that instructs users while they do the task. This is effective but takes a lot of resources to do.
- Convertbot has a tutorial that shows popup bubbles describing the UI elements. Interesting is that they use the words “press the OK button” instead of “tap OK”. This may be the use of generic language to work on different platforms, or it may be that they didn’t think of changing the language.
- eBay have video tutorials, using live fingers. This works, but you need to consider how much you need to show. Also, the device itself tends to be obscured and in the background.
Vocabulary for touch and gestures
See the Touch Gesture Reference Guide. The authors went through a number of pages of documentation for various platforms, to analyse the terminology used for gestures. This is very useful.
Joe led us through a discussion of whether we would use specific terminology per platform, as chosen by the device vendors, or whether we would use generic language. The audience chose to use generic language. Joe said that sounds sensible, but consider the user. For a customer who has chosen a Windows phone, you would probably be using terminology that is more typical in an iPhone or Android phone. Your documentation may use a different vocabulary from the other help for this device.
A member of the audience pointed out that this terminology issue means that you must work closely with your translation manager. Joe showed a slide about translation issues for gesture terms. In some languages, you will probably end up with different translations for the same term, depending on the context.
Conditional text will be a big part of our toolset.
Joe works with HTML5, CSS and MediaQuery as a solution for allowing devices to announce their screen dimensions and interfaces to stylesheets, which can then do transformations based on the device requirements. He has stylesheets to cater for 4 device types:
- 7-inch tablet (Galaxy and Kindle)
- 10-inch tablet (iPad)
We need to consider device-specific controls in our documentation. For example, different Android devices have different button bars. Or a gaming device will have gaming controls instead of those used on a phone.
Things are moving so fast that voice will soon start making user assistance easier. Siri works fairly well. It’s limited to apps that Apple wants to support. There is talk that Apple will expose an API for Siri so that other app developers can use Siri to give user assistance, either through return voice or by taking the person to a certain topic on the app developer’s web server.
Joe showed us an example of asking Siri how to write a cheque in Quicken. You get a link to the Quicken documentation. This doesn’t really work, because there is no API for Siri. Joe hacked the example together to show us that it could happen!
Thanks Joe. This was an inspiring session.
Do rough drafts have a place at a technical writing conference? They do when they’re the Rough Drafts at STC 2012!
Technical communicators jam in style. On Tuesday evening, we all doffed our serious conference faces (hah!) and donned our dancing shoes to tap along with the Rough Drafts. The band was formed by two STC members, Tommy Barker (lead guitar and vocals) and Rich Maggiani (drums). The other band members are Viqui Dill and Robert Hershenow.
Here are some photos and a video that I took during the evening.
The video below shows the Rough Drafts’ rendition of one of my all-time favourite songs: Peggy Sue. They did a great job!
A happy wave from Viqui:
The band rocking it:
Janet and Ellis chilling it:
Guest singers spicing it up, including my friend Kai Weber.:
Technical writings jiving to it: