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.
Subject:RE: Never lead with a graphic From:Emily Berk <emily -at- armadillosoft -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Sun, 13 Jul 2008 06:37:10 -0700
Rebecca:
My theory about why one would not want to lead with a graphic has to
do with readers searching through a doc for information. If a reader
does a keyword search on the doc or using a search engine, they are
not going to find your graphic. If the text that explains the
graphic is below the graphic, then the reader will search for the
keyword, get to the text (not see the graphic) and if the text refers
to the graphic, have to scroll up. If the text does not refer to the
graphic, then the reader might not even realize that the graphic is there.
One more thing: Updating of graphics when conditions change is often
an issue. That is, a procedure changes, but everyone forgets to
update the flowcharts. If there's a title over the graphic that
labels it, I think the need to update the graphics when conditions
change is less likely to be forgotten.
Brian Gause's observations below resonated with me. Sometimes we get
"stuck" in "our" positions when really the "other side" is not being
terribly unreasonable.
Having a doc standard that mandates text before graphics seems like
an idea that is not entirely silly.
Why not just accept this not terribly onerous constraint and fight
battles over decisions that ARE truly stupid?
If ever you HAVE to place a graphic with no text above it (I really
don't see why you might feel compelled to, but maybe you might have a
compelling reason), why not just DO it, rather than argue over
it? If someone calls you on the carpet to explain, THEN have the
argument. But why would you choose to have this discussion now?
- Emily
On Tue, 8 Jul 2008 19:12:51 -0400, Gause_Brian -at- emc -dot- com wrote:
"...Honestly, after reading through this thread, I'd say your biggest issue
isn't about whether to place the graphic or the text first. What I see
is someone who asked for an opinion, then ignored about a dozen
responses that agreed with her boss, and who is still determined to do
it her own way. I mean, what's the point of asking for opinions if you
ignore everyone and refuse to change your opinion?
I wonder if you want the right answer, or your answer. Speaking as an
outside observer with no stake in this matter, I'd say you're looking
for a reason to justify your behavior rather than do what is best for
your audience.
So if you have a discussion about this, be prepared for your boss to see
this perspective, too."
On Tuesday, July 08, 2008 12:44 PM, Rebecca Hopkins wrote:
>Leonard,
>
>Thanks for the advice - I'm just arming myself for the
>inevitable conversation with the boss.
>
>I talked to one of my younger co-workers, and he said that's
>what he learned in school as well - never lead with a
>graphic. He could not remember the rationale, however. Since
>the boss is newer to the tech writing circus than I am, I'm
>thinking she also "received" this wisdom that I missed out
>on.
>
>We're going through one of those clean-out-the-fridge,
>salute-it-or-paint-it re-orgs of the company's various doc
>sets, and standards for standardization's sake are being
>carved in stone as we speak. Two people who remember it from
>class outnumber one person's personal opinion. I will have
>to find references to back up my argument.
>-----
>Rebecca
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-