Re: DnD vs CnP (was Copy/Paste Events)

Paul Libbrecht< wrote:
> - drag and drop allows a precise visual target identification thus may be
> considered safer (and this is actually implemented so: you can faster
> drag-and-drop URLs than copy and paste them).

this isn't true.

depending on how friendly your drop target is, it theoretically could
be true, but in practice many apps do not make it easy to understand
precisely where you're dropping or precisely what effects a drop will
have. sometimes your entire document is replaced by the thing you
thought you were dragging. sometimes you get something you didn't
think you were dragging.

I have a mac book, and sometimes when I want to eject my usb media, i
try to drag it to the trash, because this is one way to eject disks.

http://everything2.com/title/Dragging+a+disk+to+the+trash+to+eject+it+on+a+Macintosh
talks about it a bit.

Unfortunately, the concept isn't as simple as that, it turns out (and
i finally understand it now [actually, i think i discover it ever
couple of weeks and then promptly forget), then there's a difference
between dragging the disk reference from the desktop to the trash and
dragging the item from a finder window's tray to the trash. the former
changes the trash to an eject icon and the latter doesn't. either way,
when you drag a usb volume to the trash, the volume disappears from
the finder window. except if you dragged it from the desktop you've
safely unmounted it, and if you drag it from the finder window, you've
just removed the entry from the finder window. There's almost enough
feedback, but as it happens, i've now safely unmounted my phone half a
dozen times this week because i can't remember how to use apple's drag
and drop metaphor.

Keep in mind that this drop target is supposedly *friendly* it tells
me if it's actually going to eject by changing the icon of the target,
and yet, i still don't manage to get it right most of the time
(probably because my desktop is typically obscured, so i couldn't drag
or see the volume on the desktop).

> Copying, however, is simpler
> and better understood as long as the selection model is clear.

yesterday i was merging two documents using a third window (a browser)
as a reference.

mostly this meant a was copying an annotation ("# UNUSED") from
old-document to new-document
and copying an identifier from new-document to cross reference to
verify whether the identifier was indeed unused.

I did this by having the browser (Camino.app) as approximately full
screen behind a text editor that supports multiple windows (XCode.app)
with two windows side by side.

The process was basically:
* in right editor window (new-document)
1. use the down arrow to move to the next identifier
2. use alt-right to select the identifier
3. use cmd-tab to switch to Camino
* in Camino
4. double tap into the xref search field (this is about 10% down the
screen and 10% to the right of the left edge)
5. use cmd-v to paste
6. use enter to start the search
7. use cmd-tab to switch back to XCode.app
* in XCode
8. use cmd-` to switch to old-document
9. use cmd-c to copy "# UNUSED"
10. use cmd-` to switch to new-document
11. use cmd-left to go to the start of the line
12. use cmd-v to paste
13. loop

In this process, i have two things which have to be in my "clipboard",
obviously neither is in my clipboard as "long term storage", it's in
fact merely drag and drop, but the coordinates of my drag source and
drag targets are too disparate for me to use a mouse for most of them
(and if i was really a keyboard user, i might have arranged it so that
i could use a keyboard to focus the search field in the browser, or
used the urlbar. I'm a power user, not a keyboard user, so i used the
mouse for this step.

the fact is that this process is really drag and dropping between
three windows, i'm only using the keyboard because it's expensive to
retarget and focus each of these areas.

> - copy-and-paste is aimed at long term storage: if you write to the
> clipboard you have to write all the flavours you think a recipient would
> ever make use of! The clipboard often survives computer-restarts.

That's a clipbook, not a clipboard. Most clipboards do not survive
restarts, heck half the time they don't survive apps quiting.

> - drag-and-drop is aimed at direct negotiations: generally, only at the end
> of the drag is the actual data produced. In case this is running over a
> network-based conversion this is significant I feel.

I don't understand this.

> So I would insist to split the two set of events while keeping common, of
> course, some of the interfaces to denote what can be transferred.

Insisting isn't how we do things here. Provide use cases, provide
explanations, try to convince with real data.

Hopefully my example is compelling,.

Received on Friday, 14 August 2009 08:01:13 UTC