Re: Make it quantitative when possible, or at least logical.
On Aug 28, 2004, at 10:38 PM, Jef Raskin wrote:
> You miss the point. The criterion is chosen to allow you to compare
> two or more methods in terms of learnability so that you can see which
> is better. How "it tends to go" is irrelevant, as how X or Y does it
> may or may not be how it should be done. Could you give me references
> as to here you got the "two seconds" from -- I don't think so because
> you just made it up.
I was attempting to make the point that more often than not in
practice, product mangers and even some usability folk, make up these
criterion based on an opinion of what is right. If everything were as
scientifically or research based in design, maybe I might back down on
my distaste for use of jargon. But my experience has left me feeling
jargon is used to push design politics.
> Setting up a reasonable criterion, which may be from under two seconds
> to over six months depending on the task, is part of the experimental
> design. Given a particular case, we can choose one that is meaningful
> in the context of the task to be done and the resources available.
Sounds great in theory. I have yet to see that apply practically
speaking given the myriad of constraints and time schedules on any
given product. For something as generic as "cut and paste versus move,"
how would you define the criterion given the complexity of all the
possible uses and contexts for these functions? It would seem like a
task so large as to be not worth the research effort, again, given real
world business circumstances and constraints.
Smaller features themselves also have similar problems of scale for all
the various functions and tasks that need to be completed.
>> 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?
> What about them? They are among the other factors to be considered. I
> never said that time to learn to use a widget or set of widgets to
> some criterion was the only factor. Just because there are many
> factors does not invalidate any one of them. I think that your comment
> here fails to be logical.
The point I was attempting to make, and maybe I was being too vague for
you, was that there are at least thousands of possible combinations of
contexts for something like cut-paste and move in hundreds of different
applications that I'm not sure how you would even begin to be able to
safely provide research that says cut and paste is inferior or
inefficient as compared to move.
Maybe for specific tasks, but I'm dubious for the overall case.
>> I don't need a lesson on what the term efficiency means.
> Then please tell me what it means to you.
In the context of user interface design, doing less to produce more.
Reducing repetitive tasks to maximize output. And yes, even producing
fewer errors to achieve consistent, long term results.
> Again the fallacy that because a particular measure does not measure
> everything it is wrong. Efficiency is one factor among many, and in
> some circumstances it is an important one.
So who is to say when it is the important one? You? Me? I guess it
>> 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.
> Of course it does. Higher risk means that more effort is wasted, and
> thus the cut-and-paste effort is less efficient. But perhaps you have
> a different definition of "efficient", which is why I ask for your
> definition. You say you don't need a lesson on what it means, perhaps
> I do: educate me.
Here's an example.
When I respond to email, I often duplicate the message. Usually, I will
cut a block of text from it and paste it into my new message. Then I go
about removing sections of the text to pare it down so as not to waste
space. Sometimes, I realize I have have pared down too much and rather
than undo an unknown number of steps, I prefer to reselect the block of
edited copy and re-paste in two simple steps from the cut piece of text
still in memory.
If I used a move command, I would be forced to use multiple undo to get
back to a state because of course the original piece of text was moved
from the original message when I issued the move command and is no
longer there. You tell me, how would move be more efficient for me in
Yes, there is risk with cut. The point, once again, is that risk does
not inherently make cut less efficient as compared to a move command.
It's just a risk. Nothing more.
There are many such contexts and tasks such as this. I look to you to
use your imagination to find more.
>> 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?
> Just because something is dangerous in the physical world does not
> mean we have to copy that danger in our interfaces. We can use the
> flexibility of software to do better. The knife may or may not be
> badly designed, but if you can provide a different tool that gets the
> job done and which won't kill you if you fall on it, you should
> provide such a tool.
The point I was making that when something does what it was designed to
do, and it does it well, one can make the argument the thing is as
designed. It doesn't necessarily make it badly designed. It is what it
> BTW, why does a system need a Cut command when it already has a Delete
> key on the keyboard?
See my example above. I would never use the delete key for that task.
>> Adding a move command to the toolbox is a fine and lofty goal.
> Not fine and lofty, just practical and better for users. Have you ever
> built a move-and-copy system and tried it on users?
Illustrator has a move command that also copies when needed. It's had
it since at least Illustrator 88 if my memory serves me correctly. We
never added it to the menu in the cluster of commands with Cut, Copy
and Paste (it was always in the Object menu), but it was widely used by
many expert Illustrator users. And still is today. They also use cut
just as often, usually with cut and then paste in front after selecting
Most of Adobe's applications have a transform palette, which acts as
the move and copy interface. It's used often. Quite often. It's great
to move things exactly where you want them to be and to move and copy
something to an exact location. Users work with the transform palette
in this way all the time. Although I imagine you mean a UI that is more
akin to what drag and drop does, just executed with commands instead of
being forced to use mouse movements. The transform palettes in Adobe's
apps are great move and copy interfaces for objects in arbitrary grid
systems in the same document. It doesn't work from app to app or window
to window obviously.
> I have, and the preference for it quickly becomes clear. A typical
> reaction is "why doesn't everybody do it this way?". You are speaking
> theoretically, and I am speaking both theoretically and with some
You should learn a little bit more about me and what I have done in my
career before making uneducated accusations about what kind of
experience I have or don't have, as I have quite a bit in this field.
And like I said, I'm not against a move command. I think it's perfectly
a good tool for many situations. What I'm against is losing the
cut-paste method in favor of the move-copy only method. My experience
tells me they each have their place and use. Why is that so hard to
acknowledge or accept? I say you have a point that move works and works
well, but when I say cut and paste also has a place, you say no. Oh
>> You claim that cut-and-paste is broken. I claim that's false.
> It is broken because it needlessly causes users to lose material from
> time to time. Anything that hurts users when they make a mistake is
This is a lofty goal, but one that gets many usability and research
people into serious trouble. I say this from the point of view that far
too often these days our interfaces for applications and webs sites are
littered with the good will of well intentioned designers and usability
folks trying to protect users from themselves. What we now have is a
mess, and a cluttered, more intrusive mess than we had in the 80s and
90s. Now everything musty be obvious and learnable and intuitive to the
point where I fell like my computer screen has been thrown up on by
interface designers everywhere with excessive use of icons, verbiage
and stuff popping up in my face constantly.
I'll agree that more often than not, features that lose data or hurt
users must be avoided. Especially when the UI somehow promotes that
data loss or user pain. But like the knife in your kitchen, some things
need to be learned or how to be used, such that when used effectively
and properly, they work effectively and efficiently for the task it was
Sometimes is ok to make people learn how to do something, even if that
something is a bit dangerous.
I've always said, "if a person can be taught how to drive a car, a task
which is fraught with life threatening danger to themselves and others,
then they can learn [how to use cut and paste correctly.]" For me, the
question is more whether the UI is worth the time it takes to learn it.
Is there real benefit on the other side?
> I have read much of your site. There is even one essay which is
> surprised at how good some of his work is. I don't agree with him at
> all on many issues, I am not a lover of his use of English. But he's
> generally competent. Have you read my book?
You must be referring to "Design Eye for the Usability Guy." I wasn't
really surprised actually. It just made for good reading to write as if
I skimmed parts of or your book a few years back. You've always had
some interesting points as far as I'm concerned, but to be honest, I
find most of your work impractical for real world design work in the
trenches. Sorry to say that, but most of your work I find good for
higher level thought exercises, but not for day to day design work.
> If you use quotes to indicate that you are quoting some source, you
> must give the source, otherwise the quotes, as you used them, mean
> that you are being ironic. Your misuse of punctuation was the problem
Then I won't do that again.
>> I completely disagree with you. Cut and Paste has its place.
> Why? Because Microsoft uses it? Let's have a reason. I have not found
> one instance where it is superior or otherwise justifies having a
> place in a user interface.
Microsoft? Apple was the guilty party that made Cut, Copy and Paste
standard. What's this with Microsoft? You of all people know this.
I use cut and paste all the time in coding HTML, writing email, all
sorts of purposes where move would feel awkward or not be optimal.
Further, there are many things in pixel and vector editing that make
far more sense as cut than as move. Am I supposed to go into every
single case for Photoshop, Illustrator and InDesign? I've got better
things to do, but could be convinced to make a brief starting list if
people on this list want to spawn a new thread. Using those programs at
the level that many experts and artists do and I'm sure you'll start to
discover just how much cut and paste plays a role in the day to day
workflow where move would not make as much sense.
>> 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
> That is an implementation issue, it is independent of whether to use
> Cut-and-paste or Move-and-copy.
>> 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.
> What are the negatives of Move-and-Copy in these circumstances?
> Between apps you just select (as with Cut-and-Paste), shift focus to
> the other app, choose your spot, and use the Move commands. No
> negatives I can see. If you get interrupted in the middle, forget what
> you were doing, and start another Move, you have lost nothing, unlike
> the Cut method. It's a win in every case.
That depends if the context of the target location is the same as the
context of the origin location. If I'm using Word in drawing mode, and
I go to email to move a block of text into Word, what is the behavior
of the target when it's in a different context? It largely tend sot be
a feel issue. Move and copy has many of the same issues as drag and
drop does in these sorts of cases, where the behaviors of the app due
to context create an awkward, unsafe feel.
- Make it quantitative when possible, or at least logical.
- FW: Re: Cut and Paste vs. Move (was: Make it quantitative...)
- "monotony" vs. "redundancy" (was RE: Cut and Paste vs. Move (was: Make it quantitative...))
- Cut and Paste vs. Move (was: Make it quantitative...)
- [Possible Spam] RE: Re: "Intuitive" designs can be cumbersome