Tech comm MOOC by STC not happening apparently

The STC’s MOOC which I announced last month is apparently not happening. It was supposed to let participants explore the field of technical communications, and I was scheduled to teach the introductory module starting 30 September.

My assumption that the MOOC is not happening is based on the facts I have at this point:

  • There has been no announcement by the STC beyond an introductory one-page article in the July/August issue of the STC’s intercom magazine.
  • There is no place to sign up for the MOOC and to get specific information.
  • There is no content in the MOOC’s staging area.

I’m really sorry that it’s not happening.

I think we’ve lost a great opportunity to let people know what a varied and vibrant profession technical communication is. That we are mainly about improving relationships with customers and users where people meet products and services – not about spelling and serial commas.

At a time when professions and job requirements develop rapidly around us, it is important to prove that technical communicators do add value and play important roles in defining and implementing content strategies and user experiences – and this MOOC would have been a great chance to do just that.

Advertisements

Join us for a tech comm intro MOOC by STC

This fall, the STC will run a free 5-week MOOC to allow everybody online to explore the field of technical communications – and I’m excited to be teaching the introductory module!

The full syllabus

The MOOC will highlight the roles and responsibilities of technical communication professionals through 5 specializations in 5 weekly modules, starting on 30 September:

  1. Introduction to technical communication, by myself
  2. Content development and delivery, by Bernard Aschwanden
  3. Content strategy and lifecycle, by Mollye Barrett
  4. Instructional design, by Dana West and Phylise Banner
  5. Usability and user assistance, by Ray Gallon and David Farbey

The introductory module

My module in the first week will serve as a general introduction to the field of technical communication.

What will you learn?

After the module, you should be able to

  • Define purpose, benefits and tasks of technical communication
  • Argue the value of technical communication for companies and clients
  • Describe the daily job and career of a technical communicator
  • Identify the elements of effective technical communication
  • Describe and develop basic core skills of a technical communicator

What do you do?

Your week will start with some assigned texts and videos to introduce the topics.

You will see how all the pieces fit together in an online lesson on Wednesday afternoon (US time). The outline will be the same as for the readings; it looks something like this:

  1. What is technical communication? – Definitions and trends
    • A changing definition, from technical writing to business problem-solving
    • Recent trends (mobile and embedded help, social media and user-generated content)
  2. Why have technical communication? – Benefits and business cases
    • How technical communication benefits users and companies and products
    • What only technical communication can do (USPs)
  3. Who is a technical communicator? – Tasks and career
    • A day in the life
    • Personality and aptitudes
    • A versatile career path
  4. How does a technical communicator work? – Skills and expertise
    • Know your audience through audience analysis and personas
    • Learn from subject-matter experts by research and collaboration
    • Write task-oriented topics using task analysis and modular topic types
    • Edit modular documentation for content and language

You will have a chance to try your hand on technical communications in a couple of learning activities (a/k/a assignments) around creating and editing documentation.

Oof, that’s a lot, no?

Well, yes and no. Yes, it is a wide area, but the purpose is to give you a taste of our versatile profession! I’ll start with the larger picture to illustrate the value of tech comm and how it can be cool and profitable, before diving into a few core skills in depth. The four later modules can afford to be a little more focused.

More information

More information will be available shortly on the web sites of STC which is sponsoring this MOOC and on CourseSites which is furnishing the platform for it.

In the meantime, check out Mollye Barrett talking about the MOOC and her module in a 1:30 video.

What do you think?

Would this be interesting to participate in? What other topics would you expect to see covered in the intro module? Let me know in the comments, and I’ll see if I can address your opints, either in the comments or in the MOOC module itself!

Obvious structure in tech comm benefits all users

Informational text that exposes its “structural information, such as hierarchical relations” gets high reading comprehension scores, whether readers have prior subject knowledge or not. This is the result of a study reported in Learning Solutions Magazine by Chris Atherton. And it’s good news for technical communication because it means structured writing and topic-based authoring done well benefit novice and expert users alike.

The study

The study presented a 5,000-word article in three formats to two different groups. The three formats were:

  • A linear document of paragraphs
  • A hierarchical set of linked topics which was basically web site six levels deep
  • A mixed format which combined linear text presentation with links to related topics that didn’t expose structure or hierarchy

