I'm often conflicted about how to approach this problem in my applications. I've used any number of options including:
A generic multiselect - This is my least favorite and most rarely used option. I find the usability to be atrocious, a simple mis-click can screw up all your hard work.
An "autocomplete" solution - Downside: user must have spelling abilities to find the damn values they need, aren't exposed to ones they may not have in mind, and the potential backend performance of substring searching.
Two adjacent multiselects, with an add/remove button - Downsides: still "ugly" imo
Any number of fancy javascript solutions (http://livepipe.net/control/selectmultiple, http://loopj.com/2009/04/25/jquery-plugin-tokenizing-autocomplete-text-entry/, etc.)
I haven't been able to find any usability studies done on the best approach to this problem. Many of these alternate solutions are great when you're going from <10 elements to a hundred, but may break down completely when you are going from a hundred to a thousand.
What do you guys use? Why do you use it? Can you point me to usability case studies? Is there a "magic" solution that has yet to be discovered?
My advice is don't use generic multiple select controls. I've been running User Experience Research for my whole career, and every single time I test a site with multiple select controls, it always turns out to cause problems for end users.
I did a post on this a while back: Multiple Select Controls Must Evolve or Die
Sounds like you knew this anyway, though. Your real question is "what do I use instead?" Well, to answer this question you have to work out whether the user's task leans towards recall or recognition.
(i) By recall, I mean the user knows what they want to pick before they have even seen the list. In this case, it's probably easiest for them if you offer an autocomplete tool (as used very effectively on facebook, for example). This solution is even better when the list of options is also impossibly long to present on a page (e.g. location names, etc).
(ii) Moving on to recognition - by this I mean a task that involves the user not knowing what they want to pick until they've seen the list of options. In this case, autocomplete doesn't give them any hints. An array of checkboxes would be much more helpful. If you can show them all at once, this is helpful to the user. Scrolling DIVs are more compact but they create a memory load for the user - i.e. once they've scrolled down, they have to remember which items they picked. This is particularly evident when users save a form and come back to it later.
So - thinking about your problem, do you need a solution for recall or recognition?
I can't point you to any case studies, unfortunately, but what I can tell you is that I personally prefer large checkbox arrays in two-to-five column layouts. Sure, they take up a lot of space, but they are extremely precise and uncomplicated.
I think for any control - be it basic multiselect, double list, checkbox array, or any other solution - once you go over a certain threshold of items it's going to be challenging for the user no matter what.
Have a look at Dojo Toolkit's DataGrid control. It's by far the most flexible and powerful, and supports multiple row selections. It also has accessibility features built in.
The ExtJS library has some really good solutions for your issue. There a bunch of user extensions for neat-o combos and multi select boxes.
If you want a combo select list, you can add query searching and pagination, plus design the resulting drop-down using easy templating, like in this example:
http://extjs.com/deploy/dev/examples/form/forum-search.html
Here is a nice multiselect, in the style you seemed to describe:
*(main_site)/learn/Extension:Multiselect2
You can find all user extensions here:
*(main_site)/learn/Ext_Extensions
Plus, you can easily include it into an existing web page without alot of extra overhead. ExtJS's full stack is quite large, but to get only the JS files you need, they provide a nice builder tool to grab just those parts you need:
*(main_site)/products/extjs/build/
Just a warning: ExtJS has just released 3.0, but I'm not sure the user extensions have been upgraded. The "forum-search" was taken from a 3.0 example though, so it will work just fine with the latest and greatest.
(*) Apparently new users can only post one link...
Related
I'm working on a force directed graph for a university project. We have to create a 'research archive' that presents all our research material – I've started mine here as a digital garden using Maxime Vaillancourt's Jekyll digital garden template (which uses d3). You can view it here.
Part of the reason I started with this was I was using obsidian for a while, but wanted a) it in a website format, c) something I could easily share with my tutors etc, and c) more customisable options than obsidian). Maybe it's a bit of an obsidian hang-up, but I really want to be able to add 'tags' to entry, e.g. by theme, or by entry type (so different tags for images, journal articles, primary research, etc). I'm struggling to find answers relating to this, and think maybe I'm too stuck on the idea of 'tags' and not thinking through other ways people might be expressing/phrasing something which achieves the same thing.
Ideally, I'd like these to be a toggleable feature, e.g. click a sidebar button to view all entries tagged with XYZ.
However, I was also thinking it could work through different styled/coloured lines that show connections by tag (so an entry would have, say, bold black lines to other entries they're linked to; a dashed grey line to ones that are also tagged with 'photograph'; a dotted blue ones to ones that are also tagged with 'health'; etc). Or, giving each entry only one tag, and that tag denoting the colour of the node.
The reason I am keen on this, is I would like to be able to show different 'levels' of connections, but at the moment am struggling with the 'difinitiveness' of the single line. I know for some people who use Obsidian as a zettelkasten tool they're into using links effectively as tags (e.g. having a list of 'tags' at the bottom which are in effect links), but a) I don't think this really works in the same way, and b) it requires creating full entries for themes or tags that might not naturally need one (going back to the photograph example - this work around would require creating a separate .md file titled 'photograph' which people would be able to navigate to, which would either mean I'd have to write some forced entry for this, or people would inevitably stumble on lots of dead pages.
I'm not expecting someone to come and fix my problem, but more ideas on what sort of features could work. I am self taught at a lot of this stuff, and so in particular often struggle with knowing what it is I am looking for/asking for – like I lack the language, even though I'm often able to actually work out how to do things once I've got on the right track.
In case anyone is ever stuck in a similar position –
I was managing to do a lot of the things I wanted on fiddles, but not via the template above. For some reason, I could get it to there being no errors/problems in the console log, but it just wouldn't actually 'work' (ie, there was a search bar, but typing into it wasn't performing the right functions, etc). I'm sure a more technologically capable person could work out what was the clash between the template and my edits that was causing this. But, after lots of trying, I stumbled upon https://github.com/jackyzha0/quartz – which so far already has a lot of things I wanted semi built in, and so far seems a bit more receptive to edits in this way.
I have a web form which has the user input the values of certain characteristics, however some of the characteristics have up to 45000 values.
The selects were working earlier, albeit with a slight amount of lag when populating the dropdown and trying to scroll through it fast, but now it does not populate at all and the web form hangs.
Is there a way to efficiently contain this many values into a dropdown? Also which is the best library for searchable comboboxes?
I looked at this implementation as it has a "load on open" feature which I thought might be beneficial, but it did not seem to work and is no longer actively developed.
http://john-oc.github.io/
Thanks
Perhaps it would be better to use an autocomplete feature instead of a select menu in this case. A user can type in the first few characters, causing a request to start filtering results based on their input.
Here are a couple of really good autocomplete plugins:
https://github.com/devbridge/jQuery-Autocomplete
Roll your own:
http://www.webreference.com/programming/javascript/rg16/index.html
I agree with Todd, I think you might want some solution that has autocomplete to hide too many results. I'd even go a step further and suggest bootstrap DataTables: https://datatables.net/manual/styling/bootstrap
You can make searchable tables with this, with the key advantage being that it paginates results, so you don't see it all at once.
I'm a big fan of https://github.com/angular-ui/ui-select. You can have it make a request based on the current text input, and then populate the dropdown.
Since the question is already answered, please let me just contribute here.
You can use the typeaheads from angularStrap to achieve this. Beyond the easy manipulation of data, you can even use to make async calls using data provider.
Is there any way to limit height for dataset dropdown list? When I use <input list="datalist"> and the datalist contains many elements, I'm not able to see them all. Can I limit the list size and add vertical scrolling to list all the alternatives?
I searched the web and the only answer I could find was that it's known issue without solution and to avoid it I should use jquery-ui combobox instead. I have javascript logic based on dataset so replacment with combo would require much effort.
Maybe there is some workaround to achive a limited list in html5?
The short answer is no, there is no easy way to achieve this without JavaScript. It is entirely up to the browser to render an input with a datalist. It will likely differ between browsers and devices as well.
If you go for JavaScript it is a lot of extra work, as you say. Do not forget about touch devices, keyboard navigation, visually impaired visitors and the tools they use when browsing, etc. Research available alternatives carefully, do not take for granted that they are are all good enough for your users. Unfortunately I do not know which ones to recommend myself.
Hi
To make convenient some animation, my strategy for a client-side script involves grouping list items into DIVs. It seems that having anything other than LIs as the children of OL or UL elements does validate. However, I'd be doing this in script, so no validation issue (for what that's worth!).
But might this cause a problem with screen readers and so on?
Thanks for any thoughts
One way to find out! I don't think there would be too much trouble, but the only way to know is to test it. Javascript's interaction with screen readers is a complex subject, so I'm hesitant to make any firm judgments. NVDA seems like a good place to start. :D
I'd normally steer clear of invalid markup, but I can't think of a better way to group things in the way you want to. Perhaps consider whether a single list is the best markup to use rather than multiple lists or some other set of constructs. Since you are needing to group list items in this way, it seems likely that there's a semantic reason for grouping them in markup as well.
As it goes, if browsers cope with the invalid markup in question, it is likely to work in screen readers and the like as well. As CrazyJugglerDrummer says, it's best to test it. However, you never know when that invalid markup is going to start causing problems in future software releases.
First off, screen readers and JavaScript do not have the best track record of compatibility. (Correct me if I'm wrong, I am no expert on usability) From what I have come to understand, screen readers typically read a static version of your page, and refresh it at seemingly random times irregardless of what dynamic changes have occured through JavaScript. This was my last experience with screen readers, but that was 3 years ago so things may have changed for the better.
To give an example, if your dynamic list is in fact an accordion that expands and contracts, you cannot with any degree of certainty know if a screen reader will display the text being shown (even if the JavaScript made the text visible to the screen).
Before I would start worrying about problems your script might cause for screen readers, I would instead focus on your overall accessibility of the site structure (HTML+CSS). Are you making integral elements to your page keyboard focusable? Are you following WAI-ARIA guidelines? Are you using the correct technique to hide content (situation dependent) display:none, left:-9999px, or visibility:hidden?
Quickish issue. I'm currently working with RoR with a great deal of Javascript for a project. I have a particular entity that has a "color" property. Of course I want to do this as "snazzily" (yup that's a word) as possible, however, I'm not sure how to go about it. I've seen a million and one different "Color Pickers" but none seem to fit the overall bill.
My current paradigm involves editing the entities from the "Index" page instead of having to click "Edit" for each and every one. I've got that working for several fields. What I need to implement now is a quality ColorPicker that doesn't take up too much screen real estate and/or hides itself after being presented.
So, all that said, can someone point me to some quality JS techniques for dealing with "pop-ups" and/or window return values? I'd like to really understand what needs to occur as well, so a tutorial would be nice.
Much appreciated.
Did you look at jquery and the jquery-ui tools?
This is one of the jquery-plugins http://www.eyecon.ro/colorpicker/