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: Re[2]: Style Guides, Take II From:Sharon Burton-Hardin <sharonburton -at- EMAIL -dot- MSN -dot- COM> Date:Sat, 19 Dec 1998 07:45:54 -0800
The Microsoft manuals might be difficult to use in that they don't provide
the user with the info they need, organized in a way that makes sense. Many
of their docs are like that. To be fair, many vendors docs are like that.
Many of my clients have manuals like that. That is why they employ me and
many others like me - to make them better organized, clearer and more user
appropriate. To help the user.
The MS style guide, however, is a different issue than difficult-to-use MS
manuals. Here is my opinion but it seems true to me, based on the numbers I
see in industry magazines. Microsoft owns the world. Nearly every PC ships
with MS products installed. Even many Macs. Therefore, if your user has read
a manual or a help, they have read the MS standard for how to talk about the
things they see and how to interact with them.
Given that our users already know what that stuff on the screen is called
(whether or not they even know they do), it behooves us to use the same
words to talk about that stuff. That means that our users have one less
thing to learn in the process of learning our software. We don't ask them to
learn what we mean when we refer to the stuff, we call it the same things
they are used to. That means all (!) they have to do is learn the new
software and the unique concepts in the new product.
This is similar to learning a new area of study in school. If the teacher
can use language the students already know, the learning curve is shorter
than when the students have to learn a new language and the new area of
study at the same time.
IMHO, using the MS style guide is another way for me to help my users to use
the product. If I thought that drawing pretty pictures in crayons would make
a difference for my users, I would do that. Using the MS standard to talk
about that stuff isn't sufficient to make a good manual. It may not even be
necessary. But it does move in the right direction.
hey Dave!
sharon
Sharon Burton-Hardin
President of the Inland Empire chapter of the STC
Anthrobytes Consulting
Home of RoboNEWS(tm), the unofficial RoboHELP newsletter
www.anthrobytes.com
Check out www.WinHelp.net!
See www.sharonburton.com!
-----Original Message-----
From: David Wollenberger <david_wollenberger -at- WOODLAND-HILLS -dot- STERLING -dot- COM>
To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU <TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU>
Date: Friday, 18 December, 1998 10:06 PM
Subject: Re[2]: Style Guides, Take II
> I was raised with the Chicago Manual, but at my present job they use
> Microsoft Manual of Style, and most of our software is not even for
> the PC.
>
> I wonder why, if so many tech writers think Microsoft publishes bad
> manuals and their manual of style sucks so much, so many departments
> are using it as their standard.
>
> David
>
>
>
>
>______________________________ Reply Separator
_________________________________
>Subject: Re: Style Guides, Take II
>Author: Robert Plamondon <robert -at- plamondon -dot- com> at sswhsmtp
>Date: 12/13/98 7:16 AM
>
>
>I don't see why anybody uses the Microsoft Style Guide anyway. I mean,
sure,
>if you think Microsoft's documentation is the bee's knees, then you'd want
to
>read the book to find out how they did it. But Microsoft's documentation
has
>been muddled and clueless from day 1. You'd be better off starting from
>first principles than emulating them. At least your mistakes would be
honest
>and possibly ephemeral, instead of dull and institutional.
>
> -- Robert
>
>Robert Plamondon * High-Tech Technical Writing
>36475 Norton Creek Road * Blodgett OR 97326
>541-453-5841 * Fax: 541-453-4139
>mailto:robert -at- plamondon -dot- com * http://www.pioneer.net/~robertp
>
>
>From ??? -at- ??? Sun Jan 00 00:00:00 0000==
>
>
>From ??? -at- ??? Sun Jan 00 00:00:00 0000==
>
>