News for hackers. Stuff that matters.
Re:Show HN: my Mac app just got fireballed by robomartin on Wednesday May 09, 2012 @02:44AM (#3947340)
Well, drag and drop isn't any more discoverable than c/c/p. For example, when I first started to use a Mac I had to Google to figure out how to import ebooks into my iPhone. It turns out that you have to drag-and-drop into iTunes. Just like c/c/p, once someone tells you that this is the way we are going to play the game it all makes sense.

The grab-something-and-move-it interface is OK for "normal" users. I would suspect that most techies might be far more inclined to figure out how to avoid miles of drag-and-drop action by using the keyboard.

There's another element to this. Our systems have, at a minimum, two 24 inch monitors and most have three 24 inch monitors. Drag-and-drop gets pretty old once you start to have to cruise around so much real-estate.

Beyond that c/c/p, per your own data point, has been around since the early 70's. That makes it a convention that's been around for possibly over 40 years. I think people get it.

This, of course, extends to operating almost any software. If someone is using it with any regularity it'd be crazy to mouse all over the menu system to get things done. The keyboard is far more efficient. This is particularly the case when macros can be programmed and invoked.

In general terms, I agree: For grandma, drag and drop is great and she is not likely to learn any keyboard shortcut at all. For anyone who is not a casual or lightweight computer user there's a whole other layer to the UI --via the keyboard-- that makes for better driving.

Dragondrop is a great tool. I was sincere when I said that Apple should buy it and integrate it into the OS. Not for me and those like me, but for the benefit of others for whom the grab-and-do-something interface is the only option.

Re:Show HN: my Mac app just got fireballed by jacobolus on Wednesday May 09, 2012 @02:51AM (#3947356)
I never said we shouldn’t try to make a system accessible from the keyboard, or that drag-and-drop as typically implemented is the best solution here. I merely said that c/c/p is at once too difficult/brittle and too limited.

Personally, I wish we used some kind of mashup/spinoff/extension of DragThing, Quicksilver, drag-and-drop for this sort of thing: flexible, letting us do more with the stuff in it than just paste it back, accessible from both keyboard and mouse ideally from anywhere on the screen, persistent and non-destructive. It’s a non-trivial problem, because we need something that scales from novices up through experts. But there’s a very large design space here, and most of it has been ignored for 30 years because the existing non-ideal conventions have ossified.

It’s exciting to see even tiny new ideas, like the utility being discussed in this conversation.

To follow your thought here: with all that tremendous quantity of monitor space available, we really should be devoting some chunk of it to showing what’s on the clipboard, or at least that there’s something there.

Re:Show HN: my Mac app just got fireballed by robomartin on Wednesday May 09, 2012 @09:43AM (#3948491)
> we really should be devoting some chunk of it to showing what’s on the clipboard, or at least that there’s something there.

I could see that. Microsoft tried something like that with a stack-based (presumption) clipboard in Office. I don't think it worked very well. I thought it was confusing for most. You went from copy-this-and-then-paste-it to having to select what you wanted to paste. Simple is better in this case.

I can think of no instance where I explicitly needed to know what was in the clipboard. Now, admittedly, this is me, a single data point and not a casual user. I am sure it is different for casual users. In fact, I am sure that most of them don't have a clue that ctrl-c/v/x/z exist.

As for devoting screen real-estate for showing clipboard content. I can't really get a feel for the idea because I don't feel that I need it. In some cases I know that I don't want to give up any screen real-estate to anything other the the application/s currently running. For example, my EDA package uses three screens very well. I don't want to see anything else while doing this work. Again, just me.