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.
Rosemary J Horner wrote:
Anybody have any ideas of better words than parent and child?
I've written for many programs that establish parent/child relationships. Using parent/child is the clearest, and easiest way to explain what is going on because the concept of parent and child automatically implies a hierarchy (or it should if your parents had healthy boundries <grin />). Trust me, I've had a couple of editors suggest various substitutions and they were all awkward and only confused users.
When I'm writing about parent/child relationships, I usually start out by saying something like:
"The x program uses parent/child relationships that establish a heirarchy between y and z." And then I use a graphic, if the hierarchies are particularly complex, to demonstrate what I'm talking about.
I wouldn't sell the users short. I wouldn't use non-standard terms to dumb down the matieral either. Besides, if there are people in your company who don't know what parent/child relationships are, teaching them the wrong terms will only confuse the issue in the long run. More over, you'll only confuse those who already understand parent/child relationship concept. By the way, "parent/child" isn't just programmerese. It's a concept used widely whenever you talk about hierarchies.
Based on your second email, it sounds like you're confusing what the program does with what the user goals are. If the program is flexible enough to allow for the sort of relationships you described (a and b are both parent and child), then which is the parent and which is the child will probably depend on general internal practices. The program won't care.
So, you might want to describe how the program deals with relationships, and put a note in there saying something like "your organization defines how these relationships work" In other words, the program doesn't care who, in the beneficiary example, is the parent and who is the child. That would have to be determined by the human user in a set of best practices or guidelines.
That said, your description of the interface sounds pretty unusable. It doesn't provide any visual cues about the relationships without having to click? mmmmmmm Your company may want to rethink its design a little.
Promote your group and strengthen ties to your members with email -at- yourgroup -dot- org by Everyone.net http://www.everyone.net/?btn=tag
Check out the new release of RoboDemo, our easy-to-use tutorial software.
Plus, buy RoboHelp Office in August and save $100 with our mail-in rebate.
Get details and download free trial versions at http://www.ehelp.com/techwr-l
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.