[nickm]

But for any given user, dragging within a selection could mean either "I want to drag this selection" or "I want to select a subset of this selection."

It could also mean "I want to delete this text" or "I want to make this text purple". The computer can't read your mind, and so it can only have one meaning, and that meaning has to be decided on by the interface designer. The user has to adjust to that meaning. On OS X, I have adjusted to the click and pause, but I don't like it and I think it's inconsistent. (Actually, the pause has gotten short enough in 10.3 that it isn't such a big deal).

However, I just had to put my two cents in to counter the argument that the "only way" to understand what the user wants to do is with a time delay, which is clearly false.

[weezie]

There is one subtle user context in regards to text selection that apple could do a much better job of distinguishing: Editable text vs. non-editable text.

Some text is inherently not editable, such as, a web page. When the user can't edit the text, then I think there shouldn't be a pause. I happen to be a big fan of the pause within any editable text field, but if I can't change the text in any way, if I can only select and copy it, then that should be the primary task in that context. When I want to quickly grab text off of a website like Lorem ipsum (lipsum.com), I would much prefer it to act like a movable object rather than an editable string of characters.

[himself]

Originally posted by nickm:
It could also mean "I want to delete this text" or "I want to make this text purple". The computer can't read your mind, and so it can only have one meaning, and that meaning has to be decided on by the interface designer. The user has to adjust to that meaning. On OS X, I have adjusted to the click and pause, but I don't like it and I think it's inconsistent. (Actually, the pause has gotten short enough in 10.3 that it isn't such a big deal).

However, I just had to put my two cents in to counter the argument that the "only way" to understand what the user wants to do is with a time delay, which is clearly false.

Deleting or changing the format (the color, in your example) are what you can do to the text after it has been selected, but they aren't a function of dragging over text, whether to select it or drag it. The computer can't do the rest for you in any case. But if a user is going to drag over text, it is to do either of those two functions (select it, or drag it, not delete it or alter it's formatting, which would be the step after the initial selection). Differentiating between those two functions seems like it will always be an issue with someone, at least until we find an interface superior to the mouse.

I agree that we are at the mercy of the interface designers on this one, but they typically don't work in a vacuum (at least, the good ones don't). They have to (or should) observe user behavior and move accordingly. In this case, however, they may as well just flip a coin, because everyone will not be sated.

Also, you are right that a time delay (or, a preemptive click) isn't the only solution for this problem, but it is less intrusive. The same could be achieved with a modifier key, which can get cumbersome, but could be an option... maybe a click-and-a-half (which wouldn't work for dragging, but for re-selecting, but is also a lot less intuitive)... the simplest and easiest to learn methods available to us are to either click beforehand, or wait a split second.

I have my preference, but I could easily adapt to whichever of the two methods Apple happens to settle upon. Or they can let the user choose between the two as a preference option.

[Judge_Fire]

Time spent clicking feels faster than idle time waiting for some forced pause.

To get the instant "select, drag", I'd happily agree to "select, deselect, reselect" as I'd constantly be doing something in a continuous manner, even if there's one step more.

J

[nickm]

if a user is going to drag over text, it is to do either of those two functions

The point I keep trying to make is that the user isn't just dragging over text. The user is dragging over selected text. It is not inconsistent for the system to treat a drag over selected text as different from a drag over unselected text.

[himself]

Originally posted by nickm:
The point I keep trying to make is that the user isn't just dragging over text. The user is dragging over selected text. It is not inconsistent for the system to treat a drag over selected text as different from a drag over unselected text.

My point does apply to selected text. I assumed that much was given. From my point of view, neither method is "inconsistent," but both have their inconsistencies. It's just a matter of which inconsistency we'll have to work with.

As explained earlier by someone else, there is much more you can do with text (especially editable text) than just about any other object in this environment. So the way we deal with text shouldn't be forced to be consistent with the way we deal with, for example, desktop icons, windows, folders, etc; the options for what you can do with either are not always linear or consistent. For example, with icons, you can select and drag with one click (actually, a half click). That option isn't available to text, because the selection range isn't nearly as limited. After selection of an icon (either with a drag or a click), the only operation available (that includes a mouse drag) is moving that icon.

