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: Clarification on Text Styles From:Melissa Fisher <mfisher -at- MOBSEC -dot- COM> Date:Fri, 12 Dec 1997 09:10:25 -0500
Beth Agnew writes...
thinking has been that users need the visual cues to
say, the name of a menu item and what they type in.
I'm proposing that it is not at all necessary.
Beth, what is necessary might depend a lot (in software doc, at least)
on how your UI is designed. I used to work for a company where the
standard on all their dialog boxes was to capitalize only the first word
of an option (a raido button, checkbox, field name, whatever.) So an
option on a dialog might read "Enable automatic foobaring during dibble
processing". In addition, some programs relied heavily on information
presented to the user on text-based screens, where abbreviations and
mixed capitalization/punctuation abounded.
In these situations, I felt it WAS necessary to differentiate the text
styles when referring to one of these options. I tried going the "plain
text" route, but it was hard to tell when the name of a field or option
ended and the rest of the sentence began. Without laboriously (and
often clumsily) writing around all these labels, we chose to use bold
face only for options/field names on a dialog. For the text screens, we
did choose to use a different font, and chose one that closely matched
the actual font used on the screen. (For the text screens, some of the
phrasing was so abbreviated that we felt that by trying to match the
text to the screen was the best way to eliminate as much confusion as
I agree that a lot of different text styles are not necessary - but take
your UI into consideration too.