Should it have ajax support to add items to the list instead of transforming a large select which makes it slow.

I was using selectable to implement checkboxes.

t.find('tbody').selectable({
stop: function(i){
$(this).children('.ui-selected').find('input').attr('checked',true);
$(this).children().not('.ui-selected').find('input').removeAttr('checked',true);
}
});

I took a crack at a multiselect plugin and would love to hear some feedback regarding it's practicality, design, usefulness, etc as a jQuery UI widget. http://www.erichynds.com/jquery/jquery-multiselect-plugin-with-themeroller-support/

My initial concern is scalability. The summary of this widget describes a scenario with hard-to-manage select boxes (20+ items), which my implementation doesn't address. At some point the widget will slow to a crawl, especially if the "check all" or "uncheck all" links are clicked. On the other hand, I think my design is more intuitive & practical for smaller select menus, so perhaps both have their place.

My other concern is with the visual design itself. If nestled in a form with regular inputs, will it look out of place and introduce a usability problem? Or am I trying to solve a problem that doesn't exist?

Thanks

Eric,

Very cool, I've been playing around with it in jsbin and found a couple of minor bugs.

minWidth should be a set size instead of auto. http://jsbin.com/multiSelect1

showHeader: false breaks the scrollbar http://jsbin.com/multiSelect2

I'll report more as I find them.

Looks good.

Ralph

Just my input about a few issues or scenarios that i've come across using the quasipartikel multiselect that should be looked into by yours:

* i've noticed it doesn't have a search like the quasipartikel one, is this something your going to implement, i did find even on big lists this is still very quick.
* Another thing is that it should definetely have ajax support, firstly for the search box (if implemented).
* You should also expose some of the rendering functions. This is something i had to do with the quasipartikel one which is where i added a functionality to filter the data displayed in the list (e.g. mine was a member database so wanted to filter active/new/age/ etc handled by a seperate menu (menu plugin when its finished)). I had a ajax request call a php file which did the query based on my params sent through in the url and returned a data set which i then had to parse by exposing the rendering functions. Something like this would be nice by default.
* I've tested quasipartikel with about 1000+ items and although it is very slow (specially on check all/none) it did work eventually. i'm not sure on the best way to handle large datasets, maybe render the first 20 and then render them as someone scrolls might work. Definitetly something to take into consideration.

Scott and Ralph, thanks for the feedback! The keyboard support is indeed limited at the moment. I love the idea of combining the selectedList and selectedText parameters with a function as an argument. I'll incorporate all these points as I widgetize it.

Jaggi, regarding the search, it would be nice, I'm just not sure how to fit that into the design as there is very limited space. This would work great if the menu was always 300px+ wide, but it inherits the width of the original select menu. I could put a search icon next to the close link which would reveal a search box when clicked, but I wonder if it would be noticed & used. The "infinite scroll" idea on the menu is definitely something to consider. I need to see at which point this thing begins to break down; another option is to change the design all together if the menu holds xx items, maybe something similar to quasipartikel's.

Sorry think i got a little confused as to the layout you were using, i considered it to follow the layout in the image above which is what i would suggest as good option, i did see your link ( http://www.erichynds.com/jquery/jquery-multiselect-plugin-with-themeroller-support/ ) but i don't think that works on very long lists as it doesn't provide that much difference from a normal select menu and is more tedious. Your right you could do two layouts one for < 20 and then one similar to the one above for > 20 similar to quasipartikel's layout and that above in the screenshot.

If using a layout similar to the top one you might get away putting the search on the bottom of the layout in the right corner, i think it would work and should be in view as the layout image shows it as quite small. If your using the one you linked to then i wouldn't suggest a search box as i consider the layout too compact. Could you update the main post to reflect the current development process your taking.

Correct, it would not be practical for lists large enough that might warrant some kind of search functionality. But, for those following my implementation, the UI widget version is being developed in this repo: http://github.com/ehynds/jquery-ui-multiselect-widget

Jaggi and anyone else following this, I finally got around to porting my version of multiselect over to the widget factory: http://www.erichynds.com/jquery/jquery-ui-multiselect-widget/

Great, I'll test your widget