Adding a confirmation dialog to every drag/drop operation does not solve the problem


A customer wanted to know how to enable a confirmation dialog whenever the user inadvertently perform a drag/drop operation in Explorer to move files within a volume.

For example, if I have an S drive mapped to \\server\share, I would like to display the confirmation dialog when users inadvertently drag and drop a file or folder within the S drive.

Okay, first of all, the problem statement doesn't match the question. But that's good, because the question was misguided.

The question was "How do I add a confirmation dialog to every drag/drop operation?" But the problem statement was "We have users who inadvertently drag and drop files."

So they didn't actually want the confirmation on every operation; they only wanted it on the accidental ones.

Of course, the computer can't read your mind, so it doesn't know what you were thinking when you performed a drag/drop operation in order to determine whether the operation was intentional or accidental. The customer asked for a dialog box to appear after every operation just in case it was inadvertent. But since most actions are intentional, the result is that users get confirmation dialog after confirmation dialog. Soon, dialog fatigue sets in, and users just get into the habit of ignoring them.

But let's go back to that inadvertent adjective. The way to reduce the likelihood of accidental drag/drop operations is to adjust the drag sensitivity so that the mouse must move a "significant" distance before a drag/drop operation is initiated. What constitites a "significant" distance is something you can choose based on your own experiments.

