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.
>Kathleen said:
>>Beth Agnew wrote:
>>>Milan said:
>>>>Beth Agnew wrote:
>>>>
>>>>Well, I'm a little tired of the World According to Microsoft...Why not
>>>>figure out a style that works for your user base, whether it conforms to
>>>>Microsoft or not?
Hmmm...this has been something that I've championed for years, but it meets
a lot of resistance from newbie project managers who don't have a clear
concept of what they'd like to see in documentation. They always fall back
on MS as the de facto standard.
>>>Good point, but I think in this case Microsoft also has a good point. Why
>>>say "Click the Landscape radio button" (in the Page Setup dialog box)
>>>when "Click Landscape" would work just as well?
This is something else that I used to do, but this made my editors nervous.
Sure, in the Page Setup dialog box this works well since that dialog box
remains static no matter what you're doing within an application. But, as
with the last app that I documented, the developers were concerned since we
had Refresh buttons and the app also "refreshed" when certain actions were
executed.
>>That's probably what I would have said without consulting MMS. I like the
>>most direct route between user and instruction. At some point, if one must
>>refer to the interface, using the correct terminology helps educate users.
>>That's why we drive cars that have distributor caps instead of, I dunno,
>>insulated rotor covers.
>
>While "radio buttons" nicely describes buttons that allow only one choice,
>if you've never had a car radio with buttons, it becomes meaningless almost
>an arbitrary term, in the absence of context. We have enough legacy
>language (hit Return, dial a number) that we have to deal with, but we're
>comfortable with it. Ask any 24-year old digital native about radio buttons
>and it's a different story.
Jeez, just when I got comfortable using 'radio button'. When I first used
that term (many moons ago), my readers piddled themselves laughing, but when
I showed them that the term was the standard, I reduced them to
perma-chuckling. So the MMS is now 'option button', correct? Not a button
anyway...grumble, grumble...
>My point is that we need to be aware of what makes sense to our audience,
>and continually ask ourselves whether the terms in the venerated style
>guides are still relevant.
Can't argue with logic.
[]
>Re "Click," I've always preferred using a direction, i.e., "Click on" (for
>button) or "Click in" (for box).
>
>I think it's partially an effort to avoid getting trapped into the overly
>terse/telegraphic style writers sometimes use.
Hmmm...I'm not sure that there can be one standard for the above. I can see
where you could write "Click inside the text field" - that makes it clearer
(IMO). But 'clicking on' a button has always gotten me red marks from my
editors. You're clicking the button; 'on' is just to letters you could have
used elsewhere.
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include single source authoring, team authoring,
Web-based technology, and PDF output. http://www.DocToHelp.com/TechwrlList
---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