The two groups of audience were:

  • Novices without prior knowledge of the subject
  • Experts who had formal training in the subject

The results

It’s best to scroll down to the results graph over at the magazine website, but in case that disappears, here’s a summary of the different reading comprehension scores:

  • Novices understood the hierarchical format best, closely followed by the mixed format, with the linear format a distant third.
  • Experts understood the linear format best, closely followed by the hierarchical format, with the mixed format a distant third.

So exposing the hierarchy and structure of the text benefits novices and experts alike. If you’re writing for experts only, presenting linear text gives them a slight advantage, but “shuts out” novices.

The implications for tech comm

  • Structure authoring helps your users understand and remember. Novice and expert users alike can make sense of the information not only from the individual bits and pieces, but also from the structure how everything hangs together. For example, consider relating concepts and sub-concepts to on another. Or when instructing users to do tasks, consider giving an overview of the big picture process first. Then break down the process clearly into distinct procedures and further into individual steps. For many readers, easy access to structure also helps them to retain information better, regardless how they manage to memorize it.
  • Structured authoring helps you to create complete documentation efficiently. You can organize and maintain your information more efficiently with structure and hierarchy. Structure makes it easier to ensure that each piece of information has a distinct place, so you can avoid redundancies. Hierarchies make it clear where your concepts and procedures are complete and where you still have gaps. It’s easier to note a missing topic or sub-chapter than a missing paragraph somewhere in linear text.
  • Limited advantage of linear text. The study showed that linear text in paragraphs is most comprehensible for expert readers. But I think the advantage of this format is in general limited:
    • For novices, linear text is a distant third, so relying on “linear” requires that you have a homogenously expert audience.
    • For you as a writer, linear text possibly takes more time or effort to maintain, depending on how much text you maintain and how often you update.
    • For other writers who need to edit or update your documentation, linear text is probably harder than topics that expose the internal structure of the subject matter.

By the way: Chris Atherton and I will lead a workshop together at TCUK13 in Bristol on 24 September. So if you’re in the area and want to “Bake your own taxonomy”, consider joining us. 🙂

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:

Improve tech comm by knowing a foreign language

Knowing a second language can help your tech comm work in a couple of ways. The benefit is probably not great enough in itself to justify learning a language, but if you have or had other reasons, it’s worth to consider these side benefits.

Making decisions in a foreign language

I got to think about this when I read a story in Wired that “thinking in a second language reduced deep-seated, misleading biases”. Psychologists at the University of Chicago conducted a study (abstract, full text in PDF) that asked “Would you make the same decisions in a foreign language as you would in your native tongue?”

In a foreign language, we use the same experiences and processes to evaluate situations and estimate risks. However, “a foreign language is like a distancing mechanism. It’s almost like you’re a slightly different person,” says Boaz Keysar who led the study (Business Week). According to the study, thinking in a non-native language emphasizes the systematic, analytical reasoning process. Thinking in our native tongue, on the other hand, leaves more room for the complementary intuitive, emotional decision process: “The researchers believe a second language provides a useful cognitive distance from automatic processes, promoting analytical thought and reducing unthinking, emotional reaction” (Wired). (Whether an analytical process yields “better” decisions is an entirely different story…)

Making tech comm better with a foreign language

For the past 12 years that I’ve worked full-time as a tech writer, I’ve written almost exclusively in my second language English, though I did occasionally translate my English writing into my native German. The study’s conclusion that a second language provides a “useful cognitive distance … promoting analytical thought” explains what I’ve experienced in my work in either language, beyond the limits of actual study:

1. A second chance to learn how language works. Many writers I’ve talked to have a solid grasp of their native tongue, but cannot necessarily explain the rules why something is right or wrong. When you learn a second language consciously, you also learn about grammar (again), its powers and limitations. And you can understand how something what works in one language can be similar or even different in another. For me, writing in English certainly made me a more conscientious “grammarian” in either language.

2. Mirroring the “distance” of users. In my experience, the distance that a second language brings is basically pragmatic incompetence: In a foreign language, I’m not as fully aware of the social context, of how time, space and inferred intent contribute to any communication act. I may trip over an idiom I don’t understand, or I may fail to see the irony of a statement and take it at face value.

