The Humanist Nerd Reviews oXygen 14.2

oXygen’s new release is part of the company’s policy of regularly (every three or four months) releasing “incremental” upgrades. I use quotes because Syncro Soft, the publisher of oXygen, regularly includes major new features in these free, “incremental” upgrades. This was especially the case with release 14.1 that included forms based editing of XML attributes – about which more in a moment.

Continue reading “The Humanist Nerd Reviews oXygen 14.2”

Are You Googleable?

A comment I made to one of Mark Baker’s recent posts, What is your primary media? Paper or the web? led to an interesting discussion about embedded user assistance.

In my recent webinar series on User Assistance and Cognition, I used the term Double Embeddedness to speak of embedded procedural help that has, in turn, concepts embedded in it. I also mentioned that our user assistance needs to be searchable.

In our exchange on Mark’s blog, he said,

Embedded assistance can never be comprehensive, by its nature, so there is still a role for more comprehensive information. But the place for that more comprehensive information is on the Web, where it can integrate with all the customer-produced information. People are simply going to stop looking to “the help” as an intermediate information source. They are going to start with the interface, and then go to the web.

I couldn’t agree more. Not only that, but the source of that additional material must be a true, integrated learning community, one that groups users, SME’s, developers, tech comms, marketers, and product managers in one community, sharing ideas as equal contributors (even if, eventually, some of them have decision power that others do not have).

That was one of the main points in the third webinar of the series.

If your user assistance isn’t Googleable, chances are your users are not going to find it – wherever else it happens to be.

I Keep Thinking…

…about all this communication stuff:

  • I keep thinking about how information architects don’t like to be called UX designers. “IA is so much more,” they say. The “more” they’re talking about includes content. Not Lorem Ipsum, but real content. Many IA’s think of themselves as content strategists, too. They probably are. In fact, I think IA and CS are interlocking, interdependent parts of a single, holistic process – whether done by one person or a team.
  • I keep thinking about how Map should be an element used on the publishing side of DITA, not the authoring side. Let’s rename Map to Container (that’s what it is) and then a Map could really be one: you could map a layout out on a graphic of a page or screen of your publication, and fill it with DITA elements: topics, concepts, and the newly named containers. Using these graphical elements, you could have text flows just like in old fashioned desk top publishing programs, and you could control the layout and make it pretty – removing one of the most common criticisms of working with XML.
  • I keep thinking how I really want to do it all myself. Not because I don’t like teamwork, not because I’m jealous of others’ competencies, but because I love all this stuff so much, I just want to have the fun of doing it all. Silly of me, I know.
  • I keep thinking how technical communication is a lot like playing the piano. Not just because you need to make your fingers work a keyboard in both cases, but also because, as you develop your skill and hone your craft, you become aware that you are working with subtleties that no one other than a few other specialists in your field would ever be aware of. Quality assurance people would say that this is “too much quality” – you should provide just as much as the customers ask for, and not a jot more. But we do this, every day, even though we don’t really get paid for it, and users do not – at least consciously – notice. Not only that, I encourage everyone to keep doing it.
  • I keep thinking that everything is connected. I’d better quit it, because in the end, it means thinking about the entire, infinite, exquisite universe – makes my head ache.
  • Yeah, but I keep thinking that the only really valuable skill in this age is the ability, just exactly, to make connections between things where seemingly none exists.
  • I keep thinking that one day, we’ll discover basic principles of electronic networking and break through to achieving the wonderfully facilitating type of many to many communications environments we used to have on The Source back in 1985.
  • I keep thinking that Ted Nelson was right. About just about everything.
  • I keep thinking that the more means we have to communicate, the more we seem to be throwing words and preconceived ideologies at each other like weapons.
  • I keep thinking about silence.

Why Isn’t It?

In 2009, I delivered a short, light-hearted keynote address to the STC France annual conference, entitled, It’s Not in the Job Description. This post answers that presentation with a question: Why isn’t it there? What is it that we really do, anyway?

Defining Our Profession

I’m indebted to Mark Baker for his post, The Web Does Minimalism, which I recommend to everyone, and for his response to my election post on STC’s business model. His remarks crystalized for me a number of things I’ve been reflecting about over the last few years.

We used to have a pretty straightforward idea of what we did. We were technical writers, and we wrote manuals. We provided the bridge between engineers and their world, and users. We were able to translate from the functionality-based thinking of a product’s creators, to the task-based mindset of the end users.

We were also at the end of the food chain. We had to wait until the product was done, then chase engineers around with our notepads to try and get an idea of how something was supposed to work (not necessarily how it actually did). And we always got blamed for release delays.

