« Sick and tired | Main | Nalo in town »



A couple of sites worth visiting:

  • Stephen Mancusi's forensic art page: "Forensic art is a law enforcement artistic technique used in the identification, apprehension, or conviction of wanted persons. Forensic art encompasses several disciplines including composite art, image modification, age progression, post-mortem reconstruction and demonstrative evidence." (Indirectly via Gwenda Bond.)
  • The What do you want for dinner? I don't know, what do you want for dinner? dialogue generator. (Via Will.)
  • The Usable Help blog, by Gordon Meyer of Meyerweb [added later: see comments below]. If you're a tech writer who's been involved in converting books into online help systems for the last, oh, say, dozen years, you may find it relevant, helpful, and occasionally distressing, especially if (not unlike certain authors of the page you're currently reading) you've experienced a certain tension between what you want as a user of help systems and what you keep being told ordinary users of help systems want. (Via someone at work.)


I think I'm more like the ordinary user when it comes to online help than when it comes to manuals. Ordinary users don't want to read manuals; I like to read manuals. Ordinary users don't want to read online help; I don't want to read online help. :)

I think the "ordinary user" is a bit of a myth, anyway.

But the "cardinary user" is very, very real.

:) to both of you.

But regarding ordinary users: what I was mostly getting at, obliquely, is that when I go look something up in online help systems, I almost invariably find a frustrating lack of detail. Generally the only time I look things up is when I'm in some sort of weird fringe situation where it isn't obvious what to do.

When I interviewed at Apple lo these four and a half years ago, they told me they had an official policy of minimalist documentation; they were basing their docs on studies that demonstrated that people don't want an excess of information, they just want one simple straightforward way to do things, and they'll figure out the other ways to do things on their own. That's all well and good until you find yourself trying to figure out how to make iChat AV work through a router's firewall.... (Which I eventually found in a tech note on Apple's site, btw.)

So common wisdom -- backed up with lots of studies -- in the tech writing field these days is that you shouldn't overburden users with too much information. Whereas for me, a very text-oriented person, there's pretty much no such thing as too much information.

I tend to lean towards the 'there's no such thing as too much information' end of the spectrum myself. I personally think the whole 'minimalist documentation' thing is about half right. Something happened to me at work a while back that I thought was a great illustration of these issues:

I was working on an old Word document, and it had a running header with screwed up formatting. I went into the online help, and was able to determine that if I set a particular flag on the field code that generated the header, this would fix my problem. The whole time, I was cursing the online help for giving me too much irrelevant information: I must have typed three or four different search terms into the search bar, clicked through half a dozen topics, and closed the help a couple of times in frustration before I found my answer.

Later that day, when the problem was fixed and the document done, I thought to myself, "Hey, those field codes seem really powerful - I bet I could do lots of cool things with them in my documents if I knew more about them." And I went into the online Help...and cursed it for not having enough information.

The problem users have with documentation isn't 'too much information' in and of itself, it's inability to find the right information when they want it. Minimalist documentation is actually a pretty crude solution to the problem, making it easier to find the trees by burning down half the forest.

Of course, I'm not sure that I really have a better general solution.

Gordon Meyer is not associated with, nor related to, Eric Meyer. (ie: Meyerweb).

None: Thanks for letting me know; I've now corrected the entry.

Post a comment