Laptop diary tool in REV - Glyphs
rcozens at pon.net
Mon Jun 19 09:57:11 CDT 2006
I don't expect to change your opinion, and I have not read a response
to this thread that would cause me to change mine; but for the sake of
>> what better method is available to present the UI in a manner that
>> those who don't speak the language of the programer may understand?
> But this can all too easily result in presenting the UI in a manner
> that no-one <except> the programmer understands, and even the
> programmer may have trouble if she's hasn't looked at it for a while.
> OK, a picture of a train with an arrow will suggest to anyone who
> knows what a train is that the station is that-away, but many of the
> routine actions we perform with computers are not so easily
> represented by a simple 16X16 picture - all anglophones tend to agree
> on what 'separate' means, but should the zipper icon mentioned in my
> previous post be open or closed?
That's why we have tooltips and reference manuals...and some of us
display on-screen contextual help at each step in a process. I suggest
that once the user understands the meaning of an icon within a specific
application, she/he will recognize that icon in subsequent windows in
the application more quickly than identifying a string of text.
How many of the icons on a Rev (or PhotoShop or whatever) palette or
menuBar did you understand the first time you looked at the app? Want
to picture a palette where all choices are text...in German? (Sorry
to be stereotypic, but when I think of translations that expand the
number of characters, German comes to mind)
And what do you do when you have a one-character column whose title is
15 characters? Do you give up 14 characters of table space and display
the full heading; or do you abbreviate the label or use a shorter, but
slightly different, word? Once you start abbreviating or substituting
a word with a slightly different meaning when adding support for a new
language, you have no more uniformity of understanding than you would
have with icons.
>> And using icons as label fields and column headings has a MAJOR
>> advantage over text: they remain the same size regardless of the the
>> language. So if one is translating an application from French to
>> German, for example, one need not be concerned whether the German
>> label text takes up more field space than the same text in French.
> The major advantage is only to the programmer - not a good substitute
> for proper internationalization. And tool-tips, though they have their
> uses, really don't cut it - if the user can't fathom what what the
> un-captioned little pictures mean (either because of cultural
> differences, or because of poor choices by the programmer), then she
> has to hover her mouse over each icon until she finds the one she
> wants. Captions, in the users own language, are incomparably better.
If an application can be modified and translated into other languages
more quickly, and maintained in a single source code, I say the user
benefits as much or more than the programmer. Not only will
upgrades, fixes, and support for new languages come more quickly, but
less (or no) programming time and expense is spent in duplicating the
same logic in different sized fields for different languages. And
often, depending on the data displayed, one can use one screen shot for
documentation in all languages the app supports.
> It seems to me that pictures are great where one can assume a shared
> frame of reference (nearly everyone knows about trains, and trains
> tend to look quite alike everywhere), but when striving for clarity in
> a UI, I think it's essential to remember that humans tend to use
> language, far more than anything else, for the purpose of
> communicating information effectively.
I think you underestimate the importance of non-textual communication,
and that recent List discussions re the difficulty of understanding
another person's intention or meaning based on text alone bear that
out. In my early programming career I worked with text--and nothing
but text. FORTRAN, PL/1, and other early languages had no support for
images, sounds (beyond beep), animations or color. Since my first
experience with HyperCard, my quest has been to find ways to engage the
user via as many of his/her senses I can reach as a programmer.
> Why abandon language, when it's so much more clear and efficient than
> just about anything else?
One does not abandon language by replacing label text with
icons...especially if the icons have toolTips. In essence, the textual
labels become toolTips; so the icons add to the total experience, not
CCW, Serendipity Software Company
"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631)
More information about the use-livecode