Auto-collapse subitems when using drag and drop for large hierarchical lists?

Question

We're looking at a reusable interface that can allow user to view tabular data with hierarchical structure and reorganize/re-order items.

Some use cases for this:

• Updating priority of work on a schedule. Work may be grouped together in subunits. As a project manager, I want the ability to re-prioritize subunits of work so my team picks up the highest priority items off the top of the list.
• Re-ordering items to present info to the stakeholders in a logical fashion. As a account manager, when I have financial update meetings with project stakeholders, I want the ability to reorganize the work list based on its importance to a specific stakeholder so I can more easily provide them with project updates.

Here's one sample view of one list (tabular view of a project schedule)

Note: this is just one view, the hierarchical structure to the left is fairly consistent across different use cases, but the data on the right varies. I don't think it matters for our problem.

Because this is a web app, there's a certain expectation from the users that they ought to be able to reorder items using drag and drop interactions. However, drag and drop doesn't work very well for large lists because you need to deal with the page scrolling AND the drag and drop action.

Because of the way our hierarchical lists are set up (items can only be moved within their respective groups), we have the option of collapsing the group to reduce the annoyance caused by page scrolling, but should we be doing so?

To state this clearly:

Should the system automatically collapse the groups to hide subitems as soon as the user starts dragging on the group header to facilitate reordering?

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

I'm a bit concern with the possibility of page jumping if the user is dragging on a group in the middle of the list and several large groups at the top suddenly collapses on them.

Note: I'm not tied to drag and drop behaviour at all. This is just something the users are familiar with. So feel free to suggest alternate ways of visually re-ordering potentially large lists.

Answer 1

The drag-and-drop method certainly has negative aspects, particularly when the list is long enough to overflow the page, but it may still be your best option.

I don’t think it’s beneficial to collapse groups automatically when the user starts dragging a row. That would interrupt the user’s action by moving everything around while he’s trying to interact with it, creating a moving target. To mitigate that problem somewhat, you could require that the user enter a reorder mode (similar to what you might be familiar with in iOS) in which groups are collapsed:

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

There are a few alternate patterns that come to mind. None are great, but they’re options. First, if the list has the potential to become very long, so that drag-and-drop is obviously unfeasible, there’s the GoodReads method, also used by Netflix:

The user can manually enter the numeric position to update the list order. Instead of natural drag input, which even small children can master, the user has to remember numbers and type them in. This is especially painful on mobile operating systems, where the keyboard often covers much of the screen, and users hate typing.

Another option is to offer up and down arrows that the user can click/tap to move a row one position up or down, a “stepper” control:

^{download bmml source}

This makes it tedious to move a row many positions up or down. You could try combining drag-and-drop, direct input, and stepper so that the user can choose which method is appropriate:

^{download bmml source}

Again, none of these are perfect, I’m just submitting options to help you think through the problem. Maybe user testing can be your guide from here.

Answer 2

If you have a menu in the left rail for the top categories, perhaps then you could use drag and drop for sorting by the category names. Similarly to Asana.

Answer 3

I am basically agree with Daniel, auto collapsing groups doesn't work well. I would still vote for drag&drop option if 1. User has relatively small lists upto 20-30 position in most cases or rearranges them rarely in case of bigger list 2. User needs precise control for item location: say, to move item #5 between #23 and #24 so item #23 becomes #22 and item #5 becomes #23. That is critical for example to linear stories/presentations or project management/planning where particular items are interconnected. 3. This basically means user knows all his items very well at a given point of time to make such decisions.

In many cases user needs relative items rearrangement/sorting to separate for example more important items from less important. The UI patterns for such priority escalation and de escalation are usually more user friendly (simple button/dropdown) so I would advise to consider them as well.

Answer 4

I wouldn't auto-collapse because it's unexpected. It could cause a drastic change in the appearance of the list upon drag initiation. Plus it raises the question of "do you automatically uncollapse after the drop or cancel?"

I'd also avoid a special reordering mode - I think that would cause more confusion than it's worth.

Drag/drop + scrolling is always tricky (both the implementation and UX are tricky). Some things to make it more usable are:

1) Good feedback - clearly indicate what is being dragged and the current (potential) drop location.

2) Proper scrolling speed.

3) Easy cancellation - escape key or dropping outside the list cancels the operation. When dragging outside the list there should be feedback that a drop here will cancel the operation, mouse pointer could change to indicate "cancel" (cursor: no-drop).

4) Provide an undo operation.

In addition to reordering by drag/drop you could allow reorder via cut/paste. I would have 2 paste actions: "Paste before" and "Paste after". Although this is somewhat unconventional you need the 2 actions in order to be able to both paste before the first item in the list and paste after the last item. And it never hurts to be explicit.