TECHWR-L Digest - 14 Sep 1995 to 15 Sep 1995

[Carol Simon <simon -at- MINDSPRING -dot- COM>]

There are 51 messages totalling 5074 lines in this issue.

Topics of the day:

  1. Re[2]: bogus resume stuff (2)
  2. bogus resume requirements
  3. Justified vs. ragged right text (2)
  4. UNSUBSCRIBE
  5. Scaling bitmaps
  6. unsubscribe
  7. Justified and Unjustified Text
  8. What size monitors do you have? (3)
  9. Re. Bulkiness
 10. (fwd) Re: Re[2]: bogus resume stuff
 11. Re. Productivity
 12. guidelines for styles in software manuals
 13. TW car manuals (was Exercises for Students)
 14. Resume stuff
 15. Table of Figures / Index
 16. comma with TM
 17. TLC Coordinator Position in Tulsa, OK
 18. bogus resume stuff
 19. Hatch mark, pound sign, # revisited
 20. Justified vs. ragged right
 21. Seeking synonyms for bulkiness
 22. Too informal? (2)
 23. Anonymous posting
 24. Re[2]: Re. WYSIWYG vs. tags (2)
 25. Translation/Localization companies?
 26. Illustrator to Frame4
 27. Salary Survey (not STC)
 28. Project Management Skills and Tech Writing.
 29. The word 'THAT'
 30. Bogus Resume Requirements
 31. Word and FrameMaker
 32. technical background
 33. Bye Bye AGAIN!
 34. Re[2]: what do you call it when your computer stops?
 35. Re[2]: what do you call it when your comput
 36. Re. Table of contents for figures/tables
 37. QUESTION RE CORRECT FORMAT
 38. WWW PUBLISHING
 39. Archiving outdated documentation
 40. URGENT Contract TW job, Montreal, Quebec
 41. More QuarkXPress Info
 42. SAT -- Enough, already!
 43. because/since
 44. Society for Technical Communication Meeting
 45. 17" vs. 21" monitors

----------------------------------------------------------------------

Date:    Thu, 14 Sep 1995 22:21:49 -0700
From:    Karen Kay <karenk -at- NETCOM -dot- COM>
Subject: Re: Re[2]: bogus resume stuff

Karen Mayer said:
>   If someone wants to know for
>   a job in 1995 how I performed on a test sometime in the 1970s, I'm sorry,
>   but that just isn't relevant. Besides, some people do not take tests
>   well.

I have the opposite problem--my ACT score was quite good, but I
flunked out of college. (Best thing that ever happened to me, btw.:) )
I came back several years later, and ended up getting into graduate
school at Yale with a 2.65 GPA. So, I have a lousy undergrad GPA and
no SAT scores!

Karen
  karenk -at- netcom -dot- com

------------------------------

Date:    Fri, 15 Sep 1995 02:30:50 -0400
From:    Jeffrey Pittman <Jpittman49 -at- AOL -dot- COM>
Subject: Re: bogus resume requirements

In a message dated 95-09-14 20:11:25 EDT, skahn -at- WB -dot- COM (Kahn, Stacey) writes:

> How about those of y'all who grew up and
>went to school in the South or Midwest-- did y'all take SATs, or ACTs?
     I am a product of the California State College system and I took an ACT
test.  But this was back in the '60's when we had to ride horses to class.
:-)
Good luck,
J.P.

------------------------------

Date:    Thu, 14 Sep 1995 20:26:09 GMT
From:    Cathy Quinones <quinones -at- MINDSPRING -dot- COM>
Subject: Re: Justified vs. ragged right text

In message <438jdu$on6 -at- huron -dot- eel -dot- ufl -dot- edu> - afn02078 -at- freenet3 -dot- freenet -dot- ufl -dot- edu (
William H. Price) writes:
:>
:>In <437aad$m7c -at- newsbf02 -dot- news -dot- aol -dot- com>, techwriter -at- aol -dot- com (TechWriter) wrote:
:>
:><snipped and clipped>
:>
:>T> Does anyone have strong preferences one way or another. Can anyone cite
:>T> definitive information showing why one might be prefereble? Does anyone
:>T> prefer one style while operating under a style guide that uses the other?
:>
:>      I cannot cite chapter and verse, but I remember a reasonably old
:>dissertation on the subject.  As I remember, ragged right was perceived
:>as less 'mechanical' in business letters.  Memory says dissertation
:>also held that san serif type more attention getting than serif; and
:>daisy wheel printer output regarded as 'more genuine' than laser printer.
:>
:>      Personally, I prefer ragged right in letters.


