You are what you do?

Milan Davidovic posted an interesting account of a presentation that he recently attended. The presenter stated that you need to be passionate about tech comm, and:

advised hiring managers to pay attention to the candidate’s approach to professional development, to look for candidates who identify with the profession outside the nine-to-five day.

Read the post to get a full picture.

This creates an interesting conundrum. I believe in being passionate about what you do, and think that there’s more than just a little truth to this quote:

You know who you are. It comes down to a simple gut check: You either love what you do or you don’t. Period.
– P. Bronson

But I don’t believe that tech comm (or any other career) should take up your entire life or subsume your identity. You can read more about my thoughts on this here.

In this space and elsewhere, Aaron and I tell people to take what they do seriously but not to take themselves seriously. Living, eating, breathing, dreaming, thinking, and whatever else technical communications (or any other job) is … well, it’s not a good thing. It makes someone very one dimensional, and I’m not sure I’d want to work with or hire someone like that.

I’ve worked with a few people who wrapped their identity in their careers, and they really had nothing else outside of that. No real life, few (if any) close relationships, and a lack of personality in some cases. In order to be effective at what you do, you need to step back from what you’re doing for a living. You need to take a break, and let the part of your mind that deals with your career go fallow. Even for a few hours.

And I hate to imagine what happens to those types of people when their careers don’t work out. Or, if during tough times, they lose their jobs and can’t get another one. A mind and a personal life are truly terrible things to waste.

Thoughts? Feel free to leave a comment.

Usability and documentation

Last Sunday, Tom Johnson tweeted an interesting question: What’s your biggest tip for documentation usability? Seeing as how I was deep in writing a bunch of things, I didn’t see that until late in the day. By then, a few people replied.

Looking at those replies, I thought Yeah, that’s what I would have said. In fact, those answers — especially that documentation should about specific tasks that users want to carry out — mesh well with the documentation philosophy that Aaron and I try to follow. And which we looked at in our presentation at DocTrain West 2009.

Then, I thought back to the presentation and another answer to that question came to mind. That answer:

Remove any material that disrupts the main flow of the documentation, and then give them quick, easy access to it

Therein lies the problem, though. Where do you put that information, and how do you give users access to it? Aaron and I usually advocate:

  • Using popups or mouseovers to define terms or present extra background information
  • Put the information somewhere else, like a supplementary help file, or on a wiki or a blog

That works well if you’re delivering documentation in electronic format — over the Web or as a PDF. But what about printed manuals? Believe it or not, there are more than just a few shops that still deliver documentation as dead trees.

So, what’s the solution? There really isn’t one. Aaron and I sometimes suggest putting all of the overview information upfront. Then, use cross references in the chapters that cover the actual procedures. Unfortunately, though, this doesn’t always work. We’ve found that in a few instances, we’ve had to go back to doing things the way they were done in the past in order for a printed manual to properly flow. Thankfully, not often. But often enough.

Do you work with documentation that will be primarily delivered in print? If so, what’s your biggest usability challenge? Feel free to leave a comment.

What makes a good mobile interface?

While I’ve been using mobile devices for over a decade, I’ve been seriously pondering the interfaces of such devices since I broke down and got a BlackBerry.

I’ve seen some good. I’ve seen much bad. I don’t know what the situation is like on other mobile devices, but on the BlackBerry the interfaces for many applications have a number of similarities. They share some good points, and some bad.

While I don’t think the perfect interface is beast that exists, there are good interfaces that work around any issues there are with the displays on mobile devices.

Continue reading

Is help necessary?

Before you give into that urge to happy slap me (or worse!), take a moment to read on. I’m definitely not suggesting that you do away help entirely. The real question is do we need to have an external help system?

Why not embed help right into the application? Admittedly, this has been done before. Usually with tool tips and field-level help. These give you a short explanation of what an element on the screen/window is for, or what information you can enter into a field.

Why not take this a step or two further? Instead of having a separate help system, integrate more useful, more robust, and context-sensitive help into the user interface. Doing something like that is definitely more work up front, but it benefits the user in many ways. How? One way is that it removes the need for the user to flip between the application and the help window. The help is right there.

