Mousetweaks' usability page

If you don't know mousetweaks, please have a look homepage.

What is the problem we are trying to solve?

We want to make mousetweaks more conform to the HIG of GNOME.

Currently the user interface, consists of the following elements:

There is a General tab with a button to to start and stop mousetweaks. It also contains a slider which is functional during the delay and the dwell click to make them ignore little movements.

*

There is the dwell tab, where the user finds the different settings for the software click. Below you can see the Click type window where the user tells to the dwell function what click to perform next.

There is the delay tab, to activate the fonctions the opens the contextual menu with a left click and hold. The slider is used to tell to the delay click how long the user has to keep the button pressed before it should open the contextual menu. The dialogue that you can see on the image under the mousetweaks preferences appears when the user enables the delay click while the dwell click is active. In fact, there is no sense in running them simultaneously.

Finally, here is a picture of the upper panel to show:

• the dwell applet, which can be used instead of the window to choose click type
• the capture applet: when the cursor goes over the green area, it gets trapped until the user releases it with a determined key combination

Sample Improvement

On the mailing list, Gerd already made a few propositions, which were based on how the keyboard accessibility features are already presented in GNOME. What about the following?

• There is first the Assistive Technologies preferences:

• We could add an additional button to the Assistive Technologies preferences to open the Mouse Accessibility; similar to the button to open the Keyboard Accessibility. By the way, the Passwords Dialogue As Normal Windows checkbox is an Ubuntu patch that sets an already existing gconf-key to make the Passwords Dialogue modless; otherwise it is not possible for an onscreen keyboard to enter the password into the Password Dialogue GUI.

• Then we could add an Accessibility button to the Mouse preferences similar to button that you can find on the Keyboard preferences:

• Finally, we could rework the mousetweaks preferences to make it look more like the Keyboard Accessibility preferences. We could:

• get rid of the 3 tabs in the mousetweaks preferences and
  • move the start button to the top of the preferences window
  • place the ignore movement slider below the start button
  • below the slider, use radio buttons to choose between delay click, dwell click with the window, and dwell click with gesture. This would also allow us to get rid of the warning which tells us that enabling the dwell click will disable the delay click and vice versa.
• rename several items: for example "delay click" does not tell to the user that it is the fonctionality to open the contextual menu with a click and hold of the left mouse button.
• replace the start button with a checkbox similar as in the Keyboard Accessibility preferences
  • This would give us a Mouse Accessibility Preferences window similar to this (it is only a quick sketchup built with cut and paste from different sources):

• When the upper checkbox is disabled, everything in the window should be greyed. In fact, the ignore pointer movement is only effective in combination to the left click&hold and dwelling.

• The use of a radio buttons instead of checkboxes in the Fonctionalities part of the window, is due to the fact that only one fonctionality can be active at a given time. (Of course, the left click&hold should be greyed when its radio button is not active.)

Gerd also started a blueprint to improve the feedback of the cursor during dwelling: https://blueprints.edge.launchpad.net/mousetweaks/+spec/cursor-overlays

We will appreciate any comments, propositions and designss about improving mousetweaks, especially those from the Desktop, Usability and Accessibility teams.

Comments and propositions

Please add your comments here.

MatthewPaulThomas: MouseTweaks’ contraventions of the HIG are few and minor:

• The “Stop” button should not be a button. (“Do not use groups of toggle buttons in dialogs unless space constraints force you to do so”, and “Only use toggle buttons in groups, so they are not mistaken for regular buttons”.)
• There should be more spacing between “Stop” and “Ignore Pointer Movement” than there is between “Ignore Pointer Movement” and “Threshold”. (“…[L]eave space between user interface components in increments of 6 pixels, going up as the relationship between related elements becomes more distant.”)
• Six of the labels in the “Dwell Click” tab have the wrong capitalization (“Use sentence capitalization for radio button labels”), and the last four should also end in a colon (“If the label precedes the control it is labelling, end the label with a colon”).
• If the “Enable Delay Click” alert is retained, its icon should be an exclamation mark in a triangle, not a question mark in a diamond. (“A confirmation alert … uses the stock warning icon.”)
• If the “Enable Delay Click” alert is retained, its buttons should not be “Yes” and “No”. (“A confirmation alert … presents … a button labelled with a verb phrase describing the action to be confirmed, or labelled OK if such a phrase would be longer than three words … [and] a Cancel button.”)

However, I strongly suggest aiming higher than mere compliance with the HIG! For example, your goal might be “to make Gnome usable for people who have trouble using a pointing device”. I think that even after fixing the HIG errors, MouseTweaks in its current form would succeed in that goal for less than 30 percent of people who tried it.

These problems with the current design are not covered by the HIG, except in its general “Design for People” principle:

• It doesn’t make any sense for this window to be separate from both the Mouse preferences and the “Assistive Technology” preferences windows. (“Delay Click” is not an accessibility feature, but the rest of the features are. Gerd’s first suggestions above are a start, but the “Assistive Technology Preferences” window itself is a disaster and really needs replacing.)
• “Mousetweaks Daemon” is an implementation detail that should not appear in the UI at all.
• It’s not obvious why “Ignore Pointer Movement” is useful, or why it has a “Threshold”. This could be explained with better grammar.
• “Dwell Click” is unexplained jargon.
• “Enable” is not at all useful as a checkbox label.
• “Time” is neither self-evident nor explained.
• “Dwelling with Click Type Window” is unexplained jargon.
• If “Show click type window” is unchecked and the click type button bar is not in the panel, the “Dwelling with Click Type Window” option doesn’t do anything. Whether you want the floating window or the button bar should be selected using radio buttons (or even drag-and-drop), not one with a checkbox and the other in a completely unrelated window.
• “Dwelling with Mouse Gestures” is unexplained jargon.
• The better-designed a program is, the fewer confirmation alerts it has. Here, if “Dwell Click” and “Delay Click” are mutually exclusive, this could be shown by putting them in the same tab and unchecking one when the other is checked (even though this would contravene the HIG), instead of putting up a confirmation alert.
• “Delay Click” is neither self-evident nor explained.
• Again, “Enable” is not at all useful as a checkbox label.

If anyone volunteers to implement a replacement for the “Assistive Technology Preferences” window (please?), I will be delighted to design it, incorporating the items currently offered in MouseTweaks and fixing the problems I’ve listed.

GerdKohlberger: Thanks for your comments Matthew.

• The HIG issues you've pointed out are already fixed in trunk.

• "Delay Click" is now called "Context Menu Click" and "Dwell Click" will be changed to "Automatic Click"

  • Making people learn a new name for a function is useful only if that will save time in presenting or discussing it later. I don’t think that’s true here, and “context menu” is not a term that most people know already. So instead of “Delay Click” or “Context Menu Click”, I suggest “[/] Trigger secondary button when I hold down the primary button:” (followed by a Slower/Faster slider).

    The dwell click situation is a bit different: from discussion with Francesco, I understand that people who have used the same feature on other OSes will likely already know it by that name, but people who haven’t used computers before will not. Also, we’ll need to refer to this option when explaining why delay click is unavailable. Therefore, I suggest adding “dwell click” in brackets: “[/] Automatically click when I stop moving the pointer (dwell click):” (similarly followed by a Slower/Faster slider).
    
    I also suggest providing a graphical demo area in the tab, where people can see the effects of their speed choices. I think few if any people would have a good idea of how many tenths of seconds is enough for them, so asking for exact values isn’t useful (which is why I instead suggest “Slower” and “Faster” slider labels). -- mpt

    • I prefer the solution with values: this way, I can set it right away to a value that I assume to be appropriate to my needs and then fine tune it. With no value, how can I know where to begin with? -- FrancescoFumanti

• The reason we decided to use a confirmation dialog was to avoid leaving a user who depends on dwelling with an unusable system, if he/she explores the other options.
  

  • That’s good recognition of a potential problem, but a confirmation alert is usually the worst solution to any design problem. Instead, I suggest making the delay-click checkbox insensitive whenever the dwell click option is turned on. Place a caption, aligned immediately under the checkbox label, explaining this: “Unavailable because you are using dwell click.” That way people will have to explicitly turn off dwell click before they turn on delay click, but there will be no confirmation alert. -- mpt
• The changes to click-type window vs. applet are tricky, because there is no reliable way (at least I don't know one) to tell the gnome-panel to add/remove an applet.

User Interface of revision 25

Comments

Personally I think the AT Preferences capplet as it exists today is redundant, so I wouldn't recommend adding any more features to it until its future is decided. See discussion in https://bugzilla.gnome.org/show_bug.cgi?id=485088. --CalumBenson

• I mocked up a mouse capplet which tries to intergrate the mousetweaks settings so that no new capplet is needed (you can look at it here). What do you think? -- DenisWashington

  • The mockup looks great, but there are 2 important options missing.
    • 'Show a window to select click types' is necessary for user who don't use the dwell-click applet.
    • The slider for tremor suppression to select how much movement will be ignored is missing.

    The 'Delay' option of 'Dwell Click' also affects dwelling with mouse gestures. It's the time the pointer has to be motionless before gesture drawing will be activated. The description in the current mt dialog is a bit misleading. -- GerdKohlberger

• The Start/Stop button has already disappeared in the development version. Moreover, GerdKohlberger is currently working on a layout without tabs. Here is a screenshot of the current layout, that will have to be refined:

  • -- FrancescoFumanti

• A new version with little refinements by GerdKohlberger: (currently in trunk: revision 34)

  • -- FrancescoFumanti

• Here is the mockup proposed by DenisWashington.

• And this is the final version that ships in the new Accessibility tab of the mouse control panel:

  • -- FrancescoFumanti

• 2008-10-25: There is an iconsistency for the motion threshold between the gui and how the daemon works: In fact, the gui suggests that the motion threshold only works for the dwelling features; but in reality it is also working when the secondary click feature is enabled. You can read more about it in the corresponding bug thread. I would suggest to use a modified layout like that in the following picture to improve the gui (please, don't take into account the activated and deactivated state from the widgets; it is merely to show the layout):

  • -- Francesco Fumanti 2008-10-25

• 2008-10-28; target release GNOME 2.26: I have created 3 other layouts taking not only bug #543091, but also bug #554739 into account. The result however is a really huge control panel. I put it anyway online to demonstrate the idea of putting the Motion Threshold slider in a shared position between the simulated secondary click and the dwell click. Maybe it is possible to create a more compact version of the 3 layouts below. As previously, the screenshots are taken from the Glade pane; consequently please don't take into account the activated and deactivated state from the widgets.

  • 

• 2008-10-30: Update from version of 2008-10-25: added the threshold label and fixed the delay and threshold accelerators

  • 

CategoryUsability