In tech comm, this linguistic challenge is actually a benefit, because many of my readers share in that distancing experience. My readers may read my documentation in their second language. Or they might use the product in a context and for a purpose that is more or less different than intended and documented. This is why localization is harder than just translation. Internationalization can even become an accessibility issue, when a product no longer works properly in a certain context. So facing similar pragmatic uncertainties makes me a better advocate of the users I write for.

Your turn

If you know a second language, do you find it helps your writing? Do you have other reasons or benefits beside the ones I listed?

A. Ames & A. Riley on info experience models at STC12

Andrea Ames and Alyson Riley, both from IBM, presented a dense whirlwind tour on “Modelling Information Experiences” that combine four related models into a heavy-duty, corporate information architecture (IA).

While the proceedings don’t include a paper on this session, Andrea posted the slides, and the presenters published a related article (login required) “Helping Us Think: The Role of Abstract, Conceptual Models in Strategic Information Architecture” in the January 2012 issue of the STC’s intercom journal.

The session proceeded in six parts. First, Alison explained IA models in general and how they work. Then Andrea described each of the four model types that make up an IA specifically.

IA models as science and art

Information architecture relates to science as its models draw on insights and theories of cognition. And its models relate to art as they aim to create a meaningful experience. Both aspects are important. Only if IA models manage to blend science and art can they touch the head and the heart.

The session focuses on IA models instead of theories (which are too vague and abstract) or implementations (which are too specific and limited). Thanks to the in-between position of IA models, we can use them to

  • Ask the right questions to arrive at a suitable, feasible IA
  • Tolerate the ambiguities of “real life”

Models present descriptive patterns, not prescriptive rules. They don’t say how stuff must be, but how it can be represented. They differ from real life, but real life is still recognizable in them.

That means you cannot simply implement a model on autopilot and get it right. Instead, you have to

  • Think how to implement the model
  • Vary the model for your users’ benefit
  • Listen to the right knowledgeable people when implementing

Models help you think

To arrive at your concrete IA, you take the model’s abstract patterns and apply your project-specific details to them, the who, what, where and when.

This task is less mechanical and less copy-and-paste than it sounds. It’s not so much a question of following rules and recipes, but of making abstract patterns come to life in a coherent, flexible whole. (If you’ve ever tried to create meaningful concept or task topics by following an information model, you know it’s more than just filling in a DITA template. You need to use your own judgment about what goes where to achieve and maximize user benefit.)

Since there are four related models, you need to think carefully how each of these models should benefit your users. And the models help you think, they scale and adapt to:

  • How your business and its information requirements develop over time, how they grow and expand in desired directions
  • How your customers find, understand and apply the information they need

The four IA model types

The IA model that Andrea then explained consists of four related model types:

use model (content model + access model = information model)

Each of these model types needs to be developed and validated separately.

The use model defines how users interact with information. It describes standard scenarios for optimal user experience within the product or system context. It outlines what information users need and why and how they use it. It includes use scenarios for the entire product life cycle and user personas that outline different types of users. Fortunately for us technical communicators, Andrea pointed out, describing all this is part of our core skill set.

The content model defines how information is structured effectively. This could be DITA (in the case of the company I work for, this is what we call our DITA-derived “information model”). It includes the granular information units and their internal structure, for example, task topics and their standard sequence of contained information. It also describes how these granular units are combined into deliverables.

The access model defines how users access the information efficiently. It makes provided information useable, thanks to a navigation tree, a search function, a filtering function to increase the relevance of search results, an index, etc. Artefacts of this model type are wireframes, storyboards, a navigation tree and the like.

The information model defines how users get from one stage to the next. It uses the other three model types as input and fills in the gaps. It combines the content and access models which probably work fine during the installation and configuration processes, but may not yet carry a user persona from one stage to the next. As such, the information model is sort of the auxiliary topic that you sometimes need to insert between concept, task and reference topics to make a complete book out of them. At the same time, this model type is more detailed than the use model and closer to the other two types.

My takeaways

I was extremely grateful for this session and rank it among the top 3 I’ve seen at the summit – or any tech comm conference I’ve been to! Yes, it was fairly abstract and ran too long – my only complaint is that it left only 2 minutes for discussion at the end.

