The Gestalt of Bookkeeping

Well!  The STC election is over (I won). The spring conference season is over – at least for me, with many successes and then – the one I didn’t do so well at. The home stretch in this hectic season, before relaxing for the summer (apart for some client work to pay the bills) was French tax season.

To do my taxes, I first have to do my books. If you’re like me, you wait until the last minute to do a lot of the bookkeeping work. Resolutions, year after year, to keep my books up to date all during the year have all gone down the road that’s paved with good intentions…

Bookkeeping is a simple, boring, annoying task, right? Isn’t that what it’s supposed to be? Funny thing is, each year, when I start this process, so many things come back to me:

The lunch in New York, where I invited two of my former students, from two universities on different continents and from two different generations, because I was sure they’d have something to say to each other, and they did.

The EuroIA conference in Prague that stimulated and excited me.

The Intelligent Content conference in Palm Springs where I not only was stimulated and excited, but got to have a wonderful reunion with an old friend I hadn’t seen since high school (I won’t tell you how many years ago that was…)

The new sound equipment that I bought and have not yet used as intended (real soon now).

The trip to San Francisco that I didn’t plan, after the death of my closest cousin.

The weekend canoeing with my Barcelona friends on a meander of the Ebro River near Flix.

Doing one’s books for the whole year all at once provides the kind of reflection and review that we are supposed to do around various religious ceremonies, but that many of us largely ignore. Holding that receipt in the hand opens a floodgate of memory. It can be a time for nostalgia, for bittersweet reminiscence, even for regrets, or might stimulate us to beg pardon of someone for something we did during the past year.

Bookkeeping. Who woulda thunk it?

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.

Find Your User’s Voice

I’m working on an interesting problem these days. I have a client who is about to release a new software product. I can’t tell you what it does, for obvious reasons, but I can tell you that it does some neat things. Perhaps too many.

It provides users with all kinds of useful information. Some of it is useful for a group of users – call them Group A. Some of it is useful for another Group B.  They aren’t interested in the same things, and for some information,  Group B wants to know about it, but Group A not only isn’t interested, they’re not authorized to see it.

Access to sensitive information can obviously be solved with user profiles, but it’s a challenge to sell the same software to two different audiences. To facilitate the task, we’ve decided to create two different interfaces, one for each of the groups. When a user logs into the software the interface s/he sees is dependent on a user profile associated with the login. The other interface is not available.

That was the easy part. Next, we have to design the interfaces. And each interface has to communicate with its user group in language that makes them comfortable, and, above all, inspires confidence in the software.

It’s early days, but here are a few guidelines I’m working on that you might also find useful:

  • The design (look and feel, user interaction model) of the two interfaces needs to be sufficiently similar that should someone need to have access to both, they don’t need to relearn everything to use it.
  • At the same time, the same elements of the interface need to be fine tuned to appeal to very different user populations – for example, one might be technical, or engineering oriented, the other might be business oriented. One might be implicated in operations, the other might be financial, etc.
  • The language, labels, messages used in each interface need to be 100% adapted to the user group’s profile.
  • When writing the messages and content delivered by the software, we need to think about subtext as well as overt meaning. When two people have a conversation, there is enormous subtext based on power relationships, expectations, tone of voice, etc. When software provides information to a user, there is an implied notion that one or the other is the expert. How the software communicates with the user needs to be aligned with whether the software or the user is expected to be the expert, and the tone of the communication needs to be equally adjusted.
  • The user guidance, also needs to respect the target audience. This is harder the it might seem. Some of the user guidance is common to both interfaces – and needs to maintain that level of confidence for both, despite the fact that the two groups tend to favor very different communication styles.

My takeaway from this exercise so far: when we talk about content strategy for software, we really need to take a holistic approach, and realize that content and style need to be coherent, and in resonance with the nature of the information itself, and the user who must interact with it. Interactivity, in this sense, needs to take certain aspects of human communication into account if it is to succeed at convincing users and gaining their trust.

Where Would You Take This Idea?

I invite your comments, thoughts or reflections.

Don’t geolocate me – it’s bad UX!

Software publishers, webmasters, listen up, and listen up carefully!

The fact that I happen to be in Finland doesn’t mean I need my software or web pages installed or served up in Finnish. That would be true even if I were Finnish. Many Finns speak Swedish as their native language, and the Saami people have their own languages, many of them endangered.

Just because I happen to be in Spain doesn’t mean I need my software or web pages installed or served up in Spanish. That would be true even if I were Spanish. People in Spain also have Catalan, Gallego, or Euskadi for native languages.

I live part of my life in Catalonia, and I speak both Spanish and Catalan, but English is my first language, and I prefer to read material written in English in the original version. All my computers but one have English operating systems installed, but many programmes and web sites insist on giving me the language of my IP address or GPS coordinates, or of the regional settings that I have installed on my system (in my case, French keyboard, date and time formats, currency, etc. – I also live part of my life in France). Worse, some of them don’t let you change even after the fact.

