User Experience Stack Exchange is a question and answer site for user experience researchers and experts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an application implemented with Java Swing. The main view of the applications is divided in a left side and a right side. The top of the right side contains a SearchField, and a list of search results is shown below the field. The user search for items using the SearchField then the user selects one of the items in the search results to be added to the list on the left side.

Think of this as an application where the user "build up" an order from items that are found by searching.

|                        |      SearchField      |
|                        +-----------------------+
|                        |                       |
|                        |                       |
|                        |                       |
|       List of          |      List of          |
|       added            |      matched          |
|       items            |      items            |
|                        |                       |
|                        |                       |
|                        |                       |

How should the user select the item in the search results and add it to the left list? By default in Java Swing when I have a JList or JTable the items are selected when the user clicks on an item. It have been natural if there was an "Add"-button for each item, I guess. But I have to do some work arounds if it should work like that in Java Swing. "Add" an item by double clicking it would work, but it's not that intuitive. Select an item and then press enter isn't that intuitive either.

But if I had implemented this as a web application it had been natural to have an "Add"-link for each item in the list of search results.

How should I solve this usability problem? Is it best to have an "Add"-button for each item, or is there a more intuitive solution? I feel that the user interface will look "messy" if every item has a default Button, so I guess that I have to use a more discrete custom button if a button is the solution.

share|improve this question
I've seen this concept called, dual lists, accumulator, list builder, and LOV (list of values). Perhaps these terms may help you find more material on this UI pattern. – jpierson Apr 1 '11 at 22:04

I have built several of these types of interfaces. I suggest as you mentioned having an add button on each item and a remove button from the added items list.

Another option that I have had success with is having buttons between the two boxes with arrows showing the direction of movement. From right to left <- is Add and left to right -> is Remove.

share|improve this answer
My upvote is because of "<" and ">" buttons. It makes all the sense. And I agree with @Schroedingers Cat about the order of boxes being wrong. If you read from left-to-right you want to enter a filtering criterion, after see the matched items and finally the SUBSET of matched items you've added. Real-life application example of a dialog with "<" and ">" buttons: – sergiol Jul 19 '14 at 9:06

I agree that a double click is not discoverable. You mentioned that clicking an item selects it. Why not place a big "ADD" button at the bottom of the right-side panel, which will act on all the selected items? It can be disabled when there's no selection, and become enabled once an item has been selected. Pressing Enter can be a keyboard shortcut for the button.

The left-side panel can have a "Remove" button working the same way and placed level with the ADD button.

BTW, unless this interface is for an RTL language, it seems to me like the direction of the work process should be reversed - the source is usually on the left and the target on the right.

Also, I don't know how you're handling this right now, but just in case -- in my opinion, added items should not disappear from the source panel (they're still the search results, they don't go anywhere), but there should be a visual indication that they've been added.

share|improve this answer
+1 the order of the boxes is wrong. It should move Left to Right. – Schroedingers Cat Oct 2 '11 at 14:42

I agree with Vitaly, an add and remove buttons go natural with this kind of task. If you want to give the user more options, enable drag and drop from the search field to the target list. Also enable editing through keys, return in the search list adds, delete in the built up list removes the item.

As opposed to removing items from the list that displays the search results a better solution would be to mark them (deactivate the item) this way when a user executes a search that includes items that have already been added to the list the result is the same as before but the already selected items are visible. Otherwise two searches would show two different results, that might distract some users.

share|improve this answer

You could even add a checkbox against each one of the items in both the list boxes. And provide 2 buttons, Add (Moves to selected list) and Remove (Moves to the unselected list). By doing this you can select multiple items at once from either list and move them around easily. You could do this by using a datagrid and style it to look like a list if you wanted to. Hope this helps.

share|improve this answer

By the way I've developed an alternative that shows a listbox containing only the selected items and then has a button of to the side or a way to get into a small dialog similar to a combobox dropdow. In the dropdown there are then a list of options along with checkboxes next to them as well as a filtering textbox at the top. This pattern has worked out well for me so far and moves the list modification off to a different surface while allowing a simple view of the selected options only to be shown on the main surface.

This works best in cases where you have to have multiples of this type of control within a single UI or if you need to use this control in conjunction with other complex controls upon a single surface. If your example is to encapsulate the selector within it's own dialog then it is probably easier to go with the more traditional dual lists concept.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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