RE: Typographical treatment of GUI components

Subject: RE: Typographical treatment of GUI components
From: lvarteressian -at- financialengines -dot- com
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 15 Jul 2003 18:33:05 -0600


I have an opinion about how UI elements should be treated in text. But it
really is just an opinion. At most companies where I've worked, the
department style guide dictated that UI elements should be in bold. The
one prominent exception that I recall was at a large software company
where I worked on a consumer application (aka a "shrink-wrap" product)
with over one million users (over three million if you believe the
marketing hype).

The department style guide required that we use no special typographical
treatment for menu names, but Small Caps for command names (for example:
"From the File menu, choose DATA EXCHANGE," where "DATA EXCHANGE" would be
in small caps).

For other UI elements (such as labels within dialog boxes), we used
initial caps for every word in the text element, even though only the
first word was capitalized in the UI. (For example, we'd write: "Choose
the Record A History For This Fax option." -- even though the option is
"Record a history for this fax" in the UI.)

I had no say in the use of these conventions. I just followed them, but
often felt they would be confusing to our users, many of whom were not
experienced users of Windows applications.

Fortunately, the company believed in user-testing documentation. After
many user tests of several of our procedures, we noticed that our users
were completely unaware of the typographical conventions we had chosen.
Differences in capitalization of UI elements in the documentation and the
product itself went without notice or comment.

I can't say if our typographical conventions, though somewhat
unconventional, helped our users, but they didn't seem to detract from
their ability to complete a task. I'm tempted to generalize from our
limited findings that the typographical conventions we use aren't nearly
as important as we think they are. But additional user testing would be
required to bear that out.

One interesting point about procedures: We found that those users who did
use the manual to complete a task read only the first step or the first
two steps. After that, they closed the manual and tried to figure out the
rest of the steps on their own. That discovery led to some rather
far-reaching changes to our users guides and online help. But that's a
whole 'nother subject.

Laura Varteressian

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

NEED TO PUBLISH FRAMEMAKER CONTENT ONLINE? "Mustang" is a NEW single
sourcing tool for FrameMaker that lets you easily publish your content
online. No macro language required! http://www.ehelp.com/techwr-l3

Mercer University's online MS Program in Technical Communication Management:
Preparing leaders of tomorrow's technical communication organizations today.
See www.mercer.edu/mstco or write George Hayhoe at hayhoe_g -at- mercer -dot- edu -dot-

---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit
http://www.raycomm.com/techwhirl/ for more resources and info.



Previous by Author: RE: Best Practices in Indicating Versions
Next by Author: Test to identify the potential Instructional Designer
Previous by Thread: Re: techwr-l digest: July 13, 2003
Next by Thread: Latest WOW


What this post helpful? Share it with friends and colleagues:


Sponsored Ads