Linked by Thom Holwerda on Mon 18th Dec 2006 22:27 UTC
Graphics, User Interfaces "If you pay close attention, you'll notice that most user interface actions tend to occur on the release, not on the press. When you click on a button, the action occurs when the mouse button is released. When you press the Windows key, the Start menu pops up when you release it. When you tap the Alt key, the menu becomes active when you release it (there are exceptions to this general principle, of course, typing being the most notable one). Why do most actions wait for the release?"
Order by: Score:
release
by vermaden on Mon 18th Dec 2006 22:39 UTC
vermaden
Member since:
2006-11-18

Why do most actions wait for the release?

It is very useful for mouse click, because when You click [and hold] You can move mouse out of button and release button without clicking the button, if that button would do something on CLICK You would not have that ability.

Reply Score: 4

RE: release
by ThanhLy on Tue 19th Dec 2006 14:44 UTC in reply to "release"
ThanhLy Member since:
2006-03-14

It's like in chess, you haven't really made your move until you release the piece.

Reply Score: 2

Duh
by Temcat on Mon 18th Dec 2006 23:09 UTC
Temcat
Member since:
2005-10-18

Because the click or press may be a part of some other complex action, such as drag-n-drop or entering a key combination. Does it deserve an article?

Reply Score: 5

RE: Duh
by tonywob on Tue 19th Dec 2006 20:00 UTC in reply to "Duh"
tonywob Member since:
2005-07-06

I can't believe the amount of times, I click on a button, hold it down and then change my mind, I wouldn't want it any other way ;)

Reply Score: 1

Chance to change your mind?
by CocoaCoder on Mon 18th Dec 2006 23:43 UTC
CocoaCoder
Member since:
2006-01-02

I always figured it gave you the chance to back out of a mis-click..

Reply Score: 5

RE: Chance to change your mind?
by Clinton on Tue 19th Dec 2006 05:01 UTC in reply to "Chance to change your mind?"
Clinton Member since:
2005-07-05

Right. It is like in chess, your move isn't complete until you take your hand off the piece you are moving.

Reply Score: 3

To abort...
by CapEnt on Mon 18th Dec 2006 23:44 UTC
CapEnt
Member since:
2005-12-18

Because it makes easy to abort a action. It is also more natural, since the user expect the action to trigger in software when the action with the input hardware is fully done, in this case, pressing and releasing the mouse button. If you create a software who execute their action with just the press, the user will be tainted to think that releasing the button could trigger another undesirable action.

Reply Score: 2

A few other exceptions
by PowerMacX on Mon 18th Dec 2006 23:46 UTC
PowerMacX
Member since:
2005-11-06

Some exceptions:
- Click in the menu bar: opens on press
- Click on a scroll bar arrow: scrolls on press
- Click on a scroll bar "empty" are: scrolls on press
- Click on any sort of slider control (volume and track position in iTunes, for instance): changes value on press
- Middle click to close tabs in a browser: closes the tab on press

Reply Score: 3

RE: A few other exceptions
by atsureki on Tue 19th Dec 2006 05:19 UTC in reply to "A few other exceptions"
atsureki Member since:
2006-03-12

Some exceptions:
- Click in the menu bar: opens on press


This one sort of goes both ways. The menu opens immediately so that the entire operation can be act on release, like it was in old versions of the Mac OS: click and hold on file, release over print, for example. You'll notice the operations within the menus are always act on release (click on file, click and hold on print, commits on release).

- Click on a scroll bar arrow: scrolls on press
- Click on a scroll bar "empty" are: scrolls on press


These two (the latter depending on configuration) are self-repeating actions, and so they necessarily act like holding down a letter on the keyboard (though I've often wished I could drag away from the scroll bar to cancel the motion on my Macs like you can in Windows and in volume bars.)

Good examples, but I can't mentally justify calling them exceptions. It's just all so very intuitive. It's like writing an article about why we move faster if we're late.

Reply Score: 2

RE: A few other exceptions
by Savior on Tue 19th Dec 2006 07:57 UTC in reply to "A few other exceptions"
Savior Member since:
2006-09-02


Some exceptions:
- Click in the menu bar: opens on press
- Click on a scroll bar arrow: scrolls on press
- Click on a scroll bar "empty" are: scrolls on press
- Click on any sort of slider control (volume and track position in iTunes, for instance): changes value on press

Good point; there are times when doing the action on press is more logical than doing it on release. Most of the time, however, the latter seems more natural.


- Middle click to close tabs in a browser: closes the tab on press

Actually, not. At least not in Firefox.

Reply Score: 1

Keyboards also
by flanque on Tue 19th Dec 2006 00:45 UTC
flanque
Member since:
2005-12-15

I know on some buttons if you press space bar to "click" a button but hold it down thinking.. ARGH I DIDN'T WANT TO DO THAT... you can, whilst holding the space bar, press the ESC key to release the "click". Doesn't seem to be working on my XP at the minute but it's certainly saved me in the past.

It's really handy actually and probably saved many a user.

Edited 2006-12-19 00:48

Reply Score: 3

It's confused
by Cloudy on Tue 19th Dec 2006 01:15 UTC
Cloudy
Member since:
2006-02-15

but at least it's wrong.

There are two kinds of 'press' events, modifiers and activaters. modifiers start operating as soon as they are pressed. Obvious examples include shift keys and right mouse for popup menus. Activaters start operating once the down/up sequence is completed.

They are about equally common in user interfaces, especially complex ones.

One uses the down event for an action that requires immediate visual feedback. One uses the up event to trigger completion of a primed action.

Reply Score: 3

Start Menu
by GMFlash on Tue 19th Dec 2006 05:25 UTC
GMFlash
Member since:
2006-06-30

When you press the Windows key, the Start menu pops up when you release it.

The Windows "Start Menu" opens on mousedown, not on release. Tested on Windows XP SP2.

Edit: Nevermind, I thought it was talking about mouse clicks not the Windows key ;)

