An Efficient Solution to Tiny Check Boxes(uxmovement.com)
uxmovement.com
An Efficient Solution to Tiny Check Boxes
http://uxmovement.com/design-articles/an-efficient-solution-to-tiny-check-boxes
17 comments
Couldn't agree more. The cursor should be the default for an element unless you've overridden the default behaviour as well (for instance, when a plain-Jane hyperlink becomes an AJAX button, the script that overrode the link behaviour should also override the "pointer" cursor).
Everyone: Please use <label> tags for the descriptions of your form fields. This is good for Fitt's law, accessibility, and semantics. Thanks!
Disagree. Hover effects should generally be avoided, as there's no hover state in a touch-based UI.
Some people suggest using select elements instead of checkboxes and two-option radios. Forget the source, but at least one study concluded that users preferred selects. As always, take with a grain of salt and test for yourself.
Some people suggest using select elements instead of checkboxes and two-option radios. Forget the source, but at least one study concluded that users preferred selects. As always, take with a grain of salt and test for yourself.
Progressive enhancement is a better way of dealing with hover and similar features than avoiding them altogether.
When I'm using PC, mouse and a non-Lynx browser, I absolutely want to take advantage of JavaScript, hover and any other feature that would make it easier for me.
It's just that the designer should make sure everything works even when these features are not available (e.g. on a touch screen).
When I'm using PC, mouse and a non-Lynx browser, I absolutely want to take advantage of JavaScript, hover and any other feature that would make it easier for me.
It's just that the designer should make sure everything works even when these features are not available (e.g. on a touch screen).
Agreed. Let me clarify: hover can help, but it's not a solution.
Not doing something because the minority can't use it is hardly a good reason to not do something. It's more of a reason to find alternatives for that minority, especially when it's something like this, which uses familiar elements in a familiar way.
I frequent Starbucks and it is always frustrating, even though it lasts for a second, that signing into their network requires me do exactly what this article talks about. Each time I login, I'm hopefully that an engineer has fixed this.
I've used a password manager for a while that lets me "go to and log in" in a single action. Save one for each Starbucks you frequent, save that approval form, and get in in one step :)
Works especially well for one near me, which sometimes takes 30 minutes to reach that approval screen if I browse to it. The method above usually gets me in in less than a minute on even those days.
Works especially well for one near me, which sometimes takes 30 minutes to reach that approval screen if I browse to it. The method above usually gets me in in less than a minute on even those days.
Unfortunately mobile phones don't support the rollover event.
I assume this is why Apple went with the toggle UI. The problem with toggles is you need a very short description. (on/off, yes/no, etc)
Worse, for those of us not developing only for the iPhone, there are drawbacks. There are javascript and jQuery solutions for this. But then you need to require javascript and download some images and it adds complexity, makes things more fragile, is harder to maintain, adds concerns over compatibility, and I don't even know if there are performance issues.
So I guess there are some trade offs.
I assume this is why Apple went with the toggle UI. The problem with toggles is you need a very short description. (on/off, yes/no, etc)
Worse, for those of us not developing only for the iPhone, there are drawbacks. There are javascript and jQuery solutions for this. But then you need to require javascript and download some images and it adds complexity, makes things more fragile, is harder to maintain, adds concerns over compatibility, and I don't even know if there are performance issues.
So I guess there are some trade offs.
Interestingly enough, their own poll along the right hand side uses radio buttons, but does not have a roll-over effect as proposed by the article.
Yes, it does for me with Firefox 4 on Windows 7. This is something that would be browser and OS dependent. In general, I've noticed OS X tends to have much fewer places with rollover effects than Windows.
I'm using Chrome on Ubuntu. I didn't realize they meant OS/browsers needed to take this into account. I just assumed they were talking about things to consider when designing a web application.
Or make bigger checkboxes - my little invention, mostly cross-browser:
.bigcheckbox {
vertical-align:middle;
margin-right:5px;
height:1.4em;
width:1.4em;
*font-size:1.4em;
}I stared at the screenshot trying to figure out what was special for a moment before I "got it".
UX enhancement that subtle...just made me smile. The subtle hint that the label is clickable using the hover is truly a nice touch.
UX enhancement that subtle...just made me smile. The subtle hint that the label is clickable using the hover is truly a nice touch.
Shouldn't the mouse cursor be a pointer when the mouse is over the checkbox label?
[deleted]
Am I missing something? Or is this just about the ubiquitous lack of label-for?
edit: I despise the hand-cursor on anything but an action field (like a link). If it doesn't redirect my browser or open a popup, I don't want a hand. Ever.