[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: Clipboard
From:       "Brad Potts" <pbrad () cinci ! rr ! com>
Date:       2002-08-07 22:09:43
[Download RAW message or body]

Hey all,

I'm just wondering if I'm following this.  I'm new to this newsletter and
for the past week or so all I have been hearing is people arguing/discussing
about the "cut" and "paste" icons in KDE.  If so is this what we're all
really arguing about?????  Not trying to be a jerk or anything, this just
seems like an extended discussion about something so insignificant.  If this
isn't the discussion and I just came in the middle (and missed the
beginning) then don't mind me...

Respectfully,
Brad Potts


----- Original Message -----
From: "Dave Leigh" <dave.leigh@cratchit.org>
To: <kde-look@kde.org>
Sent: Wednesday, August 07, 2002 6:25 PM
Subject: Re: Clipboard


On Wednesday 07 August 2002 12:29, Aaron J. Seigo wrote:

> unfortunately, this is not about training and "significantly easier to
> explain" is, once again, your opinion of things. to know that we'd
actually
> have to get several people to explain the old and the new icons to others
> and observe their ability to do so. i'm sorry if i sound like an
> experimentation grouch, but ad-hoc and "my opinion" based usability
changes
> create changes, not improvements. =)

Changing the Cut icon and button layout is not a usability change. The
actions performed by the users are identical. Neither toolbar is inherently
more usable than the other (excepting the Klipper integration, of course).
The change of icon and position affect comprehension (and indirectly,
retention). Training is where the benefits lie.

An explainable system is the key toward making that functionality
understandable in the users' minds. That understanding is the key to proper
usage. I made the evaluation "significantly easier to explain" after having
actually done so to people I'd previously trained on the existing system. I
found that using similar training techniques (my own) the users'
comprehension of the same functionality was enhanced by the new icons and
layout. This is somewhat subjective, yes, but it's not opinion.

> > as to what it would show. I did do a little informal (and individual)
> > training and survey of my wife and three children (ages 15, 6, and 6)
> > tonight. Not at all scientific, but I did try to keep it objective. I
>
> interesting... thanks for taking the time to do this. just to clarify:
>
>  o you didn't use the words that actually appear in the menus/tooltips (at
> least initially) but words that you felt conveyed the meaning more
> appropriately?

Yes. I have no shame at all...I'll use whatever language will best get the
point across. This is simply effective instruction. When I was in the
military (in the 1980's) I was training NCO for my unit, and we referred to
this as "functionally oriented" training. Basically, you teach the user the
task to be accomplished, and don't get bogged down in semantics. In other
words, focus on what's *important*. When they understand the task you can
assign labels. This way language doesn't get in the way of learning the
task.
Other ways of expressing this are, "Teach the concepts, not the test," and
"Target understanding, not rote recitation."

Such techniques are terribly useful in an environment where a nut might be
called a "helical core hexagonal fastening unit-7/16 (1 ea)," or when you're
instructing someone who's first language isn't the same as yours. In my case
(electronics technician assigned alongside naval and RAF personnel) I worked
alongside people who used "valves" instead of tubes and hole theory instead
of electron theory, etc. The components didn't change because of the labels,
and neither did their function. Logic says the language matters little;
comprehension of the system matters a lot.

>  o what explanation occured prior to the identification questions? i
wasn't
> clear on exactly what was said (which is vital to understanding the
> results; not word-for-word, obviously, but the jist)

None, other than these were toolbar buttons. They were shown the new toolbar
and asked to identify the buttons. Then they were shown the old toolbar and
asked the same. Then I explained the new toolbar, asked them to identify the
functions of the buttons. After that I asked the survey questions, which
basically were, "which do you prefer, and why?" Then there was a bit of
give-and-take as I tried to clarify their meaning.

>  o did they identify the icons outside of an application, or were the
icons
> in actual use (e.g. on a toolbar)?
>  o were the icons shown in context of the menus?

They were shown the same illustrations that appeared in the post on this
list. I showed them each individually (using Pixie) and said this was a
proposed change to the toolbar.

>  o were they asked to perform tasks with them, or did this part of the
> study go straight to identification questions?

I did not create an icon theme, (no time!!) so they couldn't actually
perform
tasks with them. The identification questions consisted of, "What's this
button?" and "How do you use it?"

> > * Three thought the 'Move to Clipboard' action was better than 'Cut',
but
> > didn't have a problem with CALLING it 'Cut.' (I'm still trying to figure
> > that one out.) The other understood that it was the exactly the same as
> > 'Cut' * The same three thought that the 'Copy to Clipboard' icon was
more
> > understandable than Copy, even though it's exactly the same icon in a
new
> > position!
>
> this is perhaps the most interesting find of the whole study. "Move to
> Clipboard" should be much more learnable than "Cut". "Copy" would also
need
> to be changed to "Copy to Clipboard" and Paste => "Paste From Clipboard".
> the question would be whether or not users understand what this
"Clipboard"
> thingy is, but then they have even less hint given the curent and terse
> Cut/Copy/Paste (which gives little opportunity to learning what they are).
...

