5

So a while back, I asked a question about a dual list UI. I didn't explain my question well enough, and the answers reflected that. My question now is, "Is there a better way to allow the user to accomplish their goals than with the UI I've created".

The goals are as follows.

  1. User must be able to select Super-Categories to cut down on the Available List size
  2. User must be able to Filter Categories to cut down on the Available List Size.
  3. User should be able to use a general Add/Remove to move Categories from the Available to the Selected List.

Here is my current setup, pay no mind to the colors, they were used for sizing and positioning. The thing I'm noticing is how this UI setup seems to always feel like it needs more and more space. It also feels VERY unbalanced because of the Filter and Super-Category selection being on one side, and nothing being on the other.

I could move the Filter so that it was on the same line as "Sections"/"Super-Categories" and then add a Separator for a mental break. But I feel that leads the user to think that the filter works on the Selected List when it only works on the AvailableList.

Any help is GREATLY appreciated.

UI Atrocity Below...

enter image description here

6

About the List Builder and the Add/Remove List

TL;DR. Here's a summary of two design patterns that might work, with lots of questions to help you decide.

This information is from the usage patterns for list boxes, and you have to scroll down a few rows to see details about List builders and Add/remove lists. Nothing in these guidelines says that the screen must appear "balanced", which is one of your concerns.

First, here are some questions to help you decide which pattern is best for your problem space.

Is this the right design pattern?

Is the control used to choose zero or more items from a list of values? If not, use another control. For choosing one item, use a single-selection list instead.

Does the order of the selected items matter? If so, the list builder and add/remove list patterns support order, whereas the other multiple-selection patterns do not.

Is it important for users to see a summary of all the selected items? If so, the list builder and add/remove list patterns display only the selected items, whereas the other multiple-selection patterns do not.

Are the possible choices unconstrained? If so, use an add/remove list so that users can choose values not currently in the list.

Does adding a value to the list require a specialized dialog box for choosing objects? If so, use an add/remove list and display the dialog box when users click Add.

Is screen space at a premium? If so, use an add/remove list instead because it uses less screen space by not always showing the set of options.

For list boxes, the number of items in the list isn't a factor in choosing the control because they scale from thousands of items all the way down to one for single-selection lists (and none for multiple-selection lists). Because list boxes can be used for data, the number of items might not be known in advance.

Interaction details and UI descriptions

Here is a description and the interaction details for each design pattern.

The list builder

List builders allow users to create a list of choices by adding one item at a time, and optionally setting the list order.

A list builder consists of two single-selection lists: the list on the left is a fixed set of options and the list on the right is the list being built. There are two command buttons between the lists: Add and Remove.

Add moves the currently selected option to the list being built, inserted before the selected item. (Double-clicking on an option item has the same effect.)

Remove removes the selected item from the built list and returns it to the option list. (Double-clicking on an item in the built list has the same effect.)

The built list may optionally have Move up and Move down commands to order the list items.

Example of a list builder

In this example, a list builder is used to create a toolbar by selecting items from a set of available options and setting their order.

This is an older example, and the location of the Close button, or alternatively the OK button, will be dictated by the standards for your operating system.

The add/remove list

Add/remove lists allow users to create a list of choices by adding one or more items at a time, and optionally setting the list order (like list builders).

Unlike a list builder, clicking Add displays a dialog box to select items to add to the list. Using a separate dialog box allows for significant flexibility in choosing items—you can use a specialized object picker or even a common dialog. Compared to the list builder, this variation is more compact but requires slightly more effort for users to add items.

This extra step may make it easier for users to understand.

Here is an example:

Example of an add/remove list

In this example, users can add or remove tools from a menu, as well as set order.

While the list builder and add/remove list patterns are significantly heavier than the other multiple-selection lists, they offer two unique advantages:

• Users have control over the list order, while building the list and after.

• Users can review a summary of the selected items, a benefit if the number of choices is large.

Their disadvantages are that they require much more screen space and can be difficult to use when creating a large list of items from scratch. Consequently, they are best used to create short lists or modify lists that already exist.

Filtering

If you are concerned that the user might not understand that the filter applies to both lists, you can cue the user by using layout, a graphical element, or a simple phrase (embedded assistance) to make this relationship clear. In this illustration, the filter on the right is more readily seen to apply to the entire list builder screen simply by its layout:

Filter layouts for a list-builder screen

You seem to favour balance, so you might like to adjust the layout, or use it in combination with text, or background shading, or a graphical bar. If you're unsure, you can always ask a graphic designer for advice.

I hope that helps you decide whether to implement one of these solutions.

  • 2
    Another possibly interesting question to ask here is: "Can items be selected more than once?" – O. R. Mapper Oct 6 '15 at 14:33
1

In the end, I went with this as my UI which is pretty much what was suggested in the above answers.

enter image description here

0

My first thought was to move the Sections element up and make it look more like the parent to the elements on the page, but that didn't really solve the balance problem you were talking about. You said that the Filter element unbalanced because it was unclear exactly what it referred to, so how about a solution in which both sides have Filter boxes above? I assume that the user may add all the items in the list from the Available section to the Selected section so why not allow them to filter down on both sides?

Here's a quick mockup showing what I mean.

Mockup of two filter boxes

  • 1
    I think filtering the right hand side (after the user already explicitly selected the items in that list) would be quite confusing. – user31143 Oct 6 '15 at 6:23
  • This pattern is called List Builder. I'll add some information from the Windows UX guidelines as an answer, so that you can examine the information and read more about it. – JeromeR Oct 6 '15 at 7:17
  • If each filter box only belongs to one of the lists, why are the filter boxes outside of the group boxes around the lists? That seems confusing. – O. R. Mapper Oct 6 '15 at 14:35
  • O.R., that's true, they definitely would look more suited in there. – A. Sim Oct 6 '15 at 23:34
0

Rather than the "sections" drop down and filter box on the left, why not make the left element a tree?

  • The user would be able to open and close super-categories and categories to find items they want to add.
  • It would also better show the relationship between categories and items.
  • It would allow seeing items from two super-categories simultaneously.

That being said, if you think the current mode of selecting items is better for your use case, I don't see a particular problem with the interface being unbalanced. Having the selection and filter controls on the left is the right choice for usability, because it communicates what they apply to. I don't think you need to worry so much about having three elements on the left and only one on the right.

I would put the filter box above the list rather than below it, though.

  • I'm not able to find any, myself, so could you please provide a link to research that shows a tree control performs well in the hands of users outside of the software business, for navigation and for selecting in a list-builder pattern? – JeromeR Oct 6 '15 at 7:14
  • 1
    @JeromeR, you have exposed the fact that my answer was not research-based :) – user31143 Oct 6 '15 at 7:20
  • I recall reading somewhere that tree controls perform poorly in the hands of users (outside of a Development team) but I cannot find that, today. There is one pattern (msdn.microsoft.com/en-us/library/windows/desktop/dn742445.aspx) that allows selection by using check boxes on each node, recommended only when hierarchy is important, perhaps because it does not have some of the "summary/overview" benefits of the other patterns (List builder, Add/remove list) I posted as a proposed answer. – JeromeR Oct 6 '15 at 7:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.