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:Naming cells in a grid? (take II) From:Geoff Hart <ghart -at- videotron -dot- ca> To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Sun, 13 Mar 2005 16:02:44 -0500
Patrick Wright provided additional details: <<I have no control over
the application design--it's been in use and for sale for many years
now. It has a large number of usability problems as far as I can
tell.>>
While this is true, that doesn't mean you can't make suggestions. In my
experience, developers are usually willing to listen to polite and
reasonable suggestions for improvement more readily than outright
criticism.
<<Some notes follow--not trying to argue with you, but rather to
explain the situation more clearly>>
No worries. Hopefully we'll progressively get closer to an answer that
helps!
<<The application has over a hundred columns that the user can choose
to see--the application is for financial information, so columns
reflect either real or calculated pricing information. For each column,
there is a default name which is usually abbreviated--my guess is that
if the user adds it, it doesn't take up too much space by default.
Users can change column names to their liking.>>
This raises the problem of how you know what the column name is: if the
default name remains semi-constant, and the user can use that name to
access the data it contains, then you're best off referring to the
default name. If nothing remains constant, it's not clear to me how you
can document it other than "by example". For example, in a spreadsheet
cell that calculates a mean value, the label might be "Average" but the
function underlying the cell contents might be "mean(A1:A15)" or
something similar. In a case like that, you'd use the "Average" label
as an example of the use of the "mean" function.
<<The problem is the user will usually see the name as the application
defaults it. If this were a stock pricing application, then a stock's
closing price on the most recent day of trading might default to
"ClsPrcR" (honestly). So my question is how to deal with this--some
columns have default names that are pretty clear, others less so. On
the other hand, if I always refer to the conceptual name I'm not sure
if the reference (e.g. which column) will be clear.>>
Perhaps this is a case where the solution is to offer field-level help:
a tooltips/"What's this?" approach would be ideal, since no matter what
the user renames the cell, the underlying help ID remains constant.
This lets the user point at something they want to understand better
and instantly get the available help for that item. The popup should
make it very clear what topics to consult in the main online help; for
example, "See the help topic _Using the mean function_".
<<What I am not sure of is what the user is thinking in this case--I
have no contact with them, and not sure if the conceptual names given
to the UI have stuck or not. In my own experience, some of these names
are pushed by the software vendor but don't stick in the user
community.>>
If the software is as successful as you've reported, then the users
have learned to work with the names being promoted by the vendor. They
may immediately change these to more familiar terms, but they'll at
least know the names well enough that they can look for them and make
that change. That being the case, stick with what the users know: the
default names.
If there's a lookup table somewhere that lets users determine the
relationship between the original defaults and the current renamed
versions, making it easy to find that table would be a great help.
Doubly so if combined with one-click access to the online help for each
default.
WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo: http://www.webworks.com/techwr-l
Your Ad Here! Have a product or service you'd like to get some attention for? Use this space to get the word out! Contact lisa -at- techwr-l -dot- com for more details.
---
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- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.