Re: Make it quantitative when possible, or at least logical.

29 Aug 2004 - 2:15am
9 years ago
24 replies
623 reads
Andrei Herasimchuk
2004

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
depends?

>> 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
this context?

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
is.

> 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
an object.

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
> experience.

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
well.

>> 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
> broken.

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
designed.

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 was.

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
> here.

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
>> tasks,
>
> That is an implementation issue, it is independent of whether to use
> Cut-and-paste or Move-and-copy.

How so?

>> 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.

Andrei

Comments

29 Aug 2004 - 10:25pm
Andrei Herasimchuk
2004

Not sure what is going on, but the reply header keeps changing, leading
me beleive this thread is broken for most readers o fthe list.

On Aug 29, 2004, at 9:29 AM, Jef Raskin wrote:

> And how do you know if a design doing less and producing more? That's
> where quantitative measures help. Heuristics such as you give here are
> vague and can lead to disagreement as to which of various methods
> requires "doing less" and which are "doing more". Certainly reducing
> repetitive tasks is a good idea, but if you have a few ways to reduce,
> how do you determine which is best? Part of the advance of science
> comes with providing objective measures. The quantitative approach to
> efficiency is a much more powerful tool than your hints, and should be
> used whenever appropriate.

You picked up on the obvious use of less steps. There's also using
using less controls and visual clutter to produce more as well.

I'm not arguing against objective measure and research. That's not the
issue for me. The issue is when objective measures get masked in jargon
terminology. When that happens, the objective measure tends to be based
on opinion, hijacked for such purposes, or terminology is used to push
one's own agenda in a project. But we already agreed you didn't start
the jargon thing, so it's probably pointless to continue down that
path.

>> 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 this context?
>
> Using Move was clearly the wrong thing to do. If you are wise enough
> to duplicate the message in a Cut-and-Paste (CaP) environment then you
> would be wise enough to start by using Copy instead of Move.

That's an issue of how the user likes to operate. In my case, I prefer
to see things disappear in the original duplicate message. Why? So I
know I've addressed it already and can move to the next item. If I used
copy, I would then have to go back and find what I used (which might
require scrolling depending on window size or content size) and then
delete to reduce the visual noise. Cut is much more efficient than
either move or copy for me in this context.

By the way, this is also true for programming HTML files for me. I
sometimes need to take chunks of one HTML page, and put it into ten
other pages. I use cut here so as I move between all this code,
visually, I see how much of the original is whittling away and know how
much I have done.

>> 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.
>
> All I said is that I have experience with users in systems with Move
> and Copy in particular and that I didn't think you did. Was I wrong?

Yes you were wrong.

> What is the place for CaP which is no faster or more powerful than MaC
> when the former has user risks the latter doesn't have?

Again, it's context Jef. Sometimes people want the behaviors because it
makes more logical sense to them. Sometimes, there's a nuance of the
behavior they favor that is not represented in the cold hard fact of
research or data mining. The context of the situation and the context
of the user play a role here, and you seem to be ignoring those.

>> This is a lofty goal, but one that gets many usability and research
>> people into serious trouble.
>
> And what is wrong with lofty goals? And if it gets some people in
> trouble that does not mean that it will get all people in trouble.
> Lofty goals are what we should be shooting for. Perhaps you set your
> sights too low.

My sights are very high. Asked anyone whose worked with me.

The point about lofty goals is that when they lack practicality, they
tend to be a recipe for massive headaches for designers. In your case,
you would remove cut and replace it with move. The lofty goal here
being to save users from themselves and data loss because cut is "badly
designed." In doing so, you might actually wind up causing more harm to
users who actually have legitimate uses for cut.

A lofty goal that is rooted in practicality would *add* move to the
cluster of cut, copy and paste commands, and then over time find ways
to ween users away from cut, or at least verify with actual use over
time that their instincts or insights about cut were correct and remove
the poorly designed command at the appropriate time.

>> Sometimes is ok to make people learn how to do something, even if
>> that something is a bit dangerous.
>
> It is OK, if necessary, with the important exception that if you can
> give the same or better functionality with something that is not
> dangerous, you should do so. Thus the moral imperative to provide MaC
> instead of CaP.

You have yet to acknowledge that move's strength over cut does not make
cut inherently inefficient or badly designed. But I guess moral
imperatives are now up those who get it and those who know what's right
for everyone else? Is that it?

> Skimmed parts of my book a few years ago? And you critique it on that
> basis? That's lame.

No, I also critique you based on the few times I've seen you speak, and
from your THE project. Your THE project was (and is), to be completely
honest, about the hardest, most obtuse, counterintuitive thing I have
ever used on a computer. For someone who touts a humane interface, I
had no idea what you were trying to say or do with your THE project.

>> 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.
>
> That you choose to use a particular tool is no evidence in its favor.
> If you want to make that statement stick you must show why MaC would
> feel awkward (aside from your unfamiliarity with it) and where would
> it not be optimal. You have yet to give an example.

I did give an example and you ignored its validity. That doesn't mean I
didn't give an example. I'll give you a second example, based on my
HTML code variation of the email example:

1) Find original HTML file I need to use to disperse various pieces of
DIV code into other files.
2) Duplicate this HTML file.
3) Close original so as to not accidentally corrupt it.
4) Open ten other HTML files that need this exact DIV code.
5) In duplicate HTML source file, find code snippet.
6) Cut it.
7) Switch to other ten HTML documents and paste code snippet into
location.
8) Go back to duplicate HTML source file, where I can now easily see
what is missing, and find next code snippet.
9) Repeat until done.
10) Save all.

If I would have used copy in this case that would have messed up step
#8 for me. Move would make no sense here.

>> 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?
>
> Just one case would do. So far we have zero.

First, we have to make some assumption on how move would work, and from
my understanding it would be like this:

1) Select source.
2) Choose Start Move from menu or its command key equivalent.
(I assume this is a start of the move command, so I'm not sure what you
think it would be called. I also assume the source content is somehow
highlighted, but does not disappear from its location. If it
disappeared, it would basically be Cut and Paste with different menu
names.)
3) Find target point, insertion or selection.
4) Execute Finish Move command from menu or its command key equivalent.
The content from original source moves to new location.

Based on that interface, here are some things that would not work with
Photoshop and Illustrator:

