Content strategy versus wicked ambiguity (stc14)

This week I’m attending STC Summit 2014, the annual conference of the Society for Technical Communication. Where feasible, I’ll take notes from the sessions I attend, and share them on this blog. All credit goes to the presenters, and any mistakes are mine.

I’ve just arrived in Phoenix, Arizona, this year’s host city. It’s around 40 degrees Centigrade, or 100 Fahrenheit. Phew! But I’m sure the temperature will be just one of the hot topics at this conference. 😉

The keynote presentation was given by Jonathon Colman, content strategist at Facebook.

Wicked Ambiguity, by Jonathan Colman

Jonathon started with a big smile and the sage saying, “Don’t worry, everything’s going to be fine.” It’s the sort of thing we say to children. But we live in a world of uncertainty. That’s what this talk is about.

Jonathon told us stories from Stephen King (“that shape under the sheet could be anything – anything at all”) to Claude Shannon, the father of information theory (a diagram of communication from the 1940s that is still relevant today).

He then ran through the diversity of roles technical writers fill: writer, designer, information architect, content strategist, and more. Despite our diversity, we stand united against ambiguity. We make the complex simple.

But what if we were writing a message, without knowing who would try to interpret it? Jonathan went over two scenarios that present this problem. It’s one of those unsolvable problems – one which needs a different type of solution: a “wicked problem”.

Some examples of wicked problems:

• Jonathon showed us the well-known map of the Cholera outbreak in 19th century London, showing the highest incidences of cholera in relation to the location of the water sources. This is how John Snow saved London and invented the field of epidemiology.
• Another map showed the incidence of Ebola virus in West Africa.
• The war on drugs is another example of a wicked problem, where the interdependencies resist resolution.
•  And climate change. We’re just now understanding how this effects everything, from climate to politics.

Jonathon spoke of two wicked problems in technical communication:

1) Communicating with aliens

Jonathon emphasised that this is not science fiction. He launched into a few amusing stories about scientists who’d had bright ideas to communicate with whoever is out there in the universe, such as drawing triangles in the Siberian tundra or burning messages onto Mars.

He then showed the engraved diagram and symbols designed by Carl Sagan, that were sent out with Pioneer spacecraft. And followed up with other condensed, rich and layered messages sent into space, such as the audio and visual messages sent on the Voyager spacecraft in the 70s. Jonathan says Carl Sagan is possibly the greatest technical communicator ever.

But what will an alien civilisation make of this? Will they even be able to play it? Will they be able to interpret it? And what will they do as a result of receiving the message?

Uncertainty rules.

2) Nuclear semiotics

We have nuclear weapons and nuclear power plants. Both leave behind nuclear waste. How do we communicate the dangers of this waste to future generatios who might come across it? That’s the problem of nuclear semiotics.

Plutonium 239 has a half-life of more than 24 000 years. To be safe, it has to remain untouched for nearly 100 000 years.

Uranium 235 has a half-life of nearly 704 million years.

Looking back at our past, we note that language is a fairly new invention. Thus, communicating the danger of nuclear waste is wicked problem.

The US created the Human Interference task force, with this mission: Stop humans coming into contact with nuclear waste. Their task was to create a message capable of being interpreted for over 10 000 years.

One of the suggested solutions was to create a religious priesthood, the Atomic Priesthood. The reasoning is that religions are one of the few things that last over a long period.

Another idea was to launch a global network of satellites that would constantly communicate the location of the nuclear waste sites. Or to create some genetically modified plants that would only grow near the sites, and would contain encoded information about the composition of the waste. Plants as a medium for technical communication!

Yet another idea: Ray Cats – cats that would glow in the presence of nuclear radiation. Reasoning: Humans have a long-lasting association with cats. (After all, smiled Jonathon, we created the Internet to immortalise cats. This got a good laugh from the audience.)

Jonathon listed a few more approaches to the problem of keeping future humans away from nuclear waste.

We don’t know what the effect of these messages will be on the intended audience. They may not work.

