What to consider a click?

Question

Such a simple concept, yet so many ways to interpret it.

I'm making a program (a game, to be specific) using an event based library (Allegro). The library doesn't have a specific event for a mouse click, but instead has event for button down and button up. While programming the basic menus, I was struck by a problem. What do I consider a click? The button down event? The button up event? The latter, if it happen shortly after button down? If so, from which point do I take the cursor position from?

There is no dragging functionality anywhere in the program, so all options seem equally valid to me, with the exception of the most extreme cases perhaps (dragging the cursor long ways across the screen, for example). So my question is, are there any conventions to what to consider a click?

Answer 1

The simplest questions often have complex answers. If you’re making a game, it sounds like you may be making a custom interface, so you probably need some general principles to guide your control design. Whether to trigger an action on mouse down or mouse up depends on the control and the action and how the user will interact with it. This is probably why your library gives you a choice. To decide, balance efficiency (making input fast and easy) with tolerance (making input error-resistant or easily corrected) for the particular case. The key questions are:

• What should dragging do? Even if you have no drag-and-drop functionality, you still have to decide what dragging will do.

• What should holding the button down do? Again, even if no command is made, there often should be something happening.

Focus

Generally if mouse selection merely changes focus, then focus changes on mouse down, not mouse up. This is good for efficiency, allowing the user to use dragging to complete some kind of command without having to “re-grip” the object (before an object can be dragged, it must have focus). It presents little tolerance issues since accidentally changing focus generally is easily corrected and doesn’t change any underlying data. Obviously, if the UI responds to mouse down, then you have to take the position of where the mouse pointer was on mouse down. Windows, icons, database records, slider controls, and text boxes all receive focus on mouse down.

Commands

On the other hand, if mouse selection completes a command or changes a data value, then tolerance is more of an issue. In those cases, generally the command/change triggers on mouse up. I see no reason to put a time limit on when the users must mouse up to trigger the command -let them think as long as they want.

Triggering on mouse up allows you to use dragging to cancel the command or change to another command. Activation of controls like command buttons, check boxes, and links are all canceled by dragging the mouse off the controls. Dragging-off-to-cancel also works for pulldown and dropdown menu items. Users can also change their selection of the menu items by dragging to another item while holding the mouse down. In this case, take the position at mouse up so you execute the correct command or can tell if the user is canceling. Since dragging itself is not used to execute a command, there is no appreciable efficiency loss, but tolerance is improved.

The one exception is for cases where you want to support auto-repeat for a command, where holding down the mouse button on the control repeats the command at about two times a second. Here logically the command must be triggered on mouse down. Scrollbar buttons, the scrollbar track, and spinner buttons all work this way. It would also make sense for buttons for Zoom In/Out or Find Next/Previous. The efficiency gains from auto-repeat are obvious, but to maintain adequate tolerance, it should be reserved for actions that are easily reversed (such as scrolling and Find Next/Previous). Auto-repeat for Delete sounds great for clearing spam out of a user's inbox, until the user deletes 15 important emails by accidentally setting the phone down on the mouse.

Intermediary States

Generally, selection that puts a control in an intermediary state should occur with mouse down. For example, while activation of menu items occur on mouse up, pulldown and dropdown menus open on mouse down rather than mouse up. This provides feedback on the user’s action and also allows the user to immediately drag to select an item, making for efficient input. It also allows Mac users to use Windows menus in the manner they’re used to. Tolerance is not a big issue since simply opening a menu is easily reversed and effects no command or value change. An exception is the context menu, which opens on mouse up in Windows. That’s because MS wanted to allow the user to drag and drop objects with the right mouse button (try it in Windows Explorer or Word –it’s pretty cool).

If a command triggers on mouse up, you often should provide some sort of intermediary feedback on mouse down so the user realizes what command they’re about to execute. For example, command buttons appear “depressed” on mouse down. So while a command executes on mouse up (and thus you need the mouse position at mouse up), you also need to track wherever you've provided feedback on mouse down so you can clear it on mouse up -including if the user has moved the mouse off the control on mouse up. Feedback on mouse down may not be necessary if you already show such feedback with mouse hover.

”It’s Intuitive”

Appropriate use of mouse down and mouse up can do a lot to make a UI feel fluid and “intuitive,” which is probably important for making your game fun. Most users probably couldn’t tell you how a particular control responds to mouse down and up, but good design still benefits them. I think most users will drag off a button to cancel its activation. They don’t even think about it -it just seems natural to them, even though this doesn’t work with natural (physical) electric buttons –they activate once depressed. I've never seen a user attempt to activate a command button by clicking outside a button and sliding on to it, even though that would work with a physical button. "Intuitive" can be weird.

Answer 2

It seems to me there are two issues here; what is a click? and Should I use a click?

What is a Click?

In the strictest sense a click is an extremely brief (<100ms) press of the left mouse key, or more generally the analogous control such as a tap on a touch screen. Ideally the mouse does not move at all during a click event; no more than ordinary hand twitches of the human hand.

However a sort of "hesitated click" also exists. This is acceptable in some situations; when using it a user is often thinking one of three things:

1. "I want to drag this.": This could be the start of a drag action.