A) You have some artwork in a Photoshop file. You had placed a pixel
element on a layer, but now realize the overall artwork might look
better without it, but you're not sure. Further, you also think it
might look better in a different file that's already open. So, you
select the pixel element with the marquee tool, then use cut. You can
immediately see the visual results of the artwork without the logo and
make a decision if that's what you want. If it is, you then switch
documents and paste it to see if it does indeed look better there. If
not, undo or delete the pasted pixels and continue. Cut and paste makes
more sense here and is more efficient than move or copy.

B ) To center pixel data in Photoshop on a layer, one quick way to do
it is to select the entire layer, then cut the pixels so the layer is
empty. When you paste it will paste into the exact center of the layer.
Cmd-A, Cmd-X, Cmd-V... fast and clean for expert users. (This action
requires an empty to work.)

C) You make a partial selection of a bezier object in Illustrator, say
the bevelled corner of a shape. You want to remove that section from
the original object and attach it to five other objects. Move would not
work at all for this. Further, if you used copy to do this, you would
have the extra step of going back to original object and using delete.
Not as efficient as cut and paste.

D) You have an object in an AI file that needs to be removed from one
file and placed into five other files based on creative review of the
project. Again, if you use copy here, you'd have to go the extra step
of reselecting the original object in the original file and delete it.

InDesign has variations on these. I leave you to use your imagination
to find more scenarios like these or similar to these. And don't forge
the HTML coding example I presented before, and the pasting snippets
into email docs as well.

> If you can implement CaP between applications you can implement MaC
> between applications. There is no difference in the underlying code,
> just in what commands you invoke to move the material.

There is difference in behavior, and all users care about is behavior.
I was actually referring to that aspect, not the code.

Andrei

29 Aug 2004 - 10:39pm
Donna Maurer
2003

I'm not seeing any of Jef's responses through the list, which makes it
looks like you are publicly replying to a private message ;)

Donna

At 01:25 PM 8/30/2004, you wrote:
>Not sure what is going on, but the reply header keeps changing, leading me
>beleive this thread is broken for most readers o fthe list.
>
>On Aug 29, 2004, at 9:29 AM, Jef Raskin wrote:
>
>>And how do you know if a design doing less and producing more? That's
>>where quantitative measures help. Heuristics such as you give here are
>>vague and can lead to disagreement as to which of various methods
>>requires "doing less" and which are "doing more". Certainly reducing
>>repetitive tasks is a good idea, but if you have a few ways to reduce,
>>how do you determine which is best? Part of the advance of science comes
>>with providing objective measures. The quantitative approach to
>>efficiency is a much more powerful tool than your hints, and should be
>>used whenever appropriate.
>

-------------------------------------------------
Donna Maurer
Usability Specialist
Step Two Designs Pty Ltd
Knowledge Management / Content Management / Intranets

http://www.steptwo.com.au/
donna at steptwo.com.au
(02) 6162 6307

-------------------------------------------------
New Workshop: Introductory Information Architecture
http://www.steptwo.com.au/seminars/041013/index.html

30 Aug 2004 - 2:38am
Andrei Herasimchuk
2004

On Aug 29, 2004, at 10:29 PM, Jef Raskin wrote:

> This is one problem in our discussion that we can easily fix, and that
> is to define how Move is invoked. (This information is all in
> specification SP0001v7x on my web site). As the spec explains, here's
> how it works:
> (1) select source (it becomes highlighted)
> (2) establish target point
> (3) execute Move command.

> As you see, MaC is not only safer as we've agreed, but MaC requires
> fewer steps than CaP and is more efficient on that ground alone, let
> alone the efficiency of not losing the cut buffer occasionally.
> Defining the Move command as Cmd-M, we see that MaC also has a lower
> keystroke count than CaP.

(Like I'm able to find "SP0001v7x" on your web site... Have you used
your web site? Have you used the search field on your web site?)

Your step #2 seems vague and incomplete. How does one establish this
target in one fell swoop? Command-Click? Some secret menu or gesture?
Do they will into being?

There are two critical aspects to step 2, what kind of target (an
insertion point or a selection which requires specific use of the
mouse) and that it's a target (which requires some kind of command).
Otherwise, it's just a selection or insertion point. With cut and
paste, there's need to "establish" a target. The paste command by its
execution turns whatever the selection is into a target at that time.)
The other way is to select the source and mark it as a source so as not
to need to establish a targget, which would mean step 1 is split into
two steps.

Either way, you're missing a step.

So, how are proposing your step 2 is actually one step? Specifically.
What does the user do with the mouse and keyboard to make step 2 occur
in one fell swoop?

> This compares well with current GUI technique for copying using CaP:
> (1) select source (it becomes highlighted)
> (2) execute Cut command
> (3) execute Paste command
> (4) establish target point
> (5) execute Paste command
>
> To make additional copies in other places repeat steps (4) and (5).

What is #3 doing here? There's only 4 steps to using cut and paste.

> Thus MaC is easier to learn, faster to use, and safer than CaP. All it
> lacks is familiarity, but that will come with time.

You're sounding like a neo-con now. Keep repeating the same thing over
and over until it becomes a reality, perceived or otherwise.

Look over my examples again, I don't see at all how your move method
would help. Even with this new change which I'm not sure works as
advertised. A move command as far as I can tell takes content and moves
it, meaning it's no longer in its original location. How on earth does
that help in the cases I mentioned? I don't want to move a bunch of
stuff. I want to cut it from one location and paste into multiple
locations! All without having to go back to the original, reselect it
and delete it.

> It should also now be clear how MaC would work with your examples

No, it's not. Enlighten me.

> (the second is just a side-effect, a hack really, and has nothing to
> do with CaP in particular; a similar hack could be devised for MaC.

It's not a hack, but a nice side effect of intended behavior. In other
words, it works as designed due to how Photoshop works with empty layer
and pasted data. Something that many users rely on. But again,
enlighten me. How would one center pixel data on an empty layer using
move in Photoshop? The only way I can think of is creating a specific
command that did it, because in the UI you presented above, there's no
way to clear the current target layer using your move UI.

> In either case it would be better to have an explicit command for
> centering than to have that be an accidental and unguessable
> consequence of deleting and replacing something).