As abstract as much of the session was, it actually solved a couple of problems I couldn’t quite put into words. After designing and teaching our company’s DITA-derived information model (which is a “content model” by this session’s names), I thought our model was applicable and useful, but it had two problems:

  • Our model lacked context. – Now I know that’s because we haven’t mapped out our use model in the same detail and failed to connect the two.
  • Our model was baked into a template for less experienced writers to fill in – with varying results. – Now I know that’s because the models are not supposed to provide templates, but require writers to use their own judgment and keep in mind the big picture to deliver effective information.

Another lesson I learned is that many structured information paradigms seem to include a less rigid element that sweeps up much of the miscellaneous remnants. In DITA, there’s the general topic which is used for “under-defined” auxiliary topics to give structure, especially to print deliverables such as manuals. In this IA model, there’s the information model which fills the gaps and ensures a more seamless user experience than the other three models can ensure.

– For an alternative take, see Sarah Maddox’ post about this session.

What I learned from my pattern recognition talk at STC12

My session on pattern recognition for technical communicators was a very rewarding experience which taught me a lot. I thank Paul Mueller, Conference Manager, and Alyssa Fox, Program Committee Chair, for inviting me to speak, even though this was my first summit. Their friendly, indefatigable support set the tone for a high-energy, well-run conference.

If you want to revisit the session, here are the slides and the article from the proceedings. (If you haven’t attended the session, the article will probably be more helpful, for reasons explained below.)

Here’s a look behind the scenes of my talk and what I learned:

Two different roles

Attending a conference is not the same as speaking at one. Well, duh…

But what I mean is this: I took care to be an observant attendee before my own session, so I could gauge expectations and behaviors of attendees. Bluntly put: As attendee, I want my money’s worth. As speaker, I need to give my audience their money’s worth. Observing and knowing the first helped me achieve the second – or so I hope.

When I was still in academia, I was often put off by conference presenters whose ignorance of the audience’s interests and demands could be quite arrogant – and usually didn’t help the conference as a whole, either. So I wanted to avoid that.

Plus, one of the mantras of technical communicators is: “Know your audience!” How could I afford to ignore it at a tech comm conference?

“Unusual” works

I was unsure about my topic, because it was a bit unusual and off-the-wall: Tying the psychology of perception to technical communications – only to confirm what we do anyway, such as topic-based authoring and parallelism?

Me presenting on pattern recognition at STC12

(Photo courtesy of Jamie Gillenwater)

On the other hand, I know from attending previous conferences, how much I enjoyed and benefitted from such sessions. A-ha moments are fun and enlightening, they work in TV science programs, so maybe they’ll work at a conference as well…

During the session, I was too busy to count heads, but I’m guessing I might have had an audience of 70 people maybe. There were other sessions to choose from. Or breakfast, since I was in the 8:30 slot. So I decided early on to get over my worries and trust in the general curiosity of tech writers. 🙂

Rehearsing pays

So practicing helps… Again: Well, duh…

Specifically, it allowed me to move beyond bullet points. I’ve seen many a session (less so at the summit) where presenters mainly read their slides. To me, those are usually not the best presentations. I don’t need great showmanship, but reading the slides seems as if the speaker serves the slides rather than vice versa.

I’ve tried to make at least the a-ha moments less reliant on words and bullet lists and more like an illustrated story. And I’ve found that decent images will remind me of the story just fine. (The last section about actually applying pattern recognition in tech comm has more bullet lists, so people could take notes.)

In addition, I found that rehearsing also helps me to “know time” (a pet obsession of mine; I even have a blog post about it). I’ve seen excellent presentations, but it peeves me a bit if they take up 58 of 60 minutes. I also learn by asking questions and by engaging with the speaker or others in the audience. And to me, it seems a bit careless to mar an excellent session by running overtime.

Budget your energy

I am really glad (and almost a little proud) that we’ve had such a lively, engaging discussion after my presentation. People suggested additional sources, propped up some of my arguments and ran with others, bringing up evolution, Edward Tufte’s information graphics and – privately afterwards – even Immanuel Kant!

My one regret is that by that time I was a bit exhausted and didn’t always do justice when repeating the question or comment for everybody in the room and for the recording. Not sure how I can achieve it, but I want to save not only time, but also energy to facilitate the discussion afterwards.

But all in all I think the session went well, I’ve really enjoyed the experience and am glad to contibute to our curious, friendly and supportive tech comm community!