Drag & Drop Jumps Around Target

Sorry for the weird title. Here’s what happens:


Targeting a drag/drop between two docs is harder than it should be.


I do a ton of rearranging in the Binder, so I’m frequently dragging & dropping documents in or between other documents. Unfortunately, dropping a doc where I want it isn’t just a matter of positioning the pointer accurately – it’s also a matter of delicate timing.

If I drag a doc very carefully so as to display the blue line, targeting the space between two other docs, and then pause momentarily (without consciously moving the pointer), the target suddenly switches to the big oval around one of the two docs I’m trying to drop between. If I then move a few pixels away from the big oval, I get the blue line again, but if I pause a bit longer, the selected target jumps to the other adjacent document and the big oval appears again.

I’ve practiced this quite carefully so as to be sure I’m reporting the right behaviour. Considering the actual pixel rows between documents, it turns out there is one pixel row that jumps back and forth UP, then a few rows that are stable, and then a row that jumps back and forth DOWN. This means that the visual cue (the blue line) is sometimes only correct for a fraction of a second, and then some kind of averaging kicks in and the upper or lower doc gets selected instead of the gap between them.

The net result is that about 25% of the time I accidentally drop one doc into another instead of between two other docs. In such cases, it’s not always a no-brainer to find the accidental drop and try dragging it again.

Thanks for reviewing this small but inconvenient anomaly.


I have also found this very problematic. The drop-zone between cards, or between a card and the border of the editor window, is way too small.

In fact usually it is not possible to make a drop between a card and the left border of the editor window. This means that moving a card to first position is a two stage process - first I have to move it to second position, and then move the first card out of the way.

Thanks for the report. The OP was talking about this in the binder, but it sounds like the second issue is about the corkboard? In that case, try disabling “Allow dropping dragged items onto cards” in the Corkboard tab of Tools > Options.

Allen, something that might help you out, if it is to your taste, is to use Ctrl-Arrow keys to move items around. Obviously those are better once you are within striking distance, so just plopping the item down quickly and without regard to precision, then following up with a few quick arrow taps is a pretty efficient way to get things where you want them to be.

Ah, yes, sorry.

Ok, that would work, but with a significant loss of functionality. Why not increase the size of the drop-zone, and allow cards to be dropped on the left margin?

Sorry, yes, the drop-zone is too large. I just meant that as a possible workaround for the time being.

Thanks, AmberV. I’ve tried this, but even the “without regard to precision” approach is a problem, because precision is the only way to make sure a drop isn’t into another item instead of between them. The algorithm strongly prefers selecting an item, since they are many pixels high, and the actual drop zone for “between” appears to be literally one pixel! And which pixel depends upon how many milliseconds you pause before releasing the mouse button.

Yes, I think we agree that the model could be tweaked (whether or not it can be is another thing, and the whole bug with the drop target alternating between nesting and sibling certainly needs to be addressed). My point was that with Ctrl-Arrows you don’t have to worry too much over cases where the item accidentally drops into a container (correcting that when it happens is a simple Ctrl-LeftArrow). When I said “without regard for precision”, I mean that you could just drop the item in the general vicinity, without any fussing about, and then now that it is a couple or so “taps” away from where it needs to be, using Ctrl-Arrows to get it positioned correctly is all you need.

And for items that are only moving around in the local area, you can entirely use Ctrl-Arrows efficiently, and ignore drag and drop, reserving it only for those occasions where the item is dozens or hundreds of “slots” way from where you want to move it, and using arrow keys to move it would be prohibitively slow. Hope that makes more sense.

I must have misunderstood – I interpreted your suggestion as “drop near the destination and then Ctrl-Arrow the last bit”, which would still most likely divert inside some nearby item, which is still a problem when items near the destination are themselves collapsed and internally complex. It becomes hard to find the original mis-dropped item.

But your point about using Ctrl-Arrows for the whole trip is the best solution in my workflow. Although I tend habitually to drag/drop to reorder a list, it’s actually about 98.2% as easy just to Ctrl-Arrow the blighters about.