Comments (42)
  1. My psychic powers guessed the entire article's content just by the title :-) . But it's good to tell these stories from time to time, so we can learn. The sad part is that we tend to ignore the "fatigue", and we end boring users with hundreds of dialogs, which teaches users just to ignore the text and look automatically for the OK button. Which is exactly the opposite of what we tried to achieve in the first place.

  2. Joshua says:

    For some of reason I'm more attuned to the heuristic of to drag an item for effect you must drag its center out of its bounding box.

  3. MJP says:

    And the way to reduce the consequences of accidental operations is to have a good Undo function. It also helps to provide clear but unobtrusive feedback that something has happened (say, an overlaid semi-transparent animation).

  4. Dan Bugglin says:

    @joshua A similar effect can be achieved by making the drag sensitivity point half the width/height if a typical item.  And it will even work a little better since in your scheme if a user drags an item by the corner it will start dragging almost immediately.

    Making drag sensitivity based on item size is an interesting idea but it is likely to get annoying since it will cause the drag sensitivity to change.

    Side Nitpick about MSDN Blogs: MSDN Blogs serves a HTTP 302 Found to redirect to error pages.  This blows away your browser tab's history of the article url you were trying to load since your browser assumes the article has moved to the error page URL.  It's very annoying and impacts the usability of the hosted blogs, a 500 or a 307 would be a better choice (not sure if browsers will respect a Location header without a 3xx code).

  5. Dan Bugglin says:

    @joshua A similar effect can be achieved by making the drag sensitivity point half the width/height if a typical item.  And it will even work a little better since in your scheme if a user drags an item by the corner it will start dragging almost immediately.

    Making drag sensitivity based on item size is an interesting idea but it is likely to get annoying since it will cause the drag sensitivity to change.

    Side Nitpick about MSDN Blogs: MSDN Blogs serves a HTTP 302 Found to redirect to error pages.  This blows away your browser tab's history of the article url you were trying to load since your browser assumes the article has moved to the error page URL.  It's very annoying and impacts the usability of the hosted blogs, a 500 or a 307 would be a better choice (not sure if browsers will respect a Location header without a 3xx code).

  6. Dan Bugglin says:

    And error pages give the impression your posts don't go through… sorry.

  7. Joshua says:

    @The MAZZTer: They in fact work the same if all items are the same size. "Drag the center out of the bounding box" is rather specific. If snap-to-grid is enabled, a smaller drag is almost always a no-op anyway.

  8. Maurits says:

    Or better yet, adjust the permissions on \servershare so that users have read-only access.

  9. Why hasn't MS tweaked the drag sensitivity over the years to a slightly higher value where drag and drop accidents don't happen?

    [You should be rejoicing. It's something from XP that we haven't screwed up yet. -Raymond]
  10. Nicholas says:

    Accidentally copying a file is one thing, accidentally moving it is another.  At least with the former you still have the file in its original location — when you move a file (drag-drop onto the same volume) it's just "gone".  While Explorer has an Undo operation, most people don't know about it and even if they do it's only helpful if you use it immediately.

    @John:

    Yes, it's a pain. Lazarus is a very nice addon for Firefox which saves form content, and it's saved me a huge amount of time and headache.  I imagine other browsers probably have similar tools.

  11. Brad Westness says:

    @xpclient I'd bet good money that Microsoft does tune the sensitivity based on telemetry data with every release. The trouble is that what some consider too sensitive, others would consider too forgiving. They have to pick something sane, but it's never going to be guaranteed to work for everyone. Hence the configurable option.

  12. Mark Y says:

    xpclient: You want to avoid setting it too high, because sometimes you want to drag something to a nearby location.  If the destination is 20 pixels from the initial position, then the default of 4 pixels is already a bit high.

  13. Deduplicator says:

    @xpclient:

    There's no one-size-fits-all, there are always those fumble-fingered guys, which is the reason this will stay a tunable setting.

    A too big value is just as much a nuisance as a too little one. Just the trigger changes.

    Story: Why do I can't I put that file directly in the proper folder? Why must i first drag it to the other side of earth?

  14. j b says:

    @John:

    Yes, you do get an indication that it has failed: You are returned to the top of the comments WITHOUT that greeen-background line saying thank you and maybe your comment will require moderation.

    So the standard procedure for posting, after having written your comment is

    1) Press Ctrl-A in the text buffer to mark all contents, then Ctrl-C to save it.

    2) Click the Post button

    3) Look for the green line – if it is there, you're done!

    4) Scroll down to the comment field at the bottom and click in it

    5) Press Ctrl-V to paste your comment text

    6) Fill in the Name field anew

    7) Go to step 2

    Usually, 2-3 loops are enough to get a green line. Once a forthnight you complete first time you do step 3.

  15. chentiangemalc says:

    I think the drag sensitivity is fine, and a good "undo" function is in place – Ctrl+Z to Undo. However how do you learn Ctrl+Z to undo the copy operation you didn't want to do? Unless I'm blind I can't see any GUI indication that "undo" is an option (on Windows 8 explorer)

  16. asdf says:

    @chentiangemalc:

    Right click in the explorer window. An undo item is in the context menu and it displays the Ctrl combination too.

  17. John says:

    @The MAZZTer:  MSDN Blogs is an awful platform.  My favorite feature is when you spend 10 minutes working on a response prior to submitting it.  Does your response go through?  Nope.  But you at least get some kind of indication that an error occurred, right?  Nope.  *sigh*  But don't worry!  After you've been bitten by this bug enough times you will get in the habit of copying your comment, hitting submit, then refreshing the page a few times to see if your comment went through.  I'm not bitter.

  18. In my experience the problem with accidental drag-drop has to do with two things: First, users not actually knowing about drag-drop being a thing, they aren't aware that clicking and holding an item then moving elsewhere means something. This connects to the second, which is clumsy mouse handling. Not being fully aware of drag operations on icons can lead users to be careless with their mousing, doing accidental drags. This isn't a problem for the one actually commonly used drag operation, selecting text for copy-paste, because that one generally isn't destructive, but it becomes one when icons in Explorer are involved. I'd say particularly trackpads are to blame for poor mouse control, with the loads of gestures they accept.

    The mouse training seen in Windows 3.1 could be due for re-introduction.

  19. JDP says:

    Maurits: *Inadvertent* copying, not illicit copying!

  20. Cheong says:

    How about when Explorer has the dragover event, when it detects the drop is from another drive, instead of allowing the whole window "drop target", only allow a specific region plus the folder icons to be drop target? (Explorer should highlight the dropable regions to tell the user they can drop there if they want to move files there)

    Reducing drop target's surface area helps to prevent inadvertent drop actions.

    [It also becomes harder to explain. "When I try to copy a file by dropping it into a window, sometimes it works, and sometimes it doesn't." -Raymond]
  21. Jim says:

    You can enable confirmation for drag-drop operations by dragging with the right mouse button instead. This gives a little menu when you release: "copy", "move", "create shortcut" and "cancel" (the cancel item is a decoy; just clicking elsewhere has the same effect).

    Of course, if you didn't mean to drag at all – rather than you started dragging and changed your mind – then this doesn't help.

  22. When I fall into the "accidental drag-drop" trap, the problem is not with the drag part, not with starting the drag. I indeed want to grab and move something, and I want to drop it into another file explorer window. Let's say the desktop is huge, and I have to roll the mouse twice. Then I accidentally release the left button in the middle of the move, and *poof*, the stuff is gone somewhere!

    The above scenario happened with me mostly on Mac, especially with the one button mice. (Fortunately, I'm a commander fan since the DOS Norton Commander times, so on Linux I use Midnight Commander, and on Windows Total Commander. As a result I don't have to juggle and poke with the mouse, and I perform file copy and move operations 100x faster and always knowing what's going on.)

  23. ender says:

    @tocsa: you need to roll your mouse twice to go from one side to the other? My mouse isn't particularly fast, but I need about half of mousepad to go through all of my 4 side-by-side monitors…

  24. Phill says:

    The big problem is that users often don't realise they've done something wrong, or know how to correct it if they did.

    The file system should keep track of historical changes, which are also displayed in explorer somehow, with the ability to undo them.

    This would be hard to retrofit onto a classic OS design like Windows though.

  25. Piotr says:

    @phil:

    So, what is a more modern design than Windows? Unix, which predates it by 20 years?

    Don't get me wrong, I think Unix-based and -inspired OS are better alternatives to Windows, I just don't like nonsensical arguments.

  26. Rick C says:

    @tocsa, the solution to your problem is to arrange your two windows so you aren't dragging across your entire desktop.

    @j b and others talking about the horrible blog software, I prefer, when I remember, to copy the contents of my comment, and then, before trying to post the comment, refreshing the page, pasting the comment, and posting.

  27. I thought answer to the question was "we already implemented this" ;-)

    When you drag zip/dll or other "harmful" files into a \servershare folder, explorer shows a warning upon drop.

  28. voo says:

    @Phill: Since the FS has pretty much *nothing* to do with the OS I assume the last sentence is just a thinly veiled trolling attempt? Anyhow NTFS is a journaling FS and you can indeed access the Change Journal: msdn.microsoft.com/…/aa363798(v=vs.85).aspx

    Why do you think you need OS support for something that's completely done on the FS level?

  29. @tocsa: "I indeed want to grab and move something, and I want to drop it into another file explorer window. Let's say the desktop is huge, and I have to roll the mouse twice. Then I accidentally release the left button in the middle of the move, and *poof*, the stuff is gone somewhere!"

    That is why I prefer a high DPI mouse that needs very little travel to cover large distances across screen, especially with high pointer motion set.

  30. Random832 says:

    @Voo """Since the FS has pretty much *nothing* to do with the OS I assume the last sentence is just a thinly veiled trolling attempt? """

    That's unfair. In the context of his comment, he is clearly asking for a multi-level Undo feature at the UI level, which is entirely relevant to the current discussion… which he then goes on to speculate would need support from the filesystem and is not supported by the present filesystem.

  31. 640k says:

    The only reason for confirmation dialogs are for the software developer to easier be able to blame the user for clicking wrong.

    This is the mating call of a badly designed GUI and the mating call of lousy developers.

    It's still the software developer's responsibility to prevent the user from performing faulty actions, no matter how many confirmations the user confirms. Confirmation dialogs doesn't prevent errors, it's only makes the user angry.

  32. Cesar says:

    @John, @j b: You are doing it wrong. What almost always works is:

    1. Write your comment

    2. Ctrl-A, Ctrl-C it

    3. *Reload the page* (I like going to the URL bar and pressing Enter, instead of just F5)

    4. *Quickly* paste the comment back, write your name again, and submit.

    Yeah, as they say on thedailywtf.com, the *real* wtf is this blog software…

  33. Mott555 says:

    The obvious solution is to display another confirmation dialog after the first confirmation dialog. "Are you sure you meant to click 'Yes' on the previous dialog? Yes or No"

    I'm not sure how this would solve accidental drag/drop operations, but something must be done and this is something!

  34. ender says:

    > Yeah, as they say on thedailywtf.com, the *real* wtf is this blog software…

    Would you believe that TheDailyWTF forums and this blog software are made by the same company?

  35. @Random832 says:

    >That's unfair. In the context of his comment, he is clearly asking for a multi-level Undo feature at the UI level, which is entirely relevant to the current discussion… which he then goes on to speculate would need support from the filesystem and is not supported by the present filesystem.

    >> I disagree, its completely unfair and a troll; he's speaking for a place of ignorance without bothering to do any type of research to find that it is indeed possible to implement what he asks for. Instead of offering a solution ("Why doesn't explorer just expose the Change Journal with a fancy UI?") he instead offers the flamebait "This would be hard to retrofit onto a classic OS design like Windows though."

    Thinly veiled troll, but as usual asking for a feature that could already be implemented should explorer choose to do so (every feature starts at -100 kids).

  36. Anonymous Coward says:

    I don't think users would appreciate having to wade through every file change made by any program. They only care about changes they made. (And how do you tell between Program X saving a file on behalf of the user, and Program X saving its spell checker dictionary?)

  37. Gabe says:

    I think what Anonymous Coward is trying to say is that the NTFS Change Journal is utterly useless as a means of providing an undo buffer for Explorer. One of those reasons being that it records all changes to the FS, while Explorer would only want to undo explicit UI actions.

    Other reasons are that: it records the actions of all user accounts, while you could only undo your own actions; it wasn't designed to be an undo buffer so it doesn't include all the information needed to undo an action; it only includes the changes for a single volume — what about network volumes? — so Explorer would have to combine the change journals of every mounted volume; it records information at too granular of a level, so the entry "Copy folder" in your undo buffer could correspond to thousands of change journal entries; and of course undoing an operation adds more items to the change journal rather than removing them, so there would be no way to pop things off the undo stack.

    The NTFS Change Journal is designed to let programs that need to know the state of all files on the volume (antivirus, backup, indexing) what files have changed since they last ran. It's not designed to let a user reproduce the state of the volume at some given time.

  38. Marius says:

    We have network shares that are accessed by a lot of users with write access, and it happens all the time that a folder has been accidently moved into a sub-folder. Really annoying for everybody involved!

    Are there any better ways to prevent this from happening other than changing the drag sensitivity for all users?

    For instance, why not come up with some clever heuristics that detect this situation? I would bet some serious money that people are performing a grandma-style double-click while moving the mouse when these things happen. When this happens in a treeview or listview, you could take corrective action. Or defer the action until you heuristic says its fine. Better, have Windows detect that a grandma/grandpa is accessing the PC and adapt the relevant system settings (hey, there is a patent opportunity right here).

  39. The real problem is that Windows sorely needs the new NTFS with history/revisions, or whatever you'd call it, where any file replacement/rename/delete is logged and can be unrolled. This would replace the recycle bin, and "previous versions" feature. If all files/directories are stamped with an incrementing "update serial number", fileop undo, indexing and incremental backup would become very easy, as any changes could be easily found without thrashing the whole giant disk with million files.

    [Are you also including partial file updates, too? You do realize that this would result in the journal being larger than the actual data. -Raymond]
  40. @Marius:

    You can deny folder rename/move privileges to the users. You can even only allow creation of files, but deny any changes.

  41. [Are you also including partial file updates, too? You do realize that this would result in the journal being larger than the actual data. -Raymond]

    The directories/files would need another attribute bit to enable/disable history. For example, %DOCUMENTS% would have it enabled, but %TEMP% should have it disabled. Most client applications don't do partial update; those that do can use either explicit requests for snapshots, or copy on write allocation. Database type server application, of course, use their own logging, and keep the files in folders with history disabled.

    With the disks being obscenely giant, keeping the history makes sense.

    [Would it be enabled for the registry hive files? Your icon cache? IE history? Those files churn a lot. And maybe you haven't noticed, but hard drives are small again (thanks to SSDs). -Raymond]
  42. [Would it be enabled for the registry hive files? Your icon cache? IE history? Those files churn a lot. And maybe you haven't noticed, but hard drives are small again (thanks to SSDs). -Raymond]

    Of course, it only needs to be enabled for those places that make sense. The caches are essentially temporary files. The registry only needs snapshots at certain times.

    250 MB SSD is quite affordable, and while not obscenely big, it still has a lot of space.

Comments are closed.