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

List:       kde-look
Subject:    Re: Clipboard
From:       Dave Leigh <dave.leigh () cratchit ! org>
Date:       2002-08-07 21:33:35
[Download RAW message or body]

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]