Tag: Technical Communication

TCWorld/Tekom and STC TC Summit: Two Realities

Since attending the TCWorld/Tekom conference for the first time last October, I’ve been thinking about how it both resembles and doesn’t resemble the STC Technical Communications Summit, an event that I have attended several times.

I had heard a lot of different opinions about this, and find that my own perception of this first dive into the Tekom world is a bit different from many of the comments I’ve heard. Here are a few of my observations, in no particular order, comparing the two events.

Basic Statistics


Number of days:

  • TCWorld/Tekom: 3
  • STC Summit: 4

Cost (member std rates):

  • TCWorld/Tekom: 650€
  • STC Summit: $1 025

Social Events included:

  • TCWorld/Tekom: Refreshment breaks, lunch every day
  • STC Summit: Refreshment breaks, 2 receptions, 1 lunch

Number of sessions:

  • TCWorld/Tekom: English – 62 sessions, 24 workshops German- 82 sessions, 25 workshops
  • STC Summit: 80 sessions, workshops extra

Post event access:

  • TCWorld/Tekom: Some presentation slides available for download
  • STC Summit: Summit@aClick access to full recordings of most sessions

Both conferences include trade fairs (Tekom’s is many times bigger than STC’s), and vendor showcases. Tekom also includes technology sessions that don’t seem to have a direct equivalent at the STC Summit, though some of these themes are treated in STC regular sessions.

Tekom offers a discounted rate to members of TC Europe member organisations. STC members do not receive a discount. STC, to my knowledge, has no discount programme for members of sister organisations anywhere.

Tekom’s trade fair does not include the innovation of the consultant’s corner, the space reserved for small consultancies that has been quite successful at recent STC Summits.

Content

As Kai Weber has pointed out in his overview of Tekom, it really is two parallel events: one in English, one in German. I have the impression (not totally backed up by observation) that more of the German sessions were oriented to practitioners, and more of the English sessions were oriented towards managers or consultants.

Like the STC Summit, presentations are organised in parallel tracks, and you can follow a single track or skip from one to another, as your needs and interest direct you.

Sarah O’Keefe, who speaks fluent German, said that she preferred to attend more of the German sessions. Her reasoning is that she already knows most of the English presenters, and the German presentations offer a different perspective on the themes that occupy our attention. My German is very rusty, and what remains in my head is just enough for me to feel frustrated when I try to decipher a spoken presentation. I must refresh my German before attending another Tekom event, because I would have very much liked to experience what Sarah was talking about.

Scott Abel organized a content strategy day at TCWorld that I took part in, that was the highlight of the conference for me. As I understand it, this was a new initiative for Tekom, not unlike the effort at the Dallas STC Summit. I would have liked to see a more dynamic followup at the Sacramento STC summit, as I have indicated elsewhere.

A major component of the TCWorld/Tekom event is localisation, and GALA is a partner in the event. The result is that if localisation is not at the centre of your concerns, it will seem that a huge part of the event does not concern you. A very high percentage of exhibitors at the trade fair were also vendors of localisation services, software, etc.

On the other hand, TCWorld/Tekom features a separate “Associations World,” a sort of trade fair for not for profits, for which STC has no equivalent. Exhibitors this year included other technical communication organisations such as ISTC (UK) and organisations from India, Japan, Poland, etc. It’s interesting to note that Tekom, a for-profit organisation, hosts associations, and STC, a not-for-profit, charitable organisation, doesn’t really have an equivalent.

Bottom Line

Both TCWorld/Tekom and STC Summits are great events. They have different characters, based in part on cultural differences, and also on the different business models and size of the two organisations. I am pleased to have been able to attend, and present at, both.

Never Had So Much Fun Doing Tech Comm!

It’s been a great few weeks of incredible webinars, conferences and networking, and I’m really glad to have been at the centre of some of this action, sorry I missed some other great events.

I’m especially pleased that many folks have been glad to hear what i’ve had to present, and are saying it in public. So many thanks, merci, gracies, gracias, obrigado, danke schön, etc.

The Infodesign site picked up my review of the EuroIA Summit.

I had lots of fun doing a webcast for Sarah O’Keefe and Scriptorium Publishing Services, and you’ll find a nice overview of it in Kai Weber’s blog .

Kai also did a nice write up of the content strategy day at this year’s TCWorld conference led by Scott Abel.

Die Redakteuse had some interesting takeaways from the day, even if she didn’t feel totally comfortable with the subject.

My presentation there was based on the earlier webinar, and it’s also on line.

Last, and certainly not least, is the fun of getting into the spotlight.

Recently two interviews have appeared that I can’t help crowing about a little:

Gwendolynne Barr wrote an article about technical communication in France and the STC France chapter, based in part on one of these. You can can read it in STC Berkely’s newsletter, Ragged Left

There’s also a fun interview of me in the Firehead blog, for which I thank Firehead and the folks who worked to make it so.

WHEW! What’s next? A presentation on transformation, multiple identities, and virtuality for the Consciousness Reframed conference in Lisbon, later this month.

See you there?

Software as an Information Rich Environment

Over here, in Europe, the most famous English sentence is, “My tailor is rich.”  All the old textbooks to learn English started with that sentence, and everyone knows it. For some, it evokes groans as they remember the hell of trying to understand when to pronounce l-e-a-d as “led” and when to pronounce it as “leed.”

Today, I begin with, “My software is rich.” Rich in information, that is. Rich in content. What do I mean by this?  I mean that software is quickly transforming from a tool that helps you act on content (the big three: word processors, databases and spreadsheets do just that), to a vector of information that actually informs you. It is irrelevant whether the software fetches information from somewhere out on the web or in a cloud, or actually contains its own database, or invents the information. Software now speaks to us, and sometimes in volumes.

Software today is doing medical diagnosis, it’s showing us how the climate is evolving, it’s even evaluating how well we pronounce “My tailor is rich” and suggesting ways for us to improve our accents. It exists on our desktop machines, on servers, in the cloud or the web, and we don’t really care where it is, we interact seamlessly with it wherever it is to be found. Bill Gates was right about that one.

What this means is that when we design software, we have to take all that content into account. Someone has to manage its life cycle, change out obsolete material, guide its development and make sure it is accurate, coherent, up-to-date, and understandable.

Content in software is no different from content on a web site or anywhere else. Content people need to be involved when software is initially conceived to ensure that this content is integrated seamlessly with the interface, with user guidance, with external (web or cloud based) content sources, etc.

Content strategists and designers therefore need to be involved from day one when software is designed. They need to be part of the design team, and actively involved, since they are working on one of the program’s most important subsystems: the information subsystem.

This also implies having a content strategy in the first place, one that is agreed from top management on down. This strategy needs to include all the different facets of content that the software interacts with, including, eventually, customer support web sites. You should be presenting a unified face to your public, using consistent terminology, information presentation formats, look and feel, etc.

If we don’t do this, our software’s content will be threadbare.

My sister didn’t go to the STC Technical Communication Summit. I did. Here’s how it happened.

It’s been a long time since I posted here. Despite the conventional wisdom about blogging, I only post when I really have something to say.  I’ve been needing to think about this one for a while, and my thoughts are still developing – hence the long hiatus. 

I had a great time at the STC Technical Communications Summit. I’d better have, it cost me nearly 5000 € to attend it, between air fares, hotel, meals, registration, extras etc. There was lots of good energy and good vibes at the society level, but I’m not going to talk about that here, that’s for other forums.

What I want to do is reflect on the summit (and, indirectly, its value proposition) from the point of view of a simple attendee, which, after the first Leadership Day, I was. I was not presenting in any of the non-leadership sessions, so I just attended the sessions that attracted my interest, based on their catalog descriptions.

I’d have to say, as an overall evaluation, that I was neither disappointed, nor overly excited by anything I saw or heard. Unlike last year’s dynamic conference in Dallas, the sessions this year all seemed good, workman-like presentations, well-oiled, well-rehearsed, useful, but uninspiring. At least for me.

What I was looking for and didn’t find was the bubbling excitement of what I think of as the new, interdisciplinary nature of our profession. Last year, in the wake of the European STC groups’ successful Content Strategy Forum ’10, there was an effervescence around the Content Strategy and Usability sessions. This year, both were present, but muted. This year, everyone seemed to be getting “back to basics,” and basics seems to mean docs of one sort or the other.

My sister, an STC member, does very similar work to what I do, but in a different context. I do it for software development, she does it for a web full of scientific content, aimed at a general audience. We were looking for an excuse to get together in sunny California, and the Summit seemed like a good bet, but in the end, she didn’t make it.

Why?  “I don’t write docs,” she said, “there’s not much there for me.”

“Oh, there’s lot’s of content strategy and other stuff you’ll be interested in,” I said.

“Where?” she said.

And indeed, it was hard to find. In fact, the sessions that didn’t deal directly with some sort of subject specifically oriented towards user guidance were few and far between. With all the emphasis on clouds, web content, crowd sourcing, and the rest, this summit seemed to be very firmly anchored in a closed little world of manuals and their extensions.

