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: Typography for gui items From:"McLauchlan, Kevin" <Kevin -dot- McLauchlan -at- safenet-inc -dot- com> To:Sarah Lee Hauslinger <slhauslinger -at- gmail -dot- com>, Richard L Hamilton <dick -at- rlhamilton -dot- net> Date:Tue, 28 Feb 2012 10:28:13 -0500
> -----Original Message-----
> From: techwr-l-bounces+kevin -dot- mclauchlan=safenet-inc -dot- com -at- lists -dot- techwr-
> l.com [mailto:techwr-l-bounces+kevin.mclauchlan=safenet-
> inc -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of Sarah Lee Hauslinger
> Sent: February-27-12 8:13 PM
> To: Richard L Hamilton
> Cc: techwrl
> Subject: Re: Typography for gui items
>
> On Mon, Feb 27, 2012 at 4:53 PM, Richard L Hamilton
> <dick -at- rlhamilton -dot- net> wrote:
> > Does anyone have any suggestions for typographically distinguishing
> gui items like buttons or menu items in printed documents?
> >
> > Right now, we don't distinguish them, but I've got a book that uses
> them pretty heavily. In addition, many of them in this book are common
> words that could be confused with their meaning as a word. So, I'm
> considering doing something typographical to set them apart.
>
> We typically format GUI items in the bold weight of the font we use
> for body text, which is the convention recommended in several style
> guides, including Microsoft. Although Sun recommends using an unbolded
> font and capitalizing, IMO bolding enhances clarity because it lessens
> the chance of confusion.
In some fonts, and in some lighting conditions, bold is not all that
distinctive, the more-so if you have several instances in a sentence.
I like the convention that I adopted years ago, and at least one
other writer on this list has advocated - Start and end the button
or menu item name with square brackets.
It makes it look vaguely like a button [ Next ], [ Cancel ],
[ Save as... ], [ Eliminate all free radicals ],
and it's likely to be unlike other conventions you have used in
your document.
Short buttons could be included in-line, while more verbose
items from menus could still be bracketed, but -
[ Would always appear alone on a new line ]
[ Compensate for clock drift ]
[ Print the middle two thirds of page without context ]
On the other hand, if you do have recurrent use of square brackets
for some other purpose, then this is not so useful for GUI bits.
Maybe you could combine the square brackets with shading/highlighting
of the included text. Everything inside the brackets gets a light-gray
background, perhaps.
-k
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
