Cut and Paste vs. Move (was: Make it quantitative...)

6 Sep 2004 - 9:19am
9 years ago
36 replies
930 reads
Elizabeth Buie
2004

I'd like to describe a few of the ways I use Cut and Paste and why I would
not like to see it replaced by Move (as I understand Move, from current
experience). Before I do that, I'll admit that I have been following this
thread at a high level, skimming some posts (the ad hominem tone of some
of them disturbs me) and reading some of them in reasonable depth... so I
may be bringing up things that others have mentioned already. If so, I
hope you guys will forgive me.

========

Take away Cut and Paste? You'll have to pry it from my cold dead fingers.

First, I don't always use Paste immediately after Cut. If I'm working on
a paragraph and I know I want to remove some of its text and put it
somewhere else, I often Cut it, finish my work on that paragraph, and then
Paste the text into its new location. Of course, I have to remember not
to do another Cut, but so far it has worked pretty well for me.

Second, I don't always know exactly where I want to move the text I'm
Cutting. I Cut it, then read the destination paragraph, then decide
exactly where to Paste it.

Third, sometimes I want to Paste the text into more than one place. Move
doesn't do this unless I hold down the Option key to make a copy.

Fourth, Paste allows more precise cursor control than Move (at least in
the drag-to-move operation with which I am familiar, on both Mac and
Windows platforms). Specifically, I can position the cursor (note: I'm
not talking about the pointer) exactly where I want it and get feedback
that it's in the right place. I can click in the location and move the
pointer away from it to verify that the text insertion cursor is where I
want to put the text.