Personally, I loathe right justification, I find it distracting and
annoying!  Most of the time all it does is creat a lot of rivulets in the
text (empty spaces between words that distract the reader by drawing the eye
down or upwards from the line being read) and possibly slow down reading in
general (gee, the whole page looks the same now, which was the last line I
read?).  If the right margin looks too ragged, just hyphenate the words to
get a more even appearance.

It's one thing to tweak with the spacing and kerning because you need to
force something to fit, or if the design in general demands a more even
spacing.  Or if looks matter more than content.  However, when it comes to
documents of any length, I feel that the writer should concentrate on
readability and in that case I vote against right justification.


==============================================================
Cathy Quinones                               Poicephalus rule!!
quinones -at- mindspring -dot- com                      %%%%%%%%%%%%%%%%%%
http://www.mindspring.com/~mintz/coverpg.html = Bird Care Info

------------------------------

Date:    Fri, 15 Sep 1995 06:58:29 -0400
From:    "Jennifer J. Mueller" <JenniferMu -at- AOL -dot- COM>
Subject: Re: UNSUBSCRIBE

Please unsubscribe me.  Thanks!

------------------------------

Date:    Fri, 15 Sep 1995 07:03:03 +0000
From:    David Mitchell <mitchell -at- SOLAR -dot- SKY -dot- NET>
Subject: Re: Scaling bitmaps

Stuart Reynolds wrote:
> I have always and still do them in 640x480x256 mode.  NO millions, as this is
> only new anywaze and assumes that you have a video card with the correct kind
> of chip set on it. Shame on you for mnaking an assumption.

Stuart, I usually work in 256 colors.  Oftentimes in 16 colors.  The
trick still works.  Switching to more colors lets the bitmap editor
manipulate the images is in the higher color depth.  If you aren't
running in that mode, it dithers the image so you have an approximation.

Most bitmap editors only give you a small subset of filters when
working in anything but true color.  So with screen captures, which
definitely do not need true color (at least for most Win apps), you
capture in any color depth (even 16 color), run the bitmap editor (no
need to buy a new video card or restart windows), change the image to
24 bit, resize the image, convert back to the desired color depth
(even 16 color), and save the image.

This works fairly well if you don't have to make the image too much
smaller.  It also works to make images larger.  Woody Leonhard
documents this trick in his _Mother of all Windows Books_ in a
section where he shows you how to make wallpaper bigger (no more
unsightly borders on untiled images!)






--------------------------------------------------------------------------------
 -------
David Mitchell (mitchell -at- sky -dot- net)                      David's Web Spot
GTW s+:- v+++ W++$>++++ po--- b++ e++ u-
 www.sky.net/~mitchell/index.html

------------------------------

Date:    Fri, 15 Sep 1995 13:07:57 +0200
From:    "Jong A. de" <dejong -at- HGL -dot- SIGNAAL -dot- NL>
Subject: unsubscribe

Please unsubscribe db512 -at- hgl -dot- signaal -dot- nl
and/or             db512 -at- signaal -dot- nl

Person left company

Thank you for your help

Kind regards,
A. de Jong
Corporate Security Manager I.T.
Hollandse Signaalapparaten B.V.
The Netherlands

------------------------------

Date:    Fri, 15 Sep 1995 08:57:43 -0400
From:    "PROF. JAMES LENZE, LENZE -at- LTU -dot- EDU, (810) 204-3658" <LENZE -at- LTU -dot- EDU>
Subject: Re: Justified and Unjustified Text

T> Does anyone have strong preferences one way or another. Can anyone cite
T> definitive information showing why one might be prefereble? Does anyone
T> prefer one style while operating under a style guide that uses the other?

