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 agree with Dick. Indexing each and every GUI element could make the index far
less useful for finding the other stuff. I indexed lots of windows and fields a
lot in one book and it clouded up the index. I took'em out the next time. Also
some GUI things are hard to name, or at least their names would not be something
the users would know. Are there any unlabeled scrolling fields or picture-only
icons in the interface?
I believe users generally seem to have a more gestalt approach, thinking about
the idea (entering transactions, making a table of contents, adding a portlet to
a portal) than the elements (commands button, etc).
If you have the windows in an appendix, and presumably they're organized
logically like by function or alphabetically, why would users need an index when
they can go straight to a logically organized appendix? Or if there's online help
they might just go there. Seems like users are probably already OK.
So in short I'd say maybe index really important GUI elements like the
registration/login window or the one big crucial error message window but don't
worry about the rest.
Solveig
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
solveig -at- techwriterstuff -dot- com
"I'm the Editor Your Momma Warned You About." http://www.techwriterstuff.com
Products expressing the agony and ecstacy of being a techwriter.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dick Margulis wrote:
> If you must document each gui element, use tables in an appendix, one
> table per screen/page, divided into sections (fields, buttons, etc.),
> with a text description or instruction for use for each element. In most
> cases this is serious overkill, but if your audience is such or your
> application is such that you need to document to this level of detail,
> this is by far preferable to indexing.
>
> rk5jeeper -at- hotmail -dot- com wrote:
>
> > Does anyone have any opinions on indexing gui elements. My group is in the
> > middle of a debate about including each field, button, etc. in our index.
> > Some claim users use the index to look up fields. Others think it buries
> > the real information in our user guides. Unfortunately we have not done a
> > survey to find out. But I am curious to see if others do index field
> > names. Our documentation architecture has all gui elements in the various
> > forms and dialog box separated from our process documentation. I can't
> > remember any software manuals I have ever looked at that include and index
> > entry for every field. What say you all?
> >
> >
>
>
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
