Re: minimalist documentation?

[Hillary Jones <hillary -at- NICHIMEN -dot- COM>]

> I remember getting into a discussion with a fellow writer a few years back
> about minimalist software documentation.  We both agreed that if you carry
> that idea far enough, nobody gets *anything* with their new software.  No
> books, no online help, no 1-800 number, no nuthin'.  Figure it out
> yourself.  Sink or swim.  Learn from your mistakes. etc.
>
> I think the discussion leads into the ongoing battle between behaviorists
> and constructivists.

Maybe Chris could draw some connections, because I don't quite see how
John Carroll's minimalism matches what he wrote about. (If this seems
dense, tell yourself I haven't recovered from a three-day weekend.)

From what I've read, minimalism is three things:

1. focus on tasks--you get something done instead of go through drills
that won't have an end product.
2. eliminate stuff like "About This Document" and introductory
descriptions.
3. facilitate error recovery.

The thing I've been thinking about it whether it could be applied to all
forms of documentation, or just to "Getting Started" or tutorial stuff.
Or whether anyone has real world stories of using these minimalist
principles and succeeding or failing.


--
******************************
Hillary Jones
hillary -at- nichimen -dot- com

Confucius say: Show-off always
shown up in showdown.

******************************

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html