Re: Effective Arguments for Unique Control Names...?

[pdenchfield -at- yahoo -dot- com]

Thank you all for your replies to my question on identical control names.
You have broadened my horizons immeasurably.

Some of you were (rightly, I think) puzzled by my suggestion to append
numbers to the names of each "C" control to differentiate them. Perhaps my
suggestion makes more sense when I tell you that the related A and B
control names were already appended with numbers. Therefore, "C1" would
affect "A1" and "C2" would affect "B2."

Some of you called me on the superior tone of my original
message?especially my implication that the user interface design team was
lacking judgment in their decisions and that I would "educate" them on the
impact to the documentation. I stand corrected. Thank you for mentioning
this issue. I can always use reminders to adjust my attitude.

Speaking of documentation impacts, many of you stated that I should
consider the user experience paramount, and adjust the documentation to
fit a usable design. I agree wholeheartedly with the spirit of this
statement, and I applaud the writers on this list for once again bringing
the focus back to the user. You all are great for keeping the focus where
it should be! Two howevers.

(1) Need/opportunity for user interface change. 

I beg to differ with the notion that a user interface with no problems in
training class doesn't need a change. Training class does not uncover all
erroneous interface designs. Look at usability testing?no trainers are
available. Users have to "figure it out" themselves. Sometimes a change in
the interface can actually assist in training. Sometimes a change wouldn't
even be noticed in training, but can facilitate documentation.

(2) Freedom of writing approaches. 

At my previous job for a start-up company, I *was* the technical
communications department. No translation was required. No other writers
had need for my work?there were no other writers! The user documentation
did not have to satisfy regulatory bodies. I had great freedom to write as
I wanted.

Today I work for a multi-national corporation that highly values module
design (software, user documentation, etc.) for re-use. We are
implementing a content management system in the technical communications
department to allow writers in other divisions world-wide to use and
translate published text. In this context, the phrase "maintenance issues"
takes on a whole new meaning. Translation (into 15+ languages!) and
potential re-use dictates highly structured content. For example, control
descriptions need to be written in a structured format. If I treat the "C"
control differently than the others (especially in the "control
descriptions" table), then I am making it harder for translators and other
writers to "lift" the text later on down the road.

Today my user documentation must satisfy FDA regulations and rules from
many other regulatory bodies. Unfortunately, these requirements mandate
that I broaden my writing goals beyond usability. I lose some freedom in
my approach toward instructing users.

Again, thank you all for your invaluable feedback. I've pondered your
thoughts in my off-time and will soon (if time still permits) approach the
user interface design team. I'll tell you what happens.

Note: I received a couple personal emails to which I will personally reply
as soon as I can wrestle the family computer away from the others at home.
(I cannot log onto my pdenchfield -at- yahoo -dot- com account here at work.)

Pamela Denchfield