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.
Mats Broberg reports his summary of the problem with too many heading
levels: <<I seem to have solved the problem by partly breaking up the
headings at a higher level and partly abandoning my view of the importance
of a hierarchical structure. Although the software may be hierarchical, I
take your word that the user may not be disturbed that the documentation
does not follow the same hierarchy.>>
You may have overgeneralized from our opinion. We're not saying that
hierarchy itself is necessarily unimportant, nor that it's always a good
idea to choose a hierarchy that differs from that of the software. A
clarification of each point:
First, hierarchy is indeed important. Readers need to know how the parts of
the whole are related to each other. But you have to be able to reveal that
hierarchy in a way that doesn't confuse them. Since most readers won't be
able to grasp a hierarchy that goes 8 levels deep (your original design),
you need to come up with a design that makes the hierarchy accessible. One
way to do this is to focus on the task rather than the software; the
hierarchy then relates to "what do I do next?" and "where is the command
buried in the menus?" rather than the overall menu description.
That leads to the second clarification: the hierarchy you develop must
support how users perform tasks. If that approach differs from the
software's architecture, you may have a user-interface problem. Ideally, you
can provide a hierarchy that supports task performance yet makes the
software's hierarchy clear. That's not always easy, but it should be
possible. If it's not, then it's more important to support the task than to
describe the interrelationships among the software's components; the latter
is primarily of interest to its programmers.
--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
Hofstadter's Law--"The time and effort required to complete a project are
always more than you expect, even when you take into account Hofstadter's
Law."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to 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.
