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

List:       kde-look
Subject:    Re: Clipboard
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-08-05 20:25:50
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 05 August 2002 08:31, Steven D'Aprano wrote:
> On Mon,  5 Aug 2002 04:23, Matt Perry wrote:
> > In the sole intrest of usability, I would personally have a problem
> > with the changed cut/copy/paste icons -- instead of changing the
> > standard icons, (if the application supports it) you should turn on
> > the "Icon + Text" toolbar setting.
>
> This isn't in the interest of *usability* at all, because most of us on
> this list agree that the traditional scissors/two sheets of
> paper/clipboard with paper icons are bad choices for icons. Their
> meaning must be learnt, and isn't obvious.

unfortunately the people on this list don't matter squat. the general user 
populace does. and that populace has already spent time doing the learning 
you speak to. 

i'd love to see the relative learnability difference between the current icons 
(esp the Scissors == cut) and the newly proposed ones. read further for why 
this is the key point.

> I think it is important to realise that consistancy only goes so far.
> Icons are not identical from OS to OS, or from application to
> application, or even between two versions of the same application. What
> is important is the over-all consistancy, not getting bogged down into
> exact pixel-to-pixel correspondence.

you are correct that pixel-to-pixel correspondence isn't important, but 
keeping the metaphores is worth it due to time invested in learning those 
metaphores. icons SHOULD use the same metaphores between OSes (imagine how it 
would ease transitioning from one environment to another and back again! 
imagine the lowered training costs!) and the icons damn well better be the 
same between two applications built on the same application framework.

now, good metaphore should not be, as you stated, sacrificed wholesale for 
religious adherence to consistency. but consistency should not be needlessly 
sacrificed in search of a marginally better metaphore, either.

> The rule "consistancy is good" has a hidden assumption: it assumes that
> the interface is good in the first place. A bad GUI doesn't
> automatically become good just because it is consistant.

there is no such assumption. rather, consistency is one aspect of a good UI. a 
UI w/out consistency is bad, but give a bad UI consitency it become "less 
bad" because it is now learnable. the time to learnability may still be too 
high, however, along with any number of other usability constraints.

> > Changing the cut/copy/paste icon is like changing the shape and size
> > of a Stop sign... you just can't do it.
>
> Of course you can. There is nothing intrinsic about a red octagon that
> means "stop". It is a learnt response, and what is learnt can be
> unlearnt.

no, you can't. because the moment you did that you'd have people whizzing 
through 3- and 4-way stops and causing accidents. you'd have to retrain the 
whole driving populace (which, given the nature of the change would take 
years...) ergo, in practicallity you CAN'T change the "red octagon means 
stop" paradigm

> (1) I would never use KDE again if the icons changed, no matter how
> good KDE was in every other feature.
>
> (2) KDE would have to be amazingly good for me to accept the new icons.
>
> (3) So long as KDE was reasonably good, I would accept three slightly
> different icons compared to other GUIs.
>
> (4) I love KDE so much that I'm prepared to put up with a few minor
> differences in the icons compared to other GUIs.
>
> (5) KDE with the new icons rock, the old icons suck.

these all miss the point. the answer is:

6) Changing these icons forces me relearn the interface, rendering it 
uncomfortable for me. I now spend several frustrating seconds search for what 
used to be automatic for me. I may or may not stay with KDE depending on how 
jarring and uncofmortable this experience becomes.

ergo, to change these icons one would need to show a clear and obvious 
improvement in the average time to learn the meaning of these icons before 
you can risk throwing out the millions of hours spent learning the meaning of 
the previous icons.

if you can put your new icons in front of a person and they learn them an 
order of magnitude faster than the current ones, then it could possibly be 
worth it. otherwise the trade off for "slightly more clear to those of us 
examining the inner meaning of the symbols" is too high.

for most people all icons are symbolic and must be learnt. asking them to 
relearn the metaphores is a great disservice.

> I do have a point in this little bit of history. Toolbars are here to
> stay. I use them myself, even though they are less efficient, because
> they look cool, and they aren't so terribly inefficient. But changing

actually, they are more efficient than most other elements when used with the 
guidelines you offered: action oriented, used for the most often accessed 
items, and with consistent and learnable icons.

> the icon in a toolbar isn't a critical change like changing "Open" to
> "Read file", or rearranging the Edit menu. Its a comparitively minor

actually, it is nearly identical. both changes render learned behaviour 
worthless and causes the user to have to relearn things. words are just 
symbols, as icons are. in fact, words are sometimes easier to change as even 
the abstract words usually have commonly agreed upon deffinitions.

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

"Everything should be made as simple as possible, but not simpler"
    - Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9Tt9O1rcusafx20MRArm0AKCsaxTt/fz829x01RLFSD1dR74VdQCePRDm
kWFMDux5REKJVqDj0QYeZ1s=
=yydV
-----END PGP SIGNATURE-----

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