When is it a good idea to perform actions on mouse-down *as opposed to click/mouse-up*?

Question

I've grown used to the GUI paradigm of pre-select on mouse-down, action on mouse-up. In fact, I rely on it, sometimes canceling an unwanted action after mouse-down by dragging outside of the click area and then releasing the mouse.

However, this is only an arbitrary standard, and may not be universal. For example, I noticed that in Microsoft Outlook's header pane, category selection occurs on mouse-down (and interrupts attempts to drag).

With the introduction of touch-oriented interfaces, the dividing line is even sharper. iOS automatically "retracts" finger-down events and converts them into drag-view events when the finger moves after finger-down.

What are some situations where it's preferable to take action on mouse-down? What sorts of actions are better this way, rather than waiting for mouse(/finger)-up?

Answer 1

I think you'll find most selection processes act on mouse button down - choosing items in lists, tables, tab header bars etc. With tabs, most implementations I see at least change the selection in the tab header, but might not necessarily actually switch the content page until the mouse up.

With tabs it's good to get the content switching on mouse down because if the tab is draggable (to its own window or just to reorder tabs), then you get to see the content you are about to drag before you actually start moving the mouse.

Also changing input focus between fields, or changing caret position within text is done on the mouse down as that then allows you to immediately start selecting a block of text. To have to click, release and click again to start selecting text would be annoying.

Clearly, mouse down is a prerequisite to a drag operation and therefore depending on the context, the mouse down sets up the pre-drag conditions - for example starting a selection marquee in a paint or drawing app.

I think it's going to be prevalent in areas of direct manipulation where you interact directly with the content for exactly this reason - setting up and preparing for the drag, and depending on what the drag is going to do, that preparation may require visual feedback or state change on the button down.

I don't think we can do without actions on mouse down - it's a great opportunity to provide immediate feedback about the impending action - whether that's as a result of mouse up or drag or anything else.

Answer 2

TL;DR Stick to mouse up, that is what everyone is doing, user will expect it.

Keep in mind that in the real world, we are far more accurate than on devices.

When we push down a button, there is no turning back, the button is pushed. Whether it reacts on push down or release is not relevant, the button has been pressed.

With mouse cursors, it is different. When the mouse button is pushed down, you still have the liberty to move your cursor, in order to hit another target that you may have missed when pushing down.

From what I have tested, Windows or Mac OS use form controls (buttons, check boxes) that reacts to mouse down but only to display the actual action that will be taken on mouse up. The user has "plenty of time" to detect that the triggered action is not the one he wants and remove its cursors from the target before releasing the button.

Answer 3

I agree with Roger.

In my mind the Mouse Down event has become analogous with the real-world action of touching/coming into contact with something. So in short, I think mouse-down should always show contact with the element in question.

Answer 4

HTML/JavaScript , with existing text already filled in, shifts the text cursor upon mousedown, not on click, and not on mouseup. This is necessary because you could be selecting a range of text, an area, by wiping across it and then releasing the mouse.

There's a fundamental conflict between mousedown to wipe an area to select it, and mousedown to drag an object.

In any case, mousedown should use visual and possibly auditory / tactile feedback.

Answer 5

When deciding between mousedown and mouseup one can consider various practical impacts on UX. Different behaviour is usual for different GUI controls.

Some user actions could potentially be dangerous and that is why I think the button click action happens on mouseup. Thus the user is able to rethink his intention, move the mouse away from the button and effectively cancel the action. The similar it is with checkbox and optionbox controls. On the contrary, clicking the header pane in MS Office does not imply any serious action or data change, as it only switches the selected toolbar pane. This is not very important action and thus it gets done as early as on mousedown. The same it is with standard Windows tab control.

Sometimes the use of mousedown action is practically necessary as with mouse drawing, text selection or drag & drop and resize manipulations. It is also possible to comfortably combine the select action with drag & drop action, e.g. in Chrome user can select a tab with mousedown, see its content and then immediately start to drag it to another position in the tabs pane. Finally user drops the tab with mouseup, so all of these actions are performed with only a single mousedown/mouseup couple.

mousedown can also spare some mouse clicks, like with app menus or some selectboxes: on mousedown, user opens the menu and starts selecting the item with mouse move, while on mouseup the item is finally selected. This prevents user from clicking twice - once when opening the menu and once when selecting the item.

mousedown is also practical when it is desirable to perform actions quickly. Imagine some settings dialog with a listbox containing several items. After clicking on each listbox item the displayed settings pane gets changed. As the displayed settings change on mousedown, user can just hold mouse button and switch between listbox items (and displayed settings) by only moving the mouse, i.e. without the need to click multiple times.

Several GUI controls support some action happening after mousedown and some delay. You surely know numberbox control with small buttons for increasing/decreasing the displayed number. When user does mousedown on some of these buttons, after a small delay the number in the numberbox starts increasing/decreasing quickly. The same it is with up/down buttons on scrollbars.

This delay behaviour is quite similar to keydown and keyup events. When some action is performed on keyup and user wants to repeat the action multiple times, he also has to repeat the key press multiple times. With keydown action it is enough to press the key once, hold it for a longer time and after a small dely the action gets repeated automatically (like when you hold the key 'a' and it starts to write many repeating 'a' characters).