Most studies show no significant difference in
relation to search time and comprehension of information between justified and
unjustified text.  Some research indicates that poor readers have difficulty
reading justified text.  As with all technical writing, consider your audience
first!  If your publication is informal in nature and geared toward an audience
with poor reading skills, you should probably consider using unjustified text.
If you publication needs a more polished look and is geared toward an audience
with mature reading skills, consider using justified text.  If you don't mind
the look of hyphens, they can be used in justified text to give the lines,
words, and letters more consistent spacing.

My articles on the subject are published in the annual readings of the
International Visual Literacy Association.  The best work on the subject has
been done by Tinker, M.A. (1963). Legibility of Print; and Pettersson, R.
(1989). Visuals for Information.

------------------------------

Date:    Fri, 15 Sep 1995 08:04:06 -0600
From:    "Race, Paul D" <racepa -at- WHQPOS4B -dot- DAYTONOH -dot- ATTGIS -dot- COM>
Subject: Re: What size monitors do you have?

Karen Mayer <Karen_Mayer -dot- TOUCH_TECHNOLOGY -at- NOTES -dot- COMPUSERVE -dot- COM>
wrote-->
>   We're trying to justify to a boss who's never worked with tech writers
>   before (and likely didn't know they existed before he started working
>   here) the need for
>   A) A real DTP (FrameMaker)
>   B) 21-inch monitors (instead of 17")
>   c) Formal training on Frame

I have a 17" at home and a 21" here.

When it comes to formatting text, being able to see a whole page at ONCE (in
a resolution where you can still read all but the smallest type)  instead of
having to page down, page down, page down, will literally save hundreds of
hours a year, if not thousands.

People object because the cost seems high ($1200 or so), point out that
they'd be buying $300 or so monitors anyway, so the only thing you have to
justify is the incremental cost.  Which at, say 600hrs saved per year, at
$20/hr is not hard to justify.

And as a user of a 21" monitor who has occasionally had to go back to his
17-incher, I can attest, A 21" monitor DOES SAVE A LOT OF TIME.

Hope this helps - p/r

------------------------------

Date:    Fri, 15 Sep 1995 08:41:44 LCL
From:    Geoff Hart <geoff-h -at- MTL -dot- FERIC -dot- CA>
Subject: Re. Bulkiness

     It looks like the winner is indeed "bulkiness",
     since as Tom Brinckley points out, this is the
     ASTM (American Society for Testing of Materials,
     or something similar) definition. Thanks to all
     who replied!

     --Geoff Hart     @8^{)}
     geoff-h -at- mtl -dot- feric -dot- ca

     Disclaimer: If I didn't commit it in print in one
     of our reports, it don't represent FERIC's
     opinion.

------------------------------

Date:    Wed, 13 Sep 1995 17:22:00 PDT
From:    Connie Winch <CEW -at- MACOLA -dot- USA -dot- COM>
Subject: (fwd) Re: Re[2]: bogus resume stuff

>>**My feeling is that I'd never want a client (or employer) who was obsessed
>>by
>>such things. **

Garrett Romaine:

>Can I throw some calming water on this fire?

>First, the hiring manager made it plain that they aren't  *obsessed*  by
>high SAT scores or high GPAs. It's just part of their matrix. They only seem
>obsessed.


They may not be "obsessed", but if they don't want to even see the resumes
of
people who acheived lower scores than the ones given, then those scores
effectively become make-it-or-break-it requirements.

Connie E Winch
cew -at- macola -dot- usa -dot- com

------------------------------