It's not accidental. It's a specified behavior of the program that is
also documented in the manuals. Something has to happen when a users
pastes data, cut or copied. Photoshop centers it if no selection is
present, or centers it on a selection if one is present. If the layer
is empty, Photoshop puts into that layer instead of creating a new
layer.

No accidental at all. Planned, intentioned and documented. And like all
tools, when users work with them, they discovers uses for them based on
these sorts of behaviors. There's nothing wrong with that.

As for it being better to have an explicit command. That might be true.
But considering the already unwieldily number of commands and actions
in a program like Photoshop, adding yet another menu item to do
something this specific which can easily be done once one understands
how the program works is mighty far down on the totem pole of things to
add or improve.

That whole practicality thing again.

Andrei

30 Aug 2004 - 3:00am
Andrei Herasimchuk
2004

> With cut and paste, there's need to "establish" a target.

That should read: ...there's no need to "establish" a target.

Andrei

30 Aug 2004 - 6:47am
hilhorst
2004

I would like to add my thoughts to the CaP (Copy-and-Paste) vs. SaM
(Select-and-Move) discussion. Definitively not because I know enough
about interface design to challenge the points made by Andrei and Jef,
but rather because I'm interested in understanding the fundamentals of
this debate and also because this pertains to the basic issues of
interface design.

Jeff, at the THE DESKTOP LINUX SUMMIT CONFERENCE (22 apr. 2004) you said
that "For example we often move things with cut-and-paste. But if the
dog gets into an argument with a skunk after you've cut something, and
you forget to paste it, the next time you cut something, there goes your
million-dollar idea. Maybe you can retrieve it, but if you can, it's
because you managed to learn a fix for a dumb initial design. It is a
lot easier on users to provide, instead of cut-and-paste, a
select-and-move model (with a move command, not a drag-and-drop with the
mouse). It is trivial to learn, even for cut-and-paste users, and you
never accidentally lose material."
(http://humane.sourceforge.net/the/linux_keynote.html)

In Windows XP (my current OS) the CaP function seems to behave
differently depending on context. Let me give 2 examples to illustrate
that difference:

1. Desktop (OS level)
If the dog gets into an argument with a skunk after I've cut (ctrl+x) a
desktop icon, that particular desktop icon will not be lost. It will
only be removed from its initial location if the paste (ctrl+v) function
has been effectively used. If I decide to cut another item instead, the
initial item will remain where it is. The OS assumes that CaP is a
workflow that consists of two *combined* tasks and will only perform the
action if those two tasks have both been performed (thus cut AND paste)

2. Word (Application level)
If the dog gets into an argument with a skunk after I've cut (ctrl+x)
some text, that particular passage will be "cut" immediately. It will be
removed from its initial location before the paste (ctrl+v) function has
been used. If I decide to cut another item instead, the initial item
will have dissapeared (and indeed, with it my million dollar idea.) The
application assumes that CaP is a workflow that consists of two
*separate* tasks.

I think situation no. 1. is preferable because it avoids the "if the dog
gets into an argument with a skunk after cutting" problem. Besides in
example no. 2. cut replaces the delete function (except it stores the
deleted item(s) into memory, clipboard or similar.) I personally assume
that situation no. 1. is how most people would like to see CaP behave
(of course I have not tested this hypothesis, so it's just an
assumption.) In Word the problem could be simply fixed by graying out
the passage that has just been cut (or otherwise indicate the performed
cut action). If in the meantime another cut function has been performed
the initial selection remains as it is (original state, not grayed out
anymore of course.) I'd like to refer to this as a "cohesive
cut-and-paste": a cut function will only be applied after a paste
function, not immediately.

Jeff, from your keynote I deduce that you propose to replace CaP with
SaM as opposed to have both functions available (please correct me if
I'm wrong.) In my opinion both CaP and SaM have their place in modern
GUI's and SaM would be a welcome addition, but I believe that CaP and
SaM have different inherent functionalities (to some degree):

SaM
---
Moving an item means moving it from location A to location B, for
example.

1. A ---> B

It is indeed similar to what most people use CaP for: moving an item
from one location to another. My judgement is that SaM would indeed make
this task quicker, easier and less risky for users compared to CaP. I
also think users can learn this function pretty quickly since everybody
has a fairly clear mental model of "moving", similar to moving physical
objects.

Or as Jef states in DOCUMENT SP0001 V0077:

"MOVE COMMAND
To use this command, you begin with a selection. Then you LEAP and/or
Creep the cursor to a new location and invoke this command, which
inserts the selection at the current cursor position as if it had been
typed there (except that formatting and other attributes are preserved:
this is an exact copy). The original selection is then deleted. The
command does not place a copy in the Deletions Document. After the
insertion, the moved selection is left selected with the cursor on the
character following the selection."
(http://humane.sourceforge.net/the/spec.html)

CaP
---
Cut-and-Paste can do different things: move an item from location A to
location B, but additionally duplicate it to location C and D, for
example

2. A ---> B

--> B
/
3. A ---> C
\
--> D

Now, as I see it, SaM would not be able to perform the task depicted in
figure 3. When Andrei mentioned his HTML example (with snippits of code)
he was refering to exactly this functionality (I think...) Now, granted,
this could be easily fixed by introducing a "duplicate" function with
SaM, creating a "Move-and-Duplicate" function together with
"Select-and-Move."

But in my opinion this would essentially just be renaming Cut-and-Paste
to Select-and-Move or Move-and-Duplicate, and not necessarily adding any
new functionalities or changing the way users use a system
(fundamentally.) The problem, in my opinion, lies in the way CaP
behaves. Cut and paste should be complementary tasks (cohesive), so to
speak. Cut actions will only be performed if users invoke subsequent
paste actions. Therefor a new cut action without the subsequent paste
action will cancel the initial cut action. Maybe I'm wrong, but to me
that seems to solve the issue.

Didier.

29 Aug 2004 - 10:50pm
Andrei Herasimchuk
2004

On Aug 29, 2004, at 8:39 PM, Donna Maurer wrote:

> I'm not seeing any of Jef's responses through the list, which makes it
> looks like you are publicly replying to a private message ;)

Yeah... I figured that might be the case.... Ever now and then, Jef is
responding to me, but only including this email address:
discuss at ixdg.org while also keeping my name in the header (otherwise I
wouldn't see the message as I don't subscribe to ixdg.org that I know
of.) But it seems that the original email that I've used for this list
is what works:
discuss-interactiondesigners.com at lists.interactiondesigners.com

So, I have no idea which is the right email to use and have been trying
to use both when I catch it.

Andrei

30 Aug 2004 - 12:29am
Jef Raskin
2004

On Aug 29, 2004, at 8:25 PM, Andrei Herasimchuk wrote:
>>>
>>
>> All I said is that I have experience with users in systems with Move
>> and Copy in particular and that I didn't think you did. Was I wrong?
>
> Yes you were wrong.

Please give me a reference to the system you tested with Move and Copy
instead of Cut and Paste, that is a system I'd like to know about.
Thanks in advance.

>>
>
> First, we have to make some assumption on how move would work, and
> from my understanding it would be like this:
>
> 1) Select source.
> 2) Choose Start Move from menu or its command key equivalent.
> (I assume this is a start of the move command, so I'm not sure what
> you think it would be called. I also assume the source content is
> somehow highlighted, but does not disappear from its location. If it
> disappeared, it would basically be Cut and Paste with different menu
> names.)
> 3) Find target point, insertion or selection.
> 4) Execute Finish Move command from menu or its command key
> equivalent. The content from original source moves to new location.
>
> Based on that interface, here are some things that would not work with
> Photoshop and Illustrator:

Based on that interface I would not want to use Move myself. It's not
even noun-verb.

This is one problem in our discussion that we can easily fix, and that
is to define how Move is invoked. (This information is all in
specification SP0001v7x on my web site). As the spec explains, here's
how it works:
(1) select source (it becomes highlighted)
(2) establish target point
(3) execute Move command.

Cut-and-Paste (as in current GUIs) operates like this:
(1) select source (it becomes highlighted)
(2) execute Cut command
(3) establish target point
(4) execute Paste command.

As you see, MaC is not only safer as we've agreed, but MaC requires
fewer steps than CaP and is more efficient on that ground alone, let
alone the efficiency of not losing the cut buffer occasionally.
Defining the Move command as Cmd-M, we see that MaC also has a lower
keystroke count than CaP.

I apologize for not having specified the interface to Move, I had
incorrectly assumed that you had looked up my work prior to discussing
it. Now it occurs to me that perhaps the system with Move and Copy you
tested operated as per your description, in which case I would expect
Move to be quite annoying to use. I'm still interested in learning
about the system, however.

For the record, Copy works like this:
(1) select source (it becomes highlighted)
(2) establish target point
(3) execute Copy command

To make additional copies in other places, repeat steps (2) and (3). If
you omit step (2), then you get a copy concatenated to the original.

This compares well with current GUI technique for copying using CaP:
(1) select source (it becomes highlighted)
(2) execute Cut command
(3) execute Paste command
(4) establish target point
(5) execute Paste command

To make additional copies in other places repeat steps (4) and (5).

It is easier to learn a system that requires three steps than one that
requires four or five, as the individual steps are of equal complexity
for both systems, and the number of commands to be learned is also
equal. To use CaP requires a more complex strategy, and you use both
commands in each instance; this also makes CaP harder to learn. MaC is
quite straightforward by comparison: you use the Move command to move
something and the Copy command to copy something.

Thus MaC is easier to learn, faster to use, and safer than CaP. All it
lacks is familiarity, but that will come with time.

But now I understand why you thought that MaC was less efficient than
CaP, it was a bad implementation of MaC that you were discussing. It
should also now be clear how MaC would work with your examples (the
second is just a side-effect, a hack really, and has nothing to do with
CaP in particular; a similar hack could be devised for MaC. In either
case it would be better to have an explicit command for centering than
to have that be an accidental and unguessable consequence of deleting
and replacing something).

Jef

30 Aug 2004 - 12:30am
Jef Raskin
2004

On Aug 29, 2004, at 8:25 PM, Andrei Herasimchuk wrote:
>>>
>>
>> All I said is that I have experience with users in systems with Move
>> and Copy in particular and that I didn't think you did. Was I wrong?
>
> Yes you were wrong.

Please give me a reference to the system you tested with Move and Copy
instead of Cut and Paste, that is a system I'd like to know about.
Thanks in advance.

>>
>
> First, we have to make some assumption on how move would work, and
> from my understanding it would be like this:
>
> 1) Select source.
> 2) Choose Start Move from menu or its command key equivalent.
> (I assume this is a start of the move command, so I'm not sure what
> you think it would be called. I also assume the source content is
> somehow highlighted, but does not disappear from its location. If it
> disappeared, it would basically be Cut and Paste with different menu
> names.)
> 3) Find target point, insertion or selection.
> 4) Execute Finish Move command from menu or its command key
> equivalent. The content from original source moves to new location.
>
> Based on that interface, here are some things that would not work with
> Photoshop and Illustrator:

Based on that interface I would not want to use Move myself. It's not
even noun-verb.

This is one problem in our discussion that we can easily fix, and that
is to define how Move is invoked. (This information is all in
specification SP0001v7x on my web site). As the spec explains, here's
how it works:
(1) select source (it becomes highlighted)
(2) establish target point
(3) execute Move command.

Cut-and-Paste (as in current GUIs) operates like this:
(1) select source (it becomes highlighted)
(2) execute Cut command
(3) establish target point
(4) execute Paste command.

As you see, MaC is not only safer as we've agreed, but MaC requires
fewer steps than CaP and is more efficient on that ground alone, let
alone the efficiency of not losing the cut buffer occasionally.
Defining the Move command as Cmd-M, we see that MaC also has a lower
keystroke count than CaP.

I apologize for not having specified the interface to Move, I had
incorrectly assumed that you had looked up my work prior to discussing
it. Now it occurs to me that perhaps the system with Move and Copy you
tested operated as per your description, in which case I would expect
Move to be quite annoying to use. I'm still interested in learning
about the system, however.

For the record, Copy works like this:
(1) select source (it becomes highlighted)
(2) establish target point
(3) execute Copy command

To make additional copies in other places, repeat steps (2) and (3). If
you omit step (2), then you get a copy concatenated to the original.

This compares well with current GUI technique for copying using CaP:
(1) select source (it becomes highlighted)
(2) execute Cut command
(3) execute Paste command
(4) establish target point
(5) execute Paste command

