Pattern recognition for tech comm at #TCUK11

Our presentation “Pattern recognition for technical communicators” by Chris Atherton and myself at TCUK11 was well-received and brought “Ah-ha moments a-go-go” according to one tweet. Read how it went or download the slides in PDF by clicking on the title image.

Link to PDF slides: Pattern recognition for tech comm

How the session came about

The session (see the abstract) got its start when I met Chris at last year’s TCUK where she spoke about “Everything you always wanted to know about psychology (and how it relates to technical communication) … but were afraid to ask”. She didn’t really talk about pattern recognition, and I didn’t really know what it was, but I had a notion this might be good for another presentation. I contacted Chris, she thought it was a great idea, and so over the year, we came up with this baby.

"Only Chris Atherton can have a picture of a dog's bum in her #TCUK11 presentation and make it relevant." - @robocolumn

And we brought the baby to TCUK11. 24 hours before our talk, Chris and I attended Karen Mardahl‘s and CJ Walker‘s fireside chat-like session “Content strategy year 1: a tale from the trenches“.  Their dialogue format really appealed to us, we decided to replace some of the scripted moments with more informal dialogue – and the baby had two godmothers.

Then we attended Andrew Lightheart‘s “How to be a riveting speaker” (more on that in my previous post) after which we couldn’t very well present something with reams of text-ridden slides. So we threw out most of the text slides – and the baby had a godfather.

By now, it was still the same content, but quite a different presentation. After all the tweaking, we didn’t have a measurement whether it filled the allotted 40 minutes or was longer…

How it went, a view from the lectern

Chris and I met in the auditorium, set up, added some last minute changes. Checking the watch: 2 minutes to go. Looking up: We had filled the place, a good 100 people were keen to recognise a pattern or two…

Karen introduced us, and off we went. I had decided to be extranervous because the session was being filmed and preserved (is my collar right?) – but I completely forgot!

"By creating and following patterns you help your reader understand..." - @dfarb

Through all the changes and tweaks, we had come to know the material so intimately that it seemed to flow quite smoothly. The omitted text slides were actually a relief, because we could focus on the story and the examples, without having to vindicate each and every sentence. We had picked out stories and examples which were easier to tell than some of the concepts we had thrown out.

Karen’s warning of 15 minutes left came around the time I had roughly estimated. We had to leave out the communal brainstorm of more examples and applications, but everything else fit in.

The feedback after the session was very kind and encouraging. I’m glad and proud if we presented something meaningful to our peers.

The slides

The slides are not the actual presentation we showed, but a variation with more text, so they work a little better as a self-contained slide show without the soundtrack.  Click on the image above to display or download. The video by the TCUK crew is forthcoming.

Chris and I sincerely thank the TCUK organisers for inviting us, our peer presenters for valuable inspiration, all attendees for helpful feedback, intentional or not, before and after the session!

Feel free to leave a comment, whether you were there or are merely curious what it’s all about!

Join us for pattern recognition at TCUK

Dr. Chris Atherton and I will be premiering our exciting interdisciplinary presentation on “Pattern recognition for technical communicators” at the TCUK conference near Oxford next week. You can find the session abstract on the conference web site or review my previous post.

Logo of the Technical Communication UK conference

Join us for a fun whirlwind tour through human perception and find out how you can apply pattern recognition:

  • Make sense of unknown subject matter
  • Overcome tech writer’s block and start writing
  • Chunk topics and find reuse opportunities
  • Help your readers to
    • Orient themselves in your documentation
    • Grasp individual topics quickly
    • Get the most out of navigation aids

Extra bonus! You’ll learn about apophenia, a concept that gives you something to talk about at cocktail parties and ranks high on most international geek scales… 😉

No previous experience required! If you’re at the conference and can get yourself into the right room on Thursday, September 22, at 10 o’clock, you have all the tools on-board that you need!

Next week I’ll be blogging from the conference, so watch this space…

All aboard! Onwards to structured authoring!

