"Intuitive designs" can be cumbersome

23 Aug 2004 - 3:04pm
9 years ago
25 replies
782 reads
Eugene Chen
2004

> From: Mike Beltzner [mailto:mike at beltzner.ca]
>
> In my experience, it's best to design primary interaction paths for
> beginners, and then convince management that you can build a loyal
> market by adding secondary (accelerator) interaction paths that speed
> up someone's interaction with the product. Point to examples like
> Ctrl+V ... everyone knows it means paste, but the primary way of
> getting to paste is Edit > Paste. Still, nobody would buy a product
> that doesn't support the secondary method, too.

I think this is a really good point. We need to point to the business
benefit of both initial-user-learnability and frequent-user-efficiency.

We seem to have won some battles in convincing business of the first goal. I
think part of the problem is the difficulty in running longitudinal
usability tests that would prove out the second goal. Most usability
techniques in practice are heavily biased towards intuitability and
first-impressions. Important, to be sure, but not the whole picture.

For instance, I've recently proposed some fairly tricky designs for my
current project that I *think* could provide high (to some level) efficiency
for some number (hopefully substantial) of users who eventually (not too
long I hope) would discover it. But I'm scared to death that they won't make
it past the usability test. As a matter of fact, I'm quite sure they
wouldn't be discovered in a normal usability test, even with some training
protocol.

Throughout this project I've been noticing my own use of Outlook and
basically I learn a new feature almost every day (sometimes deliberately,
sometimes by accident). I expect this to go on for many more months.

So one question is how designers of complex apps can gather any reliable
data on
how-many-users-take-how-much-advantage-of-feature-x-in-what-period-of-us
e? This seems really to rub against the grain of rapid iteration.

cheers,
Eugene

Eugene Chen * UI Design Contractor
User Experience & Design, eBay inc.

Comments

24 Aug 2004 - 1:15pm
Jef Raskin
2004

Cut-and-paste has neither initial-user-learnabilty nor
frequent-user-efficiency, however it is invoked. All it has in its
favor is familiarity. Because we are wedded to familiarity, we have
kept with horses-and-buggies for transportation, and the automobile was
a short-lived failure. But that didn't happen. Why? Because cars were
more convenient and faster. Familiarity is not sufficient justification
for sticking to old ways.

A "move" command is at least as easy to learn as cut-and-paste, is more
efficient because it does not have the risk of losing the "cut" item,
as happens occasionally to nearly every user of conventional systems. I
am sure that the correspondents quoted below have had this happen to
them, and to their annoyance.

Too often interface designers, as in this excerpt, discuss a popular,
but badly-designed and troublesome method instead of noting and giving
due consideration to problems that they know users have with it. They
are not asking the right question: what's the best way to move a chunk
of text (or some other object). They are not serving their users well.

>> Point to examples like
>> Ctrl+V ... everyone knows it means paste, but the primary way of
>> getting to paste is Edit > Paste. Still, nobody would buy a product
>> that doesn't support the secondary method, too.
>
> I think this is a really good point. We need to point to the business
> benefit of both initial-user-learnability and frequent-user-efficiency.
>

I would have said,

But we can gain a competitive advantage by switching to a "move or
copy" interface, pointing out to our customers that no longer do they
have to worry about losing stuff when they just want to move it.

24 Aug 2004 - 7:55pm
Jonathan Korman
2004

:: Mike Beltzner observes:
:: it's best to design primary interaction paths for beginners ...
:: adding secondary (accelerator) interaction paths that
:: speed up someone's interaction with the product

I would say this is often true, but not always. There are many exceptions!

There are quite a few situations at the opposite extreme. There are professional desktop applications which take up 75% of a worker's time day in and day out. There are control panels for complex industrial processes that already require months of training to learn to do anyway. For those cases interaction paths for beginners are nearly irrelevant.

Many more cases lie somewhere in-between. You need to be able to do something right away, but are willing to invest in developing greater proficiency. Many common productivity applications, like email and word processing, fall into this category. In these cases the primary design target should be the skilled, or perpetually-intermediate, user. Secondary paths can support people who are starting to figure out the system on their own.

It depends upon the context, most significantly what user population you intend to reach.

: Eugene Chen adds:
:
: I think part of the problem is the difficulty in running longitudinal
: usability tests that would prove out the [frequent-user-efficiency]
: goal. Most usability techniques in practice are heavily biased
: towards intuitability and first-impressions. Important, to be sure,
: but not the whole picture.

This depends upon where you stand in the field. The studio I work for has been rooted more in desktop and enterprise apps, authoring tools, and medical/scientific/consumer electronics --- meaning that we have been much less focused on first-time-use, much more on long-term-use. So the techniques we use are well-developed for that purpose: deep user needs research, exercises in articulating users' mental models, construction of well-articulated usage scenarios, and so on.

As you say, usability testing doesn't help much with these kinds of problems, which is why we don't do much of it. Typically in the course of this kind of design, we will identify specific questions that we cannot answer analytically --- many if not most of them concerned with first-time use, which is very difficult to second-guess and very responsive to usability testing --- and mark those for resolution through usability testing. But most of our design work is done through analytical consideration of usage scenarios without direct involvement by users, who cannot predict their long-term use.

: Eugene Chen asks further:
:
: how [can] designers of complex apps ... gather any reliable data
: on how-many-users-take-how-much-advantage-of-feature-x-in-
: what-period-of-use?

I think that's the wrong way to ask the question. The more complex the application, the harder it is to decompose it into individual features. It becomes important to think of the application as a coherent system.

It's not "how many people are using this feature?"

It's "who needs what set of functions working together in what way"?

: Then Eugene Chen suggests:
:
: This seems really to rub against the grain of rapid iteration.

Indeed it does. Rapid iteration, in the sense I read it in that comment, is very good in cases where either features are decomposable from one another, or immediate user feedback is useful, or (ideally) both. There are many cases in which that is true.

But complex applications that skilled users will employ for a long time are coherent, rather than decomposable, and do not benefit much from immediate user feedback. In those cases, interaction designers need to take more responsibility for good judgement, without the corroboration of usability testing or joint design reviews. To do that, interaction designers need the support of good initial user needs research, including ethnographic-style observation and interviews, and also need good skills in rigorous design exercises.

Jonathan Korman
Cooper | humanizing technology
www.cooper.com

26 Aug 2004 - 2:46pm
Andrei Herasimchuk
2004

On Aug 24, 2004, at 11:15 AM, Jef Raskin wrote:

> Cut-and-paste has neither initial-user-learnabilty nor
> frequent-user-efficiency, however it is invoked. All it has in its
> favor is familiarity. Because we are wedded to familiarity, we have
> kept with horses-and-buggies for transportation, and the automobile
> was a short-lived failure. But that didn't happen. Why? Because cars
> were more convenient and faster. Familiarity is not sufficient
> justification for sticking to old ways.

"Initial-user-learnabilty" is a jargon term often used to disguise an
opinion used in meetings to push one's own design politics. Too many
people in both the design and usability camps toss outs terms like this
much too often these days. In the end, these terms tend to mean very
little. And to claim cut and paste lacks frequent-user-efficiency,
whatever the hell that means, seems like a dubious claim at best.

> A "move" command is at least as easy to learn as cut-and-paste, is
> more efficient because it does not have the risk of losing the "cut"
> item, as happens occasionally to nearly every user of conventional
> systems. I am sure that the correspondents quoted below have had this
> happen to them, and to their annoyance.

That a move command does not have one of the risks of cut does not make
it more efficient. It just means it has different strengths which might
be better suited for certain tasks or users. The fact you stated that
one encounters this risk "occasionally" also weakens the claim that
move is more efficient because it lacks that risk.

> Too often interface designers, as in this excerpt, discuss a popular,
> but badly-designed and troublesome method instead of noting and giving
> due consideration to problems that they know users have with it. They
> are not asking the right question: what's the best way to move a chunk
> of text (or some other object). They are not serving their users well.