Edited 2006-12-19 05:27

Reply Score: 1

RE: Start Menu
by Doc Pain on Tue 19th Dec 2006 17:33 UTC in reply to "Start Menu"
Doc Pain Member since:
2006-10-08

"When you press the Windows key, the Start menu pops up when you release it.

The Windows "Start Menu" opens on mousedown, not on release. Tested on Windows XP SP2.

Edit: Nevermind, I thought it was talking about mouse clicks not the Windows key ;) "


But you're right, of course. :-)

An addition: The "Windows" Start Menu can be opened by pressing Ctrl+Esc, here it opens on pressing ("keydown") the Esc button - as far as I remember; I don't use any MICROS~1 product, so don't kick me if I'm wrong. :-)

The "Windows" key... at least in Germany almost nobody uses it. Most average users use the mouse only. Key combinations with the "Windows" key are not known (e. g. Win+R = Start/Run...). BTW: The other stupid key, let me call it "Menu key", does the same like Shift-F10. I never found a reason why there are useless keys taking space on the keyboard, especially on notebook keyboards that aren't very typist-friendy in use... just my individual opinion, maybe I'm too old fashioned for such innovative hardware. :-)

To come back to the original article:

"For example, if you display a dialog box while the Alt key is still pressed rather than waiting for the release, the Alt key may autorepeat and end up delivered to the dialog box. This prevents the dialog box from appearing since it's stuck in menu mode that was initiated by the Alt key, and it's is waiting for you to finish your menu operation before it will display itself."

I'm not shure I understand what the author wants to say with this paragraph. Alt usually sets a status, so it has no autorepeat function. When a dialog box is opened, the menu would activate with Alt+(Letter) or Alt press+release. Why should it prevent the dialog from appearing? When the dialog is called, it should first reset the input, so it won't get any keystrokes or mouseclicks that are not designated to be gotten by it. Maybe someone could comment a bit on this...

Reply Score: 1

RE[2]: Start Menu
by DonQ on Tue 19th Dec 2006 17:53 UTC in reply to "RE: Start Menu"
DonQ Member since:
2005-06-29

Alt usually sets a status, so it has no autorepeat function.

Actually it makes both - sets status and generates repeating keydown events. All keys generate. Thereby described scenario (dialog is stuck, waiting menu completion before displaying it) is possible - but if Alt key entered menu mode on keydown, then dialogs API had be designed to not stuck in this situation anyway.

This is the problem with pointed article - first is taken current behavor, then some (but not all related) aspects are changed and then is concluded that such system doesn't work.

Of course it doesn't, if it isn't designed properly.

Actually there are user interfaces, acting purely on keydown/mousedown events (some old graphics packages for example). No big problems (except impossibility to cancel actions).

Reply Score: 1

RE[3]: Start Menu
by Doc Pain on Tue 19th Dec 2006 18:46 UTC in reply to "RE[2]: Start Menu"
Doc Pain Member since:
2006-10-08

"Thereby described scenario (dialog is stuck, waiting menu completion before displaying it) is possible - but if Alt key entered menu mode on keydown, then dialogs API had be designed to not stuck in this situation anyway."

Ah, I see, thanks! The usual behaviour (at least as I implemented it in projects) is to flush input at dialog startup, so there are no keystrokes in the input queue when the dialog is shown.

"Actually there are user interfaces, acting purely on keydown/mousedown events (some old graphics packages for example). No big problems (except impossibility to cancel actions)."

In most cases a "take back" / "undo" functionality is provided so accidently done things can be undone.

Reply Score: 1

v Tim Holwerdi
by Tim Holwerdi on Tue 19th Dec 2006 12:07 UTC
RE: Tim Holwerdi
by BluenoseJake on Tue 19th Dec 2006 12:52 UTC in reply to "Tim Holwerdi"
BluenoseJake Member since:
2005-08-11

You sir, are out of line

Reply Score: 1

Thanks!
by ferrels on Tue 19th Dec 2006 16:13 UTC
ferrels
Member since:
2006-08-15

I was really losing a lot of sleep over this one. NOT!

Hmmm...."wait for the release".....I don't want to touch that with a 10-foot pole.

Reply Score: 1

Event handling 101
by RGCook on Tue 19th Dec 2006 16:27 UTC
RGCook
Member since:
2005-07-12

I like the explanation given for the default behavior. However, keep in mind that controls have many, many events that usually go unhandled. It would be a simple matter to override the default handling so that the behavior fits the application requirement/circumstance. This could be accomplished by adding handlers and delegating or using clever logic to handle them within the standard events associated with controls.

Reply Score: 1

why?
by dnstest on Tue 19th Dec 2006 18:34 UTC
dnstest
Member since:
2006-06-11

What kind of debate was this supposed to inspire? This is completely pointless...

Reply Score: 0