To make additional copies in other places repeat steps (4) and (5).

It is easier to learn a system that requires three steps than one that
requires four or five, as the individual steps are of equal complexity
for both systems, and the number of commands to be learned is also
equal. To use CaP requires a more complex strategy, and you use both
commands in each instance; this also makes CaP harder to learn. MaC is
quite straightforward by comparison: you use the Move command to move
something and the Copy command to copy something.

Thus MaC is easier to learn, faster to use, and safer than CaP. All it
lacks is familiarity, but that will come with time.

But now I understand why you thought that MaC was less efficient than
CaP, it was a bad implementation of MaC that you were discussing. It
should also now be clear how MaC would work with your examples (the
second is just a side-effect, a hack really, and has nothing to do with
CaP in particular; a similar hack could be devised for MaC. In either
case it would be better to have an explicit command for centering than
to have that be an accidental and unguessable consequence of deleting
and replacing something).

Jef
On Aug 29, 2004, at 8:39 PM, Donna Maurer wrote:

> I'm not seeing any of Jef's responses through the list, which makes it
> looks like you are publicly replying to a private message ;)
>
> Donna
>
> At 01:25 PM 8/30/2004, you wrote:
>> Not sure what is going on, but the reply header keeps changing,
>> leading me beleive this thread is broken for most readers o fthe
>> list.
>>
>> On Aug 29, 2004, at 9:29 AM, Jef Raskin wrote:
>>
>>> And how do you know if a design doing less and producing more?
>>> That's where quantitative measures help. Heuristics such as you give
>>> here are vague and can lead to disagreement as to which of various
>>> methods requires "doing less" and which are "doing more". Certainly
>>> reducing repetitive tasks is a good idea, but if you have a few ways
>>> to reduce, how do you determine which is best? Part of the advance
>>> of science comes with providing objective measures. The quantitative
>>> approach to efficiency is a much more powerful tool than your hints,
>>> and should be used whenever appropriate.
>>
>
>
> -------------------------------------------------
> Donna Maurer
> Usability Specialist
> Step Two Designs Pty Ltd
> Knowledge Management / Content Management / Intranets
>
> http://www.steptwo.com.au/
> donna at steptwo.com.au
> (02) 6162 6307
>
> -------------------------------------------------
> New Workshop: Introductory Information Architecture
> http://www.steptwo.com.au/seminars/041013/index.html
> _______________________________________________
> 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/
>

29 Aug 2004 - 11:29am
Jef Raskin
2004

> Andrei,

Let me pare this down some:

>>> 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.

And how do you know if a design doing less and producing more? That's
where quantitative measures help. Heuristics such as you give here are
vague and can lead to disagreement as to which of various methods
requires "doing less" and which are "doing more". Certainly reducing
repetitive tasks is a good idea, but if you have a few ways to reduce,
how do you determine which is best? Part of the advance of science
comes with providing objective measures. The quantitative approach to
efficiency is a much more powerful tool than your hints, and should be
used whenever appropriate.

>
>>> 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 this context?

Using Move was clearly the wrong thing to do. If you are wise enough to
duplicate the message in a Cut-and-Paste (CaP) environment then you
would be wise enough to start by using Copy instead of Move.

> 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.

All I said is that I have experience with users in systems with Move
and Copy in particular and that I didn't think you did. Was I wrong?

>
> 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 well.

What is the place for CaP which is no faster or more powerful than MaC
when the former has user risks the latter doesn't have?

>
>>> 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
>> broken.
>
> This is a lofty goal, but one that gets many usability and research
> people into serious trouble.

And what is wrong with lofty goals? And if it gets some people in
trouble that does not mean that it will get all people in trouble.
Lofty goals are what we should be shooting for. Perhaps you set your
sights too low.

>
> 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 designed.
>
> Sometimes is ok to make people learn how to do something, even if that
> something is a bit dangerous.

It is OK, if necessary, with the important exception that if you can
give the same or better functionality with something that is not
dangerous, you should do so. Thus the moral imperative to provide MaC
instead of CaP.

> 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.

Skimmed parts of my book a few years ago? And you critique it on that
basis? That's lame.

>
> 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.

That you choose to use a particular tool is no evidence in its favor.
If you want to make that statement stick you must show why MaC would
feel awkward (aside from your unfamiliarity with it) and where would it
not be optimal. You have yet to give an example.

> 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?

Just one case would do. So far we have zero.

> 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.

Again, show me even one example where CaP makes more sense (not: is
more familiar) than MaC.

>
>>> 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,
>>
>> That is an implementation issue, it is independent of whether to use
>> Cut-and-paste or Move-and-copy.
>
> How so?

If you can implement CaP between applications you can implement MaC
between applications. There is no difference in the underlying code,
just in what commands you invoke to move the material.

Jef

30 Aug 2004 - 9:20am
Jef Raskin
2004

>

Let us stick to solving one simple problem first, and make it clear how
CaP and MaC work.

> Your step #2 seems vague and incomplete. How does one establish this
> target in one fell swoop? Command-Click? Some secret menu or gesture?
> Do they will into being?

Point to the target. Click. It works exactly as does CaP.

> With cut and paste, there's need to "establish" a target.

It is tempting to adopt your sarcasm, and ask "How does one establish
where the material is to be pasted in one fell swoop? Command-Click?
Some secret menu or gesture? Do they will into being?" But no need for
that: you just point and click where you want it inserted.

The step of pointing to where you want the material to end up is the
same for both methods.
>
>
>> This compares well with current GUI technique for copying using CaP:
>> (1) select source (it becomes highlighted)
>> (2) execute Cut command
>> (3) execute Paste command
>> (4) establish target point
>> (5) execute Paste command
>>
>> To make additional copies in other places repeat steps (4) and (5).
>
> What is #3 doing here? There's only 4 steps to using cut and paste.

My copy of the email has this:

Cut-and-Paste (as in current GUIs) operates like this:
(1) select source (it becomes highlighted)
(2) execute Cut command
(3) establish target point
(4) execute Paste command.

I agree that there are only 4 steps.

You were quoting from my example of how to make a copy with cut and
paste, as your excerpt shows, leaving the original in place.

