Pre-Conference Dinner
The first day of a conference is always a little awkward, introducing yourself to complete strangers is always fraught with danger. So a ‘mingle’ activity is a nice idea, particularly as the TICAD conference makes some play of the networking opportunities, and the an informal dinner beforehand certainly made the following day a little easier. As it turns out I bumped into someone who worked at a sister company of my previous employers (it’s a whole complicated one company, then two companies, then one company thing), and we traded some names and stories.
Dinner was good, with many laughs and thought provoking conversation the kind of thing you get when you dine with a bunch of smart, friendly people. One topic which cropped up, and naturally I can’t recall why (did I mention the wine?) was Chess Boxing. Yes, that’s right, Chess Boxing. It was new to me as well.
The Conference itself is aimed at TechPubs managers and was celebrating its 10th year. Organised by ITR it has a focus on translation issues but is largely a TechComms focussed day. I’d heard of TICAD before but this was my first time both attending, and speaking at, the conference. The day was split into four sessions, the third comprising of two breakout sessions, the others more standard presentations. I took notes for all of the presentations but skipped the breakout sessions to go over my own presentation one more time.
Convergence in technical communications
The opening session was kicked off by Mark Wheeler of Adobe, and despite being fairly much a product pitch, it did outline Adobe’s thoughts concerning the convergence of various areas, with internal documentation, public documentation, Help systems, Knowledge Bases, training material and Demos all becoming more and more closely linked. All share similar traits, they all rely on high quality content for example, and organisations are beginning to realise the benefits of sharing information across these areas.
Part of the presentation did flummox me somewhat, and whilst it may have be a cool demo feature I do question the reality of usage. The idea presented was that by using embedded content within a document or help system, you could launch a video or “better still” initiate a text chat session or VOIP call to a support operative to help you with your current issue. Now, my belief is that, for that scenario, people want to get OUT of the help a.s.a.p. Why on earth would I want to sit through a video, or talk to someone and have to explain my issue, when all I want to do is get on with my work?
Naturally the focus was on the new Technical Communication Suite and overall it does look like it adds some value and will be of huge benefit to many technical communications teams. But then demos ALWAYS look good, don’t they…
Adapting structured documentation and DITA
When I saw this presentation listed in the agenda I marked it as one to attend. We are currently heading down the DITA path ourselves and Thomas promised to share some of the issues and pitfalls he and his team had come across. His presentation was excellent and hugely informative. A quietly spoken American, who was at our table for dinner, he covered everything I had hoped and more.
He covered the guidelines they had to put in place for help the writers cope with the move to structured authoring, including their 5 Glorious Principles (and yes I will be ‘borrowing’ this idea), namely that when writing topics:
- Standalone chunking – create discrete chunks that contain only information about the topic/type.
- Labelling – Titles are explicit, describe the topic (this also stops conceptual phrases like “this section contains” and so on).
- Relevance – the content matches the topic.
- Consistency – topics are written in the same way.
- Reuse – topics are written once and can be used many times.
Working in a large organisation they found they had to hire a dedicated Documentation Product Manager, to coordinate and liase with Technical Publications, Training, Marketing and all other information creators. They also hired a dedicated architect to manage their DTD.
Outlining the drivers for their change, with localisation being the biggest (numerical) business reason, he talked through the planning stages, and admitted that they decided to stick to topic-level reuse rather than ‘conref’ level reuse (in theory you can reuse any single element, so a paragraph or list can be used in multiple topics) although that is something they are currently addressing. As a path to ease the pain of migration it is likely we will do the same, so it’s good to hear others taking the same route.
Technical English made simple
I wasn’t too sure what to expect from this presentation, but was pleasantly surprised. Admittedly as it was focussed more on maintenance style procedures, for hardware, then the suggestions didn’t always apply to a more software oriented team writing (or moving towards writing) in a task based style, there were still many valid points to take home.
Amongst the commonly held truisms, such as writing with an active rather than passive voice, Maria expanded on these topics with several examples, and the basic premise that most technical documentation is easier to read, less ambiguous, and easier to translate, if you simply consider each sentence and make sure you are assigning the task to the reader.
At present we don’t translate our docmentation but I am more than aware that someday, soon, we will be asked to do so. Some of the suggestions made by Maria will form part of new guidelines as we adapted our writing style to be more translation friendly.
In-country translations
Helen Eckersley, of iTR, gave a presentation which I didn’t think I’d take that much from. Focussing on getting the most from the people who review translated material it largely followed general practise for making the most of any kind of review, technical, linguistic or otherwise.
However, as it the way of things, it’s always good to get a reminder of such things, and similarly to Maria’s presentation I did gleen some information that, if put in place, should make translation of our documentation a whole lot easier.
Helen touched on linguistic assets, containing glossaries of approved terms (cross-language), translation memories, style rules for acronyms, product names and so on. All things we can consider now and start to build ourselves.
Using Wikis for Collaborative Authoring
Some Scottish bloke stood up and waffled on about Wikis, illicited the odd smile and largely left everyone bemused.
Vision of the future
The final speaker was Bernard Aschwanden, who I saw present at X-Pubs earlier this year. He is an animated, charismatic and passionate speaker and was given somewhat of a free reign to pull together his Vision of the Future.
He opened with a video, one which I think I’ve linked to before and which still bears repeat viewing.
Frankly the video is enough to get the synapses firing but building on that, Bernad took us back through the history of Publishing, from the first clay tablets, past the Guttenberg Bible all the way to Playboy. He tracked back through the advances in the past 100 years of technology, and then headed into the future.
Breaking things down into two sections, the first of which dealt with the coming 5-10 years, Bernard offered his take on where the traditional Publishing processes would take us. The basic premise is the same, regardless of the timescale, but the way in which information is handled and managed will change. For example, at present we spend a lot of time fudging with DTP packages to get information into a form that is legibile for our readers, in the next 5-10 years that will no longer be an issue (it’s already not an issue for some people publishing from a CMS system, where the template is applied and any layout errors automatically dealt with by the software.
He then tackled 25-100 years and whilst at first some of his premises seemed laughable – pulling the uploading of information from the movie The Matrix for example – he quickly reminded us of the change in technology in the last 100 years.
However, one thing remains true and becomes crucial in the future. All of the sources of knowledge really on people to check and validate the information on which it is built. Those people are the technical authors of today and in 10, 25 or 100 years from now, we will be in a far more powerful position than we are today. Bear that in mind the next time you ask for a raise!
All in all a fascinating presentation which I’m not doing justice. If you ever get the chance to see Bernard speak, do so. You can always tell when people are passionate about something, and he also has the knowledge to back that up.
My final thoughts
Sitting, as I am, on the train on the way home, it’s easy to pontificate about the things I’ve learned. Everyone returns to work after such an event, with a little extra enthusiasm and grand plans for change. However this time I do genuinely feel that there are things I will take from this conference that I WILL put into action, some of them require little extra work but can have huge benefits, others will need more contemplation but are equally valid.
The conference was very slick and well organised, credit to Tanya, Sally and all the other guys and gals from ITR, they certainly made it a very relaxing experience for me, very much appreciated as it was my first time as a speaker.
If you are a team lead, a manager, or have any sort of big picture thinking about Technical Communications then I highly recommend you head along to TICAD next year, you’ll find something of interest without doubt.
Hopefully I’ll see you there.