The fact is, the only way to select text with a mouse is with a drag. The only way to move text (or any object) with the mouse is with a drag. It can be argued that it is inconsistent for dragging over selected text to result in anything other than a re-selection, since that is what dragging over text usually does (and it's been that way before moving selected text was available). Your point can be argued equally as well, since in other cases dragging from a selected item results in a move. Like I said before, both methods have their inconsistencies, and I don't believe one is more consistent or "intuitive" than the other. It really depends on how you work and what you are accustomed to.

[Brass]

Originally posted by TETENAL:
But dragging after selecting is more often than correcting an error of selecting

You are making assumptions here. This may be the case for you, but if you had read this entire thread, you would realise that this is not the case for many people.

Personally, I reselect text far more often than dragging it (for reasons already given earlier in this thread: dragging text in the circumstances where I need to move text is usually much more painful than cut/paste because of scrolling issues - too fast or too slow).

[Brass]

Originally posted by himself:
But for any given user, dragging within a selection could mean either "I want to drag this selection" or "I want to select a subset of this selection." It happens. Which is why OS X now implements both method.

Just as for some users the delay for dragging text selections in cocoa can interrupt someone's work rhythm, having to stop to think to click first before you make another selection can interrupt some one else's rhythm. The fact that so many people considered this a problem (myself included) shows that it is an issue. It's just going to be an issue where some users are going to have to learn to deal with a system that doesn't suit them (hey, you can't win them all...). The fact is, either routine requires a fairly insignificant modification of behavior (either waiting a half second, or clicking first), and it's moot to debate which routine works best, since we all work different[ly].

Personally, I prefer the delay, though I have some issues with that method as well. Whichever system Apple decides on, I just hope that they implement it consistently, so that I don't have to guess.

Or maybe, the inconsistency is Apple's attempt to please everyone at once... so if you prefer one system, use only carbon apps, otherwise you should stick with cocoa...?

Yes, the problem with the current inconsistency, is that for those people who use a variety of text editing applications, they have to BOTH click to deselct, AND click-and-wait (or otherwise have to keep in mind which application they're using and remember which behaviour to use).

[BuonRotto]

I've seen similar issues in Windows where you control-clicking selects multiple items out of sequence, but at the same time, control-dragging copies items. A slight slip of your mouse when control-selecting will copy all of the highlighted items in place. I've had the unfortunate experience of making that mistake with a LOT of large files selected. My cursor slips a tiny bit, and I instantly have another 40 files that use another GB of hard drive space in the folder. That's why I STONGLY prefer how Cocoa handles text objects, by waiting a heartbeat before deciding that you're dragging that block of text around. If it didn't, a slight slip of your hand could ruin your formatting. That extra 1/2 second delay prevents a much longer cleanup if you make a minor mistake.

[TETENAL]

I can't remember making a mistake with accidently dragging a selection.

Originally posted by BuonRotto:
That extra 1/2 second delay prevents a much longer cleanup if you make a minor mistake.

⌘Z

[Jasoco]

Originally posted by TETENAL:
⌘Z [/B]

Doesn't work in Safari forms. Nice try.

[BuonRotto]

It's not as bad as on Windows because the Mac OS has a greater tolerance for what it considers a stationary mouse pointer. If the cursor moves even one pixel in Windows, which is common when your hand is on the mouse, there can be fairly drastic consequences.

My feeling is that some hysteresis is good UI practice, like the Dock pop-ups that I suppose people might not know are there, but would be intrusive if they poppped up immediately on a click. This is just another case of waiting a moment to make sure of the user's intent, and IMO beats option-clicking and other more dextrous options that are available. I'm definitely one of these people who highlights or re-highlights a selection to delete or type over it more often than I move it, so making the drag-and-drop object behavior a priority over the current Cocoa behavior seems presumptuous to me, if not downright inconvenient.