GNOME Bugzilla – Bug 753149
Designing a coherent behavior for performing actions on items using miscellaneous input device, especially pointing device
Last modified: 2016-01-30 17:29:43 UTC
Currently the user experience for performing actions on items, especially file selection, is widely inconsistent. And often designed with "multi-buttons mouse and multiple clicks" in mind. So user is assumed to have both this devices and the ability to perform the required digital gymnastic. Nautilus have a default behavior of launching the main associated action when double click on files. You can turn that to a single click in the Nautilus preferences (rather than in the global mouse configuration). But file chooser, which use the same default paradigm, won't follow this preference change. When it comes to selecting several file, one is expected to use crtl/shift keyboard keys. As touch screen is well established by now, it shouldn't be assumed that the user have a keyboard. Moreover, even if it does have one plugged in, and that this behavior is let as an alternative, there should be some contextual information that let user know that they can do so. For example a mouse hover tooltype, or message at the bottom of the selection panel. Currently things are moving, and a selection pattern as already been introduced in several GNOME applications. But in the current state, it creates even more inconsistency in the user experience. Also the current selection design may probably be improved with a wider usage in mind. The resulting design should probably be based on the following assumption: * no specific pointing device in mind for the main behavior pattern; * as far as possible, people with disability shouldn't need an accessibility option. Which means: no option which is easily accessible only if you can make second/third button click, some multi-input combination, short/long time pointing, random incantation gesture and other ninja +5 ninja trick. Of course having incantation gesture as an *alternative* input path should be possible, and it's fine that it would be more efficient as long as the main path is not burdened as a side effect of its implementation. Regarding ninja trick, *cabal sight*, we all know there is no ninja, don't we? Here are some input device you may want to test the design upon (at least in your mind to see how extensive the design is): * keyboard * mouse/trackball/trackpoint * touchpad/touchsceen * graphic tablets * Wii Remote/Wiimote * Kinect * input gloves (indispensable for incantation gesture, isn't it?) Related links: * https://bugzilla.gnome.org/show_bug.cgi?id=121113 * https://bugzilla.gnome.org/show_bug.cgi?id=696320 * https://wiki.gnome.org/Design/SystemSettings/Mouse * https://wiki.gnome.org/Design/OS/SelectionPattern
How is this different from https://wiki.gnome.org/Design/OS/SelectionPattern ? Is this gnome-shell specific, or instead a general issue?
I wouldn't say it's different, but I thought a bug report would be complementary. I did contributed to the wiki page, but I'm unsure that it is a good tool to follow suggestions, feedback and track progression on the topic.
(In reply to psychoslave from comment #2) > I wouldn't say it's different, but I thought a bug report would be > complementary. I did contributed to the wiki page, but I'm unsure that it is > a good tool to follow suggestions, feedback and track progression on the > topic. It is true that bug reports are generally more actionable than wiki pages. However in this report I see mentions of application (nautilus, selection pattern) and toolkit (filechooser) behavior, but no mention at all of anything provided by gnome-shell. So is there a list of concrete *gnome-shell* issues you have in mind that we can actually fix? Because none of the issues you have listed so far have anything to do with gnome-shell, and thus cannot be addressed by us.
Sorry, I skipped the gnome-shell assignation issue in my previous message. Yes you are perfectly right, I miscategorized this bug. I recategorized it to gnome-desktop. I don't see an obvious way to add several components, so I let it to general. Feel free to change categorization if you think of anything better.
gnome-desktop is an admittedly confusing component as well, but it actually refers to a helper "libgnome-desktop" library. We should probably rename it at some point. We don't have any desktop-wide product as far as I'm aware, so let's change this to the GTK+ toolkit product.
A bug is not the best place for an open-ended design discussion like this.
(In reply to Matthias Clasen from comment #6) > A bug is not the best place for an open-ended design discussion like this. What would you recommend then? Mailing list? A quick search[1][2] doesn't allow to find a mailing list dedicated to design. [1] https://mail.gnome.org/mailman/listinfo/ [2] https://wiki.gnome.org/Design
(In reply to psychoslave from comment #7) > (In reply to Matthias Clasen from comment #6) > > A bug is not the best place for an open-ended design discussion like this. > > What would you recommend then? Mailing list? A quick search[1][2] doesn't > allow to find a mailing list dedicated to design. These kinds of discussions are best had in a high-bandwidth medium. Ideally face-to-face (e.g. at a conference like guadec). Second best a video call, like a hangout. Third best: realtime communication on irc, e.g. #gnome-design. Email discussion on public mailing lists tends to get derailed quickly, and bugzilla discussion is usually focused on identifying a concrete issue, and closing it quickly (from my side, at least).
not a bug, but a design discussion