I firmly believe that the future of technical communication is much more expansive than user guidance (though this will remain important). People who do web content, people who fill information-rich software with content, people who bridge the worlds of science and technology, people who engage the social, political and cultural implications of technology, all need the same kinds of tools, the same kinds of epistemological constructs, the same approaches to designing content and maintaining its life cycle intelligently.

An international technical communications meeting that ignores this, risks losing its relevance, no matter how upbeat, positive, and energetic it seems at the moment of its unfolding.

This year’s STC summit was a good tech docs meeting, and as such it was valuable and interesting. However, as an indicator of where our profession is going / needs to go, it could have done better. As an umbrella for the broad spectrum of practitioners of technical communication, it failed altogether – and seemed very parochial, at least to this participant. Since I am both active in STC leadership and concerned for the society’s future, I attended practically by reflex. If I were not involved (and partially funded by my chapter – thanks), I’m not sure I would have found it worth spending 5000 € just to network with people and attend some decent sessions. For that cost, I’d want the fire, the glory, the inspiration.

It’s been said that this is the best time ever to be a technical communicator, and I agree. I would like to see us break out of our own self-imposed ghettos, and provide that forward-looking, multidisciplinary, global umbrella that will lead us forward into this very exciting century.

Oral Tech Comm

This, too, is technical communication, and it enters perfectly into the “humanist nerd” camp. This TED talk has made a few rounds, but is worth viewing, or reviewing.

Jill Bolte Taylor is a brain researcher who got an insight into her own field through her own stroke.  While this kind of occurrence is dramatic, it is not in itself that exceptional. Many bright people who are researchers have had insights into their own research through a personal accident – the most well-known probably being Sir Isaac Newton’s famous apple.

What makes this one special is the combination of the following:

  • The clarity of the explanation – the technical content.
  • The personal point of view – she describes each of her senses shutting down, one by one, from a first-person point of view that has rarely been possible.
  • The emotion that suffuses the presentation. She manages to communicate an intense personal experience with all its sensations, and at the same time be clear about the scientific part, and for the most part (perhaps not so much at the very end), she manages to keep both clarity and a certain kind of precision in her content, and to convey the human experience.

I’ve noticed some problems using the embedded player, so in case, here’s the URL: http://www.ted.com/talks/lang/eng/jill_bolte_taylor_s_powerful_stroke_of_insight.html

Lessons Learned:

We technical communicators have come from what used to be called “technical writing.”  We forget, sometimes, that the written word is just one means of communication. We also communicate orally (presentations, webinars, etc. – see my previous post about my experience delivering a webinar for the first time, for example).

The quality of the technical part of the communication – and its ability to stay in the memory of our audience – can often be a function of the human impact (humanistic impact) that it carries.

While this example is probably at the extremes of such a communication, and while some might even criticize the excess of emotion and loss of objectivity, particularly near the end of the talk, it remains a vivid illustration of just how powerful a technical communication can be.

Minimalism and Dogma

Let’s talk about minimalism for a minute.

A recent emailing on the subject from JoAnn Hackos emphasized the need that

“..users get only the information they need… And, the more languages we translate means that we cannot afford to add “nice to know” extras that fail to help the users succeed in reaching their goals. Their critical goal — getting their tasks done as quickly and efficiently as possible.”

I’d guess very few of us would argue with this position. At the same time, I’m not sure we’d all agree on what constitutes “nice to know extras that fail to help the users succeed in reaching their goals.”

If we define extras as “any non procedural information,” for example, we come into conflict with another important trend, the need to include decision support in on line help. Getting tasks done quickly and efficiently might mean, in some circumstances, having the answer to “why would I want to do this?”

Let’s be clear – most of the time, these days, we’re talking about software, and thus, online help. If you’re doing paper documentation, or even electronic, but related to electro-mechanical operations, or chemical processes, or manufacturing operations, you might have a different view of what constitutes essential information, even if you buy into minimalism as a principle.

The answer to “why would I want to do this?” or other decision oriented questions needs to be clear, concise, and limited to the immediate need. In most cases, probably not more than a sentence or two.

It means that those of us with an editorial function have a particularly onerous task. If we’re to practice minimalism with intelligence, and really provide service to our users, we need to avoid the dogmatic approach of ideas such as, “if it’s not procedural, cut it out.”  On the other hand, if we favour too much conceptual information, we’re not minimalist any more.

How much is enough?  How much is too much?

I’d like to take a stab at a simple guideline: ask yourself, “if I didn’t know anything about this software (or whatever it is), would I know when and why I need to do this?”

If the answer is “yes,” see if there’s anything to strip away, and ask the question again. Keep at it, until the answer is “no.” Then put back the smallest number of bits that make it “yes” again.

As you might imagine, this can’t be done by the numbers – it requires judgement, intelligence, and intuition.

What do you think?