GNOME Bugzilla – Bug 543091
wrong place for motion treshold slider
Last modified: 2021-06-09 16:09:55 UTC
Hello, In the Accessibility tab of the Mouse control panel, there is a Motion Treshold slider. As I thought that it would only work for the dwell click, we placed it under the corresponding item in the Accessibility tab. That was wrong: The Motion Treshold works for both, the dwell click and the Simulated Secondary click. So it might be good to move that slider to reflect that it also works for the Simulated Secondary Click. However, we have to take care that the user does not think that the Motion Treshold slider also works generally. In fact, it only works in combination with the Simulated Secondary Click and in combination with the Dwell Click. Francesco PS: I filed this bug against version 2.23.x, but it also occurs in version 2.21.x and 2.22.x.
I don't know how we should fix this. Some usability advice would be great.
*** Bug 544394 has been marked as a duplicate of this bug. ***
I have created an improved gui layout that takes into account the inconsistency for the motion threshold between the gui and how the feature really works. You can view it on the following page: http://live.gnome.org/action/edit/Mousetweaks/Usability It is the picture under the paragraph dated 2008-10-25 (currently the last of the page). In fact, by placing the motion threshold outside of the dwell click feature and outside of the simulated secondary click feature, we can have the following which corresponds to when the motion threshold works: - When the simulated secondary click and the dwell click are both disabled, the motion threshold is greyed (inactive) because it only works when at least one of the two features is active. - When the simulated secondary click is enabled, the motion treshold gets also activated. - When the dwell click is enabled, the motion treshold gets also activated. Somebody might wonder why I did not simply put one motion threshold under the simulated secondary click and a second under the dwell click, like it is the case for the delay slider. Here is the reason: the simulated secondary click and the dwell click both have their own setting for the delay time, so it makes sense to have two sliders. The motion theshold slider however is shared by both features; in other words there is only one motion threshold value in the mousetweaks daemon.
I'd say the new UI doesn't make it clear that the "Motion Threshold" setting is related to either "Dwell Click" or "Simulated Secondary Click". Admittedly, I don't have a better idea, either. Did you talk to the usability guys, yet? Also, in your screenshot both features are disabled, yet "Motion Threshold" is still sensitive.
@Jens First of all, thanks for your feedback. The screenshot was taken from the Glade Editor pane, so please don't take into account the activated/deactivated state of the widgets of the screenshot. Obviously, the Motion Threshold setting will be deactivated when the dwell click and the simulated secondary click are both off. For the user to get aware of the relation of the Motion Threshold to the two other features, I counted on the fact that the Motion Threshold gets automatically activated when the user enables the simulated secondary click or the dwell click. Moreover, the tooltip of the Motion Threshold slider can also inform the user that it is related to the simulated secondary click and the dwell click. I am aware that the solution is not perfect; however I think that it is better than the current situation where there is no hint at all that the Motion Threshold feature is also active when only the simulated secondary click is enabled and that he can change the Motion Threshold setting by enabling the dwell click. Maybe you or anybody else has a better idea about how designing a more accurate layout. That would be great.
(In reply to comment #5) > Maybe you or anybody else has a better idea about how designing a more accurate > layout. That would be great. That's why I asked whether you had spoken to the usability guys...
I have created 3 additional layouts trying to also take the height of the window into account because of bug http://bugzilla.gnome.org/show_bug.cgi?id=554739 The outcome is a really huge control panel. I nevertheless put these layouts on the usability page to show the idea of placing the Motion Threshold in a shared position between the simulated secondary click and the dwell click. http://live.gnome.org/Mousetweaks/Usability @Jens I had not spoken to the usability team yet. Thanks for pointing me to them and there is now an email asking for help in their mailing list.
Created attachment 121740 [details] Quick mockup Your most recent image <http://live.gnome.org/Mousetweaks/Usability?action=AttachFile&do=get&target=motion_threshold_gui_fix.1.png> is actually what I first thought of myself. The relationship between the slider and the two checkboxes certainly might not be very discoverable, though. Taking into account the window size issues in bug #554739, another suggestion would be to strip all the configuration for each option into sub dialogs. That neatly gets around the slider duplication/relationship problems, and greatly simplifies the dialog. Quick mockup attached. The default settings (especially for the Dwell Click mode) would have to be pretty reasonable, of course-- I assume they already are, but especially now that the settings would be hidden, you wouldn't want every user who turned on Simulated Secondary Click or Dwell Click to *have* to go and tweak the settings to make it usable. If there are no reasonable set of defaults that would achieve this, then this probably isn't the right design either. (Incidentally, is there a particular a11y-related reason you use "primary" and "secondary" here, rather than "left" and "right"? There's obviously the usual handedness issue, but elsewhere in GNOME we've made the conscious decision just to use "left" and "right" to refer to the primary and secondary buttons, and we explain that we've done this right at the start of the desktop user guide and other relevant documents.)
Created attachment 191517 [details] screenshot of the mouse accessibility tab in 3.1.3 I think the problem still exists with Gnome 3.1.3, as the Motion Threshold slider is still under Hover click (I guess that's Dwell click renamed), and that doesn't reflect that it also works for Secondary click, as stated in the bug description.
Thanks for your interest in mousetweaks. The mockup from Calum Benson gives the impression that there are two motion threshold sliders in mousetweaks, but there is only one, and it is shared by both function: the simulated secondary click and the hover click (previously called dwell click). Unfortunately, we have not found a good layout yet, that makes clear that there is only one motion threshold slider and that it is shared by both functions.
Moving to "Universal access". I'm guessing that this portion of the UI needs rejiggering. Designers, the motion threshold slider in comment 9 is relevant for both the "Simulated Secondary Click" and the "Hover click" settings. It obviously needs to be moved.
While I don't consider Calum's solution bad, this might be solved by layout alone. As long as we can align things properly (using a table I guess), it seems to be clear the threshold slider applies to both of these controls: https://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/control%20center/mouse/bug-543091.png
I think that a simpler solution would be to move motion threshold to its own section. Motion Threshold Adjust how much the pointer can move when using simulated secondary click and hover click Threshold Small ----------------0------------- Large
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, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.