Moving Elements Between Lists

Question

I have a question... I'm dealing with an interface that has two lists, and you can drag and drop elements between them.

What would be a better approach and why?

a) Moving between lists doesn't change any behavior of the buttons between them. If item three is moved to the right, the system will remove the item from the source list, select the next available item in it and put it desired item in the target list. Focus of previously selected item gets lost and replaced by another one. (In the figure below, Item Three was pushed to the other list, and Item Four got selected).

^{download bmml source – Wireframes created with Balsamiq Mockups}

b) The behavior of the middle button changes, as the item selected doesn't lose focus. As opposed to previous example, moving clicking once on the middle button > will move the item from one list to the other and it will change to <.

^{download bmml source}

In my opinion, option b is more friendly as it allows you to go back to a previous state (undo) easily. It also removes the need for disabling buttons, and having items selected on both lists, and that to me makes it a bit easier to use.

---

Bonus: Considering solution a) we know that when an item on the left list is selected, it can only go to the list in the right, and the other way around; when an item on the list on the right is selected, it can only go to the left list. Would disabling buttons accordingly may be annoying to the user or should be encouraged?

Answer 1

Take a look at the bigger picture. What is the user going to do next? Probably not undo - possible but not probable?

If the likely next step is to move another item from the left list to the right then you should leave focus on the next item in the source list, so that the user can move multiple items easily be sequential pressing of the arrow button. So to move items 2,3 and 4, you'd select item 2 and then press the arrow button 3 times.

Similarly if you moved an item from the right list to the left.

Assuming the list is ordered, you should maintain the same order in the second list as the first, unless there is a good reason not to (like the list is acting as a history of chronological events and is ordered by most recently added).

There's no need to disable (grey out) buttons except when one list is empty, and don't hide them at all as it prevents visual exploration of the affordances of the scene.

So option a) it is.

Answer 2

Here are the points to be taken into account for transfer lists:

• Single-selection vs multiple selection (including by dragging);
• Selection after transfer;
• Double-clicks in lists;
• Possible handling of the ENTER/DELETE keys to transfer items when focus is on the lists;
• Focus traversal policy;
• Sorting.

To be honest, I think it is best to keep the two transfer buttons, provided that the behavior is as follows:

• When transferring selected item(s) from one list to another (in either direction), the transferred item(s) should be automatically selected in the destination list. This allows the user to revert back quickly by clicking on the other button, in case he makes a mistake for instance. Also, this gives a good feedback that items have been transferred as it is easier for the user to follow what is going on, especially if the items in the destination list are sorted for example (the transferred item may not appear at the end of the destination list).
• When transferring selected item(s) from one list to another (in either direction), the next item in the source list should be automatically selected. This allows the user to quickly transfer consecutive items by clicking quickly on the same button without having to move the mouse to select each item individually.
• Depending on your use case, multiple selection could be handy in both lists to let the user transfer several items at once. And if nothing is selected in a list, the associated button to transfer to the other list should be disabled. So buttons should be enabled only if clicking on them would actually have an effect.
• Make the traversal policy in such a way that the next component getting the focus after the > button is the < button. In many implementations (especially Java Swing), this order is not the default one, and tends to surprise the user (not natural).
• As many people tend to double click on items, it could be a good idea to transfer double-clicked items to the other list.
• Some people also tend to use the DELETE key on the right hand list (depending on the semantics). So it might be a good idea to support it. In such a case, you could also allow the ENTER key on the left hand list. However, maybe this is just a matter of taste, not sure.

This implementation, requiring 2 transfer buttons, is very handy and allows to the user to go very quickly, and it is also easy enough to quickly correct mistakes.

Note that here, we make the distinction between selection and focus. For keyboard manipulation, the focus should remain the last used component. I have seen many implementations (in Java Swing again) where buttons temporarily get disabled during intermediate selection state in the lists, what transfers the focus from the activated button to the next component. This makes keyboard handling very annoying.

One last think to consider is sorting: either in none of the lists, or only in the first list, or in both lists. This really depends if the order in the lists has a semantic meaning. However, it is often advised to sort the first list, especially if it initially contains a lot of items. This makes it easier to find items. You may have a look at this question: Am I right to sort the the RHS listbox alphabetically in a paired-listbox GUI?.

I hope this helps ;)

Answer 3

I would recommend going for option A for the simple reason that it clearly highlights the role of each button and keeps the user informed of the actions he can perform.

In option B, if you are going to switch the button based upon which column is selected there is a good possiblity that users might not notice the change in the button action( I didnt and first reaction was where is the reverse option). Further more option B is not intuitive as you are potentially hiding the various functionalities of the move button which get revealed only when an action is performed and users at first glance might get the impression that moving stuff from Column 1 to 2 is an irreversible.

With regards to option A, I would recommend going with the approach of keeping the right to left arrow disabled when there are no items in the right column (and vice versa) and enable it as soon as an item is moved across the columns as that would inform the user that he can shift between columns.Keeping it disabled initially is fine as you are just preventing an error from getting the user to trying shifting content from an empty column.

Answer 4

If you are considering option B you need to add a visual cue (e.g. "-------") of the previous position in the original list. You also need to realize that this separator won't be visible anymore if the user unfocus the item in the second list: the list on the left will be reset and moving the item back would logically result in putting it at the end (after item four). Keep in mind that the items shouldn't lose focus when you tab to the button.

You have to remember that the button must have an original state: if the list on the right is initially empty the choice is simple (>). But what happens if there are items in both lists? So that's what I would recommend: put both buttons but when the items are focused/hovered/dragged hide the inactive button or change the outline color of the active button.

So my answer is do both in an interactive way: the behavior should adapt to the user and not the other way around.