Chosen: A javascript plug-in that makes long select boxes user-friendly. | Hacker News Reader

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

harvesthq.github.com

923 pointsutkarshkukreti76 comments

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, you can't make a a control work exactly like its native counterpart - but that IMHO just means that you shouldn't even try imitating them and provide its own unique look.

I really dislike nearly-native controls - they feel wrong to me.

But don't get me wrong: The controls are really cool and incredibly useful. If only they didn't try to mimic the native look without quite matching it.

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.

When we do this (with jQueryUI) we add the little down arrow button decoration so you expect the dropdown to appear.

Hmm, it definitely is a learned experience. Some form of affordance here would really help clarify what will happen. You could add some placeholder text that says something like "click to add items", but that seems a bit like "turn knob to open door."

I agree it's not ideal, but I think the majority of users have seen less friendly versions of this. The concept is Token Input. Facebook uses it in places, and they don't have the placeholder text that says "Choose..." when nothing is selected. I think the placeholder text ought to help quite a bit.

this. a tag text input even.

Looks fantastic, but here's another feature it doesn't have which makes it feel less native.

Try mouse scrolling too far whilst the menu's options are open/visible. The parent page scrolls as well when you reach the start/end. This doesn't happen with a normal select menu.

I wonder if there's a way to do an event.preventDefault() on the mouse scroll event when reaching the end of the list?

FF on Mac actually tries to do something clever here. It won't start scrolling the page itself until after a small delay or until you move the mouse.

That's exactly what i found but on the whole I give it a thumbs up.

Not just looks, it solves certain big usability problems I have with regular selects or checkboxes for values. However the few non-native problems are indeed problematic. We got brainpower here, lets make it work!

Reminds me vaguely of the uncanny valley[1]. Not a perfect analog, as nearly-human forms seem to elicit a particularly strong and emotive response. I also do wonder to what extent, and for whom, this is true. (i.e., are power users more or less aggravated? When do people change from disliking the new FB chat window to being familiar enough with it to dislike it when you change it again?)

[1] http://en.wikipedia.org/wiki/Uncanny_valley

"no-doubt OS-specific delay" - on Windows, this delay is a factor of the double-click speed. http://blogs.msdn.com/b/oldnewthing/archive/2008/04/23/84175...

It's also far worse than a standard dropdown for mobile.

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.

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

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 time. Not a huge deal but felt like a loss in usability (but a gain visually). If the faux dropdown was just a little taller in height it'd be better.

Secondly, this just killed iPhone support. Apple did a good job with <select>s on iOS and this completely breaks it. It should just turn itself off on iOS.

> Apple did a good job with <select>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 five and I never replace the pseudo element with plugins.

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.

It doesn't work well on Android either. The scrollbars don't appear, and unlike the normal Android behavior there is no zoom-in on the options to make them easier to select with a touch. These are probably fixable issues, but I think I agree that the device's native control is going to be better.

> "Apple did a good job with <select>s on iOS and this completely breaks it."

It's not always the best solution. When you have a drop down with many choices it's very hard to go to a certain spot by just scrolling.

On a computer, you can drag the scroll bar or start typing.

Anyway, good to know that it breaks iOS.

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.

The more libs like this I see, the more I feel that the core HTML controls should be improved and expanded. They are getting really, really dated and don't address a lot of common problems.

Things I feel would make a lot of sense:

