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.
I always bold UI labels, in both steps and paragraphs. Although UI elements appear more often in steps, if the element is important enough to mention in a paragraph, then it should be clear exactly which piece of the text is the label. Bolding the text ensures the customer will realize it is a UI element's label you are talking about.
________________________________
From: Odile Sullivan-Tarazi <odile -at- mindspring -dot- com>
To: Nancy Allison <maker -at- verizon -dot- net>
Cc: techwr-l -at- lists -dot- techwr-l -dot- com
Sent: Tuesday, July 19, 2011 3:54 PM
Subject: RE: Quotation marks around user interface labels
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.
>
> --Nancy
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
---
You are currently subscribed to TECHWR-L as ruthsessions03051 -at- yahoo -dot- com -dot-
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
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-