SUMMARY: Alternatives to "tasks"

[Ben Kovitz <apteryx -at- CHISP -dot- NET>]

Here are some alternatives to "tasks" that people suggested:

   Functions
   Activities
   Exercises
   Procedures
   What the Customer Does, What the <er, XYZ Employee> Does

Another thing that several people said was that they didn't see
anything wrong with "tasks".  I can't believe it's just me, but
it seems that "tasks" and most of its synonyms have somewhat
less-than-desirable connotations:

   Tasks
      To me, sounds like a tedious chore assigned to you by your
      wicked stepmother or by a "taskmaster".  We tech writers
      use this term all the time among ourselves, in phrases like
      "task-oriented organization" and "task analysis".  Notice
      that we use it to describe what *other people* do, but not
      what we do.  I don't think I've ever seen it in a user's
      manual.  Interesting that we don't normally need to use
      this word when telling users what their tasks are and how
      to do them.

      In favor of "tasks", what I'm trying to avoid is the feeling
      of "here's a whole bunch of new junk you're supposed to do, in
      addition to all your other responsibilities," but that's
      exactly what this manual is supposed to describe.  The users
      need to know not only how to do various jobs, but *that*
      they're supposed to do them.  The only reason I'm doing it is
      because I have two major categories of tasks to distinguish.

   Functions
      Mind-numbing in its vagueness (at least if it were to
      appear in a user's manual); old-time IBM system analyst talk;
      also, sounds more like a description of the software than
      something to do with it.  (This was actually the first
      candidate I considered.

   Exercises
      Sounds too much like practice instead of the real thing.

   Activities
      Actually, not bad, but it makes me think of Romper Room or
      the Love Boat.  (Maybe I watch too much TV.)

   What the Customer Does, What the <XYZ employee> Does
      As much as I like this, it just has too informal a feel
      for a user's manual for a big, serious corporation.

This may sound like a lot of trouble for one word choice, but I
think we make a big mistake if we ignore people's emotional
reactions to our writing.  Karen Schriver's book _Dynamics in
Document Design_ has a lot of interesting discussion and examples
of this aspect of technical writing.

I'm probably going to go with "procedures".  To me, that doesn't
have any connotation at all, either negative or positive.

(In my requirements book, I mention that a UI designer needs to
design "operating procedures" and that these should be thought
through *before* writing the manual.  I greatly prefer that term
to the awful but currently fashionable "use cases".  I was
thinking mainly of internal, "scaffolding" documentation, not
user documentation, but I suppose it works in either.)

I was hoping to hit on some radically different approach, maybe
even reorganizing the manual, or something that would get me out
of having to call these things by any name at all (just as in
most user's manuals).  One person did suggest something that I
like very much--not a synonym, but a different concept.  The idea
is to describe the categories in terms of results, not in terms
of the actions that bring them about.

Unfortunately, I can't think of how to apply the idea in this
case.  The tasks/results in each category are: logging in data
from engineering documents, checking to see if all the documents
have been received and logged, granting privileges to users,
updating a database of location codes; and, on the external side,
viewing a schedule for hypothetical orders, tracking orders in
progress, printing invoices, and that sort of thing.  Looks like
"procedures" is it.

--
Ben Kovitz <apteryx -at- chisp -dot- net>
Author,  _Practical Software Requirements: A Manual of Content & Style_
http://www.amazon.com/exec/obidos/ASIN/1884777597
http://www.manning.com/Kovitz


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=