Our team of technical writers is embarking on a journey towards structured authoring. With 10 writers, we’ll move from an unstructured Word to PDF/CHM environment to a structured Flare to WebHelp/PDF environment. Or I should say “semi-structured”: We do have an information model based on DITA, but we won’t actually be able to enforce it with Flare (which we knew before we chose the tool).

It’ll be an interesting cruise, to be sure! Four writers already apply topic-based authoring rather than the previous free-form documentation guided mainly by common sense. The others have had training, but no real opportunity to write topics continuously. We have drafted tighter new processes to draft, write, review and edit topics to replace the previous loose processes of writing and reviewing, but they are not in place yet.

And then there’s the new tool, of course. Only one of us has worked with Flare before. Many of us are excited about getting Flare. Some really like it – what we’ve seen in several demos so far. Others just really loathe the current writing environment.

“Regarding the pain of others”

So as we’re about embark, I’ve been looking out for others who’ve taken the trip before. Scriptorium’s State of Structure webcast has been very helpful: Its results of a survey among 200 tech communicators helps to position us in relation to others who are currently implementing structured authoring or considering it. It also collects some mistakes respondents have gone through. I’ll just be quoting a few select points, but the whole webcast by Sarah O’Keefe is totally worth checking out, so thanks to Scriptorium for making this webcast available!

Reasons

The top reasons why survey respondents (consider to) move to structured authoring made us nod emphatically: Reuse, consistency and cost savings are also at the top of our wish list of achievements. Looking ahead, it’s promising that the majority of respondents achieve these goals.

We’ll also take other goals that respondents achieved, whether it’s to automate processes or to reduce content (oh, yes, please, we’re not even exactly sure how much redundant, almost identical content we have). So far we’re confident, we’re not only doing the right thing, but doing it for the right reasons, too!

Efforts

Savings have their own price, of course. Sarah’s survey confirms several cost points we’ve already identified in the project.

  • Converting legacy content is a biggie for us, simply because we currently have a lot of stuff.
  • Redefining output layout will take time, but will be worth it given what Flare is capable of doing with CSS in both web and print outputs.
  • Integrating a new system with its writing and publishing processes into our product and workflow systems will also take some time.

Mistakes

Mistakes have been made by others before us, and we’ll have plenty of chances to make our very own mistakes. If we’re lucky, we can avoid repeating the mistakes of others:

  • Planning and project management cause problems, maybe because most companies lack the experience of major documentation overhaul projects. Sarah specifically mentioned the lack of understanding of the project scope and of the need for testing. So we’ll look through our project plan again and ensure that the estimates are plausible.
  • Converting legacy contents can also get you into trouble, especially when you convert something that’s less than structured. It doesn’t help if you reserve too little time to do it or get inexperienced people to do, whether it’s off-shore labor or student helpers. That’s sound advice: GIGO (“garbage in, garbage out”) can certainly endanger the expected benefits. A new tool can help us be more efficient, but we still have to learn and apply structured writing in topics. So this confirms one of my two tech comm dogmas: Don’t get a new tool to fix your processes!

Setting out

What do you think? Is our crew well-equipped, given a tried and proven method, well-defined processes, a new tool and the words of warnings above? If you have additional advice, please leave a message.

Pattern recognition for tech comm

Chris Atherton and I will present a session on pattern recognition for technical communicators at this year’s Technical Communication UK conference near Oxford. The conference takes place from September 20 through 22.

Logo of the Technical Communication UK conference

Adding up Chris’s interest in evidence-based information design and her background in researching and teaching human cognition with my experience in designing and modelling technical communications, we’re sure it’ll be an interesting, thought-provoking session. Here’s the abstract:

Pattern recognition is one of the essential mental strategies for acquiring and disseminating knowledge, though most of us are not aware of it. This session presents some ideas and findings about human pattern recognition. It aims to help technical communicators think about how they can employ pattern recognition processes to develop their own documentation and user assistance.