2. "Can I click this?" The user might be unaware if a button-like shape is really a button. Ideally an active state (a la CSS) will provide an affordance cue showing "You've pressed a button!"

3. "Should I click this?" The user might simply be debating whether they want to perform a certain action.

From all these use cases I think it should be clear that the click action can not start on button down. The user is hesitating for a reason; don't perform an action until you're sure it's a click. This is especially true on touch displays, as a hesitated click might really mean "I'm trying to drag this page".

If the user's pointer remains on the touch point (e.g. a button) the entire duration of the hesitation, then they lift up the mouse button, it's still a click. Your user might have a slow reaction time, but that doesn't mean they didn't want to click on an item. If they want to cancel the clicking action a viable option should be moving the mouse away from the clicking area.

More generally, a click is targeted. If drag and drop is excluded, check the position of the cursor before considering a click; if the user presses down on one target and up on another that's almost certainly a canceled click.

Should I Use a Click?

Sometimes a mouse button is just a button, and the Click paradigm no longer applies; this is often the case in game design.

Often actions in games begin when the mouse button is clicked (like firing a weapon) and stop when the mouse button is released. This is not strictly a click; the mouse button is acting just like any keyboard button.

What makes a click depends heavily on context and in the context of a game, mouse clicks are generally just another button.

In a game I would only stick to the desktop GUI click conventions if those conventions apply directly to the interaction; for instance in a menu with buttons clicks makes sense. If you're clicking to fire a weapon, you're not really "clicking" you're just pressing a button down.

Answer 3

The click is usually registered when both the button down and button up events happen on the same UI element. Take any program, click a button, then drag the cursor away without releasing the mouse button, and then release it outside of the UI button you clicked on. The button won't be triggered. The same goes for clicking outside of the button and releasing over the button. That's the only way to determine whether the action had been meant as a click or a drag. While your specific program doesn't support dragging, the user isn't necessarily aware of that, and you need to make it clear to the user. Try dragging a link in a browser, and you'll usually get a "no entry" sign on the cursor.

Answer 4

I would say a click is when the mouseup is triggered - that is the point at which the actions should happen - when the mouseup event producer (that is the item on which the mouse up is registered) also registered the previous mousedown.

In other words, you must click mousedown and mouseup on the same element, the event being triggered by the mouseup action. However, you sometimes do see clicks activated (wrongly, IMO) on mousedown and wait. So if you click the mouse and keep the mouse in the same place, sometimes it will register a click.

Note that there should not be a maximum time between the mousedown and mouseup events - not like a double click which has to be distinguished from two single clicks. So I should be able to click down, take the mouse all over the place for as long as I want, return to the starting point and click up, and for this to be logged as a click.

ETA: The seemingly simple process of "detect a mouse click" is actually quite complex, which is why a mouseclick event is so good to have. Also, from a UX perspective, it is CRITICAL to get it right according to the expected perception of the user. It is so fundamental that getting it wrong, even if the rest of the app is astounding, will wreck it.

Answer 5

Mouse, as a device, reports 2 inputs (button state & movement along 2 axes) that the active software uses to control our interactions with objects on the screen. Since software receives raw events from the mouse, developers have to create filters for movement sensitivity and maximum delays between events. The software then uses the filters to interpret the events as actions to be executed. The general practice for interpreting events has been so far to start tracking on button down and perform the action on button up after a short delay, which allows for chaining of inputs (e.g. double-clicking).

There's a limited number of sequences of events we can trigger with a mouse:

• button down -> no movement -> button up - usually, performs action on the object under the pointer based on the button triggered
• button down -> movement -> button up - usually, performs action on the object under the pointer based on the movement parameters and the button triggered
• movement & no button events - moves the pointer without any actions

Thus, the technical definition of a "click", it's button down followed by button up with either no movement or movement within the tolerated range (that accounts for users with motion disabilities who aren't able to hold the mouse steadily).

Answer 6

Interactive application developer's point of view: Generally, you want to trigger the click as soon as possible. So preferably on mouse down.

However, many items respond to more than just clicking: eg. dragging or double clicking. That might force you to respond later: eg. For an item that can be dragged or clicked you have to wait for mouse up and trigger the click only if the mouse didn't move more than 5 pixels.

The exception seems to be text buttons in modal dialogs. On most platforms, these are only triggered if mouse goes down and up within the same button.

Answer 7

A click is not simply a mouse down or a mouse up event, it is a result of a sequence...

1. On mouse down store reference point, flag click in progress
2. Listen to keyboard events, if user clicks ESC then cancel click
3. Listen to mouse move event, if mouse moves beyond epsilon (e.g. 1 pixel) from mouse down then cancel click
4. Mouse up --> if click in progress flag is up then click is complete

This enables cancelling clicks and dragging.

Alternatively, you could store the UI element that was hit instead of the the XY coordinate and compare element under mouse up hit text (as Vitaly stated), however, for a textbox this could prevent selection of text.

If you must only use one event, the mouse up would be more similar (you could check for ESC on mouse up too).

Similar sequences exist for double click and for drag and drop (used for dragging items, for selecting a range and for dragging a scroll bar).