Date:    Fri, 15 Sep 1995 09:22:34 LCL
From:    Geoff Hart <geoff-h -at- MTL -dot- FERIC -dot- CA>
Subject: Re. Productivity

     Larry Grinnell asked how to measure productivity
     and compare his group's productivity with that of
     other organisations. Larry, this was discussed
     recently (not a flame), so I'm sure the original
     posters will summarize. One common thread was that
     you must collect data in your own unique context
     to serve as a benchmark; another is that quality
     must be part of any productivity metric, since
     volume is irrelevant unless quality is also high.
     It seems to me that what you need is an "approach"
     to defining productivity as much as you need
     specific details, so here's one for discussion:

     Premise: Productivity with respect to others is
     irrelevant provided that you're meeting internal
     deadlines and not delaying the delivery of the
     products that you're documenting.

     Conclusion: Don't waste your time comparing your
     productivity with anyone else. Identify your
     current productivity using whatever metrics seem
     appropriate, then see if you can come up with
     strategies to improve these metrics. Periodically
     test whether you're still meeting whatever goals
     you've set with respect to those metrics. For
     example, one metric might be "no more than two
     edits required", in which case, if you're
     currently having a document edited 3-4 times,
     you'd have to ask your editor to teach your
     writers how to require less editing. (A bit fuzzy,
     but I'm illustrating a metric rather than
     recommending one.)

     If the need for productivity measures reflect an
     attempt to estimate how long projects will take,
     there's no alternative other than to start timing
     your own projects and attempt to correlate these
     times with characteristics of the job. This
     provides benchmarks that you can use to estimate
     your own projects. A few examples of possible
     correlates: number of words or concepts (better
     than words) per manuscript, number of product
     features, number of parameters per feature,
     whether the expert/developer/author is available
     locally or by phone or by airplane for
     consultation, etc. Here's how this might work
     (warning: very simplistic example to show approach
     rather than realistic numbers): A typical author
     might produce 1000 words per day, less 20% if
     there are more than 4 concepts to document, less
     5% per parameter that must be documented for each
     feature, less 50% if the expert is unavailable and
     the writer must go to the library or do similar
     research. On the other hand, increase productivity
     by 25% if the expert works two doors from the
     writer and loves explaining how things work, if
     the engineering specs are followed closely, if the
     author is highly experienced, etc.

     --Geoff Hart    @8^{)}
     geoff-h -at- mtl -dot- feric -dot- ca

     Disclaimer: If I didn't commit it in print in one
     of our reports, it don't represent FERIC's
     opinion.

------------------------------

Date:    Fri, 15 Sep 1995 09:10:13 -0500
From:    LaVonna Funkhouser <lffunkhouser -at- HALNET -dot- COM>
Subject: guidelines for styles in software manuals

A coworker here is tasked with developing a style guide, and
one section that causes some difficulty is text formatting for
documenting software manuals.

I know we've discussed this before, so if you kept a copy of
the summary or a really good posting, could you forward it
to me?

I'm looking for stuff like text formats for entry text, file names,
and that sort of thing.

Thanks.

LaVonna
  LaVonna F. Funkhouser           Immediate Past President, OK Chapter
  lffunkhouser -at- halnet -dot- com         Program Manager, 1995 Region 5 Conf.
  COREStaff Communication Svcs.   Society for Technical Communication
      http://stc.org/region5/okc/conferences/region5conf.html

  My opinions do not officially represent anyone other than me.

------------------------------

Date:    Fri, 15 Sep 1995 06:52:28 MST
From:    Beverly Parks <bparks -at- HUACHUCA-EMH1 -dot- ARMY -dot- MIL>
Subject: Re: TW car manuals (was Exercises for Students)

David Broudy wrote-->
> Hm, I wonder how one gets a gig writing owner's manuals for cars... some of
> those things are veritable epics.
> David, Mac/car geek.
==========
I corresponded briefly with a tech writer for Nissan maintenance
manuals (not owner's manuals, but what some people call shop
manuals) whom I met in a usenet newsgroup. I told him about this
wonderful list and sent him subscribe instructions. I never
heard back from him after that <hmmm..> so I don't know if he
ever subscribed.

Are you out there?

   =*=   Beverly Parks -- bparks -at- huachuca-emh1 -dot- army -dot- mil   =*=
   =*=     Huachuca : That's pronounced "wah-CHEW-ka"     =*=
   =*= "Unless otherwise stated, all comments are my own. =*=
   =*=   I am not representing my employer in any way."   =*=

------------------------------

Date:    Fri, 15 Sep 1995 09:53:32 EST
From:    Tara Barber <tara -at- BARBER -dot- CTEXT -dot- COM>
Subject: Resume stuff

Oh, heck with it; I'll jump in.

My SATs were excellent (1500).  My GPA wasn't.  Why?  I majored in Zoology, and
one of the courses required was Organic Chemistry.  Unfortunately, the
university had a major medical training program, and the Organic course was
designed to weed out prospective medical students.  It also rapidly turned out
that although I'd done very well with Inorganic Chemistry, I had a horrible
blindspot for Organic.  It took me a total of *five* semesters to get through
that two-semester course.  I *had* to; I couldn't graduate without it.

