After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 754455 - Figure out a good way to navigate when dnd
Figure out a good way to navigate when dnd
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 745264 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-09-02 13:19 UTC by Carlos Soriano
Modified: 2021-06-18 15:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Diogo mockups (514.23 KB, image/png)
2015-09-02 13:19 UTC, Carlos Soriano
Details

Description Carlos Soriano 2015-09-02 13:19:07 UTC
Created attachment 310498 [details]
Diogo mockups

Previous 3.18 we were automatically opening a folder when hovering it while performing drag an drop. However, timeouts and performing actions when the user is still is problematic.

See context at:
https://bugzilla.gnome.org/show_bug.cgi?id=727790
And original email which implemented the feature:
https://mail.gnome.org/archives/desktop-devel-list/2003-February/msg00919.html
and follow up for problems that people were worry about.

For 3.18 we disabled it by default to avoid making the experience difficult, but it would be nice to have a good way to navigate while dnd.

In bug 727790 Diogo Campos did some nice mockups (thanks!) that could be a good solution. I'm attaching them on following comments so we can discuss them for 3.20 (when also, if there is time after the views rework, one of the items is adding actions bars, so these mockups will fit nicely).
Comment 1 Diogo Campos 2015-09-02 22:29:46 UTC
Companion text to the mockups:

1 - User holds a file/folder.

2 - User hover over a folder (nothing should happen, just usual visual guide/confirmation).

3 - User drops the file/folder.

4 - A confirmation dialog (popover?) with three options appear:

[Move file/folder "x" to folder "y" | Enter "x" folder | Cancel move]

4.1 - If "Move": drop file/folder into that folder (without opening it).

4.2 - If "Enter": open that folder and show (unobstrusively, somewhere) two options:

[move file/folder "x" here | Cancel move].

4.3 - If "Cancel": cancel move attempt.

NOTE: A *strong* reason for the "cancel" option is mine personal experience in witnessing huge organization mess that happens when users drag a file/folder unintentionally (because malfunctioning mouse, touchpad bad quality or settings, little skills with touchscreen, disabilities, or whatever reason). They *definitely* don't even know what happened to them, let alone how to fix it.
Comment 2 Carlos Soriano 2015-09-03 07:48:00 UTC
The behaviour looks like a good trade-off, it's not as quick or convenient like the current implementation (just one click and one release) but it allows to take the time the user considers necessary to navigate trough the folders, even quickier than hovering and waiting.
Also, is touch friendly, because can't imagine how do you cancel the current implementation in a touch dnd operation.

> NOTE: A *strong* reason for the "cancel" option is mine personal experience
> in witnessing huge organization mess that happens when users drag a
> file/folder unintentionally (because malfunctioning mouse, touchpad bad
> quality or settings, little skills with touchscreen, disabilities, or
> whatever reason). They *definitely* don't even know what happened to them,
> let alone how to fix it.

And it's the main reason that made me disable the behaviour. We can't relay on those things, and even more if the consequences can be more or less important like losing track of important files, dropping in a public folder unintentionally leaking private data, etc.
Comment 3 luke.nukem.jones@gmail.com 2016-05-29 01:41:45 UTC
It took copious amounts of Google trawling to get here, and find that there was recently a dconf key added to disable this behaviour.

This behaviour as many people have already noted, is rather jarring for new users, and can cause some very bad behaviour; eg, pause over one folder, and before you know it you're knee deep in it. All too often I found that I'd accidentally end up 3 or 4 folders down from where I started.

*And*, my first thought was "there must be an option in preferences to turn this off". Well, there wasn't. My next thought was "Okay, the time delay must be configurable". Nope, that wasn't either.

If these types of UI/UX changes are going to be introduced, then reasonable steps should be taken to give users the ability to *change* the behaviour if it doesn't suit them, and *without* having to dive in to dconf. This goes for much of Gnome tbh, all too often I find that "expected" options are missing, and I either have to search with Google for ways to adjust them (in extreme cases, recompile source), or they are just shunted off in to "Gnome-Tweak-Tool". Things such as "start-up apps" should be a common option under common settings.

/rant

Please introduce a proper option under "Preferences/Behaviour" for Nautilus and the DND behaviour.
Comment 4 Carlos Soriano 2016-05-30 08:21:04 UTC
(In reply to luke.nukem.jones@gmail.com from comment #3)

Please only comment if it adds some valuable information/proposal for solving this.

I don't think an option is the right thing here, because this behavior is simply broken imho. Also adding an option and remove it afterwards when is fixed always bring complains from everyone using the UI.

>If these types of UI/UX changes are going to be introduced

This was introduced 14 years ago, when no UX/UI design was being done when introducing features.
Comment 5 António Fernandes 2017-08-12 16:03:49 UTC
*** Bug 745264 has been marked as a duplicate of this bug. ***
Comment 6 António Fernandes 2017-08-12 16:10:20 UTC
(In reply to Diogo Campos from comment #1)
> NOTE: A *strong* reason for the "cancel" option is mine personal experience
> in witnessing huge organization mess that happens when users drag a
> file/folder unintentionally (because malfunctioning mouse, touchpad bad
> quality or settings, little skills with touchscreen, disabilities, or
> whatever reason). They *definitely* don't even know what happened to them,
> let alone how to fix it.

An alternative would be notification "File X was moved to Y [UNDO]".

We already have such in-app notifications for undoing sending items to trash, and we have the hability to undo a move with Ctrl+Z. We need a notification for this too.
Comment 7 André Klapper 2021-06-18 15:54:31 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of Files (nautilus), then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/nautilus/-/issues/

Thank you for your understanding and your help.