Live data from Hacker News

Chosen: A javascript plug-in that makes long select boxes user-friendly.

harvesthq.github.com

71–80 of 81 posts

Re: Chosen: A javascript plug-in that makes long select boxes user-friendly.

#71
Love it! Sure it's not perfect, but it's a huge improvement already. I've had similar ideas myself but haven't gotten around to implementing them. The existing HTML input controls are clunky and haven't kept up with the pace of web development, maybe we can improve on them using CSS & JS until we develop a new set of canonical input primitives that then become standardized.

Re: Chosen: A javascript plug-in that makes long select boxes user-friendly.

#72
post #12

And yet another control that pretends to be a dropdown box, but isn't. No. I'm not complaining about the appearance or the fact that it has a search field while the real dropdown doesn't. I'm complaining about the way it responds to mouse actions: The real dropdown box, on my machine, expands the menu on mouse down after a no-doubt OS-specific delay. The fake dropdown doesn't - it only reacts on mouse up. Of course,…

[deleted]

Re: Chosen: A javascript plug-in that makes long select boxes user-friendly.

#73
post #65

Earlier quoted context omitted.

> Apple did a good job with s on iOS and this completely breaks it. Agreed. Also, when a user has to access both your desktop and mobile apps, the experience has to be the same. This plugin, however nice, is trying to solve a problem by further modifying the problematic feature. Just remove the select if your list is too long; there should really only be a handful of options contained within. As a rule, I keep it to…

Interesting statement! What would you suggest as a replacment for long option lists? Autocomplete?

No, there is no conventional standard for auto-complete and you would have to be able to determine whether or not the user was actually trying to employ a/c functionality versus typing a term that they've already brought to the forefront of their action. Auto-complete interrupts this mental workflow and affects the UX in a negative manner. It's like continuously prompting a person who has difficulty with stuttering. After awhile they'll find you too difficult to talk to and go back to drinking beer and watching TV.

One aside is the convention of time/date/location that you'll find everywhere. For whatever reason someone needs to capture the information from the Andorrans to the inhabitants of Wallis and Futuna. I can't fight people that include over 200 options for countries and territories when this info could be ascertained and captured via other methods, but people already have a mental map of where their options are in these lists, so if you really need to, then go ahead. iOS has the best solution for this. Also, a select is a part of CRUD, so please don't use it for navigation.

The solution that I like to employ is an unordered HTML list, with the items bricked in equal size, separated uniformly right and bottom and floated left. You can see this when you look at Google+'s circles. The user knows to read from left to right (assuming western conventions) and can navigate top to bottom with the ease of the mouse without making commitments. I currently do this with a list of ~250 options and employ ajaxy magic to capture the user's actions. I assist the user by alphabetizing the list so that they'll be able to mentally map their position as well as curated and separately displaying the most popular option at the top of the list, much like US-based website will do when displaying "United States" as the first option in their select. If displaying on a mobile device, I would recommend displaying in a one-column list; if a user can navigate Twitter, they'll have no problem with scrolling down to find their selection because they've already been trained to do so and it'll come as second nature. (which is why is good practice to adopt conventions from popular applications. Why fight it?)

Another option that I've found helpful i to employ pathways when too many options with similar names can cloud the user's mental map. It's ok to break up a form into logical step-by-step pieces. You gain the user's trust by preempting tedious actions. Intersticial pages, not pop-ups, are ok if the user understands where you are taking them and for the tricky parts, some reassuring copy can do the trick. People read; just go through Amazon's checkout process a couple of times over the course of a week. You may forget a step, but they're right there to help you without employing navigation or CRUD devices on the screen.

tl;dr: just put the options in a list as ajax buttons or checkbox-activated text. Keep it simple and organized and don't play hide and go seek with the user.

Re: Chosen: A javascript plug-in that makes long select boxes user-friendly.

#74
post #61

This project looks awesome. This stuff is annoying to have to replicate yourself, and I'm glad to see MooTools support as well. That said, my first reaction when looking at the first Country dropdown example was that I liked the native one better since in OS X it shows me dozens of choices at once (fills most of the screen vertically) and then in the "after" suddenly I was constrained to only seeing 7 countries at a…

The single select also cannot be reached by pressing the tab key (for me, Safari 5.0.5). When I fill out a form, my hands are on the keyboard. I tab to the country field, start typing my country to select it, and move on. So I'd say the single select is worse than native on both Safari and Mobile Safari. The multi-select is great, though. Why not make the single select work like the multiple?

