2

The WPF (Windows Presentation Foundation) checkbox control has opposite visual behaviors for when it is checked and unchecked.

That is, when the mouse button is pressed, the check mark fades into view and stays when the mouse button is released. If pressed again, the check mark stays until the mouse button is released (at which point it then fades away).

Checking - Mouse Down
Checking (Mouse Down)

Checking - Mouse Up
Checking (Mouse Up)

Unchecking - Mouse Down
Unchecking (Mouse Down)

Unchecking - Mouse Up
Unchecking (Mouse Up)

This behavior reminds me how a mechanical toggle button works. The button is pushed in and clicks into place. When pushed again, it stays in place until you let it spring back out.

Is there a practical UX lesson to be learned here from this behavior?

Do these subtle visual cues add any value to the user's experience?

1

As you say, it's akin to a mechanical toggle switch: pressing a toggle 'in' would make the control darker with the shadows as it's depressed. In terms of whether this adds value: it provides feedback that what the user is doing has had an effect on the computer; generally speaking subtle feedback like this helps the user feel reassured without demanding that they pay (significant) attention to something.

  • 1
    I think the OP is asking about the difference between checking and unchecking. – ispiro Dec 31 '15 at 0:13
1

Actually, you have 3 visual states: MouseDown(ActiveClicking), Checking and Unchecking. In WPF the action command is usually fired at MouseUp. For obvious reasons like DragAndDrop, which is pretty common at Desktop Apps.

MouseDown - Checking and Unchecking: gives users a blue indicator where the action takes place. Regardless of which interface you use: mouse pointer, touch or keys.

Mouse Up - Checking: shows the final state.

Mouse Up - Unchecking: shows the final state and the blue indicator, where the action might take place (important for control by use of keys).

This might look confusing at first glance, but only if one looks from web perspective at it. In web realms one is used to OnClick(MouseDown) as start the action command. But this might change as it has drawbacks with DragAndDrop and Touch (hold and gesture).

We might learn - it makes developer life easier if the command fires only at MouseUp/onMouseUp.

And other (well-known) learning - blue is a good indicator for users with color vision difficulties. And indicator for the active one (out of all interactive elements) is a must for keyboard useage and good for overall orientation.

And - it promotes learnability of interactive elements as you can try click and hold/touch and hold in order to see how it reacts (DragAndDrop or context menu), but you are able to cancel the intended click by move mouse away and release button upon a not clickable area.

-1
Is there a practical UX lesson to be learned here from this behavior?

Well, I certainly find this counter-intuitive. So I would say the answer is yes - it's bad :)

Visual cues for a pressed control do help. If you don't know that you're changing the state of the checkbox, you might instinctively wonder what was the checkbox's state before ("Did I change it or was it like that?"). Remember that these things are often done without much attention. But why the confusing difference between checking and unchecking? As a programmer, I'm guessing that the base class for checkbox already had a highlighted check created for some reason, and they didn't deem it worthwhile to create a highlighted unchecked version. Yes, pure speculation, I know. My main answer is in the previous paragraph.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.