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.
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.
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.
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?
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.
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.
<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.
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.
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.
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.
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?
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?)
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.
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.
Didn't test on the iphone but on the ipad if you expand one control and then click on another it will keep both expanded. Click on a third and now you'll have 3 expanded. Looks weird. Also, +1 to try to replicate the native look, maybe just adding a down arrow. Good job otherwise.
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>
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.
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.
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.
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.
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 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.
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.
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.
80 comments
[ 2.2 ms ] story [ 113 ms ] threadThis is currently only supported by Firefox Opera. A JavaScript polyfill to get this working in other browsers would be great.
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.
If you manage to fix it for other browsers I hope you push your fixes upstream.
How about integration with jQueryUI's theming system?
[1]: http://www.whatwg.org/specs/web-apps/current-work/multipage/...
[1] https://github.com/mathiasbynens/Placeholder-jQuery-Plugin
I'd be impressed if it does. I can't parse that sentence in the spec.
Beautiful plugin, bookmarking for definite future use.
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.
Better solution: on mouse click, hide the box. Only show the box for autocompletes.
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?
[1] http://en.wikipedia.org/wiki/Uncanny_valley
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.
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
For example, this converts a select menu to an input field. On iOS the keyboard comes up instead of the select control.
On the desktop the element still feels like a <select>. On the iPhone it feels nothing at all like a <select>
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.
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.
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'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 multi-select is great, though. Why not make the single select work like the multiple?
I really like the multi-select control.
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.
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
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.
It's way simpler for the average user.