I thought so, too. However, I'm ambivalent about this. I don't think it's
necessary to change the labels if instruction is provided. They didn't have
any problem with the labels so long as they were  explained in a way that
matched the depictions on the icons.

The problem with NOT changing the labels is that only people who have had
some kind of formal instruction would have the benefit of the association.
Hmmm. As you suggest in another context below, can't we do both? What about
having something like the following in the menu:
Cut (Move to Clipboard)
Copy (Copy to Clipboard)
Paste (Insert from Clipboard)

BTW, here's one place where I think that the icons can be improved... as
they
are they look pretty static. I think it would be better to convey a sense of
motion toward the clipboard, if it's possible. I'll leave that to someone
with time and talent to do the artwork, though.

> > * All preferred the paper-as-indicator on the Clipboard icon, which is
> > one part I thought would cause problems. They liked it better than
> > greying the icon out,
>
> "liked it better" or "used it and performed better"? liking is irrelevant,
> performance is everything (people are bad at juding peformance results
> based on personal preferences). this would need to be tested in a toolbar
> with some items greyed (as per the *styleguide*) with this one being an
> exception.

Liking is not irrelevent. As you've noted yourself, users will change their
own environment, often using settings that are not what you would call
optimal. If it turns out that the vast majority of users like the
sub-optimal
settings better, then it's usage and performance that lack relevance,
counter-intuitive as that sounds. When we converted an entire company from
OS/2 to Windows95 we knew that OS/2 was better in nearly every respect.
However, they liked Windows95 better. It doesn't sound reasonable, I know,
but if Fortune 500 companies are willing to make decisions based on this,
you
can't really believe that home users are going to give it more than a
passing
thought. They'll simply use what they like. In THIS case, "used it and
performed better" doesn't mean much anyway. It's simply a status indicator.
The same status is conveyed whether it's greyed out or toggles the paper.
This is purely a 'preference thing.'

> exceptions == inconsistencies, yadda yadda
>
> but there is no reason we couldn't combine both: a greyed out paperless
> clipboard when there is nothing to paste, and a coloured papared clipboard
> when there is. this should give us the clarity of metaphore without
> breaking consistency. the only challenge there might be accomplishing it
> programmatically, as it would require changing the icon at the right time
> as opposed to simply marking it as "innactive". this may not be feasable
> given how it currently works?

Actually, my personal inclination is to ignore the users' preference and
say,
"Yeah, it looks cool, but it's not the way icons work." After all, as I said
above, it conveys no new information. So at this point I'm going to be the
one to ask if the benefit outweighs the effort of doing it. (I don't think
there really is a cost to the users.)

--
Dave Leigh, Consulting Systems Analyst
Cratchit.org
  http://www.cratchit.org
  864-427-7008 (direct)
  AIM or Yahoo!: leighdf
  MSN: leighdf29379@hotmail.com
  ICQ: 37839381

The first myth of management is that it exists.  The second myth of
management is that success equals skill.
-- Robert Heller



[prev in list] [next in list] [prev in thread] [next in thread]