TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
I _haven't_ taken a full course in Information Mapping (IM), but I have
attended a few lectures in which the process was explained in some depth by
IM staffers, and I've read a few articles by Robert Horn, its godfather.
I've also talked to many folks who have used the approach, both here on
techwr-l and at STC conferences. All these inputs considered, I'm left with
mutually contradictory feelings about the whole idea of IM: on the one hand,
it's clear to me that IM brings little or nothing to our toolkit that wasn't
already well-known to anyone who's read broadly in the technical
communication literature; on the other hand, most of us don't have the time
to read this widely, and it's awfully helpful to have the information all
packed into one clear, easily digested approach by IM.
The main problem I have with IM is that the company's speakers always strike
me as too evangelical for their own good, and that seems to lead
occasionally to the "all I have is a hammer, so everything looks like a
nail" syndrome. If you need a really good introductory or refresher course
in things like chunking, use of white space, and so on, and you have the
money (IM courses are overpriced in my very subjective opinion), by all
means take the course. But don't be lulled into using it as a "one size fits
all" solution for all communications problems. The analytic approach can be
very helpful in understanding a problem, but (for example) the templates
they use to format the results are too constraining for universal use.
"Technical writing... requires understanding the audience, understanding
what activities the user wants to accomplish, and translating the often
idiosyncratic and unplanned design into something that appears to make
sense."--Donald Norman, The Invisible Computer