Today we do many things that have never been thought of in the context of technical “writing:”

  • Interface design – user assistance is embedded in the interface. How can we design it if we don’t get involved with interface design?
  • Software information content – software today is an information rich environment, and often has to talk to users in one or more clearly defined voices. We write a lot of this content, whether or not it concerns user guidance.
  • Content strategy – this is a new buzzword, more or less since 2009, but if anyone thinks we didn’t do this before, they’re nuts. We’ve always had to make our work fit into an existing strategy, when there was one, and we’ve often helped define one when there wasn’t – it just wasn’t formalized. Now it’s getting more so.
  • Information Architecture – most of us don’t like being told we’ve got to fill in all the lorum ipsum’s that some designer has created for us without ever asking us what we needed to write and what prominence it needed. But we also can’t really start writing if we don’t have an idea of the structure it’s going into. In truth, content and structure need to evolve together and in parallel. So we do a bit of IA as well, and work with designers and information architects to make sure our content has a place to go – the right place to go.
  • Localization – Most of us don’t do translation, even if we are able to. But localization is not just translation. All the activities above also need to take localization into account. You need a good 30% more screen space for material in French or German than you do in English, just take a mundane example. Then there is the HOW you write – there are ways to write that make translation easier – and less costly, too. We have to know about them. Fortunately, most of these techniques also make better source language content.

I’m sure we could find a few more, but you get the idea. The fact that we do all of the above does not necessarily make us experts in all the fields mentioned. We are technical communicators: jacks of all trades, masters of some. We work in teams with other content workers, engineers and developers, marketers and designers, to create content in a variety of environments and situations.

Our skill, today, is not knowledge of English grammar or good style – though these are tools we must have in our kits. It’s not our knowledge or this or that desktop publishing solution, DITA schemas, or CMS systems, though these are also important.

Our primary and most important skill in today’s market is the ability to find information quickly, synthesize it, and make connections where relationships don’t seem apparent.

To quote Mark Baker, knowledge is no longer a salable commodity. Instead, it is “the calling card of expertise.”

In this context, all the definitions of our profession in all the labour bureaus throughout the world are obsolete and out of date.

The Value Question

OK, this is not a blog for or about my family, but I’m going to talk about my sister again.

You see, I pick on her (she’ll tell you I always did) as an example because she’s pretty typical in certain ways.  She’s been carrying on quite nicely as a science writer, web content editor, media rep, and other nifty stuff that technical communicators routinely do, but to my knowledge, she’s never written a user manual or other direct user guidance in her life.

She’s done all this very well over a long, distinguished career (family resemblance is much more than coincidental ;-)) without ever being a member, herself, of the STC.

Suddenly, she gets it into her head to join, partly because of my participation and activism in the society, and guess what?  She can’t find anything that speaks to her.

I’ve already posted about how my sister didn’t go to the STC technical communication summit and I did. So, she looked for a webinar to take, and found one on scenario-based IA. Of course, she had to pay $79 for it. This was her take on it:

I thought this session was far too basic for a tech comm crowd (tell me who doesn’t already know what a scenario is?) and far too limited in scope, with the entire focus on “get your customer to do x monetizing goal.”  …I was looking for something a bit more directed to the education/nonprofit world, and my question [about that] was never acknowledged or addressed in the live presentation. So, what would motivate me to pay that much money for a live STC webinar in future, when it’s essentially a canned presentation?  I could have bought two books on info architecture for that $79 bucks.

This is the value dilemma. When a professional organisation offers a webinar and expects people to pay for it, it needs to make sure it’s delivering good value, or people will spend their money elsewhere. Stands to reason. My own first webinar presenting experience gave me pause to think about this from the other side of the screen – and to feel a bit guilty.

Seems obvious to me, that an organisation that presents webinars for a fee needs to be sure of the quality of the content. Beyond that, however, a proper educational service should be vetting the presenters, and be able to provide some help and support for them beyond managing the technical presentation tool. Those of us who do a lot of teaching already know there’s no better way to learn, and speaking for myself, although an experienced teacher and presenter, the webinar situation was new to me, and I could have used some preliminary coaching.

In STC, in this day when so much information is available free via social networks and search engines, it is incumbent on us to be “serious,” as the French would say, to be sure that our quality, and our image, be consistently above average. I think I’m pretty good, but my webinar for STC was not above average. This is certainly my fault and not STC’s – let’s be clear. But perhaps the education department should have – could have helped prepare me to make sure that my first time avoided the common pitfalls. This is not only a help to the presenter, it helps to guaranty quality for STC.

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.

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.