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.
Re: Best places to put topics when they're needed twice
Subject:Re: Best places to put topics when they're needed twice From:Editor in Chief <editorialstandards -at- gmail -dot- com> To:Gene Kim-Eng <techwr -at- genek -dot- com> Date:Sun, 3 Nov 2013 19:13:41 -0500
Not sure what that has to do with the question at hand.
Are you annoyed that you would be in the minority that would not follow the
main flow that most of our customers are known to use?
There's no "reducing work for the writer" the material is written, the
examples captured. It's a matter of where and how it is presented.
We're reacting to the other users that get ticked-off no end that they have
to keep skipping over material that doesn't apply to them, just to get to
[what they hope is] the next step in the overall procedure.
We've been through the lot, over the years.
We had a minimal configuration section that got through the basics to a
minimally working system, with almost no choices and 'ifs' to navigate.It
was the 'no-fail' option. In places where a fair number of customers might
be expected to want to go into some depth or to take a variant path, we'd
insert NOTEs to let them know where to find that "extra" material.
It had the advantage of being brief and straightforward, and at the end,
you were guaranteed a functional system.
That system might not know how to do everything you needed it to do, but at
least you'd been through a successful setup, and could do it again with
confidence while selecting additional options and features.
This is hardware, plus software, in high-end business (or government) IT
environments, and is installed, configured, and managed. Our customers tend
to do a lot of lab/integration work before ever rolling out.
Some customers had your objection.
Our pendulum swung to having a very lengthy configuration section with any
number of "if this, then that", "skip over the next eleventy-two steps if
you aren't doing this option".
Some customers seemed OK with that, but many found it just too much clutter
with full configuration info about choices and options and features they'd
never need.
So, we've picked out a middle path that a majority of our customers seem to
follow, and have made that the config path, with just a few "skip this if
you aren't using", and a few "NOTE you could also configure this feature
and that feature at this point, if it makes sense in your application - see
this page for more info".
We think, though, that we have ascertained that virtually nobody wants to
have to read a manual to figure out which manuals they need.
On Sun, Nov 3, 2013 at 2:47 PM, Gene Kim-Eng <techwr -at- genek -dot- com> wrote:
> Speaking as user/customer, it ticks me off to no end when a step in the
> middle of a procedure sends me off to somewhere else to do another
> procedure that has to be done before I can proceed to the next step in the
> procedure I'm trying to accomplish in the first place. And in an online or
> electronic document, such a diversion can't even be rationalized as an
> attempt to cut down fewer trees. It's just inconveniencing the user for the
> sake of reducing work for the writer.
>
> Gene Kim-Eng
>
--
__o
_`\<,_
(*)/ (*)
Don't go away. We'll be right back.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.