Got it that you think cut-and-paste is badly designed and troublesome.
Got it that you think designers are not asking the right quetions. That
doesn't make cut-and-paste badly designed and troublesome. And it
doesn't mean designers aren't asking the right questions. In fact, when
most designers do push outside of what is familiar, trying to add new
tools that might prove useful, they are usually shot down by "experts"
like Nielsen telling them to do what is familiar.

That being said, it sounds like all you are suggesting is the interface
design world add a "Move" command into the cluster of Cut, Copy and
Paste standard bearers. Another tool for the arsenal that in due time
might make users happier if they find Move works more often for what
they want to do than Cut and Paste.

There, that wasn't so hard.

Once the design and usability community, and especially "leaders" like
yourself Jef, stop using jargon words, stop talking around the issues
no matter how large or small, stop talking cross-purposes and start
saying what they mean in simple, clean language that anyone can
understand, we'll all see a design renaissance in high-tech field like
America saw in the mind 1900s in graphic, industrial and automotive
design.

Andrei

26 Aug 2004 - 3:16pm
Gerard Torenvliet
2004

Andrei:

Let's give Jef a fair shake here. What he is driving at is actually quite deep, and goes far beyond the cut, copy, paste, and move activities. These may look like rants, but that's becuase it is easiest to view's Jef's ideas from our current paradigm (or what we have learned to find intuitive).

Jef has done lots of work suggesting new paradigms. He probably won't go plugging his book "The Humane Interface" here, so I'll do that for him. I highly suggest reading this book - you may not agree with what he says, but in it he operationalises the entire idea of working toward the simple, and not necessarily the currently familiar.

Highly recommended for stretching your mind.

Regards,
-Gerard

:: Gerard Torenvliet / gerard.torenvliet at cmcelectronics.ca
:: Human Factors Engineering Design Specialist
:: CMC Electronics Inc.
::
:: Ph - 613 592 7400 x 2613
:: Fx - 613 592 7432
::
:: 415 Legget Drive, P.O. Box 13330
:: Ottawa, Ontario, CANADA, K2K 2B2
:: http://www.cmcelectronics.ca

-----Original Message-----
From: Andrei Herasimchuk [mailto:andrei at designbyfire.com]
Sent: August 26, 2004 3:46 PM
To: Interaction Discussion
Subject: Re: [ID Discuss] "Intuitive designs" can be cumbersome

On Aug 24, 2004, at 11:15 AM, Jef Raskin wrote:

> Cut-and-paste has neither initial-user-learnabilty nor
> frequent-user-efficiency, however it is invoked. All it has in its
> favor is familiarity. Because we are wedded to familiarity, we have
> kept with horses-and-buggies for transportation, and the automobile
> was a short-lived failure. But that didn't happen. Why? Because cars
> were more convenient and faster. Familiarity is not sufficient
> justification for sticking to old ways.

"Initial-user-learnabilty" is a jargon term often used to disguise an
opinion used in meetings to push one's own design politics. Too many
people in both the design and usability camps toss outs terms like this
much too often these days. In the end, these terms tend to mean very
little. And to claim cut and paste lacks frequent-user-efficiency,
whatever the hell that means, seems like a dubious claim at best.

> A "move" command is at least as easy to learn as cut-and-paste, is
> more efficient because it does not have the risk of losing the "cut"
> item, as happens occasionally to nearly every user of conventional
> systems. I am sure that the correspondents quoted below have had this
> happen to them, and to their annoyance.

That a move command does not have one of the risks of cut does not make
it more efficient. It just means it has different strengths which might
be better suited for certain tasks or users. The fact you stated that
one encounters this risk "occasionally" also weakens the claim that
move is more efficient because it lacks that risk.

> Too often interface designers, as in this excerpt, discuss a popular,
> but badly-designed and troublesome method instead of noting and giving
> due consideration to problems that they know users have with it. They
> are not asking the right question: what's the best way to move a chunk
> of text (or some other object). They are not serving their users well.

Got it that you think cut-and-paste is badly designed and troublesome.
Got it that you think designers are not asking the right quetions. That
doesn't make cut-and-paste badly designed and troublesome. And it
doesn't mean designers aren't asking the right questions. In fact, when
most designers do push outside of what is familiar, trying to add new
tools that might prove useful, they are usually shot down by "experts"
like Nielsen telling them to do what is familiar.

That being said, it sounds like all you are suggesting is the interface
design world add a "Move" command into the cluster of Cut, Copy and
Paste standard bearers. Another tool for the arsenal that in due time
might make users happier if they find Move works more often for what
they want to do than Cut and Paste.

There, that wasn't so hard.

Once the design and usability community, and especially "leaders" like
yourself Jef, stop using jargon words, stop talking around the issues
no matter how large or small, stop talking cross-purposes and start
saying what they mean in simple, clean language that anyone can
understand, we'll all see a design renaissance in high-tech field like
America saw in the mind 1900s in graphic, industrial and automotive
design.

Andrei

_______________________________________________
Interaction Design Discussion List
discuss at ixdg.org
--
to change your options (unsubscribe or set digest): http://discuss.ixdg.org/
--
Questions: lists at ixdg.org
--
Announcement Online List (discussion list members get announcements already)
http://subscribe-announce.ixdg.org/
--
http://ixdg.org/

26 Aug 2004 - 3:51pm
sandeepblues
2003

I had originally started this thread. "Familiar is
mediocre and unprogressive" is another way to put the
same subject.

Unforunately, I feel like waving a white flag here -

The demand for minor changes in familiar user
interfaces will always be met with resistance from
both product managers, as well as users. If you were
to design an expert interface, or if there were a
"paradigm" shift (such as from commands to WIMP), then
one can hope for inserting such incremental
improvements that are unfamiliar.

Note that WIMP was successful because it used a
desktop metaphor- a familiar metaphor.

Why aren't pie menus common-place? How freaked would a
user be to see that? Perhaps not in Alias|Wavefront's
Maya (which is an expert UI), or other vertical
applications.

On another note re. the "move" command -

Take the example of doing a cut-and-paste in a long
Word document.

Let's say that I did a cut.

Then, I scrolled a few window lengths down, and was
looking for a place to paste the clipped info. Now,
someone walks into my cubicle, and distracts me for
the next 3 minutes. When I get back to work, I start
looking for the place to paste, and by reflex, I see a
spelling error. So, I happen to select stuff and fix
the spelling. And then, I paste. This works.

Now, if one were to use Move...would this work? Would
we set markers, where the user first selects the text,
then marks it as candidate for a move, and then, does
a move at some point? There would be a "Mark Move",
"Move", "Copy", and "Paste"? Seems like more stuff to
deal with, and "Mark Move" is not term from everyday
life....like cut and paste are.

Losing info problem. Isn't that what Undo is for?

Sandeep

26 Aug 2004 - 4:15pm
Peter Bagnall
2003

> "Initial-user-learnabilty" is a jargon term often used to disguise an
> opinion used in meetings to push one's own design politics. Too many
> people in both the design and usability camps toss outs terms like
> this much too often these days. In the end, these terms tend to mean
> very little. And to claim cut and paste lacks
> frequent-user-efficiency, whatever the hell that means, seems like a
> dubious claim at best.

I've been working with a fair number of non computer users recently,
and what I've found very interesting, is how design choices which seem
obvious and intuitive to typical computer users are completely baffling
to people with no computer experience. I should emphasise that when I
say no computer experience I mean it literally. These are mostly people
around 75 years old, who's tolerance for learning new things is also
pretty low.

That's pushed me very hard to re-examine what is obvious, and the
conclusion I'm moving towards is that really nothing is obvious without
prior experience. But there is a huge difference in learn-ability.
Designs which use concepts that are familiar are accepted much more
rapidly than those which are more abstract. Often though the more
abstract concepts are more powerful.

I'm also finding that tolerance for hidden functionality, by which I
mean things which aren't immediately visible on the screen is very low
indeed.

Of course I'm working with a set of people who's needs are extreme, but
I think some of the lessons generalise.

So in terms of "initial-user-learnability" - it does have very great
relevance, but there is no one design that is most learnable for all
users. Learnability depends largely on how well the design matches the
person using it, and if you fail to take that into account, I'd agree
that is can be used to push personal biases. But then any argument
without accurate data to back it up can be used the same way - but then
it's just propaganda. Learnability can be measured too - most simply
you measure how long it takes someone to learn to do a certain task. Or
you can measure how long it takes to train someone to do a task. There
are undoubtably better metrics, but those are some simple ones.

