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:Richard L Hamilton <dick -at- rlhamilton -dot- net> To:Wanda Phillips <wetcoastwriter -at- me -dot- com> Date:Mon, 27 Feb 2012 21:18:43 -0800
Thanks to all for the great suggestions.
Regarding the question of tagging, I fully agree with the suggestions to use named tags. We use DocBook, and these elements are already tagged using the appropriate DocBook tags.
Wanda makes a distinction that I've also considered; that is the distinction between various types of gui elements. DocBook gives you <guilabel>, <guibutton>, <guiicon>, <guimenu>, <guimenuitem>, and probably some others I've forgotten. I think that's a bit much, though I might consider a distinction between buttons and menu items.
I'm leaning towards bold and slightly smaller than the body text (90% or 95%), as has been suggested, but I may try a sans serif font (in contrast to the serif font we use for the body text).
Best Regards,
Richard
-------
XML Press
XML for Technical Communicators http://xmlpress.net
hamilton -at- xmlpress -dot- net
On Feb 27, 2012, at 7:48 PM, Wanda Phillips wrote:
> Hi Richard,
> Like Margaret, rather simply using bold which I may want to apply in other contexts, I have created new tags, generally named something clear, like UIControls. In one job I used two tags, one for UIControls and one for MenuOption. The joy of a separate tag comes during production over the long haul. It frees up you standard tags for their true purpose and it gives your writers a semantic tag reminding them what the tag is used for. If you get into translation, or it's wheel-of-fortune cousin localization, the unique use for the tag allows you to set up translation parameters such as: since our UI is translated only into French and Dutch, but we sell our software with English, French, Dutch, Arabic, and Spanish user manuals, the contents tagged UIControl remain in the original English where there is no corresponding UI translation.
> - in one company we used the same typeface & font size as the body text, we added bolding and a color change - out interface elements appeared in the same color as the corporate trademark. This worked particularly well online until our corporate palate became muted and strange. At that point we chose a color we agreed was pleasant, obvious, and provided enough hand-waving without sliding into garish. The decision process was long and finally resolved through bribes (Krispy Kreme donuts were knocked out by Top Pot donuts) and leg wrestling contests. We used processing to produce the delightfully subtle online highlighting in color but left the print as simple black, especially good since one of the first cost-saving measures was to move from color to B&W print manuals.
> - in another company we had two formats, and almost went to three before tests showed we'd confuse customers. For controls and option that appeared on screen, we used UIControls and for menu options we used MenuOption. After several hours in a small, poor aired room we decided that the menu titles were tagged as UIControl, visible on screen, and the controls and options listed on the Menus were tagged as MenuOption. I recall only that both were based on the tag for body content with some highlighting. Color was, again, involved. In this case, on-screen controls and options were colored so we carried that across and used it both print and on-line during the boundless budget heydays. The MenuOption was slightly smaller, maybe 0.5pt, bold, and for a brief, but crazy, ten minutes it was also italicized.
> Basically the first case has been the predominant choice. And, in case you're thinking about that there DITA stuff, the more structured your tagged, the more semantic your tagging, the more rigorously your writers adhered to the correct tagging of content, the easier your transition. Not leaps and bounds better but you have writers who have been introduced to semantic tagging and you have cleaner conversion tables with a ton less manual clean-up.
> Back from my temporary Internet exile (my friends have a wireless network that seems to only allow two specific devices connect to the Internet. Neither of these rarified beasts were mine. I curled up into a small, lonely ball of abjectivity.
> I'm back!
> Wanda
> ------------------
> ...in order to understand the true nature of reality, we must realize that nothing ever really happens.
> Khenpo Tsultrim Gyamtso, Rinpoche, Sun of Wisdom (Shambhala Publications), 3-4.
> ------------------
>
> On 2012-02-27, at 9:43 PM, Margaret Cekis <Margaret -dot- Cekis -at- comcast -dot- net> wrote:
>
>> Richard L Hamilton asked about Typography for gui items
>> "Does anyone have any suggestions for typographically distinguishing gui
>> items like buttons or menu items in printed documents?...I'm considering
>> doing something typographical to set them apart.
>> --------------------_______________________________
>> Richard:
>> I set up a character style named "Emphasis" that makes terms I want to stand
>> out bolded and one pt smaller than the body or paragraph text. By downsizing
>> the pt size, it emphasizes the items without overwhelming the rest of the
>> text. For instance, if my text font is 11-pr Arial, my Emphasis font id
>> 10-pt Arial. Both Frame and Word support character styles. I set up Ctrl-e
>> as my keyboard shortcut. HTH
>> Margaret Cekis, Johns Creek GA
>>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 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://bit.ly/doc-to-help
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as dick -at- rlhamilton -dot- net -dot-
>
> To unsubscribe send a blank email to
> techwr-l-leave -at- lists -dot- techwr-l -dot- com
>
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwhirl.com/email-discussion-groups/ for more resources and info.
>
> Looking for articles on Technical Communications? Head over to our online magazine at http://techwhirl.com
>
> Looking for the archived Techwr-l email discussions? Search our public email archives @ http://techwr-l.com/archives
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