Tab works as expected here in FF4.0.1, when the focus is on the normal control, I can switch to the 'enhanced' version using tab and start typing my country.

Re: Chosen: A javascript plug-in that makes long select boxes user-friendly.

#75

Apparently Chosen takes the placeholder text from the select element's 'title' attribute; does it also support the official HTML5 syntax[1] for placeholder attributes in select elements? How about integration with jQueryUI's theming system? [1]: http://www.whatwg.org/specs/web-apps/current-work/multipage/...

does it also support the official HTML5 syntax[1] for placeholder attributes in select elements?

I'd be impressed if it does. I can't parse that sentence in the spec.

Re: Chosen: A javascript plug-in that makes long select boxes user-friendly.

#76
post #12

And yet another control that pretends to be a dropdown box, but isn't. No. I'm not complaining about the appearance or the fact that it has a search field while the real dropdown doesn't. I'm complaining about the way it responds to mouse actions: The real dropdown box, on my machine, expands the menu on mouse down after a no-doubt OS-specific delay. The fake dropdown doesn't - it only reacts on mouse up. Of course,…

My problem with this is that when I see the box (e.g. Multiple Select), I perceive it as a text input. I'd be ill-surprised to discover on a site to (all of a sudden) have this protruding box appear out of nowhere. Better solution: on mouse click, hide the box. Only show the box for autocompletes.

this. a tag text input even.

Re: Chosen: A javascript plug-in that makes long select boxes user-friendly.

#77
On the iPad, the custom control is decidedly worse. The native one is larger and more appropriate for the device. This idea of custom UI elements seems really bad. It's gonna be worse than native on any platform. The issues with native controls should be addressed on their respective platforms.

Re: Chosen: A javascript plug-in that makes long select boxes user-friendly.

#78

Apparently Chosen takes the placeholder text from the select element's 'title' attribute; does it also support the official HTML5 syntax[1] for placeholder attributes in select elements? How about integration with jQueryUI's theming system? [1]: http://www.whatwg.org/specs/web-apps/current-work/multipage/...

does it also support the official HTML5 syntax[1] for placeholder attributes in select elements? I'd be impressed if it does. I can't parse that sentence in the spec.

The markup it describes is basically:

    
        Placeholder Text Here
        first real option
    
The rest of the text basically says that select elements that are not required don't have placeholder text; that select elements that allow multiple selections don't have placeholder text; multi-line select elements don't have placeholder text, and that if the first option is inside an optgroup element, it doesn't count as placeholder text.

Re: Chosen: A javascript plug-in that makes long select boxes user-friendly.

#79
post #12

And yet another control that pretends to be a dropdown box, but isn't. No. I'm not complaining about the appearance or the fact that it has a search field while the real dropdown doesn't. I'm complaining about the way it responds to mouse actions: The real dropdown box, on my machine, expands the menu on mouse down after a no-doubt OS-specific delay. The fake dropdown doesn't - it only reacts on mouse up. Of course,…

Was testing it out on our homepage. Noticed a couple of bugs as well:

http://teaspiller.com

The search for "Tax" yields result, but nothing for "Estates". I think it doesn't work for first word if the term contains a space.

EDIT: was testing on Firefox 5, works on Opera. Bug filed: https://github.com/harvesthq/chosen/issues/50

Re: Chosen: A javascript plug-in that makes long select boxes user-friendly.

#80
post #60
post #12

And yet another control that pretends to be a dropdown box, but isn't. No. I'm not complaining about the appearance or the fact that it has a search field while the real dropdown doesn't. I'm complaining about the way it responds to mouse actions: The real dropdown box, on my machine, expands the menu on mouse down after a no-doubt OS-specific delay. The fake dropdown doesn't - it only reacts on mouse up. Of course,…

I'm trying to understand your point of view, but I'm a bit confused about something (I'm probably just completely misunderstanding it). In the context of select boxes, it seems like the only advantage of mouse-down activation vs mouse-up is that you could click, hold, "drag" to your selection, and release. This would only be advantageous if your selection is near the top.

The problem isn't that opening on mouse-up is worse, it's that it's different. After using an operating system for thousands of hours, one becomes accustom to the behavior of the standard controls. Anything that deviates from them and is not in widespread use - even if it is technically an improvement - will feel uncomfortable and "wrong".

In some cases, like upgrading from Snow Leopard to Lion or Windows XP to Windows 7, the users adapt to the change. This is not likely to happen for a Javascript contro that is not in use on any major sites.

Post reply on HN