A couple of examples

Something like this works better with a Web-based application where there’s a little more unused real estate in the interface. A good example of this is Writeboard, a simple but useful collaborative writing tool. The text entry mode of Writeboard is a simple text editor — imagine typing text in Windows Notepad. You can add basic formatting using a lightweight markup language called Textile. Of course, not everyone knows Textile. Many people use it only occasionally and may need a refresher. In a Writeboard, you click a link to get a guide that illustrates the supported formatting markup. It doesn’t open in a new window; it unfurls from the top of the Writeboard window.

Admittedly, Writeboard is a very simple application. It’s possible to this with a more complex one. And you can make that help context sensitive by hooking in the topic or topics relevant to the tasks that users want to carry out in a particular window.

Another example: a former employer of mine called uptime software. uptime develops a Web-based server monitoring tool. They integrated an interesting feature that, among other things, added an RSS feed which linked to the latest articles in the company’s knowledge base. That feature also gives users quick access to tutorials and the support forums on the uptime Web site. There’s also search engine that enables users to find content in the forums and in the company’s knowledge base.

Doing something like this is easier (relatively speaking) in a Web-based program than on the desktop. A lot of GUI toolkits don’t support the kinds of effects as well as popular Web development frameworks like AJAX or Ruby on Rails.

How much information?

That’s always the question. The amount of available space will vary depending on the application. You might have enough space for a procedure, or just a one sentence explanation. Sometimes, one or both won’t be enough.

Hyperlinking comes in handy in those situations. You can include a link to more detailed information — on a wiki, a blog, or elsewhere.

But is this a solution that applies to all applications? As you’ve probably guessed, the answer is no. It is worth thinking about, though.

Thoughts? Experiences? Flames? Feel free to leave a comment.

Social networking and you

coffee_cups Social networking is something that frequently crosses both my vision and my mind. To be honest, I have little time for networks like Facebook and MySpace. I’m grudgingly doing some microblogging. And while I’m not the most regular user or vocal advocate of it, I definitely understand the appeal and uses of social networking.

A trio of tweets by Scott Abel got me thinking a little more about social networking. Here’s what Scott wrote in those tweets:

  • Why reinvent the wheel? Groups/associations should consider using social networks as their “platform”; saves $, increases reach
  • STC chapters should have Facebook groups like Puget Sound’s there’s increasingly no need for
  • [TechComm] Most common answer when I ask unemployed tech writers if they have a profile on Linkedin: “What’s Linkedin?”

Scott started a small excrement storm with one of those tweets (can you guess which one?) — as usual, he was just calling things as he saw them. And I have to agree with him on all of those points. Not just with regard to the STC and our wacky little industry in particular, but to the professional world in general.

To me, social networks are (or, at least, can be) a manifestation of what musician Robert Fripp called small, mobile, self-contained units. They can spring up quickly. They can readily adapt to new trends and adopt new ideas. They’re easier to maintain and lack all of the organizational and historic and inertial baggage that burden far too many established organizations.

Going back to the third post in the list above, I’ve heard something like that from far too many technical communicators. Not just about LinkedIn, but about social networking and the like in general. For every technical communicator who blogs and podcasts, how many don’t? For every technical communicator who regularly uses a microblogging or social networking site, how many don’t? I’m sure that the number would surprise you as much as it would surprise me.

I could hammer out a lot of words trying to analyze why that is, but that’s not the point of this post. I’ve got a couple of questions for you:

  1. Are you a user of one or more social networking sites?
  2. If so, which ones?
  3. Why?
  4. If not, why not?

OK, that’s more than a couple. Even more than three of a perfect pair. I was never good with numbers, which is why I turned to writing …

But feel free to leave a comment with your answers.

Photo from

Form and function

The other night, I was watching the Andrei Tarkovsky movie Stalker. Like Tarkovsky’s other venture into the realm of SF, Solaris, Stalker was a very stark and spare film. No special effects to speak of and the use of special sets was minimal. The key was the story. The content, if you will.

The next day, I was reminded of a conversation that I first had back in the mid-1990s about form versus function in documentation.

Continue reading