Re: Useful and not-so-useful user feedback
Complicated and fragile processes need to be simplified and made more robust. You can't solve those problems (bad design) through documentation, and anyone who believes otherwise is a fool. I'm sure you'll hear the argument "this is too complex to simplify", but that's evidence of poor design skills and ignorance of user behavior more often than evidence of a truly insoluble problem.Geoff, my esteemed colleague, I think the opinion you've given is an answer in search of a problem.
Basing my impression solely on the OP's case description, I think the OP's installation problem is not the one your reductionist answer answers.
Based on some years as IT tech writer, and having documented three or four complex installations in the past 5-10 years, I'd have to say that "complicated and fragile" is an apt description for the installation of some normal business-class software systems. These installations can't be simple as tic-tac-toe; under the covers, they're simple as Rubik's Cube. They can involve a harrowing lash-up of disparate independent software packages doing their own things on mainframes, workstations, and PCs, patched together in a client-server architecture with custom software and scripts and databases, all of which need to find themselves installed in a prescribed environment with the right versions of libraries, utilities, patch levels, ...
The installation hinted at by the OP, apparently is doable. Doable, in my experience, means that complex installs requires three things of the installer : planning, practice, and comprehension. Planning and practice, while time consuming for the installer(s), ultimately require little more than diligence to accomplish.
If the installer can't spend time on planning and practice, (due to full plate, obliviousness, last minute-ness, ...) then comprehension has no chance to come. Sure enough, the OP said it seemed the installer hadn't read the crucial documentation section. OP humbly acknowledges that the docs aren't perfect.
I think that this account, of an installation snafu, makes an interesting case study, but it is a bit sensitive to be aired, as is. A techwriting grad student should interview the OP, get the details and permissions, and write it up as an academic study. It could help the next generation of tech writers to focus on getting the user to recognize their responsibilities viz the documentation.
doc -at- edwordsmith -dot- com
Create HTML or Microsoft Word content and convert to Help file formats or printed documentation. Features include single source authoring, team authoring,
Web-based technology, and PDF output. http://www.DocToHelp.com/TechwrlList
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
To unsubscribe send a blank email to techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40infoinfocus.com
To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com
Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.
Search our Technical Writing Archives & Magazine