Once you understand how MaC works and we agree on what a step is, then
perhaps we can discuss more complex examples.

30 Aug 2004 - 12:41pm
Andrei Herasimchuk
2004

On Aug 30, 2004, at 7:20 AM, Jef Raskin wrote:

>> Your step #2 seems vague and incomplete. How does one establish this
>> target in one fell swoop? Command-Click? Some secret menu or gesture?
>> Do they will into being?
>
> Point to the target. Click. It works exactly as does CaP.

At which point the previous selection is now gone due to the mouse
click. If the previous selection were to stay highlighted, that would
require new visual behaviors and interaction behaviors so as not
confuse people that the past selection is hanging around in the random
case they decide to execute the move command. This would have its own
set of issues to solve that might make this new command not as optimal
as your simple sweeping, generic "they just click somewhere else and
move." Conversly, if the system uses what the last selection was with
no visual clues at all, that can lead to issues where the user might
make mistakes or forget what the last selection was, therefore moving
the wrong thing and potentially finding themselves pulling the string
of a sweater and compounding errors as they attempt to fix the move.

I had assumed you would have covered either of these issues, which is
why I also assumed there was more to your step #2. And let's not
forget, this is not just email and writing documents we are talking
about, but pixel editing, vector data, tabular data, 3D modeling, etc.
This move command has to work universally with different kinds of
window and data contexts.

So given the issues above, how does the system know what to move? You
have to have some way of telling the system that the new click does not
destroy the initial selection but uses that previous selection for this
new move action, which may or may not be the next thing the user does
or wants to do.

> It is tempting to adopt your sarcasm, and ask "How does one establish
> where the material is to be pasted in one fell swoop? Command-Click?
> Some secret menu or gesture? Do they will into being?" But no need for
> that: you just point and click where you want it inserted.

See above regarding the click. Just write down the steps explicitly --
more so than you're original three -- and we'll all get past it.

>> What is #3 doing here? There's only 4 steps to using cut and paste.
>
> My copy of the email has this [Only one paste command.]

Well... you sent the wrong message then. I didn't make that up. Check
the record.

> Once you understand how MaC works and we agree on what a step is, then
> perhaps we can discuss more complex examples.

You have failed to make it clear how your version of MaC would work, as
far as I'm concerned.

Andrei

30 Aug 2004 - 2:30pm
Alain D. M. G. ...
2003

But why call it MaC when in fact the user actions are TaM or SaM?

Alain Vaillancourt

__________________________________________________________
Lèche-vitrine ou lèche-écran ?
magasinage.yahoo.ca

30 Aug 2004 - 8:22pm
Andrei Herasimchuk
2004

On Aug 30, 2004, at 5:15 PM, Jef Raskin wrote:

> The information you seek is explained at keystroke-level detail in
> http://humane.sourceforge.net/the/spec.html

Cut us all a break and just snip the simple text from this. I'm not
going to take the time to search through a verbose, arcane, novella
length spec that is poorly formatted to try and find a simple
description of the UI for your proposed move command. It was hard
enough trying to read through earlier versions of this document when I
downloaded THE a couple of years ago.

(And last time I checked, this spec makes no mention of other objects
types like pixel editing, vector editing, 3D modeling, etc.)

Andrei

30 Aug 2004 - 9:25pm
Alain D. M. G. ...
2003

Target and Move or Select and Move. A person using it has to Target or
Select before moving if I understand this system, in the same way a
person as to Cut before Pasting in the current widespread ones. So why
invert the order?

--- Jef Raskin <jef at jefraskin.com> a écrit :
> It stands for "Move and Copy" What are T, M, and S in your
> abbreviations?
>
> On Aug 30, 2004, at 12:30 PM, Alain D. M. G. Vaillancourt wrote:
>
> > But why call it MaC when in fact the user actions are TaM or SaM?
> >
> > Alain Vaillancourt
> >
> >
> >
> > __________________________________________________________
> > Lèche-vitrine ou lèche-écran ?
> > magasinage.yahoo.ca
> >
>
>

__________________________________________________________
Lèche-vitrine ou lèche-écran ?
magasinage.yahoo.ca

3 Sep 2004 - 5:43pm
Andrei Herasimchuk
2004

Been a busy week so far. Just getting around to this.

On Aug 30, 2004, at 11:23 PM, Jef Raskin wrote:

> You had said you wanted detail down to the keystroke level: the spec
> has the detail down to the keystroke level and puts it into context.
> Now you say that it's too much bother for you to take the time to read
> and understand it.

First, you have to find the spec on your website, which is buried as
"Tech Spec v77" in the sidebar among what appears to be 100+ other
links. As for the spec itself, there's very little formatting to help
the reader parse the various sections. There's no use of illustrations
to example scan and parse the examples, and the illustration that are
there are textual illustrations, which are difficult to understand at
best. Finally, the language is hard to follow both due to to sentence
structure, large use of terminology and jargon. All of the combine to
make the spec only readable by the most dedicated reader.

Sorry, but I'm THAT emotionally invested in this debate to spend hours
and hours grokking your tech spec over something as minor as move
versus cut and paste, when I think the points about this debate are
very clear and straight forward, requiring very little background
knowledge to discuss.

As for your specific Move UI, the specs says,

"MOVE COMMAND. To use this command, you begin with a selection. Then
you LEAP and/or Creep the cursor to a new location and invoke this
command, which inserts the selection at the current cursor position as
if it had been typed there (except that formatting and other attributes
are preserved: this is an exact copy). The original selection is then
deleted. The command does not place a copy in the Deletions Document.
After the insertion, the moved selection is left selected with the
cursor on the character following the selection."

From what I can tell, this seems to use nothing but a text editing
interface and after having used THE in the past, I assume this is all
it encompasses. (Thee rest of spec seems to confirm this from a quick
scan.) Further, it does not take into account a mouse or windowing
environment where when the context switches, visual clues play a vital
role in the UI for the user.

My initial point from before about the previous selection needing to be
tagged or some visual indicator needing to occur when the user clicks
and loses the previous selection still remains. You have yet to address
the point as I described, using my desire to not weed through your
long, hard to read and scan spec as some excuse to avoid the point in
contention.

> That's your prerogative. But you thereby have lost your credibility in
> arguments about my methods: you don't understand them yet you refuse
> to do the work needed to gain the understanding you'd need to discuss
> them meaningfully.

