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: Quotation marks around user interface labels From:Odile Sullivan-Tarazi <odile -at- mindspring -dot- com> To:Nancy Allison <maker -at- verizon -dot- net> Date:Tue, 19 Jul 2011 12:54:12 -0700
Two issues we encountered that I haven't seen mentioned yet, I don't
think, in this thread:
Do you bold all UI control labels in the step, or only those that the
user touches (clicks, selects, or enters data into)?
Do you bold these UI control labels only in step text, or always? Or
do you bold them everywhere they come into play procedurally (whether
in step or paragraph text), but not when simply named in background
or general discussion?
_______
By "UI control labels," I mean the names of menus, menu items, tabs,
fields, group boxes (which organize groups of controls, but are not
themselves clickable), dropdown lists, icons, buttons, radio buttons,
checkboxes, and so on.
_______
We grappled with these issues and went with using bold on UI control
labels always, whether in step or paragraph text, whether in a
procedural or a conceptual context. It made seeing the labels and
parsing them distinct from the rest of the sentence a lot easier,
though it could mean introducing a lot of font changes in the page.
Because the label itself was so distinct, we then in turn did not
have to always include the clarifying generic noun (button, box,
etc.) in order to help set the label off from the rest of the
sentence. We were free to use it or not, as best worked with the
sense of the phrase and the sentence. And likewise, because the
label was now so distinct, we didn't have to worry about long strings
interfering as much with the syntax of the sentence, nor is there any
longer a problem with labels that are capped sentence-style.
(Though, for consistency in the doc, when we encounter sentence-style
capping in a UI where all labels are to be capped headline-style, we
silently correct the error.)
It can make for a heavy page, but that seems to be the only drawback.
In steps, we likewise apply bold to all labels that might be cited,
even when they are cited only so as to direct the user to what will
finally be touched in some way. We do this for two reasons: one, it
provides a navigation path to the item selected or clicked; and two,
if we're going to be placing these names in bold elsewhere, we can't
very well leave it off here in the step.
We do not bold the names of windows, wizards, or dialogs. We do not
bold the names of pages within wizards or multipage dialogs.
Odile
At 2:19 PM -0500 7/19/11, Nancy Allison wrote:
Hey, all! I'm wondering you you might do me a great favor if you
have a minute (and if your companies permit it).
Would you send me a PDF of a typical procedural page from one of
your documents, so I can see how you use fonts?
Only if your company doesn't object and if you have time.
My preference is to bold only the UI items the user clicks, selects,
or enters data into, so I bold only buttons, radio buttons,
drop-down list items, and field names (I'm probably forgetting a few
controls, but you get the idea).
I tend to think that the more things you bold (like window names and
dialog box names) the less impact the bold type has.
But maybe I'm wrong, and I need to see some fresh examples of
different styles to help me figure it out.
If you could do this for me, it would be much appreciated.
Create and publish documentation through multiple channels with Doc-To-Help.
Choose your authoring formats and get any output you may need. Try
Doc-To-Help, now with MS SharePoint integration, free for 30-days. http://www.doctohelp.com