As for frequent user efficiency - to me it seems clear that Ctrl-X is
more efficient than Edit -> Cut (to pick a pretty trivial example). But
from what I've seen with older users almost all of them use Edit -> Cut
(that is, those that use cut and paste at all, which is a minority,
most just retype instead, cut and paste is most definately not
obvious). For them the effort of remembering Ctrl-X is greater than the
value of the time lost using the less efficient route. Why? Partly it's
because learning is harder as you get older, but it's also partly to do
with practise. They just don't use computers as much, so they forget
things between sessions. That's why interfaces for frequent users are
different to those for occasional users.

Interestingly, I've also been working with kids from 11-16 recently.
They seem to have similar issues with learnability - but not with
forgetting between sessions. The learn the tricks for frequent users
much faster - but they still have to be shown them - they don't seem to
find them obvious.

--Pete
------------------------------------------------------------------------
------
Blood stains cannot be removed by more blood; resentment cannot
be removed by more resentment; resentment can be removed
only by forgetting it."
Buddha

Peter Bagnall - http://www.surfaceeffect.com/

26 Aug 2004 - 5:06pm
Robert Reimann
2003

Sandeep said:

> The demand for minor changes in familiar user
> interfaces will always be met with resistance from
> both product managers, as well as users.

Changes to anything in a product that risks schedule or
cost is likely to be met with resistance from product
managers.

As far as users are concerned, they will resist random
changes of little perceivable benefit (or negative
benefit). Unfortunately most users have been trained by
poor product design and development practices to assume
that any change will be random, and of little or negative
benefit, because that is the typical experience.

However, if users are confronted with a change that results
in obvious and considerable benefit, they will by and large
embrace that change.

> Note that WIMP was successful because it used a
> desktop metaphor- a familiar metaphor.

Metaphor is a terribly overused and misused term in
interaction design. The computer "desktop" interface in reality
bears little resemblance to a real world desktop. Most
user interfaces are far more *idiomatic* than metaphorical.
You need to learn them, and they become "familiar" only
after repeated exposure and use. This means that users will
have an strong investment in what they have already learned.
It will take something significantly better for them
to abandon what they know for something new. Different users
in different contexts have different thresholds for making
this jump.

To revisit Jef's analogy, the automobile was significantly better
than the horse and buggy -- eventually! The first autos were more
dangerous, prone to breakdowns, difficult to start and operate,
dirty, expensive to own, and a noisier than your average Clydesdale.
It took about 30 years for them to get good enough to really catch on.
But once they crossed that threshold of usability (and economy), the
buggy-whip vendors were toast.

WIMP works pretty well for most desktop productivity applications.
You don't see many alternatives because they haven't crossed the
threshold of being so much better that most users forsake what they
already know well. But someday a new set of idioms may come along
that are so much better that many of us will leave our windows and menus
behind. I think it might be a while, though.

In the meantime, what do we do? I believe that interaction design
can (and does) make an enormous difference not necessarily by redesigning
widgets or by focusing on abstract ideas of learnability or efficiency,
but rather by holistically crafting the total behavior of products to
better meet real goals of real humans in real contexts, using whatever
toolsets are at our disposal. Of course there is plenty of room for
innovation at the widget/action level, but it's the level at which
widgets/actions are assembled together into larger frameworks of behavior
and structure that the real leverage resides to provide great user
experiences.

Robert.

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Sandeep Jain
Sent: Thursday, August 26, 2004 4:51 PM
To: Interaction Discussion
Subject: Re: [ID Discuss] "Intuitive designs" can be cumbersome

I had originally started this thread. "Familiar is
mediocre and unprogressive" is another way to put the
same subject.

Unforunately, I feel like waving a white flag here -

The demand for minor changes in familiar user
interfaces will always be met with resistance from
both product managers, as well as users. If you were
to design an expert interface, or if there were a
"paradigm" shift (such as from commands to WIMP), then
one can hope for inserting such incremental
improvements that are unfamiliar.

Note that WIMP was successful because it used a
desktop metaphor- a familiar metaphor.

Why aren't pie menus common-place? How freaked would a
user be to see that? Perhaps not in Alias|Wavefront's
Maya (which is an expert UI), or other vertical
applications.

On another note re. the "move" command -

Take the example of doing a cut-and-paste in a long
Word document.

Let's say that I did a cut.

Then, I scrolled a few window lengths down, and was
looking for a place to paste the clipped info. Now,
someone walks into my cubicle, and distracts me for
the next 3 minutes. When I get back to work, I start
looking for the place to paste, and by reflex, I see a
spelling error. So, I happen to select stuff and fix
the spelling. And then, I paste. This works.

Now, if one were to use Move...would this work? Would
we set markers, where the user first selects the text,
then marks it as candidate for a move, and then, does
a move at some point? There would be a "Mark Move",
"Move", "Copy", and "Paste"? Seems like more stuff to
deal with, and "Mark Move" is not term from everyday life....like cut and
paste are.

Losing info problem. Isn't that what Undo is for?

Sandeep
_______________________________________________
Interaction Design Discussion List
discuss at ixdg.org
--
to change your options (unsubscribe or set digest): http://discuss.ixdg.org/
--
Questions: lists at ixdg.org
--
Announcement Online List (discussion list members get announcements already)
http://subscribe-announce.ixdg.org/
--
http://ixdg.org/

27 Aug 2004 - 5:09pm
hans samuelson
2003

The question of what is 'intuitive' is particularly juicy. There is
some interesting work right now on the 'Whorf hypothesis' that language
fundamentally shapes thought - see, for example,

http://www.newscientist.com/news/news.jsp?id=ns99996303

which describes a tribe whose members have an extremely limited
comprehension of numbers... On the order of "one, two, a whole
bunch".... This suggests to me that they might have some trouble with,
say, drop-down menus, unless you get them hooked on GameBoys at some
young and impressionable age. Nature versus nurture versus age versus
beauty. In my humble opinion, there's not much that's intuitive in a
computer, though the power buttons used to be red once upon a time.