Get it? I’m an international person. My computer And I speak and use many languages. In many places. But we most like to function in English, except when the information is originally in a language I know or is culturally specific.

Here’s a real life experience with a web service many of us use, Survey Monkey. I set up an account using the English interface. If I type the general URL for the site in Barcelona, the interface comes up in Spanish. This is not necessarily bad usability, most people with IP addresses in Spain will prefer that language – except if they are in Catalonia. Except if they are in the Basque country. Except if they are in Galicia. OK, so I type in my user ID and password, but guess what? It doesn’t know me. Now what? Well, one of the things I do is look for a language selection. But would most users know to do that? Anyway, finding it on Survey Monkey’s login page is no easy feat. It’s way at the bottom. I changed the language to English, eventually, and tried again. Success this time, I got in.

Next time I went to Survey Monkey I was on the same (laptop) computer, but in France. Surprise, the French interface comes up, and it doesn’t know me! Change to English, success.

Frustrated, I searched the settings for a language preference. There is none. Come on, guys,
even Google lets you pick your interface language and set it, and they know who you are in any language. And they speak a lot more of them than you do.

In a fit of pique, I treated Survey Monkey to an email with my opinion. I got a terse reply from a French representative telling me that most people in France prefer to speak French and that I could switch languages. Thanks.

Oddly, another offender is Canon printers. If you install their software from a CD it gives you a nice language choice screen. But if you download their drivers or other software, you get what they give you, which is the language of your regional settings. Even from the English download site!

These are clearly examples of poor thinking, leading to poor user experience.

Just because we know how to geolocate someone doesn’t mean we should. I would rather you looked at what language my system is in. It seems to me, this gives you a better guess about what language I want to use.

What do you think?

What’s Emotion Got to do with Technical Communication?

I’ve just returned from the 12th Consciousness Reframed conference, in Lisbon. This conference, started by my friend Roy Ascott, is based on the idea that we can raise our level of consciousness using a combination of scientific research and mental and spiritual discipline. It’s based on the concept that artists are social researchers and socializers of new technologies, and that an artistic regard towards the planet and human existence is as useful as – and is a parallel activity to – scientific investigation. This ideas was also expressed in the 1950’s by Werner Heisenberg, one of the godfathers of quantum physics, and whose uncertainty principle is most easily understood from the point of view of Eastern philosophies such as certain branches of Buddhism, rather than from our traditional Western methods.

I was a presenter at this conference, but also an avid attendee, listening to people from a wide variety of disciplines and experiences speak about evolving ideas of transformation and multiple identities in the age of virtual, networked communication. The point of departure of this conference is to reject any and all dogmas, and be open to the possibilities of any serious study, be they based in science or the knowledge systems of aboriginal peoples worldwide. Thus, the gestalt of the conference is to avoid being boxed in, either by a purely materialistic idea of science, or by a totally spiritual approach that excludes more “rational” or traditional scientific methods.

I was struck by the similarity of approach between the best speakers at this conference, and the incredible balancing act of humanism, emotion, and science that I’ve already related in recommending Jill Bolte Taylor’s TED Talk.

I have since read Dr. Taylor’s book, My Stroke of Insight, where she likens some of the states she experienced during her stroke and long recovery as akin to the “Nirvana” of Hindu and Buddhist philosophies. She goes to great lengths to explain how her brain function, from a physiological point of view, was functioning to cause these sensations. She also swings back from that “concrete” explanation to the subjective account of how she experienced this – emotionally, sensorially, mentally and physically.

There is an incredible lesson in these types of experiences for us technical communicators. Jill Bolte Taylor wrote a book that was a New York Times best seller. It was about her own brain. It is full of technical and scientific information that, at times, can be extremely complex. Yet her book was a best seller.

She didn’t get to have a best seller by going into great detail to explain the intricacies of brain function. She got to have it because she told a powerful, human story.

We’ve all heard about “story telling” as a technique. But how many of us understand it at this visceral level?  How many of us are able to communicate complex, technical and scientific information to our audiences with the clarity and liveliness that Jill Bolte Taylor does either in her TED talk or her book?

How many of us even think about doing it?

Don’t most of us tend to think emotions have no place in technical communication?

But what if that emotional component, the human side of things, enabled our audiences to do what they want and need to do faster, easier, and with more enjoyment? Shouldn’t we be glad to provide that? Shouldn’t we be thinking about the lessons learned from the communications of Jill Bolte Taylor and the speakers at Consciousness Reframed, and understanding how we can tell human stories to our human users and give them a rewarding experience?

How would you do it?

How would you start to include human stories in your technical communication? What methods would you use? What kinds of stories would you tell, and how would you tell them? What delivery methods would you use?

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.