Fifth (and I think I've seen this mentioned in this thread), it's harder
to scroll while doing a Move because Move requires me to keep the mouse
button pressed and I can't let up on it to use the scroll bar.

Some of the above reflects my use of a Mac, of course, and except in
Photoshop and Virtual PC I tend not to use modifier keys for the mouse.
I'd be curious to know if the proposed Move operation uses mouse modifier
keys to overcome some of my concerns.

Elizabeth

--
Elizabeth Buie
Computer Sciences Corporation
Rockville, Maryland, USA
+1.301.921.3326

----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

Comments

6 Sep 2004 - 11:17am
Nick Ragouzis
2004

Elizabeth Buie wrote
...
>
> I'd like to describe a few of the ways I use
> Cut and Paste and why I would not like to see
> it replaced by Move (as I understand Move,
> from current experience).
...
>
> Take away Cut and Paste? You'll have to pry it
> from my cold dead fingers.
>
...

[Oh, I had so hoped this thread was dead. Will this help
get us closer to slaying the near-dead horse, even if
by weight? That's probably hope over experience.]

I'd have been happier with many of the points here if
we were casting all our arguments in competitive advantage
through delivering usable returns to users. It's a point
that's been mentioned, but I see that the argument gets
less useful when we move (sic) away from that to, say,
just defending or advancing, Move, or Cut.

Where we've heard competitive advantage for user advantage,
and therefore the user context, in this thread, we've heard
that users might happier (have a larger marginal increase in
happiness) if OTHER aspects of their work were addressed.
For example, if in addition to "cut;shiftcontext;paste", or
"mo-shiftcontext-ve", they had the option of not dealing in
such record keeping in this way at all.

In the same way I'm not agreeing that cut-paste is
universally a scourge, nor move a savior, I'm not saying
that users would universally treat this (not dealing in
record keeping) as a gleeful innovation. No matter how
much training (even to overcome or supplant the familiar).
E.g., Elizabeth wants, to paraphrase, to also to be able
to name some of those automatic saves (IOW, to be able to
use Save-As (by any other name)).

In particular, extending Elizabeth's comments re Move, we
also have the case where the question of CnP, or Move, or
of Scratchpads(-with associative retrieval) where the
first-order distinction doesn't concern learning or
key-stroke-level physical or mental efficiency. Rather,
the first-order distinction concerns the context of the
work, or the specific work at hand -- efficiency at a
much higher level.

Such as:

In composing music, CnP or Move is probably less important
than an effective way of organizing 'torn' riffs (and
finding "moved" ones too, to "move" or "copy" again).

In dealing with project plans, anything more complicated
than a meeting agenda quickly cries for associative
retrieval aids rather than either CnP or Move.

In command environments, and operating tools to manage
such environments, CnP vs. Move is a nearly irrelevant
choice, work proceeds in a push-down manner. An aid to
prevent/prohibit 'losing' something (before disposition)
would have higher priority than any question of Move vs
CnP. (You might thing that Move has advantages here, but
then you'll have overlooked that to alter priorities
requires arrival of a higher-priority command (in the
work context, not the UI), whose execution would accomplish
that work w/o a UI CnP or Move ... or with either with
all the necessary contextual protections.)

A tracking environment (such as in inventory, or finance)
might find some of the tasks much improved if you were
prevented from shifting to an inappropriate context (such
as a wrong size carrier; wrong type of controlling account)
as a more important innovation than whether you used
CnP vs Move.

. . .

To paraphrase, it's a question of thinking through the
problem in a way that serves users by returning to them
significant advantage. "Move" doesn't really rise to this
level -- it represents more a change in harnessing horses
to the buggy. Dealing more seriously with the CnP question,
in the way suggested overall in the thread, means taking
up the "shift context" problem.

Doing *that* entails thinking about people, and how the
concerned individuals will use a product **once they've
expended the effort they're likely to invest to learn it
to a level that likely will deliver sufficient on-going
returns**. (Note: that's a distribution, not a point ...
I'm not introducing novice-vs-expert here.)

And *that*, in turn, helps us in understanding an important
error in understanding "intuitive=familiar" ... the
"familiar" part of the equation is not constant. This is
why, to pilots with fixed-wing single-engine instrument
qualification, a 747 *is* very intuitive. This is related
to why aspects of STS system design (shuttle) *now* mimic
FWSE design, to reduce error in times of stress and
distraction (like seeing Earth from above) ... and how
new errors arose.

So, not only is "familiar" not constant, and not based
only on 'concrete' metaphor, and not only on cross-
context transfer (typing text; manipulating 3D mesh),
but it also is non-linear ... where fast- and high-leverage
learning in the earliest parts of training in a subject
(or sub-subject, if that's the structure of the domain)
must quickly return broad returns.

I notice that a tool becomes "unintuitive" where this
last aspect is significantly missing or lacking. Meaning
both senses: a tool can fail from the outset because it
lacks this, or as a user expands their context or
expectations surrounding the tool (again, still not
novice-vs-expert). For the first, to default to the
extreme(complex) -- the oft-quoted life-threatening
contexts. For the latter, to default to the extreme(simple)
-- the oft-quoted hammer, where a cabinet maker is going
to find their favorite and at-hand 300g hammer a poor
answer for working the lock on the door they've just
crafted (too-sharp edges on the face and on the
also-offset prick, over a proper lock hammer).

Unfortunately for many of us, this construction lays bare
a fundamental problem: few of our 'sponsors' will admit
at the outset that their product has a limited audience.
That is: our sponsors' pursuit for competitive advantage
conflicts with delivery of usable returns (advantage,
competitive or otherwise) to users.

Instead we have overreach. And one of the least satisfying
parts of a designer's job, that of dissatisfying the fewest.

Which often leads to fiddling with the mostly irrelevant,
although often at great length, and ferocity.

And verbosity.

FWIW,
--Nick

6 Sep 2004 - 1:29pm
Andrei Herasimchuk
2004

On Sep 6, 2004, at 9:17 AM, Nick Ragouzis wrote:

> Unfortunately for many of us, this construction lays bare
> a fundamental problem: few of our 'sponsors' will admit
> at the outset that their product has a limited audience.
> That is: our sponsors' pursuit for competitive advantage
> conflicts with delivery of usable returns (advantage,
> competitive or otherwise) to users.
> Instead we have overreach. And one of the least satisfying
> parts of a designer's job, that of dissatisfying the fewest.
> Which often leads to fiddling with the mostly irrelevant,
> although often at great length, and ferocity.

Wish I would have said this. It's so perfectly accurate it kills me and
wants me to go take up mountain climbing to forget I ever learned how
to deisgn software.

Andrei

6 Sep 2004 - 2:39pm
Jef Raskin
2004

Your critiques apply nicely to what I could consider a very badly
implemented Move. I am speaking of Move as implemented in the SwyftWare
product, the Canon Cat, and THE. And also as discussed in my most
recent book. A few specific comments below.

On Sep 6, 2004, at 7:19 AM, Elizabeth Buie wrote:

> [For those using lower bandwidth, or the DIGEST version of this list;
> the administrators ask people to voluntarily trim their postings to
> only include relevant quoted material.]
>
> I'd like to describe a few of the ways I use Cut and Paste and why I
> would
> not like to see it replaced by Move (as I understand Move, from current
> experience). Before I do that, I'll admit that I have been following
> this
> thread at a high level, skimming some posts (the ad hominem tone of
> some
> of them disturbs me) and reading some of them in reasonable depth...
> so I
> may be bringing up things that others have mentioned already. If so, I
> hope you guys will forgive me.
>
> ========
>
> Take away Cut and Paste? You'll have to pry it from my cold dead
> fingers.
>
>
> First, I don't always use Paste immediately after Cut. If I'm working
> on
> a paragraph and I know I want to remove some of its text and put it
> somewhere else, I often Cut it, finish my work on that paragraph, and
> then
> Paste the text into its new location. Of course, I have to remember
> not
> to do another Cut, but so far it has worked pretty well for me.

It is that having to remember that's the problem. Sometimes you forget,
and lose your cut work. Any command structure that has a built-in bomb
like that is something that interface designers should fix. This leads
to the MaC methods I've been discussing.

>
> Second, I don't always know exactly where I want to move the text I'm
> Cutting. I Cut it, then read the destination paragraph, then decide
> exactly where to Paste it.

That's how Move works. You select what you want to move, find the
destination and exactly where you want to move the text to, click
there, and execute the Move command.

>
> Third, sometimes I want to Paste the text into more than one place.
> Move
> doesn't do this unless I hold down the Option key to make a copy.

Again, a poor implementation of Move that I would never design or build
into a product. The solution is to have a distinct Copy command.

>
> Fourth, Paste allows more precise cursor control than Move (at least in
> the drag-to-move operation with which I am familiar, on both Mac and
> Windows platforms). Specifically, I can position the cursor (note: I'm
> not talking about the pointer) exactly where I want it and get feedback
> that it's in the right place. I can click in the location and move the
> pointer away from it to verify that the text insertion cursor is where
> I
> want to put the text.

This is what I have been referring to as click-and-drag. It is not a
Move command. We can discuss this some other time.

>
> Fifth (and I think I've seen this mentioned in this thread), it's
> harder
> to scroll while doing a Move because Move requires me to keep the mouse
> button pressed and I can't let up on it to use the scroll bar.

Again, a consequence of a poor design of Move.

>
> Some of the above reflects my use of a Mac, of course, and except in
> Photoshop and Virtual PC I tend not to use modifier keys for the mouse.
> I'd be curious to know if the proposed Move operation uses mouse
> modifier
> keys to overcome some of my concerns.

As I have pointed out, your concerns are not about the Move-and-Copy
(MaC) methods that I have been discussing, and your concerns do not
apply. They are a very good critique of some problematic
implementations.

>
> Elizabeth
>
> --
> Elizabeth Buie
> Computer Sciences Corporation
> Rockville, Maryland, USA
> +1.301.921.3326
>
>
> -----------------------------------------------------------------------
> -----------------
> This is a PRIVATE message. If you are not the intended recipient,
> please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery. NOTE: Regardless of content, this e-mail shall not operate to
> bind CSC to any order or other contract unless pursuant to explicit
> written agreement or government initiative expressly permitting the
> use of
> e-mail for such purpose.
> -----------------------------------------------------------------------
> -----------------
>
> _______________________________________________
> 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/
>

6 Sep 2004 - 3:20pm
Jef Raskin
2004

I think that it is important to take pebbles out of user's shoes as
well as providing them with jet planes. The pile of small insults that
our present interfaces deliver add up to a substantial impediment to
fluid computer use.

It is, to me, very important to create interfaces that a user can
trust. That is why I continue to discuss cut-and-paste, because the
occasional loss of a user's work due to a preventable design flaw is
unacceptable.

If that were the only instance I perhaps would not be worried, but we
may take it as a miner's canary. The standard GUIs abound with dozens
of such small "gotchas". Recognizing them, understanding the distress
they cause users, and fixing them is not "mostly irrelevant" but vital
to user happiness and satisfaction.

And it's marketable.

On Sep 6, 2004, at 9:17 AM, Nick Ragouzis wrote:

>
> Which often leads to fiddling with the mostly irrelevant,
> although often at great length, and ferocity.
>
> And verbosity.
>
> FWIW,
> --Nick
>
> _______________________________________________
> 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/
>

6 Sep 2004 - 3:41pm
Elizabeth Buie
2004

Jef,

I see what you mean.

Your comments pretty much answer my concerns, except in one case. Let me
repeat that one:

<<First, I don't always use Paste immediately after Cut. If I'm working
on a paragraph and I know I want to remove some of its text and put it
somewhere else, I often Cut it, finish my work on that paragraph, and then
Paste the text into its new location. Of course, I have to remember not
to do another Cut, but so far it has worked pretty well for me.>>

You replied:

<<It is that having to remember that's the problem...>>

You didn't address the main point of my comment, which was that very often
I want to delete the text from the source paragraph (section, page,
whatever) and finish working in that area before I turn my attention to
the destination of what I have removed. While I'm finishing up the source
paragraph, I want to keep the cut material handy but out of sight (such as
what a Cut to the Clipboard will do). Do you have a model for a Move
operation that will do this?

Elizabeth

--
Elizabeth Buie
Computer Sciences Corporation
Rockville, Maryland, USA
+1.301.921.3326

----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

6 Sep 2004 - 10:16pm
Jef Raskin
2004

Elizabeth.

> Often I want to delete the text from the source paragraph (section,
> page,
> whatever) and finish working in that area before I turn my attention to
> the destination of what I have removed. While I'm finishing up the
> source
> paragraph, I want to keep the cut material handy but out of sight
> (such as
> what a Cut to the Clipboard will do). Do you have a model for a Move
> operation that will do this?
>
I have two solutions. One, the way THE works, is that there is a
"Deletions Document" where all deletions (even backspacing) appear.
This feature is incredibly handy. Many a time I've gone back to it to
find something I thought I didn't need, but found hard to phrase as
well as I did the first time.

The other, for systems without the Deletions Document, is to just put
it up at the top of your document, above the title perhaps, where you
can easily get it and you won't accidentally confuse it with other
things. I often use this method in working with ordinary text editors.
Of course, without a Deletions Document, it takes extra effort to do
this.

May I invite you to look at the specifications for The Humane
Envirnonment; that may answer a lot of questions. It will be some
months before we have a system you can try out.

Jef

6 Sep 2004 - 11:49pm
Larry Tesler
2004

At 12:39 PM -0700 9/6/04, Jef Raskin wrote:
>That's how Move works. You select what you want to move, find the
>destination and exactly where you want to move the text to, click
>there, and execute the Move command.

The difference between Move in THE and Cut-and-Paste in the standard
GUI is subtle, especially in an application like Microsoft Excel that
defers Cut until Paste.

To move a block of cells in Microsoft Excel (Mac OS version; Windows
is similar):
1 - Click one corner of the source area.
2 - Shift-click the opposite corner.
3 - Issue the Cut command by typing command-X. It stays there and
acquires a marquee.
4 - Click the upper left corner of the destination area.
5 - Issue the Paste command by typing command-V.

To move a block of text in THE per http://humane.sourceforge.net/the/spec.html:
1 - Leap or creep to one end of the source text.
2 - Leap or creep to the other end of the source text.
3 - Issue the Select command by typing command-S. It becomes
highlighted differently.
4 - Leap or creep to the destination character.
5 - Issue the Move command by typing command-M.

Same number of steps. Same effect.

In both systems, Undo after step 5 undoes steps 4 and 5.

Edge cases:

(A) You perform some unrelated command between steps 3 and 4.

- Mac Excel: The Cut is annulled. But the material remains in the
clipboard and can still be pasted. It is as if you had used Copy in
step 3 instead of Cut.
- Windows Excel: The Cut is annulled.
- THE: The Move never started. There is nothing to annul.

(B) After step 5, you repeat steps 4 and 5.

- Mac Excel: The second Step 5 pastes the same material again.
- Windows Excel: The second Step 5 does nothing.
- THE: The spec implies that the second step 5 does nothing.

(C) Between steps 3 and 4, you wish to see the material you are moving.

- Mac/Windows Excel and THE: The material you are planning to move is
still in its original location.

When the Mac/Windows application is a text document, the steps the
user takes are similar:
1 - Click one end of the source text.
2 - Shift-click the opposite end.
3 - Issue the Cut command by typing command-X.
4 - Click the destination.
5 - Issue the Paste command by typing command-V.

Again, same number of steps as in THE. Same ultimate effect. And
again, in both THE and a standard text editor, Undo after step 5
undoes steps 4 and 5.

Edge cases:

(A) You perform some unrelated command between steps 3 and 4 4.

- Mac/Windows. Permitted, as long as the commands do not alter the
Clipboard. Whatever is in the Clipboard when you begin step 5 will be
pasted.
- THE: Permitted, as long as the commands do not alter the Selection.
Whatever is selected when you begin Step 5 will be moved.

This is a pretty small difference.

(B) After step 5, you repeat steps 4 and 5.

- Mac/Windows text editors: The second step 5 pastes the same material again.
- THE: The spec implies that the second step 5 does nothing.

(C) Between steps 3 and 4, you wish to see the material you are moving.

- Mac/Windows text editors: Because Cut is also a way to delete, the
cut material is no longer in the document. On Mac, it is visible in
the Clipboard window. Hardly anyone leaves this window open, but you
could.
- THE: The material you are planning to move is still in its original location.

This is what Jef means when he says that you can lose what you cut.
You may forget you cut it, and never paste it. Not so in Excel. But
true in standard text editors.

Summary
-------

THE and the standard GUI differ far more in the favored way that
selections are made (LEAP keys vs. mouse) than in the way selected
stuff is moved. I don't think that a comparison of the two approaches
should focus on how stuff is moved.

If someone really wanted to eliminate Jef's perceived problem with
Cut and Paste, they could tweak the standard GUI in either of the
following ways:

(i) As in Excel, use something other than Cut to delete. Don't remove
Cut material until the Paste command is issued.

(ii) Implement a visible clipboard window or pane that contains a
history of recent cuts. Some applications do this. I prefer this
option to the other for most applications.

Larry Tesler

7 Sep 2004 - 12:44am
pabini
2004

Jef Raskin wrote: I have two solutions. One, the way THE works, is that
there is a
> "Deletions Document" where all deletions (even backspacing) appear.
> This feature is incredibly handy. Many a time I've gone back to it to
> find something I thought I didn't need, but found hard to phrase as
> well as I did the first time.

***Sounds wonderful!

> The other, for systems without the Deletions Document, is to just put
> it up at the top of your document, above the title perhaps, where you
> can easily get it and you won't accidentally confuse it with other
> things. I often use this method in working with ordinary text editors.
> Of course, without a Deletions Document, it takes extra effort to do
> this.

***Sounds dangerous. I can just see users distributing documents with all of
those deletions at the top, because they never scrolled up again and didn't
know they were there.

Pabini

7 Sep 2004 - 8:40am
Jef Raskin
2004

I entirely agree. I don't know of any non-dangerous option in
conventional systems. Another argument in favor of change.

On Sep 6, 2004, at 10:44 PM, Pabini Gabriel-Petit wrote:

> Jef Raskin wrote: I have two solutions. One, the way THE works, is
> that
> there is a
>> "Deletions Document" where all deletions (even backspacing) appear.
>> This feature is incredibly handy. Many a time I've gone back to it to
>> find something I thought I didn't need, but found hard to phrase as
>> well as I did the first time.
>
> ***Sounds wonderful!
>
>> The other, for systems without the Deletions Document, is to just put
>> it up at the top of your document, above the title perhaps, where you
>> can easily get it and you won't accidentally confuse it with other
>> things. I often use this method in working with ordinary text editors.
>> Of course, without a Deletions Document, it takes extra effort to do
>> this.
>
> ***Sounds dangerous. I can just see users distributing documents with
> all of
> those deletions at the top, because they never scrolled up again and
> didn't
> know they were there.
>
> Pabini
>
>

7 Sep 2004 - 1:40pm
Elizabeth Buie
2004

Jef Raskin writes, in response to my wish to delete something and have it
handy for later insertion:

>I have two solutions. One, the way THE works, is that there is a
>"Deletions Document" where all deletions (even backspacing) appear.

And then what do I do when I want to insert it into the destination
paragraph? Go into the deletions document to find and select the deletion
I want, and insert it?

>The other, for systems without the Deletions Document, is to just put
>it up at the top of your document, above the title perhaps, where you
>can easily get it and you won't accidentally confuse it with other
>things.

I do this too, if I know I will need to do additional cutting and pasting
while working in the source paragraph.

However -- and this is important -- neither of these solutions is as
convenient as having the text already in the Clipboard, where when I want
to insert it all I have to do is pick the insertion point and Paste. I
don't have to choose anything but the insertion point, and the Paste can
be done with a quick keyboard action.

I'm sorry, Jef, but I don't see the benefit in eliminating Cut and Paste.

Elizabeth
--
Elizabeth Buie
Computer Sciences Corporation
Rockville, Maryland, USA
+1.301.921.3326

----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

7 Sep 2004 - 2:32pm
Jenifer Tidwell
2003

On Mon, 6 Sep 2004 20:16:31 -0700, Jef Raskin <jef at jefraskin.com> wrote:
>
> I have two solutions. One, the way THE works, is that there is a
> "Deletions Document" where all deletions (even backspacing) appear.
> This feature is incredibly handy. Many a time I've gone back to it to
> find something I thought I didn't need, but found hard to phrase as
> well as I did the first time.
>
> The other, for systems without the Deletions Document, is to just put
> it up at the top of your document, above the title perhaps, where you
> can easily get it and you won't accidentally confuse it with other
> things. I often use this method in working with ordinary text editors.
> Of course, without a Deletions Document, it takes extra effort to do
> this.

Interesting! And there are at least two other possible solutions to
the "keep deletions around just in case" problem, on opposite ends of
the feasibility scale:

1. Keep an ordinary document around that contains only deletions.
When I work on large Word projects, I keep an extra Word document open
for exactly that purpose. My deletions don't get saved with the
original document, as they would if I put them at the top of the
document, but they do stay "in scope" while I work.

The underlying model -- multiple documents viewed simultaneously -- is
flexible enough to allow this ad-hoc solution. I think that kind of
flexibility is critical to good app design, though it's a slippery
quality to define. We've got to give users enough "openness" to
create their own ad-hoc solutions to workflow problems, since we
designers are human and can't anticipate everything that users might
deal with.

2. Fine-grained, reliable versioning built into the operating system.
I dream about having this someday... "I don't think I like the edits
I made in the last few hours. Computer, show me what this document
looked like as of last night, with the differences marked for me." Or
last Friday, or last year. (There are already systems that can do
this if you remember to check things in and out; I'm talking about
having it done automatically and transparently.)

This is not so much an application design problem as an
infrastructure/OS problem -- and quite a big one -- but think of the
changes such a thing might precipitate in our application UIs. And in
users' workflow.

(Jef, it's been a couple of years since I read your book. Forgive me
if you already mention this there!)

- Jenifer

---------------------------------------
Jenifer Tidwell
jenifer.tidwell at gmail.com
http://jtidwell.net

7 Sep 2004 - 2:48pm
Jef Raskin
2004

>
>
> However -- and this is important -- neither of these solutions is as
> convenient as having the text already in the Clipboard,

Until you accidentally erase the clipboard with something that took a
while to construct, and don't realize it until it is out of the range
of Undo.

Which is the greater evil?

We have to do a frequency of use analysis; a widget used frequently
must be quick, one used seldom can be slower to use. And we have no
measure of the relative pain of losing a cut buffer (or its frequency).

Then again, in THE you don't print documents per se, so the problem
with accidentally including material is lessened. There is another
facility in THE, the fact that old selections are available, that helps
considerably in convenience, but I don't want to take the time or space
here to describe how it works; it's easy to learn and use but not easy
to describe in terms of present systems. As always, it is discussed in
THE spec down to the keystroke level of how to use it.

Discussions of how I think it should be done do tend to spin out of
control, because to make a consistent and unified system meant changing
many things we take for granted. When I describe part in isolation, the
well-versed interface designer (such as yourself) will put it into a
familiar context where, suddenly, the "solution" doesn't seem to work.
But in the context it does. It may not be worth your while to study the
spec and understand the fundamental changes, but if you want to really
see the solution, that's necessary. To understand why it works, the
principles explained in my book are useful.

7 Sep 2004 - 3:08pm
Elizabeth Buie
2004

Jef writes, in response to me:

>> However -- and this is important -- neither of these solutions is as
>> convenient as having the text already in the Clipboard,
>
>Until you accidentally erase the clipboard with something that took a
>while to construct, and don't realize it until it is out of the range
>of Undo.

I'm not saying that that doesn't happen. It has happened to me maybe once
or twice. But that's once or twice out of several times a day over the
years that I have been using this approach.

I'm not arguing against having an alternative way.

I'm saying don't take *this* alternative away from me.

It isn't humane. :-)

Elizabeth

P.S. I would be perfectly happy to see a Deletions Document with all my
Cuts in it, as long as my most recent Cut was also on the Clipboard.
--
Elizabeth Buie
Computer Sciences Corporation
Rockville, Maryland, USA
+1.301.921.3326

----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

7 Sep 2004 - 3:11pm
Elizabeth Buie
2004

Jef writes, reasonably enough:

>When I describe part in isolation, the
>well-versed interface designer (such as yourself) will put it into a
>familiar context where, suddenly, the "solution" doesn't seem to work.

Granted!

>It may not be worth your while to study the
>spec and understand the fundamental changes, but if you want to really
>see the solution, that's necessary.

I would understand it better by seeing it in action before reading the
spec. Would that be possible?

Elizabeth
--
Elizabeth Buie
Computer Sciences Corporation
Rockville, Maryland, USA
+1.301.921.3326

----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

7 Sep 2004 - 3:30pm
Jef Raskin
2004

On Sep 6, 2004, at 9:49 PM, Larry Tesler wrote:

> At 12:39 PM -0700 9/6/04, Jef Raskin wrote:
>> That's how Move works. You select what you want to move, find the
>> destination and exactly where you want to move the text to, click
>> there, and execute the Move command.
>
> The difference between Move in THE and Cut-and-Paste in the standard
> GUI is subtle, especially in an application like Microsoft Excel that
> defers Cut until Paste.

You are quite correct.

The problem here for users is that Cut in Excel and Cut in Word have
different behaviors. In particular, if you expect to delete by cutting
in Excel, you will be surprised that the cut material is still there.
This leads to the usual mode errors in moving between Excel and Word.
Cut in Excel works exactly as does Select in THE, and "Cut" is an
inappropriate name. "Select" or "Designate" would be better. When
you've seen a user ask how they can cut something from a spreadsheet
and tell you that the Cut command keeps on failing, the MS design
error becomes apparent.

>
> To move a block of cells in Microsoft Excel (Mac OS version; Windows
> is similar):
> 1 - Click one corner of the source area.
> 2 - Shift-click the opposite corner.
> 3 - Issue the Cut command by typing command-X. It stays there and
> acquires a marquee.
> 4 - Click the upper left corner of the destination area.
> 5 - Issue the Paste command by typing command-V.
>
> To move a block of text in THE per
> http://humane.sourceforge.net/the/spec.html:
> 1 - Leap or creep to one end of the source text.
> 2 - Leap or creep to the other end of the source text.
> 3 - Issue the Select command by typing command-S. It becomes
> highlighted differently.
> 4 - Leap or creep to the destination character.
> 5 - Issue the Move command by typing command-M.
>
> Same number of steps. Same effect.

The only distinction is that Leap is faster than pointing and clicking.

>
> In both systems, Undo after step 5 undoes steps 4 and 5.
>
> Edge cases:

A very nice analysis.
>
> (B) After step 5, you repeat steps 4 and 5.
>
> - Mac Excel: The second Step 5 pastes the same material again.
> - Windows Excel: The second Step 5 does nothing.
> - THE: The spec implies that the second step 5 does nothing.

Not quite right. The spec states:
After the insertion, the moved selection is left selected with the
cursor on the character following the selection.

Thus you may move it again without having to reselect it. Or, if you
wish, you could use the copy command to put a copy into another
location if you suddenly realized you wanted it in more than one place.

>
> (C) Between steps 3 and 4, you wish to see the material you are moving.
>
> - Mac/Windows Excel and THE: The material you are planning to move is
> still in its original location.
>
> When the Mac/Windows application is a text document, the steps the
> user takes are similar:
> 1 - Click one end of the source text.
> 2 - Shift-click the opposite end.
> 3 - Issue the Cut command by typing command-X.
> 4 - Click the destination.
> 5 - Issue the Paste command by typing command-V.

I am not clear what you are trying to accomplish here. If you are
trying to see the material you are moving, but it is not on the display
and you are not at your final location, then you've moved the text, but
as it is selected you can now move it to where you wished without
having to reselect it.

>
> Again, same number of steps as in THE. Same ultimate effect. And
> again, in both THE and a standard text editor, Undo after step 5
> undoes steps 4 and 5.

Actually, the spec is not clear on this point. I am grateful for your
observation, and we will have to discuss the granularity of Undo in
this case. Undo is being implemented at present so this is a timely
observation.

>
> Edge cases:
>
> (A) You perform some unrelated command between steps 3 and 4 4.
>
> - Mac/Windows. Permitted, as long as the commands do not alter the
> Clipboard. Whatever is in the Clipboard when you begin step 5 will be
> pasted.
> - THE: Permitted, as long as the commands do not alter the Selection.
> Whatever is selected when you begin Step 5 will be moved.
>
> This is a pretty small difference.

The difference is more significant in context because of the
consistency of the select-and-activate paradigm in THE.

>
> (B) After step 5, you repeat steps 4 and 5.
>
> - Mac/Windows text editors: The second step 5 pastes the same material
> again.
> - THE: The spec implies that the second step 5 does nothing.

Already discussed. You move the selection.

>
> (C) Between steps 3 and 4, you wish to see the material you are moving.
>
> - Mac/Windows text editors: Because Cut is also a way to delete, the
> cut material is no longer in the document. On Mac, it is visible in
> the Clipboard window. Hardly anyone leaves this window open, but you
> could.
> - THE: The material you are planning to move is still in its original
> location.
>
> This is what Jef means when he says that you can lose what you cut.
> You may forget you cut it, and never paste it. Not so in Excel. But
> true in standard text editors.

Exactly.

>
> Summary
> -------
>
> THE and the standard GUI differ far more in the favored way that
> selections are made (LEAP keys vs. mouse) than in the way selected
> stuff is moved. I don't think that a comparison of the two approaches
> should focus on how stuff is moved.

I agree that that is not something to focus on, but the issue arose in
response to a particular question.

>
> If someone really wanted to eliminate Jef's perceived problem with Cut
> and Paste, they could tweak the standard GUI in either of the
> following ways:
>
> (i) As in Excel, use something other than Cut to delete. Don't remove
> Cut material until the Paste command is issued.

(As in Excel, Swyftware, and the Canon Cat :-) And perhaps change the
nomenclature. Another difference not noted in this discussion is that
the step of cutting, in Excel, is Cmd-X. This is twice as slow and more
difficult than selecting in THE; you almost always Leap and then
select. But selecting just means a tap on the opposite Leap key.

>
> (ii) Implement a visible clipboard window or pane that contains a
> history of recent cuts. Some applications do this. I prefer this
> option to the other for most applications.

Unfortunately, it gives you yet another window or pane, adding to
screen clutter. In any case, it is less powerful than THE's deletion
document which always contains all deletions (including those
accomplished by backspacing).

>
> Larry Tesler

I would like to add publicly that I am especially appreciative of
Larry's remarks because of their thougtfulness, specificity, and
accuracy. Even, or especially, when we disagree, I inevitably learn
something.

7 Sep 2004 - 6:37pm
Jef Raskin
2004

>>
>
> I would understand it better by seeing it in action before reading the
> spec. Would that be possible?
>
>
We're building it now on a multiplatform basis. We had a version on the
net for Mac OS9 for a year, but we are no longer supporting it. If you
can find someone with a Canon Cat, that demonstrates the basic methods
I've been discussing.

7 Sep 2004 - 9:13pm
pabini
2004

Jef Raskin wrote: I entirely agree. I don't know of any non-dangerous option
in
> conventional systems. Another argument in favor of change.

Yes. Sounds to me like there should be no *compromise* for conformity with
the way deletions are currently handled. We really need that Deletions
Document.

Pabini

8 Sep 2004 - 12:51am
pabini
2004

Elizabeth Buie wrote: However -- and this is important -- neither of these
solutions is as
> > convenient as having the text already in the Clipboard,

Jef Raskin replied: Until you accidentally erase the clipboard with
something that took a
> while to construct, and don't realize it until it is out of the range
> of Undo.
>
> Which is the greater evil?
>
> We have to do a frequency of use analysis; a widget used frequently
> must be quick, one used seldom can be slower to use. And we have no
> measure of the relative pain of losing a cut buffer (or its frequency).

***[Pabini] Jef, you've done a great job of defining the greatest evil. It's
happened to us all. However, there's no reason why these solutions have to
be mutually exclusive or why one shouldn't leverage the cut-and-paste model
to achieve it, moving progressive deletions from the Clipboard to the record
of deletions. It would be very frequently used functionality. And you'd get
greater adoption for your solution if you didn't *require* people to change
their behaviors. That's not to say that cut and paste should be the only way
of moving deletions to the record of deletions.
>
> Then again, in THE you don't print documents per se, so the problem
> with accidentally including material is lessened. There is another
> facility in THE, the fact that old selections are available, that helps
> considerably in convenience, but I don't want to take the time or space
> here to describe how it works; it's easy to learn and use but not easy
> to describe in terms of present systems. As always, it is discussed in
> THE spec down to the keystroke level of how to use it.

***[Pabini] That selection capability sounds interesting. More motivation to
read that spec. :-)

Pabini

8 Sep 2004 - 9:37am
Jef Raskin
2004

I was just saying that whenever you make something a lot better than
the competition, that a good marketing department can sell it
effectively.

On Sep 8, 2004, at 6:49 AM, Nick Ragouzis wrote:

> Thanks for the reply, Jef. More power to you. Press
> onward. Establish new frontiers for us all. Fight
> the good fight. (q.v. Robert Coover's Briar Rose)
>
> Perhaps you could clear something up, tho'. What is
> the antecedent to this fragment?
>
> Jef Raskin wrote:
>> And it's marketable.
>
>
> --Nick
>
>

8 Sep 2004 - 11:07am
Alain D. M. G. ...
2003

--- Jef Raskin <jef at jefraskin.com> a écrit :
It may not be worth your while to study
> the
> spec and understand the fundamental changes, but if you want to
> really
> see the solution, that's necessary. To understand why it works, the
> principles explained in my book are useful.
>

I wish to add that after buying the book, reading it twice from cover
to cover and reading parts of it over and over I still could not
understand quite a few things. I kept thinking "What does he really
mean by this or that, in practice?" or "Can he really be so keyboard
-centric?". I persisted because of my curiosity for the Canon Cat,
over the years, and for historical reasons.

Finally, I found nearly all of what I was missing by discovering and
reading all the THE Web pages and also all of the "Raskin family" Web
pages surrounding them on Sourceforge. I have not understood many of
the "new" content on these Web pages themselves, but they made me
understand nearly all of the book. I used to persist because of the
Canon Cat enigma (and still do, in a limited way), now I persist
because THE is a zoomable interface, a concept which merits
exploration, I think.

Take the above as a caveat. Neither book nor Web pages are for
dilettantes.

Alain Vaillancourt

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

8 Sep 2004 - 11:55am
Dave Collins
2004

>understand nearly all of the book. I used to persist because of the
Canon Cat enigma (and still do, in a limited way), now I persist
because THE is a zoomable interface, a concept which merits
exploration, I think.

Glossary incomplete:
Canon Cat = ?
THE = ?

I know it's back-threaded somewhere, but...

8 Sep 2004 - 1:32pm
Alain D. M. G. ...
2003

--- Dave Collins <DCollins at phoenix-interactive.com> a écrit :

> Glossary incomplete:
> Canon Cat = ?

A dedicated micro computer (one might even say an information
appliance) launched in 1987 and incorporating what were and still are
innovative interface ideas, albeit in a text mode.

See the short text here, and take a look at the links under it for
more:
http://en.wikipedia.org/wiki/Canon_Cat

> THE = ?
The Humane Environment
See the short text here:
http://en.wikipedia.org/wiki/The_Humane_Environment
and take a look at the links under this one for more:
http://en.wikipedia.org/wiki/Jef_Raskin

Alain Vaillancourt

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

8 Sep 2004 - 2:09pm
Jef Raskin
2004

While some people do not find my work as enigmatic as he does, I am
grateful to Alain for pointing out that it requires some effort to
understand what is going on. Things that are different require
unlearning and stepping outside of present and comfortable mental
paths.

If some things seem especially opaque, please feel free to ask me
questions at my regular email from my web site, which is googleable.

On Sep 8, 2004, at 9:07 AM, Alain D. M. G. Vaillancourt wrote:

> --- Jef Raskin <jef at jefraskin.com> a écrit :
> It may not be worth your while to study
>> the
>> spec and understand the fundamental changes, but if you want to
>> really
>> see the solution, that's necessary. To understand why it works, the
>> principles explained in my book are useful.
>>
>
> I wish to add that after buying the book, reading it twice from cover
> to cover and reading parts of it over and over I still could not
> understand quite a few things. I kept thinking "What does he really
> mean by this or that, in practice?" or "Can he really be so keyboard
> -centric?". I persisted because of my curiosity for the Canon Cat,
> over the years, and for historical reasons.
>
> Finally, I found nearly all of what I was missing by discovering and
> reading all the THE Web pages and also all of the "Raskin family" Web
> pages surrounding them on Sourceforge. I have not understood many of
> the "new" content on these Web pages themselves, but they made me
> understand nearly all of the book. I used to persist because of the
> Canon Cat enigma (and still do, in a limited way), now I persist
> because THE is a zoomable interface, a concept which merits
> exploration, I think.
>
> Take the above as a caveat. Neither book nor Web pages are for
> dilettantes.
>
> Alain Vaillancourt
>
> __________________________________________________________
> Lèche-vitrine ou lèche-écran ?
> magasinage.yahoo.ca
>

8 Sep 2004 - 2:15pm
Jef Raskin
2004

Canon Cat: a "work processor" of the middle 1980s that was widely
acknowledged as having an unusual user interface far superior than
anything else available (some would add: then or now).

THE = The Humane Environment. See www.jefraskin.com
>
>> understand nearly all of the book. I used to persist because of the
> Canon Cat enigma (and still do, in a limited way), now I persist
> because THE is a zoomable interface, a concept which merits
> exploration, I think.
>
> Glossary incomplete:
> Canon Cat = ?
> THE = ?
>
> I know it's back-threaded somewhere, but...

9 Sep 2004 - 12:27am
Adam Korman
2004

Larry's comparison was very helpful in understanding the (very few)
differences between cut & paste and move, as proposed. What it
highlighted for me, was how THE handles selection differently...

>> Edge cases:
>>
>> (A) You perform some unrelated command between steps 3 and 4.
>>
>> - Mac/Windows. Permitted, as long as the commands do not alter the
>> Clipboard. Whatever is in the Clipboard when you begin step 5 will be
>> pasted.
>> - THE: Permitted, as long as the commands do not alter the Selection.
>> Whatever is selected when you begin Step 5 will be moved.
>>
>> This is a pretty small difference.

I would argue that this is neither an edge case nor a small difference.
I frequently perform tasks after cutting and before pasting that alter
the selection. THE doesn't seem to handle this well (at all?). Among
other things, THE forces you to do decide where something is going
before you move it -- while this is sometimes how people think, it's as
likely that the exact destination isn't known (or ready) before one
starts to move something. Think about moving physical objects ... you
might start to move something, set it down, clear a space, then move it
to its final location. What traditional Cut & Paste provides that Move
seems to lack is a temporary holding space. The main complaint with Cut
& Paste seems not to be with the core function (since, as Larry noted,
it's nearly identical to Move), but that the temporary holding is
invisible and error-prone.

The issue is not Move per se, but that THE uses a grammar which is both
more complex and strict than what we're used to. Most applications rely
on simple noun-verb constructions. THE requires you to add an adverbial
complement (a target) between the noun and verb, without interrupting
the phrase. I'm very interested to know how intentional this
construction is, and if there's an analysis of the trade-offs.

THE has added complexity in that selections and the insertion point are
indicated and tracked separately, whereas most applications/OSes treat
these as the same. Although the tasks of selection and indicating the
insertion point may be quicker because of this, it's not clear to me
that in practice this won't lead to confusion, except when they are in
very close proximity to each other. This feature of the system demands
that the user focus on two locations (one of which may not be
visible!), because one gesture can result in different consequences in
two places at once. This seems problematic, and is compounded by
implicit selection behaviors which can make keeping track of the
current selection difficult (for the user).

I don't think that the widget-level behaviors of the dominant
systems/apps are perfect by any means, but I'm not convinced yet that
this is a better alternative, or see how this model is broadly
applicable (for anything other than a simple text editor).

Regards, Adam
....
Adam Korman
adam at flexid.com

9 Sep 2004 - 12:52am
Jef Raskin
2004

On Sep 8, 2004, at 10:27 PM, Adam Korman wrote:

> Larry's comparison was very helpful in understanding the (very few)
> differences between cut & paste and move, as proposed. What it
> highlighted for me, was how THE handles selection differently...
>
>>> Edge cases:
>>>
>>> (A) You perform some unrelated command between steps 3 and 4.
>>>
>>> - Mac/Windows. Permitted, as long as the commands do not alter the
>>> Clipboard. Whatever is in the Clipboard when you begin step 5 will
>>> be pasted.
>>> - THE: Permitted, as long as the commands do not alter the
>>> Selection. Whatever is selected when you begin Step 5 will be moved.
>>>
>>> This is a pretty small difference.
>
> I would argue that this is neither an edge case nor a small
> difference. I frequently perform tasks after cutting and before
> pasting that alter the selection. THE doesn't seem to handle this well
> (at all?). Among other things, THE forces you to do decide where
> something is going before you move it

This description of THE is not correct. Larry took the time to read the
spec and it seems Adam has not. I hope that he and others who wish to
discuss THE read it. Adam's discussion therefore does not apply to THE
and we may ignore it in that context. THE is quite different than
current systems in many ways, even at the text-handling level. Also,
THE's core methods have been implemented commercially and extensively
tested with hundreds of test subjects and thousands of users, which
makes an opinion such as Adam's "This seems problematic, and is
compounded by implicit selection behaviors which can make keeping track
of the current selection difficult (for the user)." difficult to
sustain. In development, if users did have such problems, we changed
the interface. This is a system that has has a long gestation and much
testing. Often we found our guesses as to how something would work were
also wrong -- and fixed them.

The current version of the spec is v80, which is going up on the web
site as soon as our webmaster returns from vacation, but it is not much
different than the currently available version. THE is not a text
editor, though we have spent a lot of effort getting simple text
editing right. A document on the web site discusses this, too.

> -- while this is sometimes how people think, it's as likely that the
> exact destination isn't known (or ready) before one starts to move
> something. Think about moving physical objects ... you might start to
> move something, set it down, clear a space

(if you clear a space, moving something by cutting and pasting, you've
just lost what you said you wanted to preserve)

> , then move it to its final location. What traditional Cut & Paste
> provides that Move seems to lack is a temporary holding space. The
> main complaint with Cut & Paste seems not to be with the core function
> (since, as Larry noted, it's nearly identical to Move), but that the
> temporary holding is invisible and error-prone.
>
> The issue is not Move per se, but that THE uses a grammar which is
> both more complex and strict than what we're used to. Most
> applications rely on simple noun-verb constructions. THE requires you
> to add an adverbial complement (a target) between the noun and verb,
> without interrupting the phrase. I'm very interested to know how
> intentional this construction is, and if there's an analysis of the
> trade-offs.
>
> THE has added complexity in that selections and the insertion point
> are indicated and tracked separately, whereas most applications/OSes
> treat these as the same. Although the tasks of selection and
> indicating the insertion point may be quicker because of this, it's
> not clear to me that in practice this won't lead to confusion, except
> when they are in very close proximity to each other. This feature of
> the system demands that the user focus on two locations (one of which
> may not be visible!), because one gesture can result in different
> consequences in two places at once. This seems problematic, and is
> compounded by implicit selection behaviors which can make keeping
> track of the current selection difficult (for the user).
>
> I don't think that the widget-level behaviors of the dominant
> systems/apps are perfect by any means, but I'm not convinced yet that
> this is a better alternative, or see how this model is broadly
> applicable (for anything other than a simple text editor).
>
> Regards, Adam
> ....
> Adam Korman
> adam at flexid.com
>
>

9 Sep 2004 - 1:26am
Andrei Herasimchuk
2004

On Sep 8, 2004, at 10:52 PM, Jef Raskin wrote:

> This description of THE is not correct. Larry took the time to read
> the spec and it seems Adam has not. I hope that he and others who wish
> to discuss THE read it.

Better yet, find a copy and use it. (Your download page seems disabled,
for reasons I don't know why.) I did, about a year and half ago. I'd be
interested to hear what others think about it.

> THE is quite different than current systems in many ways, even at the
> text-handling level.

You ain't kidding.

> Also, THE's core methods have been implemented commercially

In what applications?

> and extensively tested with hundreds of test subjects and thousands of
> users

Care to publish the results?

Andrei

9 Sep 2004 - 1:52pm
Elizabeth Buie
2004

Adam Korman writes:

>I would argue that this is neither an edge case nor a small
>difference. I frequently perform tasks after cutting and
>before pasting that alter the selection. THE doesn't seem to
>handle this well (at all?).

Exactly my point, Adam. Well said.

Elizabeth
--
Elizabeth Buie
Computer Sciences Corporation
Rockville, Maryland, USA
+1.301.921.3326

----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

9 Sep 2004 - 1:54pm
Elizabeth Buie
2004

Jef writes, in response to Adam Korman:

>This description of THE is not correct.

Then you can disregard my response to Adam's post. I replied before I had
read your message, Jef.

Sorry!

Elizabeth
--
Elizabeth Buie
Computer Sciences Corporation
Rockville, Maryland, USA
+1.301.921.3326

----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

9 Sep 2004 - 2:13pm
Jef Raskin
2004

On Sep 9, 2004, at 11:52 AM, Elizabeth Buie wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Adam Korman writes:
>
>> I would argue that this is neither an edge case nor a small
>> difference. I frequently perform tasks after cutting and
>> before pasting that alter the selection. THE doesn't seem to
>> handle this well (at all?).
>
> Exactly my point, Adam. Well said.
>

Well said, but wrong. Also, it is unclear what selection Adam meant:
the selection that was cut can't be changed. Nothing else can be cut
and pasted in the interim. Typing (or drawing and other forms of
content generation) and deletions made before you Paste but THE also
permits that before using Move. THE also allows you to Move other
things in the interim without losing your previous selection. That
seems more flexible than Cut and Paste where you can't use Cut and
Paste again until you've completed the first one (or lose the cut
material). Am I missing something?

Elizabeth, you have said that you'd rather wait for the implementation
than read the spec, so it will be a while before you will understand
how it works. The key to the present case is that we handle selections
differently than you and Adam are assuming. As I said previously, his
comments are irrelevant as he is not discussing THE, but some hybrid
design he thinks is THE.

10 Sep 2004 - 10:40am
Jef Raskin
2004

On Sep 7, 2004, at 10:51 PM, Pabini Gabriel-Petit wrote:
>>
>
> Jef, you've done a great job of defining the greatest evil. It's
> happened to us all. However, there's no reason why these solutions
> have to
> be mutually exclusive or why one shouldn't leverage the cut-and-paste
> model
> to achieve it, moving progressive deletions from the Clipboard to the
> record
> of deletions. It would be very frequently used functionality. And
> you'd get
> greater adoption for your solution if you didn't *require* people to
> change
> their behaviors. That's not to say that cut and paste should be the
> only way
> of moving deletions to the record of deletions.

There is a reason, in fact two come immediately to mind. The first is
the cognitive principle of monotony, which leads to beneficial
habituation. The second is the avoidance of software bloat.

Avoiding *requiring* people to change means that a system can only get
larger, and that the legacy methods continue to cause the problems that
drove you add new methods. This is standard practice at Microsoft and
Apple, to name two offenders in the gigabloat operating system group.

If you are not familiar with the term "monotony" in the sense used
here, it is explained in "The Humane Interface" starting on page 66. A
typical application of the concept is at e.g.
http://www.pixelcharmer.com/fieldnotes/archives/process_designing/2004/
000462.html From the Meatball Wiki comes this brief summary:
"Monotony is good. If there is only one way of doing things, then
people develop habits and feel secure and in control. If there are too
many choices, it is difficult to teach, and difficult to use because
you have to decide *how* you will do something."

10 Sep 2004 - 11:10am
Jenifer Tidwell
2003

On Fri, 10 Sep 2004 08:40:53 -0700, Jef Raskin <jef at jefraskin.com> wrote:
>
> If you are not familiar with the term "monotony" in the sense used
> here, it is explained in "The Humane Interface" starting on page 66. A
> typical application of the concept is at e.g.
> http://www.pixelcharmer.com/fieldnotes/archives/process_designing/2004/
> 000462.html From the Meatball Wiki comes this brief summary:
> "Monotony is good. If there is only one way of doing things, then
> people develop habits and feel secure and in control. If there are too
> many choices, it is difficult to teach, and difficult to use because
> you have to decide *how* you will do something."

I no longer believe that "monotony is good" in all interfaces. Or
even most of them.

In the systems I've helped design -- and I'll admit up front that many
of them were complex desktop UIs -- users' preferred workflow and UI
habits varied tremendously from person to person. This user loves
context menus, and she right-clicks on everything. This one depends
on the menu bar. This one drag-and-drops things all over the place,
and he expects double-click to always do the appropriate thing in his
context of work. ...And all that was from one suite of usability
tests, on one narrow slice of the product! If we offered only One
True Way of performing these actions, I don't think all these users
would be well-served.

Or think about an email client. People organize their email in
predictable but very different ways -- compulsive filing, letting
backlogs accumulate, tagging, filters, etc -- and they want to view it
differently too. Users develop email-reading habits that suit their
way of thinking and working. I wouldn't want to take those choices
away by cutting back functionality duplication in the software.

When you offer different ways of doing similar things, you allow the
emergence of varied user-defined workflows. In many cases, this is a
good thing.

Yes, choices impose a cognitive burden. Yes, it's harder to teach
software that offers different ways of organizing things and
performing actions. But I trust that when users are motivated enough
-- and that's key! -- they're more than capable of making their own
choices. And they probably appreciate it.

(Can't argue with you about software bloat, though... it's no fun for
documentation writers, either.)

- Jenifer

---------------------------------------
Jenifer Tidwell
jenifer.tidwell at gmail.com
http://jtidwell.net

10 Sep 2004 - 12:04pm
Adam Korman
2004

On Sep 8, 2004, at 10:52 PM, Jef Raskin wrote:

>> I would argue that this is neither an edge case nor a small
>> difference. I frequently perform tasks after cutting and before
>> pasting that alter the selection. THE doesn't seem to handle this
>> well (at all?). Among other things, THE forces you to do decide where
>> something is going before you move it
>
> This description of THE is not correct. Larry took the time to read
> the spec and it seems Adam has not. I hope that he and others who wish
> to discuss THE read it. Adam's discussion therefore does not apply to
> THE and we may ignore it in that context.

That's a pretty broad dismissal of what I wrote based on a faulty
premise, since I have read the spec.

Jef wrote in a previous message: "That's how Move works. You select
what you want to move, find the destination and exactly where you want
to move the text to, click there, and execute the Move command." This
seems to match what I wrote. Am I missing something?

I admit that after re-reading parts of the spec, my descriptions of how
selection works were not entirely accurate, but the behaviors are still
not clear to me.

Despite my flawed understanding, I think my discussion is still valid
about THE's use of the structure: (1) select (2) target (3) issue
command vs. the familiar structure of (1) select (2) issue command (3)
target (4) issue follow-on command. Although the familiar method has 4
steps, it's really a pair of 2-step operations, which you could argue
is simpler (if not more efficient) at the task level. I'm not really
sure this is better, and I'd be interested in comment on this. I'm
curious if there's anything other than a GOMS analysis driving this
grammar.

> Typing (or drawing and other forms of content generation) and
> deletions made before you Paste but THE also permits that before using
> Move. THE also allows you to Move other things in the interim without
> losing your previous selection. That seems more flexible than Cut and
> Paste where you can't use Cut and Paste again until you've completed
> the first one (or lose the cut material). Am I missing something?

Yes, you are missing that I am not arguing that Cut & Paste is better.
I am trying to figure out how THE does the things you've just
mentioned, and evaluate its model for doing them. It's not clear how
after a series of intervening, unrelated operations, THE knows which
prior selection you want to move. Any clarification would be helpful.

> THE's core methods have been implemented commercially and extensively
> tested with hundreds of test subjects and thousands of users, which
> makes an opinion such as Adam's "This seems problematic, and is
> compounded by implicit selection behaviors which can make keeping
> track of the current selection difficult (for the user)." difficult to
> sustain.

This is a non sequitur. Without any details, that THE has been
implemented and tested has no bearing on the validity of my opinion.
You can say the exact same things about all of Microsoft's products --
they are implemented, tested and problematic. The reason I engaged in
the discussion was to figure out if my opinion has any merit.
Unfortunately, all I have to evaluate is the spec. While the spec might
be an accurate description of THE, it is not a clear description. This
is not enough information to make an informed judgment.

> In development, if users did have such problems, we changed the
> interface.

Did users have these kinds of problems?

> This is a system that has has a long gestation and much testing. Often
> we found our guesses as to how something would work were also wrong --
> and fixed them.

I have found that testing is a good way to identify things that do or
do not work, but not a very good way to identify solutions or validate
that something is the right solution. I am curious which sorts of
things didn't work, and what the method was to fix them.

> THE is not a text editor, though we have spent a lot of effort getting
> simple text editing right. A document on the web site discusses this,
> too.

THE seems optimized for linear, flat content in a single-user
environment. I look forward to details on how it translates to image
editing, workflow applications, shared documents, etc.

Regards, Adam

10 Sep 2004 - 1:02pm
Jef Raskin
2004

On Sep 10, 2004, at 9:10 AM, Jenifer Tidwell wrote:

> On Fri, 10 Sep 2004 08:40:53 -0700, Jef Raskin <jef at jefraskin.com>
> wrote:
>>
>> If you are not familiar with the term "monotony" in the sense used
>> here, it is explained in "The Humane Interface" starting on page 66. A
>> typical application of the concept is at e.g.
>> http://www.pixelcharmer.com/fieldnotes/archives/process_designing/
>> 2004/
>> 000462.html From the Meatball Wiki comes this brief summary:
>> "Monotony is good. If there is only one way of doing things, then
>> people develop habits and feel secure and in control. If there are too
>> many choices, it is difficult to teach, and difficult to use because
>> you have to decide *how* you will do something."
>
> I no longer believe that "monotony is good" in all interfaces. Or
> even most of them.

Do you think habituability is a good thing in an interface? If you do,
and if you understand cog. psych. then you will also accept
modelessness and monotony as useful design guides. Most people make an
interface monotonous by choosing a subset of the available methods that
they stick to. Present GUIs often force non-monotonous interface usage
by not allowing you to use your favorite method everywhere. There are
some keyboard shortcuts, but some operations demand menus, not
everything you can do appears on a menu, etc. This is clearly an
interface design error.

>
> In the systems I've helped design -- and I'll admit up front that many
> of them were complex desktop UIs -- users' preferred workflow and UI
> habits varied tremendously from person to person.

Perhaps this was due to using a desktop UI in the first place.

> This user loves
> context menus, and she right-clicks on everything. This one depends
> on the menu bar. This one drag-and-drops things all over the place,
> and he expects double-click to always do the appropriate thing in his
> context of work. ...And all that was from one suite of usability
> tests, on one narrow slice of the product! If we offered only One
> True Way of performing these actions, I don't think all these users
> would be well-served.

Why not? For example, most RSI comes from mouse usage; a person weaned
from drag-and-drop or dependence on the menu bar will be faster and at
less risk of injury. It is hardly being helpful (or much of an
interface designer) to say, here's a pile of widgets from all over the
place, make yourself an interface from them.

>
> Or think about an email client. People organize their email in
> predictable but very different ways -- compulsive filing, letting
> backlogs accumulate, tagging, filters, etc -- and they want to view it
> differently too. Users develop email-reading habits that suit their
> way of thinking and working.

I think you underestimate the randomness of user choices. They tend to
prefer whatever method they learn first. And the interfaces I design do
not restrict how people organize their email, so this example does not
apply.

> I wouldn't want to take those choices
> away by cutting back functionality duplication in the software.
>
> When you offer different ways of doing similar things, you allow the
> emergence of varied user-defined workflows. In many cases, this is a
> good thing.

In my testing, in most cases, a bad thing. In EVERY situation where
I've simplified an interface by removing alternatives (judiciously) for
a client, the result has been beneficial. Sometimes there are
complaints at first (where is my favorite widget?) although a lot fewer
than most companies expect. Shortly afterward, there is only gratitude
among both users and management. The question "would you rather go back
to the old methods" is answered in the negative by almost all users
after about a month. You have to be brave to try it, but monotony
works.

>
> Yes, choices impose a cognitive burden. Yes, it's harder to teach
> software that offers different ways of organizing things and
> performing actions. But I trust that when users are motivated enough
> -- and that's key! -- they're more than capable of making their own
> choices.

That assumes that users are well-educated about interface design and
will make rational choices based on understanding cognetics. In
practice, most users do not make optimal choices, which slows them
down, decreases productivity, increases RSI risks, and lowers the
profitability of the companies they work for. I disagree with your
statement that most users are capable of making good interface choices.

> And they probably appreciate it.

People appreciate fast motorcycles, booze, illicit drugs, and many
other things. User appreciation is good to have in a product, but it is
not the only desirable property. Anyway, I have found that when you
give users a truly superior interface, even if unfamiliar at first,
they appreciate it.

>
> (Can't argue with you about software bloat, though... it's no fun for
> documentation writers, either.)
>
BTW, did you read the section in my book that explains why monotony
works?

> - Jenifer
>
> ---------------------------------------
> Jenifer Tidwell
> jenifer.tidwell at gmail.com
> http://jtidwell.net
>

10 Sep 2004 - 3:53pm
Jenifer Tidwell
2003

On Fri, 10 Sep 2004 11:02:44 -0700, Jef Raskin <jef at jefraskin.com> wrote:
>
> > I no longer believe that "monotony is good" in all interfaces. Or
> > even most of them.
>
> Do you think habituability is a good thing in an interface? If you do,
> and if you understand cog. psych. then you will also accept
> modelessness and monotony as useful design guides.

They certainly are useful design guides. If I can figure out one way
of doing something that I know most users will prefer, then sure --
I'll happily make it the single path to that functionality.
Unfortunately, the design choice isn't always that black-and-white.
More on that below...

> Most people make an interface monotonous by choosing a subset of the
> available methods that they stick to.

Not necessarily. One person may use different methods depending on
their hand positions, state of flow, memory (or lack thereof) of where
something is, etc. David Heller gave a good example of that:
invoking "Back" in a browser can be done in several ways by the same
person at different times.

How common is that? Probably depends on the users you're targeting
with your design. What you say is undoubtedly true for some users of
some software; I'm not going to second-guess the observations you've
made of your users, just as I hope you aren't second-guessing mine. I
suspect that motivation, experience, and frequency of use are some of
the variables that affect users' interaction preferences and desire
for choice.

> Present GUIs often force non-monotonous interface usage
> by not allowing you to use your favorite method everywhere. There are
> some keyboard shortcuts, but some operations demand menus, not
> everything you can do appears on a menu, etc. This is clearly an
> interface design error.

An error, or a compromise?

It sounds like you're suggesting that all functionality be reachable
by all methods -- menu bar, keyboard, direct manipulation? And that a
halfway measure is less good than providing only one mode of
operation? (Not a rhetorical question; I'd like to hear more of your
thoughts on this.)

But practically speaking, offering duplicates of all functionality in
all modes would be pretty tough in some applications. Some operations
can't be forced into a direct-manipulation model; others can't be
forced into a keyboard-driven model. Or if I have a loooong list of
actions to be performed on a selected object, I'm not going to put
them all on a context menu -- I would carefully choose which ones
belong there.

(That said, it would be nice if more keyboard-only operations were
supported in some apps!)

> > In the systems I've helped design -- and I'll admit up front that many
> > of them were complex desktop UIs -- users' preferred workflow and UI
> > habits varied tremendously from person to person.
>
> Perhaps this was due to using a desktop UI in the first place.

Yes, perhaps. There's that old "installed base" problem... The user
populations I've dealt with have been at least moderately skilled at
using the common WIMP modes of operation (menu bars, context menus,
drag-and-drop, etc.), and they will have already developed preferences
about using them by the time they test my group's designs. So we
compromise and work with those preferences. Occasionally we "retrain"
users into a non-standard interaction path that we know works better,
but we'd better have a really good reason to do that, and we can't do
it too often. We do have to sell software, after all.

> > If we offered only One
> > True Way of performing these actions, I don't think all these users
> > would be well-served.
>
> Why not? For example, most RSI comes from mouse usage; a person weaned
> from drag-and-drop or dependence on the menu bar will be faster and at
> less risk of injury. It is hardly being helpful (or much of an
> interface designer) to say, here's a pile of widgets from all over the
> place, make yourself an interface from them.

It's not that random. Of course we pick and choose when we design
interfaces -- see what I said above. Some functions take well to some
interaction modes, others to other modes.

> > Or think about an email client. People organize their email in
> > predictable but very different ways -- compulsive filing, letting
> > backlogs accumulate, tagging, filters, etc -- and they want to view it
> > differently too. Users develop email-reading habits that suit their
> > way of thinking and working.
>
> I think you underestimate the randomness of user choices. They tend to
> prefer whatever method they learn first. And the interfaces I design do
> not restrict how people organize their email, so this example does not
> apply.

Maybe not to what *you* design, but to the broader idea of monotony --
presumably it's applicable to all of us designers. Is it only about
modes of physical access? Is it about navigation paths? Is it about
different kinds of views on the same data? Is it about ways of
searching, sorting, and organizing stuff? With all of these, I can
imagine many ways of achieving the same end, but each way has
different advantages and disadvantages.

And I think you underestimate the ability of users to make choices
that work for them. :-) Maybe those choices aren't ergonomically and
cognitively optimal, but it's up to us designers to pick a few that
*should* work well and offer them as choices.

> > And they probably appreciate it.
>
> People appreciate fast motorcycles, booze, illicit drugs, and many
> other things. User appreciation is good to have in a product, but it is
> not the only desirable property. Anyway, I have found that when you
> give users a truly superior interface, even if unfamiliar at first,
> they appreciate it.

That's very true. And we should strive for that, even while we make
compromises in order to ship workable software.

> BTW, did you read the section in my book that explains why monotony
> works?

I did, but over a year ago. My copy is at home. I'll reread that
section this weekend.

---------------------------------------
Jenifer Tidwell
jenifer.tidwell at gmail.com
http://jtidwell.net

12 Sep 2004 - 1:51am
Jef Raskin
2004

On Sep 10, 2004, at 1:53 PM, Jenifer Tidwell wrote:

> On Fri, 10 Sep 2004 11:02:44 -0700, Jef Raskin <jef at jefraskin.com>
> wrote:
>>
>>> I no longer believe that "monotony is good" in all interfaces. Or
>>> even most of them.
>>
>> Do you think habituability is a good thing in an interface? If you do,
>> and if you understand cog. psych. then you will also accept
>> modelessness and monotony as useful design guides.
>
> They certainly are useful design guides. If I can figure out one way
> of doing something that I know most users will prefer, then sure --
> I'll happily make it the single path to that functionality.
> Unfortunately, the design choice isn't always that black-and-white.
> More on that below...
>
>> Most people make an interface monotonous by choosing a subset of the
>> available methods that they stick to.
>
> Not necessarily. One person may use different methods depending on
> their hand positions, state of flow, memory (or lack thereof) of where
> something is, etc. David Heller gave a good example of that:
> invoking "Back" in a browser can be done in several ways by the same
> person at different times.

I claim that that is due to bad design of the browser. The user is
compensating for interface design errors.

>
> How common is that? Probably depends on the users you're targeting
> with your design. What you say is undoubtedly true for some users of
> some software;

I locate the problem in the interface, not the user.

> I'm not going to second-guess the observations you've
> made of your users, just as I hope you aren't second-guessing mine. I
> suspect that motivation, experience, and frequency of use are some of
> the variables that affect users' interaction preferences and desire
> for choice.
>
>> Present GUIs often force non-monotonous interface usage
>> by not allowing you to use your favorite method everywhere. There are
>> some keyboard shortcuts, but some operations demand menus, not
>> everything you can do appears on a menu, etc. This is clearly an
>> interface design error.
>
> An error, or a compromise?

A compromise (as per this example) is a partial acceptance of an error
for some political, temporal, or financial reason. Thus a compromise is
an error.

>
> It sounds like you're suggesting that all functionality be reachable
> by all methods -- menu bar, keyboard, direct manipulation? And that a
> halfway measure is less good than providing only one mode of
> operation? (Not a rhetorical question; I'd like to hear more of your
> thoughts on this.)

Not by all methods, by one good method. I must apologize for not having
time to address this fundamental issue in detail here. By way of excuse
all I can say is that I am spending my time implementing an example of
what I am talking about.

>
> But practically speaking, offering duplicates of all functionality in
> all modes would be pretty tough in some applications. Some operations
> can't be forced into a direct-manipulation model;

What is "direct-manipulation"? Some people claim that dragging an icon
of a document into the trash is direct manipulation, but I think that
dragging the document rather than a symbol representing it, would be
direct manipulation.

> others can't be
> forced into a keyboard-driven model. Or if I have a loooong list of
> actions to be performed on a selected object, I'm not going to put
> them all on a context menu -- I would carefully choose which ones
> belong there.
>
> (That said, it would be nice if more keyboard-only operations were
> supported in some apps!)

Yup.

>
>>> In the systems I've helped design -- and I'll admit up front that
>>> many
>>> of them were complex desktop UIs -- users' preferred workflow and UI
>>> habits varied tremendously from person to person.
>>
>> Perhaps this was due to using a desktop UI in the first place.
>
> Yes, perhaps. There's that old "installed base" problem...

I call it the "installed base opportunity." It can be a competitive
advantage to have your competition mired in trying to please the
installed base while you move ahead.

> The user
> populations I've dealt with have been at least moderately skilled at
> using the common WIMP modes of operation (menu bars, context menus,
> drag-and-drop, etc.), and they will have already developed preferences
> about using them by the time they test my group's designs. So we
> compromise and work with those preferences. Occasionally we "retrain"
> users into a non-standard interaction path that we know works better,
> but we'd better have a really good reason to do that,

Granted.

> and we can't do
> it too often. We do have to sell software, after all.

We differ as to what you have to do to sell software. But I am being
deliberately radical here; there are many situations where I help a
client improve an interface within the familiar because their company
doesn't feel capable of engaging in more risk.

>
>>> If we offered only One
>>> True Way of performing these actions, I don't think all these users
>>> would be well-served.
>>
>> Why not? For example, most RSI comes from mouse usage; a person weaned
>> from drag-and-drop or dependence on the menu bar will be faster and at
>> less risk of injury. It is hardly being helpful (or much of an
>> interface designer) to say, here's a pile of widgets from all over the
>> place, make yourself an interface from them.
>
> It's not that random. Of course we pick and choose when we design
> interfaces -- see what I said above. Some functions take well to some
> interaction modes, others to other modes.
>
>>> Or think about an email client. People organize their email in
>>> predictable but very different ways -- compulsive filing, letting
>>> backlogs accumulate, tagging, filters, etc -- and they want to view
>>> it
>>> differently too. Users develop email-reading habits that suit their
>>> way of thinking and working.
>>
>> I think you underestimate the randomness of user choices. They tend to
>> prefer whatever method they learn first. And the interfaces I design
>> do
>> not restrict how people organize their email, so this example does not
>> apply.
>
> Maybe not to what *you* design, but to the broader idea of monotony --
> presumably it's applicable to all of us designers. Is it only about
> modes of physical access? Is it about navigation paths? Is it about
> different kinds of views on the same data? Is it about ways of
> searching, sorting, and organizing stuff? With all of these, I can
> imagine many ways of achieving the same end, but each way has
> different advantages and disadvantages.

Again, forgive me for referring to "The Humane Interface"; the argument
for monotony is there; but you have to be careful (as it says) to
distinguish between gestures and content. It is habituated gestures
that need to be monotonous, you mention many other kinds of things to
which the concept does not apply.

>
> And I think you underestimate the ability of users to make choices
> that work for them. :-) Maybe those choices aren't ergonomically and
> cognitively optimal, but it's up to us designers to pick a few that
> *should* work well and offer them as choices.
>
>>> And they probably appreciate it.
>>
>> People appreciate fast motorcycles, booze, illicit drugs, and many
>> other things. User appreciation is good to have in a product, but it
>> is
>> not the only desirable property. Anyway, I have found that when you
>> give users a truly superior interface, even if unfamiliar at first,
>> they appreciate it.
>
> That's very true. And we should strive for that, even while we make
> compromises in order to ship workable software.
>
>> BTW, did you read the section in my book that explains why monotony
>> works?
>
> I did, but over a year ago. My copy is at home. I'll reread that
> section this weekend.
>
> ---------------------------------------
> Jenifer Tidwell
> jenifer.tidwell at gmail.com
> http://jtidwell.net
>

Syndicate content Get the feed