So my GPA works out to about a B-.  But if you refigure it without the Organic,
it's an A-, shading to A.

So here I am, with my bad GPA, and a major in Zoology, and I'm a tech writer.
And a successful one.  The reason why is that I've been lucky enough to
have started out in responsible positions (conference manager), used what I
learned there to present myself well when applying for *other* positions,
lucked into an excellent mentor when I choose to switch careers to tech
writing, and made the most of my opportunities since.

But there have been a couple of times when I've missed getting jobs because
"you don't have a tech writing/engineering/computer degree; how can you
possibly write for us?"  Ah well, their tough luck.  One of the most satisfying
moments of my life, while working as a contractor, was to take an engineer with
exactly that attitude, and in three weeks have him saying "you're wonderful;
you express this so clearly.  I guess you don't *have* to be an engineer."

Now I find myself in the position of advertising for, and hiring, other tech
writers.  I *don't* ask for GPAs or SATs in my ads.  Nor do I specify a degree
in tech writing as a must, although the handwritting on the wall says that this
may change in the next decade or so, as tech writing gains credence as a
"legitimate" profession, and more colleges design degree programs for it.

I *do* advertise for X-many years of documentation experience, depending on the
position.  I do advertise that experience with certain software packages is a
"plus," 'cause it means I'll have less training time to worry about before the
new person comes up to speed.  Depending on the job, I may list other
requirements; if they're going to be writing about client-server networks, it
helps if they've run into such beasts before.

But when it comes down to going through the resumes, and interviewing, I'm
looking at the experience, the quality of work, and the person.  That's what
matters.  That's what has to come through to me, both from the resume and from
the applicants themselves.  And so far, out of all the people I've been
involved with hiring, I'm not disappointed in any of them.  So I guess I'm
doing something right.

I feel for the problems of HR types trying to shift through the chaff to find
that wheat; I've seen some pretty horrendous resumes myself.  But the ability
to write and communication clearly can develop under all types of conditions;
to exclude possible candidates on the basis of numbers, without context, is
short-sighted.

============================================================
Tara Edwards Barber
Documentation Manager
CText, Inc.

Since my opinions belong to me, anyone stealing them deserves what they get.
=============================================================

------------------------------

Date:    Fri, 15 Sep 1995 07:05:45 MST
From:    Beverly Parks <bparks -at- HUACHUCA-EMH1 -dot- ARMY -dot- MIL>
Subject: Re: Table of Figures / Index

Richard G Harris <rgh -at- WORLD -dot- STD -dot- COM> wrote-->
> About a year ago Lori Lathrop, who seems to do a lot of indexing (Lori,
> if my memory is inaccurate, my apologies), said that she indexes Table of
> Figure entries. I do something slightly different.

> Instead of a separate List of Figures, I index all of the figures. My
> thought was to give the user one place tp go when navigating through my
> manual.
==============
Dick, from my (possibly faulty) interpretation of what you just
said, I think you and Lori are doing the same thing. I think
when she "indexs Table of Figure entries," that means she
includes those entries in her master index--I don't interpret
that as having a *separate* index for figures.

OTOH, a separate List of Figures is often used following the
Table of Contents. This would be in addition to, not instead of,
including figure references in the index.

   =*=   Beverly Parks -- bparks -at- huachuca-emh1 -dot- army -dot- mil   =*=
   =*=     Huachuca : That's pronounced "wah-CHEW-ka"     =*=
   =*= "Unless otherwise stated, all comments are my own. =*=
   =*=   I am not representing my employer in any way."   =*=

------------------------------

Date:    Fri, 15 Sep 1995 07:14:21 MST
From:    Beverly Parks <bparks -at- HUACHUCA-EMH1 -dot- ARMY -dot- MIL>
Subject: Re: Justified vs. ragged right text

Also, a justified BLOCK of text looks just like that: a block. A
big gray block on a sheet of white paper. Think of being stopped
in your tracks by a brick wall. Now think of that solid block of
justified text as a wall.