Collapsible trees. Numeric sliders (preferably done like draggable digits http://worrydream.com/Tangle/). Native drag-and-drop sipport for elements. (And yes, this can be done with plain forms. I can explain how if you want.) Native rich tooltips and a standard notation to show that something has a tooltip. Maybe tabs. I think you could do tabs with CSS, but I'm not 100% sure.

If most UI libraries have something, it probably would be a good addtion to HTML spec. It would work faster and eventually have better compatibility.

Numeric slider exists in HTML5: http://diveintohtml5.org/examples/input-type-range.html

Best plug-in of the year, so far.

Apart from what it says, I do not see problems in IE7 or IE8 (there is some style issues in IE9, though). Also, it is nearly working in IE6. I think I'll try to diddle around with some z-index and CSS stuff to get it working. Can't be much more than that.

What's the nature of the nonworkingness on the dodgy browsers? Does it fail catastrophically or degrade satisfactorily?

If you manage to fix it for other browsers I hope you push your fixes upstream.

It looks to me as if there is a z-index problem and the position is not upheld correctly in IE6. In IE9 there is a difference in the linear gradient color. No catastrophes there, imho.

This nearly completely breaks the select ui on iOS. It should do some kind of feature detection so that it can disable itself on browsers that have alternate ui's for controls like this.

For example, this converts a select menu to an input field. On iOS the keyboard comes up instead of the select control.

This just seems like a matter of preference to me. It works on iOS pretty much just like it works on a desktop. It may be that some iOS users would prefer the native UI, but you could say the same for some desktop users (particularly keyboard-wary ones). I certainly wouldn't call anything "broken".

It's broken. When I tapped it the element the dropdown part of it didn't come up on the screen. The only way to scroll inside it is to do the 2 finger scroll, which 90% of users wouldn't know how to do (since normally you do a 1 finger).

On the desktop the element still feels like a <select>. On the iPhone it feels nothing at all like a <select>

I believe that on iOS5, the 2 finger scroll has been removed and replaced with a 1 finger one.

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/...

It'd be better if it looked for the HTML5 "placeholder" attribute even in older browsers rather than having to use "title" also. Some JS plugins [1] do this to replicate placeholder support in older browsers and I don't think there's any downside.

[1] https://github.com/mathiasbynens/Placeholder-jQuery-Plugin

The trouble is that no version of HTML (currently) allows a "placeholder" attribute on a select element, even HTML5. If you want your pages to validate, @placeholder won't do the trick.

Ah gotcha, wasn't thinking about <select>s. Makes sense.

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:

    <select required>
        <option value="">Placeholder Text Here</option>
        <option value="1">first real option</option>
    </select>

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.

Excellent. Makes you wonder why browser vendors never improved on the usability of such controls themselves.

Some do. Maemo's MicroB browser shows this when you click on a select menu: http://i.imgur.com/rP6Mz.png - one of the few places interacting with a website is actually easier and faster on a mobile than on a desktop browser. I think Nokia's Symbian devices do this too.

I'd rather my OS (desktop theme) be left to take care of the controls, which at least lends to better consistency than a myriad of different browser and site implementations.

Um, what use this?

If I click on a dropdown box, I can already type the value on my keyboard to select it. No javascript necessary.

(using chromium on ubuntu)

This was my first thought, too. Safari does the same thing.

I agree, but 99% of the users out there don't know that. :\

This is fantastic. ComboBox is what's missing in HTML. This is a keeper.

HTML5 has the datalist element, which provides suggestions for an input box and is similar to a combo box. The best info I can find on it is: http://dev.opera.com/articles/view/an-html5-style-google-sug...

This is currently only supported by Firefox Opera. A JavaScript polyfill to get this working in other browsers would be great.

For the multiple select, I like this one a lot: http://loudev.com/

It's way simpler for the average user.

The UI widgets like this all have the same defects:

1. They are slow, as all their markup has to be generated on the client side each time the page loads

2. They are not ajax friendly. I mean that if you insert a select box in a HTML document with javascript, it will remain a plain native select box unless your script specifically calls the right widget's function. So you have to update all your scripts.

3. They are not drop-in replacements for native widgets, all your script must know how to handle these widgets for things like getting the widget's value, listening for events, etc.

Points 1 and 2 could be fixed by generating the widget's HTML code on the server side and using delegated events (like jQuery's delegate()). (Progressive Enhancement can still be achieved without doing _everything_ on the client side.)

Other than that, the idea of a text input on the top of the options list is awesome.

I've been using the jQuery UI ComboBox for a while, it's essentially this. - http://jqueryui.com/demos/autocomplete/combobox.html

I would also add a fuzzy matching. I.e. "unitd sta" should match "United States" even with the missing "e". Or "East coast" should match "The East Coast".

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.

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.

I think it's pretty cool, though it would be nice if they had a simplified single selection version. Which is to change a single select list into a text field with "instant search". The current incarnation make me first go for the pull down rather than just tabbing over and start typing.

This plugin makes the case that this sort of functionality should be implemented into browsers very well.

So... why don't they use this thing on their own web app? The "Project / Task" select box becomes very unwieldy with a growing client base. I spend way too much time looking for the correct project almost every time I have to create a new entry.

Because the plugin is written by a github user, not github themselves.

Writing good widgets from scratch is an endless task. It's missing ARIA roles: http://www.w3.org/TR/wai-aria/roles#combobox

Sexy! I do agree with a previous comment that the more technologies like these that come out, the more apparant it becomes that HTML as a whole needs a long overdue makeover.

The first sentence on the linked page has a typo: "javsacript"

Note: IE8 (and lower) support is done via Chrome Frame.

Does it means this doesn't work on IE when Chrome Frame is not installed ?

I just verified that it works in IE8 without Chrome Frame. I think what they mean by "legacy support is enabled" is "it's fugly but it works."

Hopefully some of these ideas will end up in dojo/dijit (a couple similar takes are already there).

I really like the multi-select control.

I think this is great and would like it to be a browser extension so that I can use it all over the web

That looked like a cool project, so here:

https://github.com/gk777/Easy-List-Select

Unfortunately, I don't think it's as good as I thought it would turn out to be, but it's definitely neat.

EDIT: it's a chrome extension BTW

Does anyone know if it's compatible with formalize.me? Does it work well on android/iphone?

Works well on Android 2.1 for me here.

Beautiful plugin, bookmarking for definite future use.

Seems OK on the default Android browser here too, though there are a couple of non-breaking issues under Opera Mobile.

Technically it works ok on the iPhone. From a UX standpoint it's not that good. It's completely different from a native iPhone drop down control. I don't know that there is anything that the developer can really do about it. IMHO I would use a JavaScript check to make sure that mobile clients use the native controls and everyone else uses this plugin.

Multi-select could use some work. Drag-highlighting, shift, ctrl, etc.

Awesome. This is going into my UI toolkit.

Wow. The results are really polished!

Has anyone tried this on an iPad?

I did it just now. The divs that contain the choices can only be scrolled with two fingers, a trick most users don't know about. The native select can be scrolled with only one finger.

I love this. LOVE it!

Reply on news.ycombinator.com