Wicked problems are everywhere. They’re catalysts. They change us, and ignite our creativity. They make us think, they force us to solve them, and that’s how we evolve.

Ambiguity and technical communication

Jonathon finished off by returning to ambiguity and its relationship to our role as technical communicators.

Ambiguity, uncertainty, and the unknown are part of every-day life.

Some people are terrified of uncertainty, but technical communicators grapple with it routinely. We ask the hard questions, instead of passing that ambiguity onto our customers.

Technical writers communicate complex information in a way that is clear and simple. We can’t solve the wicked problems, but we can try. And that effort is what we do best.

Thanks Jonathon

This presentation was a great start to STC Summit 2014. Jonathon is an amusing, engaging speaker. He filled the room with laughter and with enthusiasm for our field of technical communication. Here’s a link to Jonathon’s presentation on SlideShare: Wicked Ambiguity: Solving the Hardest Communication Problems.

Introducing Tech Comm on a Map

I’ve been working on a personal project, and I’m delighted to say it’s ready to share with you! The idea is to help us see what’s happening around the globe, in the world of technical communication. So I’ve put tech comm titbits onto an interactive map, together with the data and functionality automatically provided by Google Maps. To see it in action, go to Tech Comm on a Map.

At the time of writing this post, Tech Comm on a Map contains information of the following types, all related to technical writing and technical communication:

• Conferences (purple circles)
• Societies (yellow circles) – includes societies and associations.
• Other (blue circles) – a grab bag to catch anything that doesn’t fit into the first two categories. This is also the default category for data items that aren’t correctly categorised.

To find the information, click one of the coloured circles on the map. You can also zoom into a particular city or address, by entering the place name or address in the search box.

Where does the data come from?

It’s all in a Google Docs spreadsheet. Up to now, I’ve collected and entered the data myself. I’ve scoured the Web for information about conferences. I’ve also added just a few societies, and a couple of ‘other’ items to prove the category exists. The spreadsheet looks like this:

Spreadsheet containing tech comm data for map

What’s the plan for adding more data and maintaining what’s there?

My plan is to invite a few people to help update the spreadsheet that holds the data.  Any data added to the spreadsheet appears on the map immediately. It’s pretty cool!

How does it work?

The tools I’ve used are the Google Maps JavaScript API, the Google Places Autocomplete widget, and Google Apps Script to extract the data from a spreadsheet in Google Sheets. The code and website are hosted on GitHub.

I’ll write another post soon, with more details about the code and the APIs.

Am I planning to add anything more to the project?

There is plenty of potential for enhancements. For example, we could add more categories to the existing three (conferences, societies, and other) to include events like technical writers’ group meetings. We could add styling to the map. And other sweetening we can think of…

A number of people have already made some exciting suggestions for v2. The project is open source, so if you have an improvement to suggest, send me a pull request. 🙂

Feedback

I’d love to know what you think of the map, and whether you’re excited about adding more events and other types of tech comm titbits! If you’d like to share your ideas, please add comments to this post.

Get ready for APIs at STC Summit 2014

STC Summit 2014 is fast approaching! The conference starts in Phoenix AZ on Saturday May 17th. I’ll be speaking on Monday afternoon, on the topic of API Technical Writing: What, Why and How. My aim is to inspire people about APIs: how much fun they are, how developers use them to build useful, fascinating, inspiring software, and how we as technical writers can help by providing the essential documentation and other assistance.

In my session, we’ll take a look at what an API is, and see two popular APIs in action: The Flickr API and the Google Maps JavaScript API. Then we’ll move on to the technical writing side of things: what an API technical writer does, and what good API documentation looks like.

Part of the discussion will be about different types of APIs: web services, JavaScript APIs, object-oriented libraries, and more. There won’t be enough time to cover this aspect in depth, so as an adjunct to the session I’ve put up a short slide deck that accompanies my recent blog post about API types. The blog post has a link to the slide deck, as well as more detailed information about API types. Check out the comments on the post too, for knowledge shared by others.

I’m greatly looking forward to all the sessions and meetups at STC14. I hope to see you there!