Button labels?

[Geoff Hart <ghart -at- videotron -dot- ca>]

Suzanne McKinney wondered: <<When I write interface documentation 
(describing buttons, fields, etc.) and procedural documentation, I have 
always been careful to match the interface as closely as possible. This 
includes capitalization and the like.>>

Good choice. Power users may well ignore mismatches and forge blindly 
ahead, but anyone who is the least bit secure about computer 
use--possibly the majority of some audiences--will notice the 
difference and possibly be completely derailed by it. I've seen _many_ 
otherwise intelligent adults give up in despair at equally simple 
roadblocks.

<<I am in an environment now where the developers can easily change the 
text case for labels and have not been very worried about deciding how 
they will be done for the upcoming release. So the test releases have 
varied.>>

One solution that works very well is to ask for permission to edit the 
button labels in a word processor; I used Word so as to take advantage 
of the revision tracking feature, but you can do the edits on paper 
printouts or in any other word processor that suits you. The trick is 
to pick an approach that reassures the developers that you won't be 
damaging anything; blind edits (without tracking) violate this 
principle.

Some programming environments (Delphi, for instance) store these text 
strings in an external resource file that you can edit directly. The 
only real problem is that the names are provided with no context: you 
don't always know what dialogs etc. they belong to. But that's why we 
use comments and questions, no?

Offering to help the developers come up with descriptive names and 
possibly even type the names for them also helps. If they like your 
suggestions enough, they may even invite you over to kibbitz over the 
user interface; many programmers hate developing interfaces, and have 
little or no formal training in it, and thus eagerly embrace the advice 
from someone who knows what they're talking about*. That's practical 
experience speaking, by the way, not just theory and "wouldn't it be 
nice".

* Of course, some program managers feel threatened when you demonstrate 
that you know more about UI design than they do. (Again, the voice of 
experience.) Approach with caution, and use all your strongest 
political skills.

<<Am I overreacting to expect them to choose a style so that my docs 
can match it?>>

No, you're not overreacting. And you can make your case easily enough 
with their manager by pointing out that the programmers surely have 
better things to do with their time than change a button name 20 times. 
Do it once (or once, plus a single revision), then spend the rest of 
their time developing software. You'd think that would be  a 
no-brainer, right?

<<Should I just document them all title case (as a friend suggested) 
and not worry about how they look in the interface?>>

No. Advocate strongly for a consistent user interface, and push the 
manager to avoid the wasted time spent constantly jiggering with button 
names. There's no reason not to do it right the first or second time.

--Geoff Hart   ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)


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

ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl

WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! http://www.webworks.com/techwr-l 

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -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.