The presentation combines the wit and wisdom of a cognitive psychologist and a technical writer who draw on examples and evidence in their respective fields to show:

  • What pattern recognition is and how it works
  • Which mental strategies we employ without knowing it
  • How technical communicators can employ those strategies
  • Making sense of new subject matter
  • Starting to build new documentation
  • Designing and structuring documentation
  • Supporting users efficiently

New conference trend: Collaborative sessions

It’s interesting to see collaborations appear at the conference that create a mushroom-like network of sessions:

  • Chris and I talk about pattern recognition.
  • Chris leads a session with Mike Smith and Karen Mardahl on statistics (without maths).
  • Karen joins forces with CJ Walker to tell about content strategy from the trenches.

Do you think joint sessions are a good idea or not? Have you had bad experiences that we should avoid? Feel free to leave a comment.

When tech comm does other teams’ work

Should documentation be expected to do the job of other teams and departments to make up for their shortcomings?

That was the essential question in an interesting conversation I once had with a fellow tech writer. It’s basically a twist on the general idea that you often have to pick two of the three: High quality, speed, low cost.

The writer said she had changed her way of writing user manuals to include fewer screenshots, because some of them were not essential to the described task, and they’re difficult to translate and update.

Less than efficient reuse

Her manager didn’t exactly appreciate her efforts to create similarly useful documentation more efficiently, but objected to the new manual. He asked her to use more screenshots as before, arguing they were necessary for three additional purposes of the manual:

  • Sell the product – though dedicated sales materials are also available.
  • Double as self-study training material – though training is also available.
  • Make up for poor usability where the software isn’t so intuitive in some places.

She is totally capable of creating documentation that can also be used for these purposes. (Apparently, the company didn’t have a content strategy which easily allows to share contents between sales, training and documentation.) But it’s just difficult to do it all when she faces pressure to limit cost and throughput time at the same time.

Possible reactions

During the conversation, my position was that her company can’t reasonably expect her to make documentation more efficient while she continues to make up for other shortcomings. (This ties in with the “Two words every (lone) writer should know“, which are “Later” and “No”.)

Then I thought that maybe her manager doesn’t actually know which tasks an efficient technical writer does best (if you can even generalize that) and what to expect from the sales, marketing and training teams. In this case, it might even be an opportunity to clean up processes beyond just documentation (though this easily gets presumptuous).

Your turn

What do you think? Have you been expected to do things that got in the way of your efficiency and that were really the tasks of other teams? How can we writers deal with that? Any ideas? Please leave a comment.

Organize bookmarks in folders by task

Make the most of bookmarks by sorting them by tasks.

That’s the lesson I learned after months of trudging along with a looong list of bookmarks. I would add links for later reading, then randomly pick pages to read or otherwise process, and it was not working.

Around New Year’s, I cleaned up the mess, threw out dead links and pages that seemed merely vaguely interesting. The remainder went into separate folders. This has been working really well for me so far: I remember and find bookmarks faster, and I process them faster (which means reading and filing or deleting).

Organize by task, not by content

The trick for me was to create bookmark folders by tasks, not by subject matter or contents! I now have the following bookmark folders:

  • Tech Writing with pages to read and archive useful ones.
  • Blog with pages to write about in this blog.
  • [Project] with pages to work on for articles or presentations, one per project.
  • Portable Freeware with pages of software to try out.
  • Travel with pages of hotels and restaurants to visit.
  • Inspire with pages to get me unstuck from writer’s block.
  • Lookup with pages to look up grammar rules, translations, prices, streets, etc.

Why does this work?

It works for two reasons:

  1. It’s basically following our own professional advice: Create documentation task-based, not based on the stuff you organize, whether it’s a user interface or random web pages.
  2. It’s inspired by GTD (Getting Things Done): Get productive by ensuring you can simply crank widgets as a tech writer.

Bonus tip

Sync your bookmarks across all your machines for even better order and productivity. I use xmarks for Firefox to ensure all my bookmarks are always up to date, regardless of which PC I use. When I’m on someone else’s machine, I can still look up my bookmarks online.

Your turn

How do you organize your tech comm bookmarks? Do folders work? Is there a better way? Please leave a comment.