Speaking of language, I can't help but notice that things are getting a
little snippy around the sloppy use of English by people who might be
expected to know better. Admittedly, penalty points should be deducted
for the excessive use of hyphens (horse-and-buggy is fine,
cut-and-paste is unavoidable, but initial-user-learnability does not
really benefit from the extra characters), and for the sloppy use of
the term 'metaphor' (see

Language is a beautiful thing, and a big part of what any designer does
these days, especially those of us who worship the Great Whirring Beige
Box. So read more Mark Twain and George Orwell, and remember that less
(syllables, that is, and hyphens too) is more.

27 Aug 2004 - 6:07pm
hans samuelson
2003

To complete the incomplete part of my previous post (sorry for the
itchy trigger finger): FWIW, there's a doctoral disseration on the
question of metaphor in interface design online at

http://www.redwines.btinternet.co.uk/chris/phd.html

which will provide probably more than anyone wants to know about that
particular debate!

To move back into the world of hyphens for a minute, cut-and-paste is
an interesting metaphor in and of itself. One of the hard things to
explain to novices is that you are 'cutting' from an infinite
computational 'stuff' which can be 'pasted' infinitely and at will
without ever diminishing the original stock. There is nothing
intuitive about an infinite and never-depleted material, and why should
there be? Nor does the idea of a 'move' actually address the
fundamental novelty of this operation, since one of the main advantages
of pasting is the ability to reuse the originally 'cut' element a
number of times, a feature which the idea of a 'move' does not suggest,
at least in my own cognitive and linguistic processes!

The 'clipboard' is an image which has certain advantages; the idea of
being able to take clippings, store them, move them around, copy them,
and retain a trace on a 'board' has lots of appeal. Perhaps one could
make a 'clipboard' which would behave something like the 'history'
feature in a Web browser—storing a record of the last few items
'cut'—which could then be retrieved should an accident or distraction
intervene. This could be better than a straight 'undo,' since the
'undo' feature often requires that many operations be eliminated in
order to return to the earlier state. Some of those operations might
not be things you actually want to undo...

My five cents (inflation, you know),

Hans Samuelson

28 Aug 2004 - 5:38am
Peter Bagnall
2003

> Perhaps one could make a 'clipboard' which would behave something like
> the 'history' feature in a Web browser—storing a record of the last
> few items 'cut'—which could then be retrieved should an accident or
> distraction intervene.

MS Office actually does allow a clipping history now, although IMO the
implementation is rather clunky. It uses a side bar to show the
clippings, but it is a little hard to find.

Emacs has also done this for years - but in a way which is very
definitely aimed at frequent users! It uses Ctrl-Y to yank (paste) and
then Meta-Y to cycle through the kill-ring (cut history). Fast once you
know, but harder to learn that the MS solution for "normal" people. The
interesting thing about the implementation though is that the first
Ctrl-Y does paste, so it optimised for the common case. Meta-Y then
removes the latest paste and replaces it with an older cut, which might
be slightly confusing, but it is quick!

The most interesting clipboard solution I've seen recently though has
to be Spike from Porchdog software. It allows networked clipboards so
you can cut on one machine and paste on another - very useful for
sharing clippings in the office or if you use more than one computer.
Again, it's a little clunkier that I might like, but it's useful.

http://www.porchdogsoft.com/products/spike/

As for move - the select and drag version of move seems to be fairly
widely implemented now, but from what I've seen it's not used as much
as cut and paste. Possibly because it's harder to discover, but I don't
have any evidence for that, I'm just guessing.

Cheers
--Pete

28 Aug 2004 - 1:11pm
hans samuelson
2003

> [JR] The presently available spec is fine for seeing why Move and Copy
> are quite superior to Cut and Paste, however.

Thanks for the comments, Jef; it's true that I was not speaking from a
position of solid understanding. Ignorance without malice, mind you.

Let me back the argument up for a moment. I will admit both that my
familiarity with the system you are designing is limited, and that my
familiarity with your recent work is equally limited. I would like to
paraphrase; is this more or less accurate?

"Assuming that current, widespread institutional inertia can and will
be overcome, allowing the emergence and widespread diffusion of new
computational paradigms which replace or supplant current commands and
functions and thereby motivate change in user habits and mental models,
the Move and Copy functions as specified and integrated in the THE
environment (currently text-based, but one day to be available in other
media forms) are to be preferred to the present-day Cut and Paste
functions. This superiority can be scientifically demonstrated—through
a number of clearly defined and theoretically justified metrics—to
permit greater efficiency while providing many additional and clearly
desirable functionalities."

This is a bit less punchy than flatly saying that something is
'better,' I'll admit. But that first step is a pretty big one.

If I am reading this right, this also moves the argument to 'intuition'
to a different plane. I would call this the 'hard' argument to
intuition, which I would tend to see as follows: Intuition, as it
pertains to the use of interfaces, is a function of cognition and
perception. Current computational paradigms do not take maximal
advantage of the state of current knowledge in cognitive science and
perceptual psychology. More optimal solutions (with a closer coupling
to this new and improved scientific understanding of human sensory and
mental processes) are both possible and desirable; and, even retaining
the keyboard and mouse as primary input modalities, significant
functional improvements are possible. However, the limitations of
current interface paradigms and implementations inhibit or hobble these
potential benefits to a point where drastic change is necessary to
arrive at anything which could resemble the close coupling which could
then more accurately be called 'intuitive.'

One of the issues, as Robert pointed out, would be to have an idea of
the 'tipping point' where the undeniable advantages of such an improved
system would translate into the business cycles of early adoption,
market verification, significant corporate advantage and eventual
widespread dissemination.

I am not qualified to address the science that underpins this
particular argument to intuition, and I will gladly defer.
Furthermore, my frustration with Word has almost reached the point
where I would consider investing the time in an exotic and proprietary
alternative despite a steep learning curve. Give me another week or
two (and a native OS X port), and I might just get on board.

But I have a question of a different order: is this perhaps a point
where HCI and interaction design part ways? This particular interface
debate does seem to involve hypothetical, abstract users with no
institutional, social, cultural, or physical contexts and baggage, and
whose identified needs are to maximize efficiency and minimize
keystrokes (and frustration). It would be foolish to deny the
importance of efforts to improve fundamental infrastructure, and it
might be that a group like this could well evangelize on behalf of such
work. But my personal and professional goals are much closer to what
Robert described as

> [RR] holistically crafting the total behavior of products to better
> meet real goals of real humans in real contexts, using whatever
> toolsets are at our disposal. Of course there is plenty of room for
> innovation at the widget/action level, but it's the level at which
> widgets/actions are assembled together into larger frameworks of
> behavior and structure that the real leverage resides to provide great
> user experiences.

This is a typical design approach—one term for it is 'bricolage'—which
is to use the currently available and affordable pieces as best one
can, and trying, in the process, to retain a maximum of rigor and
generalizability, but placing primary emphasis on creating the best
design possible at the time the project is carried out, thereby
resulting in an improved quality of experience for particular groups of
people situated in particular contexts.

And, to swing back to the idea of 'intuition,' the model of the 'user'
is somewhat different in the latter case. The pragmatics of current
design practice mean that we assume and test for various degrees of
user familiarity with existing computational paradigms in particular
cases, while also recognizing that the mental models that users have
developed (again contextually determined) may also be less than totally
accurate. This degree of familiarity is what we can actually build
on—or consider as 'intuitive'—in real, contemporary design contexts.
It is almost certainly a 'softer' version of intuition than that
developed above, more prone to variation and change, and less
generalizable. Is it possible that we are simply not talking
addressing the same user, or the same intuition?

My apologies for such a long post. It's useful for me, as a teacher,
to understand these kinds of terms and to have answers to these
questions (or at least to come up with some better questions), and I
appreciate having a forum for doing so.

Hans

28 Aug 2004 - 10:32pm
Andrei Herasimchuk
2004

On Aug 26, 2004, at 1:33 PM, Jef Raskin wrote:

>> "Initial-user-learnabilty" is a jargon term often used to disguise an
>> opinion used in meetings to push one's own design politics.
>
> On the contrary, it is a measurable quantity. In particular you
> establish a criterion for success (e.g. correctly uses the command
> within time t some percentage p of the attempts) and measure how long
> or how many trials it takes for a statistically significant number of
> naive subjects to meet the criterion.

Like I said, a fancy term to describe an opinion. What is the
"criterion for success?"

It tends to go a little bit like this usually: Users should be able to
to do task in two seconds. (Why? What is so relevant about two
seconds?) Therefore, I'll create a "initial-user-learnability" metric
to measure against.

What about context? What about emotional connection to task completion?
What about long-term efficiency, where going slower might create
steadier results and longer term efficiency? What about focus and
attention, where multiple things might be going on for the user outside
the current task?

> Efficiency is defined objectively in "The Humane Interface",
> Addison-Wesley 2000, pp 83 ff. Because you don't know what it is
> doesn't mean that it has no meaning.

I don't need a lesson on what the term efficiency means.

> If two methods are otherwise equal, and one sometimes loses
> information the other does not, the one that loses information has
> lower efficiency.

That completely misses the point of context and its impact on the
methods.

You claimed a cut command was inefficient as compared to a move command
because of the risk from cut in losing information. That risk is just a
risk, it doesn't make move inherently more efficient. Further, as the
example Sandeep pointed out, move can sometimes impede on the fly work
if one's attention gets caught by something else to fix. There are many
other examples of these sorts of pros and cons for both move and cut.
Enough that I don't think you can make blanket statements about move
being inherently better than cut and paste.

>> Got it that you think cut-and-paste is badly designed and
>> troublesome. Got it that you think designers are not asking the right
>> quetions. That doesn't make cut-and-paste badly designed and
>> troublesome.
>
> But it is. You haven't shown otherwise, and I've given references and
> methods that show it is troublesome. And most users have had it cause
> them trouble. You'd have to have your head in the sand to not see this
> happening.

How is cut and paste badly designed? It does what it was meant to do:
cut information away. It even uses a word that has dangerous yet
precise meaning! Is a knife badly designed because one might slip on a
wet floor and fall on it killing themselves? It happens occasionally,
so are knives badly designed?

Adding a move command to the toolbox is a fine and lofty goal. A move
command has it use and I agree it has strengths. But to use the
justification for move that cut is badly designed and needs to go based
on some sort of criteria of intial-user-learnability and
frequent-user-efficiency jargon is the kind of thing that gets
designers in trouble in meetings.

> The very best interface cannot be expected to make a broken method
> work.

You claim that cut-and-paste is broken. I claim that's false.

>> In fact, when most designers do push outside of what is familiar,
>> trying to add new tools that might prove useful, they are usually
>> shot down by "experts" like Nielsen telling them to do what is
>> familiar.
>
> Don't malign my friend Jakob.

Too late for that. I assume you've never read anything on my web site.
Further, Nielsen brings it on to himself as near as I can tell. Just
read the reactions from designers on my articles to see that.

> If you are restricted to current methods and widgets, his
> recommendations are very good as to how to use them well.

Even when you are not constrained in that regard, Nielsen would claim
to play it safe and return to the familiar. Most of what he has written
these last ten years has been exactly about this point. I don't see how
this can be disputed with what Nielsen has written for the record.

> As you've put the word "expert" in ironic-quotes to refer to Nielsen
> and "leader" in ironic-quotes to refer to me I take it you have an
> animus toward us. Care to explain why?

Just repeating. http://www.useit.com/jakob/

> Not at all, that would violate the interface principle of monotony.
> They should replace Cut and Paste with Move. The details can be looked
> up, but I am sure you can figure out a good interface design for
> yourself.

I completely disagree with you. Cut and Paste has its place. I also
think Move is fine and dandy too. The are many contextual issues with
both that have to be considered. Sandeep mentioned one, another is
holding different kinds of data in memory, from words to pixels to
vectors and pasting each in different apps while crossing tasks,
another is moving data from one app to another, like from email into
Word where context of the data and focus might completely switch on the
user. They both have positives and negatives.

> But, in this case, if you will recall, I was responding to somebody
> else's post which used "Initial-user-learnabilty", and was responding
> in their terms out of courtesy and so as not to muddle the discussion
> with one about terminology. I do not use that term in my own work, so
> you are yelling at the wrong party in that particular case.

I missed that message in the thread then, and I apologize for thinking
you added it.

Andrei

29 Aug 2004 - 12:16pm
Larry Tesler
2004

Eugene,

If a "normal" usability test is unsuitable, why not design a more
suitable test?

Because the feature you propose is intended for experienced users of
a certain application, your testers will be experienced users of that
application. It sounds like you want to learn two things from them:
(a) Will they discover the feature? (b) Will it increase their
efficiency?

You can design a test to provide insight into both questions. For example:

- In the early minutes, see how much prompting it takes to get the
participant to notice the feature. Start by asking what he sees. If
he doesn't mention the new feature, ask him if he sees anything
different from usual. Then ask him to list all the ways he could
accomplish task X (the task the new feature is intended to
accelerate). If he still hasn't noticed the new feature, focus his
attention on its screen location. As a last resort, show it to him
and teach him what it does. Abandon this series of escalating prompts
as soon as he demonstrates awareness of the new feature. The more
prompting you had to provide, the less discoverable the feature
probably is. By watching and listening, you will probably develop
some good theories about why, and what to do about it.

- Once the user knows that the feature is there, give him a task to
do that can take advantage of it. Measure his efficiency. Compare
that with his efficiency measured a week earlier without the feature.
Bring him back a week later and a month later to find out whether he
remembers the feature, how much he says he uses it, and whether his
efficiency has improved. If someone whose attention has been directed
to the feature doesn't use it, others probably won't either.

Most of the time, if the experimenter is not biased in favor of the
design change,it will become obvious after a few users have tried it
that the feature is undiscoverable or unproductive and will remain
so, or that the users aren't willing to try new things. If that
becomes clear during the first exposure, then rather than schedule
return visits, it would be more productive either to iterate the
design based on what was learned or to drop the feature. In this way,
rapid iteration has a place in a longitudinal study.

Say you are fortunate enough to come up with a design that looks
promising after a longitudinal series of usability tests. If your
situation allows it, run a monitored field test using a beta version
of the software. Provide the feature to a random sample of all
available users. Use automated data gathering to measure usage levels
and to quantify efficiency differences between users who have and do
not have the feature. If you learn that experienced users gain but
new users lose, run a standard usability test to gain insight into
the cause.

A pretest, a test, two follow-up tests, and a monitored field test.
That's a lot of steps. But a procedure that drawn out is often
required to assess with confidence whether a new feature for expert
users that they did not ask for and that is hard to discover
increases their efficiency over the long run.

You can omit some of the steps if you are willing to proceed with
lower confidence. Or you can forget about "tricky designs"
altogether. Work with users to identify a simpler approach. Assess
its success using a low-cost, standard usability test. What works for
most people in the first hour will usually work for most people after
months of use.

Larry Tesler

At 1:04 PM -0700 8/23/04, Eugene Chen wrote:
>... I think part of the problem is the difficulty in running longitudinal
>usability tests that would prove out the second goal. Most usability
>techniques in practice are heavily biased towards intuitability and
>first-impressions. Important, to be sure, but not the whole picture.
>
>For instance, I've recently proposed some fairly tricky designs for my
>current project that I *think* could provide high (to some level) efficiency
>for some number (hopefully substantial) of users who eventually (not too
>long I hope) would discover it. But I'm scared to death that they won't make
>it past the usability test. As a matter of fact, I'm quite sure they
>wouldn't be discovered in a normal usability test, even with some training
>protocol.
>
>Throughout this project I've been noticing my own use of Outlook and
>basically I learn a new feature almost every day (sometimes deliberately,
>sometimes by accident). I expect this to go on for many more months.
>
>So one question is how designers of complex apps can gather any reliable
>data on
>how-many-users-take-how-much-advantage-of-feature-x-in-what-period-of-us
>e? This seems really to rub against the grain of rapid iteration.

29 Aug 2004 - 7:11pm
Thea
2004

Thanks for the link, Hans. For those who still want to know more, I have
been studying "intuitive use" for the past few years.

Here are some of my publications on the subject.

Peer reviewed journals

BLACKLER, A., Popovic, V., & Mahar, D. (2003). The Nature of Intuitive Use
of Products: An Experimental Approach. Design Studies, Vol 24, Issue 6.

Refereed conference papers

BLACKLER, A., Popovic, V., & Mahar, D. (2003). Designing for Intuitive Use
of Products. An Investigation. Paper presented at the 6th ADC, Tokyo.
BLACKLER, A., Popovic, V., & Mahar, D. (2002). Intuitive Use of Products.
Paper presented at Common Ground. Design Research Society International
Conference 2002., London.
BLACKLER, A., Popovic, V. and Mahar, D. (2004). Studies of Intuitive Use
Employing Observation and Concurrent Protocol. Paper presented at Design
2004, Dubrovnik.
BLACKLER, A., Popovic, V. and Mahar, D. (in press). Intuitive Interaction
with Complex Artefacts. Paper to be presented at Futureground Design
Research Society International Conference, Melbourne, 2004.

Regards,

Thea

At 07:07 PM 27/08/2004 -0400, hans samuelson wrote:
>To complete the incomplete part of my previous post (sorry for the itchy
>trigger finger): FWIW, there's a doctoral disseration on the question of
>metaphor in interface design online at
>
>http://www.redwines.btinternet.co.uk/chris/phd.html
>
>which will provide probably more than anyone wants to know about that
>particular debate!
>
>To move back into the world of hyphens for a minute, cut-and-paste is an
>interesting metaphor in and of itself. One of the hard things to explain
>to novices is that you are 'cutting' from an infinite computational
>'stuff' which can be 'pasted' infinitely and at will without ever
>diminishing the original stock. There is nothing intuitive about an
>infinite and never-depleted material, and why should there be? Nor does
>the idea of a 'move' actually address the fundamental novelty of this
>operation, since one of the main advantages of pasting is the ability to
>reuse the originally 'cut' element a number of times, a feature which the
>idea of a 'move' does not suggest, at least in my own cognitive and
>linguistic processes!
>
>The 'clipboard' is an image which has certain advantages; the idea of
>being able to take clippings, store them, move them around, copy them, and
>retain a trace on a 'board' has lots of appeal. Perhaps one could make a
>'clipboard' which would behave something like the 'history' feature in a
>Web browser—storing a record of the last few items 'cut'—which could then
>be retrieved should an accident or distraction intervene. This could be
>better than a straight 'undo,' since the 'undo' feature often requires
>that many operations be eliminated in order to return to the earlier
>state. Some of those operations might not be things you actually want to
>undo...
>
>My five cents (inflation, you know),
>
>Hans Samuelson
>_______________________________________________
>Interaction Design Discussion List
>discuss at ixdg.org
>--
>to change your options (unsubscribe or set digest): http://discuss.ixdg.org/
>--
>Questions: lists at ixdg.org
>--
>Announcement Online List (discussion list members get announcements already)
>http://subscribe-announce.ixdg.org/
>--
>http://ixdg.org/

Thea Blackler
PhD Candidate
P/T Lecturer in Industrial Design
School of Design and Built Environment
Queensland University of Technology
CRICOS No 00213J.

26 Aug 2004 - 3:33pm
Jef Raskin
2004

On Aug 26, 2004, at 12:46 PM, Andrei Herasimchuk wrote:

> On Aug 24, 2004, at 11:15 AM, Jef Raskin wrote:
>
>> Cut-and-paste has neither initial-user-learnabilty nor
>> frequent-user-efficiency, however it is invoked. All it has in its
>> favor is familiarity. Because we are wedded to familiarity, we have
>> kept with horses-and-buggies for transportation, and the automobile
>> was a short-lived failure. But that didn't happen. Why? Because cars
>> were more convenient and faster. Familiarity is not sufficient
>> justification for sticking to old ways.
>
> "Initial-user-learnabilty" is a jargon term often used to disguise an
> opinion used in meetings to push one's own design politics.

On the contrary, it is a measurable quantity. In particular you
establish a criterion for success (e.g. correctly uses the command
within time t some percentage p of the attempts) and measure how long
or how many trials it takes for a statistically significant number of
naive subjects to meet the criterion.

> Too many people in both the design and usability camps toss outs terms
> like this much too often these days. In the end, these terms tend to
> mean very little. And to claim cut and paste lacks
> frequent-user-efficiency, whatever the hell that means, seems like a
> dubious claim at best.

Efficiency is defined objectively in "The Humane Interface",
Addison-Wesley 2000, pp 83 ff. Because you don't know what it is
doesn't mean that it has no meaning.

>
>> A "move" command is at least as easy to learn as cut-and-paste, is
>> more efficient because it does not have the risk of losing the "cut"
>> item, as happens occasionally to nearly every user of conventional
>> systems. I am sure that the correspondents quoted below have had this
>> happen to them, and to their annoyance.
>
> That a move command does not have one of the risks of cut does not
> make it more efficient.

Indeed it does make it more efficient. From your high school physics
you know that efficiency is defined for a system that transforms power
as the power output divided by the power input; Claude Shannon showed,
in the 1940s (this is not late-breaking news), that information theory
was equivalent to thermodynamics (either can be derived from the other)
and it is a consequence that any system that transforms information
also has an efficiency, which is bits output divided by bits input. If
two methods are otherwise equal, and one sometimes loses information
the other does not, the one that loses information has lower
efficiency.

> It just means it has different strengths which might be better suited
> for certain tasks or users.

That's a different question.

> The fact you stated that one encounters this risk "occasionally" also
> weakens the claim that move is more efficient because it lacks that
> risk.

It doesn't weaken that claim at all. What it does suggest that it is
useful to know the failure rate, but more important still are the dire
consequences of losing work, and the psychological fact that random
reinforcement (in this case, of the fear of losing something) is
stronger than constant reinforcement -- as slot machine designers know
all too well. That cut-and-paste works most of the time (instead of all
of the time) is a strong mark against it.
>
>> Too often interface designers, as in this excerpt, discuss a popular,
>> but badly-designed and troublesome method instead of noting and
>> giving due consideration to problems that they know users have with
>> it. They are not asking the right question: what's the best way to
>> move a chunk of text (or some other object). They are not serving
>> their users well.
>
> Got it that you think cut-and-paste is badly designed and troublesome.
> Got it that you think designers are not asking the right quetions.
> That doesn't make cut-and-paste badly designed and troublesome.

But it is. You haven't shown otherwise, and I've given references and
methods that show it is troublesome. And most users have had it cause
them trouble. You'd have to have your head in the sand to not see this
happening.

> And it doesn't mean designers aren't asking the right questions.

In the discussion I was commenting on, they were working on an
interface for a particular, less-than-optimal command set instead of
first asking if there wasn't a better command set. It's a bit like
Lewis Carroll's Mat Hatter's tea party in "Alice in Wonderland".

'Two days wrong!' sighed the Hatter. 'I told you butter wouldn't suit
the works!' he added looking angrily at the March Hare.

'It was the best butter,' the March Hare meekly replied.

The very best interface cannot be expected to make a broken method
work. This is what I mean when I say that some interface designers are
sometimes looking at the wrong problem. They are making sure to use the
best butter when butter isn't the right stuff to begin with.

> In fact, when most designers do push outside of what is familiar,
> trying to add new tools that might prove useful, they are usually shot
> down by "experts" like Nielsen telling them to do what is familiar.

Don't malign my friend Jakob. If you are restricted to current methods
and widgets, his recommendations are very good as to how to use them
well. As you've put the word "expert" in ironic-quotes to refer to
Nielsen and "leader" in ironic-quotes to refer to me I take it you have
an animus toward us. Care to explain why?

>
> That being said, it sounds like all you are suggesting is the
> interface design world add a "Move" command into the cluster of Cut,
> Copy and Paste standard bearers.

Not at all, that would violate the interface principle of monotony.
They should replace Cut and Paste with Move. The details can be looked
up, but I am sure you can figure out a good interface design for
yourself.

> Another tool for the arsenal that in due time might make users
> happier if they find Move works more often for what they want to do
> than Cut and Paste.
>
> There, that wasn't so hard.

Not at all difficult.

>
> Once the design and usability community, and especially "leaders" like
> yourself Jef, stop using jargon words, stop talking around the issues
> no matter how large or small, stop talking cross-purposes and start
> saying what they mean in simple, clean language that anyone can
> understand, we'll all see a design renaissance in high-tech field like
> America saw in the mind 1900s in graphic, industrial and automotive
> design.

Sometimes technical terms are necessary when ordinary language lacks
sufficient precision. But, in this case, if you will recall, I was
responding to somebody else's post which used
"Initial-user-learnabilty", and was responding in their terms out of
courtesy and so as not to muddle the discussion with one about
terminology. I do not use that term in my own work, so you are yelling
at the wrong party in that particular case.

Come to think of it, are you familiar enough with my writings to
critique my use of English? If you are, I would appreciate any specific
examples of unnecessary jargon and the other complaints you make.

>
> Andrei
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>

26 Aug 2004 - 6:58pm
Jef Raskin
2004

>
> On another note re. the "move" command -
>
> Take the example of doing a cut-and-paste in a long
> Word document.
>
> Let's say that I did a cut.
>
> Then, I scrolled a few window lengths down, and was
> looking for a place to paste the clipped info. Now,
> someone walks into my cubicle, and distracts me for
> the next 3 minutes. When I get back to work, I start
> looking for the place to paste, and by reflex, I see a
> spelling error. So, I happen to select stuff and fix
> the spelling. And then, I paste. This works.
>
> Now, if one were to use Move...would this work? Would
> we set markers, where the user first selects the text,
> then marks it as candidate for a move, and then, does
> a move at some point? There would be a "Mark Move",
> "Move", "Copy", and "Paste"? Seems like more stuff to
> deal with, and "Mark Move" is not term from everyday
> life....like cut and paste are.

You are making an assumption that Move works in the way you describe.
But that is a poor interface to Move. I have a detailed spec on my
website. But you'd probably have more fun figuring out a way that
doesn't require any extra commands and is faster (in a GOMS analysis)
than cut-and-paste -- as well as having fixed the problem with losing
the cut buffer.

>
> Losing info problem. Isn't that what Undo is for?

Undo solves a host of problems. I consider a deep Undo a necessity. But
we should still design so that its use is minimized.

>
>

27 Aug 2004 - 9:02pm
Jef Raskin
2004

Check out the spec on my website: Move is accompanied by a Copy
command. Move and Copy are no more numerous than Cut and Paste.

Discussing a command in isolation is often non-productive, as Hans has,
I hope, just discovered. That's why I mentioned earlier in this
discussion that people interested in my solutions see the spec on my
web site. Similarly, his comments on Undo apply only to one style of
Undo, which has exactly the problems he mentions. However, there are
better approaches that do not have those problems.

For these reasons it is often amusing to read critiques of particular
interface widgets when a detailed specification is not given as to how
the widget is implemented. It is easy to bash an opponent that you can
shape to be vulnerable. It is more difficult (and more helpful) to
discuss these things in terms of a rigorous specification of how the
interface works and exactly what it does, especially in edge cases.

Incidentally, there will be a version 80 of the spec out in about two
weeks that covers how we do Undo. The presently available spec is fine
for seeing why Move and Copy are quite superior to Cut and Paste,
however.

On Aug 27, 2004, at 4:07 PM, hans samuelson wrote:

> Nor does the idea of a 'move' actually address the fundamental novelty
> of this operation, since one of the main advantages of pasting is the
> ability to reuse the originally 'cut' element a number of times, a
> feature which the idea of a 'move' does not suggest, at least in my
> own cognitive and linguistic processes!

28 Aug 2004 - 1:14pm
Jef Raskin
2004

On Aug 28, 2004, at 3:38 AM, Peter Bagnall wrote:
>>
>
> As for move - the select and drag version of move seems to be fairly
> widely implemented now, but from what I've seen it's not used as much
> as cut and paste. Possibly because it's harder to discover, but I
> don't have any evidence for that, I'm just guessing.
>
> Cheers
> --Pete
>
This method, if you will forgive the pun, is somewhat of a drag. I have
observed users and here's what happens rather often: they make a
selection but get it a little wrong. They then try to make the correct
selection, which often starts in the existing selection, but instead of
selecting the gesture of click-and-drag now moves the selection. It is
a very (and I mean very) bad design when the same gesture, in the same
context, does different tasks. This is modal with a vengance.

The other problem is that dragging a selection either does not work or
is awkward if your destination is off-screen, so you have to use
different methods depending on the location of your destination. This
forces you to make a conscious decision about the method to use, and
defeats habituation.

Jef

29 Aug 2004 - 11:15pm
Jef Raskin
2004

Thea,

I see that you, too, have come to the conclusion that "things that
humans use intuitively are those that they have used before." I have
never been happy with the term "intuitive" because it presumes a human
facility of intuition which many people superstitiously believe exists.
I would like to read what you've written: Are any of your papers
available online? My Google search found only abstracts and titles. If
not, could you email one or more of them?

You are probably familiar with my paper on the topic.

Jef

On Aug 29, 2004, at 5:11 PM, Thea wrote:

> Thanks for the link, Hans. For those who still want to know more, I
> have been studying "intuitive use" for the past few years.
>
> Here are some of my publications on the subject.
>
> Peer reviewed journals
>
> BLACKLER, A., Popovic, V., & Mahar, D. (2003). The Nature of Intuitive
> Use of Products: An Experimental Approach. Design Studies, Vol 24,
> Issue 6.
>
> Refereed conference papers
>
> BLACKLER, A., Popovic, V., & Mahar, D. (2003). Designing for Intuitive
> Use of Products. An Investigation. Paper presented at the 6th ADC,
> Tokyo.
> BLACKLER, A., Popovic, V., & Mahar, D. (2002). Intuitive Use of
> Products. Paper presented at Common Ground. Design Research Society
> International Conference 2002., London.
> BLACKLER, A., Popovic, V. and Mahar, D. (2004). Studies of Intuitive
> Use Employing Observation and Concurrent Protocol. Paper presented at
> Design 2004, Dubrovnik.
> BLACKLER, A., Popovic, V. and Mahar, D. (in press). Intuitive
> Interaction with Complex Artefacts. Paper to be presented at
> Futureground Design Research Society International Conference,
> Melbourne, 2004.
>
> Regards,
>
> Thea

26 Aug 2004 - 3:14pm
Listera
2004

Jef Raskin:

> A "move" command is at least as easy to learn as cut-and-paste, is more
> efficient because it does not have the risk of losing the "cut" item,
> as happens occasionally to nearly every user of conventional systems. I
> am sure that the correspondents quoted below have had this happen to
> them, and to their annoyance.

If there was a way to not lose the item, would you still object? (Mind you
I'm not objecting to the utility of "move".)

It occurred to me that I never think about this issue, personally, because I
have installed a utility that saves the last 50 clipboard items and
forgotten about it. We already have desktop-level undos, so if the OS gave
you, say, 100 clipboard "undos" out of the box, how big an issue/risk would
this still pose?

BTW, do you think alt+dragging to make a copy offers any
frequent-user-efficiency?

----
Ziya

Is it easier to reject a good solution or accept a bad one?

26 Aug 2004 - 9:19pm
Listera
2004

Reimann, Robert:

> But someday a new set of idioms may come along that are so much better that
> many of us will leave our windows and menus behind. I think it might be a
> while, though.

One could argue that the Web was just that. If you compare desktop apps in
the mid-80s with the fully-loaded web experience of today, the difference is
more than just skin deep: searchbox-resultset navigation, rollovers,
streaming audio/video, liquid page layout, device-adaptive presentation,
URI-based applications, highly-personalized content navigation, contextual
advertising...and the general blurring of the lines between applications,
documents and multimedia.

Yes, it's all mixed in with the old paradigm, but there's a lot of
significantly new stuff in the web *and* they are exposed to half a billion
people online. If I was told in 1985 that I could access billions of pages
worth of info through a tiny little searchbox in mere microseconds, I don't
think I'd believe it. So the new set of idioms may not come relatively
abruptly as they did in 1984 with the Mac's "Hello" but may gradually
transform our perception of HCI over a long gestation period.

Sandeep Jain:

> Why aren't pie menus common-place? How freaked would a user be to see that?
> Perhaps not in Alias|Wavefront's Maya (which is an expert UI), or other
> vertical applications.

Incidentally, the general public took to the hybrid-but-nevertheless
circular "menu" of the iPod very quickly. And with all the talk of Apple's
new case modding patents for illuminated "active enclosures" how far behind
could an adaptive pie menu *in hardware* be? :-)

----
Ziya

Any system that is useful will have to be modified.

26 Aug 2004 - 5:30pm
Andrei Herasimchuk
2004

On Aug 26, 2004, at 1:33 PM, Jef Raskin wrote:

>> "Initial-user-learnabilty" is a jargon term often used to disguise an
>> opinion used in meetings to push one's own design politics.
>
> On the contrary, it is a measurable quantity. In particular you
> establish a criterion for success (e.g. correctly uses the command
> within time t some percentage p of the attempts) and measure how long
> or how many trials it takes for a statistically significant number of
> naive subjects to meet the criterion.

Like I said, a fancy term to describe an opinion. What is the
"criterion for success?"

It tends to go a little bit like this usually: Users should be able to
to do task in two seconds. (Why? What is so relevant about two
seconds?) Therefore, I'll create a "initial-user-learnability" metric
to measure against.

What about context? What about emotional connection to task completion?
What about long-term efficiency, where going slower might creating
steadier results and longer term efficiency? What about focus and
attention, where multiple things might be going on for the user outside
the current task?

> Efficiency is defined objectively in "The Humane Interface",
> Addison-Wesley 2000, pp 83 ff. Because you don't know what it is
> doesn't mean that it has no meaning.

I don't need a lesson on what the term efficiency means.

> If two methods are otherwise equal, and one sometimes loses
> information the other does not, the one that loses information has
> lower efficiency.

That completely misses the point of context and its impact on the
methods.

You claimed a cut command was inefficient as compared to a move command
because of the risk from cut in losing information. That risk is just a
risk, it doesn't make move inherently more efficient. Further, as the
example Sandeep pointed out, move can sometimes impede on the fly work
if one's attention gets caught by something else to fix. There are many
examples of these sorts of pros and cons for both move and cut. Enough
that I don't think you can make blanket statements about move being
inherently better than cut and paste.

>> Got it that you think cut-and-paste is badly designed and
>> troublesome. Got it that you think designers are not asking the right
>> quetions. That doesn't make cut-and-paste badly designed and
>> troublesome.
>
> But it is. You haven't shown otherwise, and I've given references and
> methods that show it is troublesome. And most users have had it cause
> them trouble. You'd have to have your head in the sand to not see this
> happening.

How is cut and paste badly designed? It does what it was meant to do:
cut information away. It even uses a word that has dangerous yet
precise meaning! Is a knife badly designed because one might slip on a
wet floor and fall on it killing themselves? It happens occasionally,
so are knives badly designed?

Adding a move command to the toolbox is fine and lofty goal. A move
command has it use and I agree it has strengths. But to use the
justification for move that cut is badly designed and needs to go based
on some sort of criteria of intial-user-learnability and
frequent-user-efficiency jargon is the kind of thing that gets
designers in trouble in meetings.

> The very best interface cannot be expected to make a broken method
> work.

You claim that cut-and-paste is broken. I claim that's false.

>> In fact, when most designers do push outside of what is familiar,
>> trying to add new tools that might prove useful, they are usually
>> shot down by "experts" like Nielsen telling them to do what is
>> familiar.
>
> Don't malign my friend Jakob.

Too late for that. I assume you've never read anything on my web site.
Further, Nielsen brings it on to himself as near as I can tell. Just
read the reactions from designers on my articles to see that.

> If you are restricted to current methods and widgets, his
> recommendations are very good as to how to use them well.

Even when you are not constrained in that regard, Nielsen would claim
to play it safe and return to the familiar. Most of what he has written
these last ten years has been exactly about this point. I don't see how
this can be disputed with what Nielsen has written for the record.

> As you've put the word "expert" in ironic-quotes to refer to Nielsen
> and "leader" in ironic-quotes to refer to me I take it you have an
> animus toward us. Care to explain why?

Just repeating. http://www.useit.com/jakob/

> Not at all, that would violate the interface principle of monotony.
> They should replace Cut and Paste with Move. The details can be looked
> up, but I am sure you can figure out a good interface design for
> yourself.

I completely disagree with you. Cut and Paste has its place. I also
think Move is fine and dandy too. The are many contextual issues with
both that have to be considered. Sandeep mentioned one, another is
holding different kinds of data in memory, from words to pixels to
vectors and pasting each in different apps while crossing tasks,
another is moving data from one app to another, like from email into
Word where context of the data and focus might completely switch on the
user. They both have positives and negatives.

> But, in this case, if you will recall, I was responding to somebody
> else's post which used "Initial-user-learnabilty", and was responding
> in their terms out of courtesy and so as not to muddle the discussion
> with one about terminology. I do not use that term in my own work, so
> you are yelling at the wrong party in that particular case.

I missed that message in the thread then, and I apologize for thinking
you added it.

Andrei

30 Aug 2004 - 6:41pm
Jef Raskin
2004

Listera (Ziya?),

I am in no way criticizing your use of a utility that prevents Paste
from being the potential disaster command that it is. However I will
point out that this utility is a patch to correct a design goof. This
is the accumulative technique of interface design that has led us to
our present, overcomplicated GUIs. Problem after problem "solved" by
patch after patch instead of asking what we should have done in the
first place.

Even in a system with depth of Undo limited only by memory available it
is better to have a design that does not unnecessarily lead to the need
for the Undo. Given human imperfections, Undo must always be available,
but having it should never be an excuse for a poorly designed widget,
with the designer saying "it doesn't matter if we sometimes get the
user into trouble because we have Undo." Undo still takes time and
thought to operate, whereas eliminating the source of the error (if
it's at least as efficient as the original method) saves the need to
Undo and then create what you really wanted.

alt+dragging solves one problem and is efficient, but it introduces
another "trick" that you have to memorize. It is less than elegant.

Jef

On Aug 26, 2004, at 1:14 PM, Listera wrote:

> Jef Raskin:
>
>> A "move" command is at least as easy to learn as cut-and-paste, is
>> more
>> efficient because it does not have the risk of losing the "cut" item,
>> as happens occasionally to nearly every user of conventional systems.
>> I
>> am sure that the correspondents quoted below have had this happen to
>> them, and to their annoyance.
>
> If there was a way to not lose the item, would you still object? (Mind
> you
> I'm not objecting to the utility of "move".)
>
> It occurred to me that I never think about this issue, personally,
> because I
> have installed a utility that saves the last 50 clipboard items and
> forgotten about it. We already have desktop-level undos, so if the OS
> gave
> you, say, 100 clipboard "undos" out of the box, how big an issue/risk
> would
> this still pose?
>
> BTW, do you think alt+dragging to make a copy offers any
> frequent-user-efficiency?
>
> ----
> Ziya
>
> Is it easier to reject a good solution or accept a bad one?
>
>
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>

30 Aug 2004 - 9:06pm
Listera
2004

Hi Jef,

> Given human imperfections, Undo must always be available,
> but having it should never be an excuse for a poorly designed widget...

Some widgets improve with time. :-)

Google's simple textfield evolved from a simple search access point to a
spellchecker to a calculator to a finder of phone numbers, bookmarks, stock
quotes, DNS relationships, etc. Same widget -> dramatically improved
capabilities. (More confusion than utility? I'm not qualified to answer on
account of the fact that I'm not a Google millionaire. :-)

Lots of other UI components also get significant and continual boost from
hardware and software enhancements under the surface. CPU/GPU/RAM
advancements allow, for example, what was once a mere outline during a drag
and drop to be a vastly better-looking Technicolor proxy on today's PCs.

I'd assume that the speed and quality of results from the upcoming Tiger
Spotlight will probably change users' appreciation of the little searchbox
whose capabilities will have been vastly improved from System 7 days.

Apple was roundly criticized for all the eye candy it introduced with OS X,
for making the overall UX slower. Yet what was decidedly slow in 10.1 is no
longer so in 10.3.5.

When they were first introduced, audio/video timeline scrubbing UIs were
jerky affairs at best. Today, they are quite smooth. I have zero doubt in
mind that those designers thought one day soon HW/SW would catch up to fully
exploit the widget's utility. I see nothing wrong with that.

Now, I'm not saying that those who designed CaP originally (who?) made a bet
that one day native, ever-present, "infinite" undo would take care of your
main opposition to it. But I just wanted to point out that as a designer it
is permissible, at least in my book, to make bets against supporting HW/SW
improving over time, and thus improving the widget.

> alt+dragging solves one problem and is efficient, but it introduces
> another "trick" that you have to memorize. It is less than elegant.

Yes, but that is simply unavoidable. There will *always* be "tricks".

I'm sure you've had a child come to you proudly explaining how he discovered
that the TV remote can bounce off the walls to change the channel? I don't
think you'll ever find that "trick" in the manual and the "lazy" children
will always figure out a way to change the channel without getting up from
under the coffee table.

----
Ziya

People don't want to buy a quarter-inch drill.
They want a quarter-inch hole.

5 Sep 2004 - 4:18pm
Andrei Herasimchuk
2004

On Aug 30, 2004, at 4:41 PM, Jef Raskin wrote:

> Even in a system with depth of Undo limited only by memory available
> it is better to have a design that does not unnecessarily lead to the
> need for the Undo.

Even low-tech objects like pencils have erasers. Why? Because we are
fickle, ever-changing, imperfect beings. You might have an issues with
that, but I find it perfectly logical and acceptable.

There's nothing wrong with Undo.

Andrei

Syndicate content Get the feed