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.

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.

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: i.imgur.com/OWR8Cm0.png
–
sergiolJul 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.

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.

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.

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.