Jef, for someone who criticizes current interfaces and makes such a
ruckus about humane interfaces -- and for someone with your background
in this field -- you would do well to lead by example and write
specifications that are easy to read, easy to navigate, and
straight-forward for the majority of the audience to understand using
clear, simple language. Your tech specs are anything but. Some
practical use of formatting, some links in the spec to make it easy to
move around, less use of walls of text and yes some visual examples
would all contribute significantly in helping people to understand the
work. http://www.designbyfire.com/000094.html

Outside of that, I'm still waiting to hear you address the points I
made regarding the usefulness of cut and paste that are not addressed
by your move interface proposal. If you refuse to address those points
and want to believe that that cut and paste is badly deigned and has no
place in modern interfaces, then I guess this conversation is over. I
have clearly shown a few places where it makes perfect sense and is
quite useful, but I guess I don't count as a user in my own right. And
my experience in designing interfaces also means nothing in that
regard.

Once again, for the record, I agree that move is a great new function
to add to the toolbox. It does not replace cut and paste, nor is cut
and paste badly designed.

Andrei

30 Aug 2004 - 12:46pm
Andrei Herasimchuk
2004

On Aug 30, 2004, at 4:47 AM, Didier Hilhorst wrote:

> Now, as I see it, SaM would not be able to perform the task depicted in
> figure 3. When Andrei mentioned his HTML example (with snippits of
> code)
> he was refering to exactly this functionality (I think...) Now,
> granted,
> this could be easily fixed by introducing a "duplicate" function with
> SaM, creating a "Move-and-Duplicate" function together with
> "Select-and-Move."

That is what I was referring to, yes.

> But in my opinion this would essentially just be renaming Cut-and-Paste
> to Select-and-Move or Move-and-Duplicate, and not necessarily adding
> any
> new functionalities or changing the way users use a system
> (fundamentally.)

Agreed.

> The problem, in my opinion, lies in the way CaP
> behaves. Cut and paste should be complementary tasks (cohesive), so to
> speak. Cut actions will only be performed if users invoke subsequent
> paste actions. Therefor a new cut action without the subsequent paste
> action will cancel the initial cut action. Maybe I'm wrong, but to me
> that seems to solve the issue.

Microsoft Excel has worked this way for years using cut, if I
understand you correctly. (Although it did it based on awkward manner
in which it was originally coded as far as I know.) In some ways, it's
nice, but in some ways, it's a pain. Part of the use of cut is that it
removes the visual noise which can lead to making decisions by the
user. That was a key factor in my #A example in my previous message in
this thread.

Andrei

30 Aug 2004 - 6:03pm
Jim Kauffman
2004

Jef Raskin wrote:

>
> Based on that interface I would not want to use Move myself. It's not
> even noun-verb.
>
> This is one problem in our discussion that we can easily fix, and that
> is to define how Move is invoked. (This information is all in
> specification SP0001v7x on my web site). As the spec explains, here's
> how it works:
> (1) select source (it becomes highlighted)
> (2) establish target point
> (3) execute Move command.
>
> Cut-and-Paste (as in current GUIs) operates like this:
> (1) select source (it becomes highlighted)
> (2) execute Cut command
> (3) establish target point
> (4) execute Paste command.
>
> As you see, MaC is not only safer as we've agreed, but MaC requires
> fewer steps than CaP and is more efficient on that ground alone, let
> alone the efficiency of not losing the cut buffer occasionally.
> Defining the Move command as Cmd-M, we see that MaC also has a lower
> keystroke count than CaP.
>
> I apologize for not having specified the interface to Move, I had
> incorrectly assumed that you had looked up my work prior to discussing
> it. Now it occurs to me that perhaps the system with Move and Copy you
> tested operated as per your description, in which case I would expect
> Move to be quite annoying to use. I'm still interested in learning
> about the system, however.
>
> For the record, Copy works like this:
> (1) select source (it becomes highlighted)
> (2) establish target point
> (3) execute Copy command
>
> To make additional copies in other places, repeat steps (2) and (3).
> If you omit step (2), then you get a copy concatenated to the original.
>
> This compares well with current GUI technique for copying using CaP:
> (1) select source (it becomes highlighted)
> (2) execute Cut command
> (3) execute Paste command
> (4) establish target point
> (5) execute Paste command
>
> To make additional copies in other places repeat steps (4) and (5).
>
> It is easier to learn a system that requires three steps than one that
> requires four or five, as the individual steps are of equal complexity
> for both systems, and the number of commands to be learned is also
> equal. To use CaP requires a more complex strategy, and you use both
> commands in each instance; this also makes CaP harder to learn. MaC is
> quite straightforward by comparison: you use the Move command to move
> something and the Copy command to copy something.
>
Jef,

MaC sounds like the old WordStar block commands. Not GUI, of course, but
the concept is similar.

I suspect that Cut/Paste is a remnant of tight RAM restraints,
specifically the original 128K Macintosh. Did it originate on the Xerox
GUI, or the Mac GUI?

Jim K.

30 Aug 2004 - 7:15pm
Jef Raskin
2004

Andrei,

The information you seek is explained at keystroke-level detail in

http://humane.sourceforge.net/the/spec.html

Jef

On Aug 30, 2004, at 10:41 AM, Andrei Herasimchuk wrote:

> On Aug 30, 2004, at 7:20 AM, Jef Raskin wrote:
>
>>> Your step #2 seems vague and incomplete. How does one establish this
>>> target in one fell swoop? Command-Click? Some secret menu or
>>> gesture? Do they will into being?
>>
>> Point to the target. Click. It works exactly as does CaP.
>
> At which point the previous selection is now gone due to the mouse
> click. If the previous selection were to stay highlighted, that would
> require new visual behaviors and interaction behaviors so as not
> confuse people that the past selection is hanging around in the random
> case they decide to execute the move command. This would have its own
> set of issues to solve that might make this new command not as optimal
> as your simple sweeping, generic "they just click somewhere else and
> move." Conversly, if the system uses what the last selection was with
> no visual clues at all, that can lead to issues where the user might
> make mistakes or forget what the last selection was, therefore moving
> the wrong thing and potentially finding themselves pulling the string
> of a sweater and compounding errors as they attempt to fix the move.
>
> I had assumed you would have covered either of these issues, which is
> why I also assumed there was more to your step #2. And let's not
> forget, this is not just email and writing documents we are talking
> about, but pixel editing, vector data, tabular data, 3D modeling, etc.
> This move command has to work universally with different kinds of
> window and data contexts.
>
> So given the issues above, how does the system know what to move? You
> have to have some way of telling the system that the new click does
> not destroy the initial selection but uses that previous selection for
> this new move action, which may or may not be the next thing the user
> does or wants to do.
>
>> It is tempting to adopt your sarcasm, and ask "How does one establish
>> where the material is to be pasted in one fell swoop? Command-Click?
>> Some secret menu or gesture? Do they will into being?" But no need
>> for that: you just point and click where you want it inserted.
>
> See above regarding the click. Just write down the steps explicitly --
> more so than you're
> original three -- and we'll all get past it.
>
>>> What is #3 doing here? There's only 4 steps to using cut and paste.
>>
>> My copy of the email has this [Only one paste command.]
>
> Well... you sent the wrong message then. I didn't make that up. Check
> the record.
>
>> Once you understand how MaC works and we agree on what a step is,
>> then perhaps we can discuss more complex examples.
>
> You have failed to make it clear how your version of MaC would work,
> as far as I'm concerned.
>
> 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/
>

30 Aug 2004 - 8:56pm
Jef Raskin
2004

It stands for "Move and Copy" What are T, M, and S in your
abbreviations?

On Aug 30, 2004, at 12:30 PM, Alain D. M. G. Vaillancourt wrote:

> But why call it MaC when in fact the user actions are TaM or SaM?
>
> Alain Vaillancourt
>
>
>
> __________________________________________________________
> Lèche-vitrine ou lèche-écran ?
> magasinage.yahoo.ca
>

30 Aug 2004 - 10:29pm
Jef Raskin
2004

> Didier,

> In Windows XP (my current OS) the CaP function seems to behave
> differently depending on context.

Another one of the examples that shows Microsoft's demonstrated
incapacity to produce good interfaces.
>
> Jeff, from your keynote I deduce that you propose to replace CaP with
> SaM

You have introduced term I did not use: "SaM", which I think means
"select and move" but the term I have been using is "MaC" which stands
for the Move and Copy commands. By not discussing the Copy command your
analysis does not apply to my proposal, for example, you say
"Cut-and-Paste can do different things: move an item from location A to
> location B, but additionally duplicate it to location C and D,"

But you can, of course, do that with the Copy command.

Comparing CaP with SaM may be an interesting exercise, but it does not
speak to what I am in favor of.

Jef

31 Aug 2004 - 1:23am
Jef Raskin
2004

> I'm not going to take the time to search through a verbose, arcane,
> novella length spec that is poorly formatted to try and find a simple
> description of the UI for your proposed move command.

You had said you wanted detail down to the keystroke level: the spec
has the detail down to the keystroke level and puts it into context.
Now you say that it's too much bother for you to take the time to read
and understand it.

That's your prerogative. But you thereby have lost your credibility in
arguments about my methods: you don't understand them yet you refuse to
do the work needed to gain the understanding you'd need to discuss them
meaningfully.

31 Aug 2004 - 1:37am
Jef Raskin
2004

Alain,

I now see the source of the confusion. The term "Move and Copy" as I
was using it has nothing to do with the order of actions, it is just a
list of the commands to be used instead of the Cut and Paste commands.
If you wanted to name the conventions in terms of the actions then
we'd need the two other actions involved: Select and Point.

To use Cut and Paste to move then becomes Select, Cut, Point, and Paste.

To use Cut and paste to copy becomes Select, Cut, Paste, Point, and
Paste.

Move becomes Select, Point, and Move.

Copy becomes Select, Point, and Copy.

So we'd have SCPaP, SCPPaP, SPaM, and SPaC. I like that "spam" has
snuck in like an old Monty Python routine. But I think that these
action-list names are a bit awkward. Thus I used MaC and CaP as
shorthands for the range of methods that use each of those pairs of
commands for moving and copying.

Jef

On Aug 30, 2004, at 7:25 PM, Alain D. M. G. Vaillancourt wrote:

> Target and Move or Select and Move. A person using it has to Target or
> Select before moving if I understand this system, in the same way a
> person as to Cut before Pasting in the current widespread ones. So why
> invert the order?
>
> --- Jef Raskin <jef at jefraskin.com> a écrit :
>> It stands for "Move and Copy" What are T, M, and S in your
>> abbreviations?
>>
>> On Aug 30, 2004, at 12:30 PM, Alain D. M. G. Vaillancourt wrote:
>>
>>> But why call it MaC when in fact the user actions are TaM or SaM?
>>>
>>> Alain Vaillancourt
>>>
>>>
>>>
>>> __________________________________________________________
>>> Lèche-vitrine ou lèche-écran ?
>>> magasinage.yahoo.ca
>>>
>>
>>
>
> __________________________________________________________
> Lèche-vitrine ou lèche-écran ?
> magasinage.yahoo.ca
>

3 Sep 2004 - 5:46pm
Andrei Herasimchuk
2004

> Sorry, but I'm THAT emotionally invested in this debate to spend hours
> and hours grokking your tech spec over something as minor as move
> versus cut and paste, when I think the points about this debate are
> very clear and straight forward, requiring very little background
> knowledge to discuss.

Should read: "Sorry, but I'm NOT THAT emotionally invested in this
debate..."

Andrei

5 Sep 2004 - 8:04pm
Jef Raskin
2004

>>
> Jef,
>
> MaC sounds like the old WordStar block commands. Not GUI, of course,
> but the concept is similar.

There are many similarities between word processors in general, It is
the details that make one work better than another. The WordStar
commands were modal, for example, and the method for defining blocks
was clumsy compared to using Leap. (Leap is explained in my book and in
the spec)

>
> I suspect that Cut/Paste is a remnant of tight RAM restraints,
> specifically the original 128K Macintosh. Did it originate on the
> Xerox GUI, or the Mac GUI?

MaC does not require more RAM than CaP. My original design for the Mac
did not have CaP, it was changed by others.

>
>
> Jim K.
>
> _______________________________________________
> 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/
>

Syndicate content Get the feed