Making space for the “drop cue” in a drag-n-drop design

Question

I'm developing a drag-and-drop reordering interface for books on shelves.
(You can try it live if you're on the latest WebKit.)

When you drag a book over a shelf, it accommodates space for it by shifting nearby books to the right.

Accordingly, when a shelf loses hover, the previously accommodated free space collapses.

.

If this doesn't make sense to you, please see it in action, for a drag is worth a thousand of words.

To my taste, this looks pretty sweet, except for the case when the shelf is already packed.
In our example, a shelf can contain no more than five books.

So what should happen when you hover over a shelf that has exactly five books?
I was thinking hard on this, and I'm not sure I found a satisfactory answer yet, hence this question.

I'm considering several options which I will briefly explain below.

All of them have their pros and cons, and I'm open to community's opinion on which one is better and whether there are some solutions I haven't thought of in the first place.

Okay, so that's what I came up with so far.

We can “overflow” the shelf immediately by moving rightmost book to the next shelf.

This solution is pretty straightforward.
We need some space, we ain't got any—let's free some by moving the last element to the next shelf.

Now we do have some!

This is the way the demo operates now.

Unfortunately, this solution has two major drawbacks that render it unusable in practice:

• It messes up user's order of books before an action is even completed.
• If the next shelf is also packed, it will have to overflow as well, and so on.

This leads to cascades of overflowing shelves if dragging over an almost packed bookcase.
This will most definitely suck.

I guess the takeaway lesson here is don't ruin user's order of books unless absolutely required, and never do it before the drag is over.

So we come to the solution #2.

We can clump the books together to free some space.

We can't avoid overflowing altogether unless we forbid dropping on packed shelves at all.
Nevertheless, we are free to only overflow after drop, and keep the layout unchanged while dragging.

This will balance overflow's negative impact on user's order of books with user's conscious decision to change it by placing a book in the middle of a packed shelf.

All in all, this solution seems better than the first one but poses several other problems:

• How do you beautifully clump the books together?
• How do you let the user know that the overflow is going to happen after drop?
  Coverflow-like clumping seems to suggest that books will stay clumped but this isn't the case.

There are also other options I haven't really thought through—for example, we may decide to allow more than five books on the shelf by emulating spines. This is precisely the way real books and shelves solve this problem.

We may enter “spine mode” once the shelf is packed.
However, this could make UI unnecessary more complicated.

To wrap up the post, I'm looking for answers to these very specific questions:

• Which do you think is a better solution in terms of UX?
• What other solutions to the problem described can you think of?
• Has a similar problem been solved before by someone? How?

Answer 1

The way you have it right now is exactly how iBooks behaves on the iPad.

An additional solution that I might recommend is to place more emphasis on where the book will be after drop, so provide the user with an idea of where the book will end up when they drop. See the below for an idea:

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

The basic thought is that you show the user a clearer picture of where the item will be when the mouse is released. I think allowing the wrap is ahead of time is OK. However, if the user "cancels" the drag by dragging it back to the original shelf, the item that was wrapped should be returned to the shelf it wrapped from.

I agree that your thought of a "spine mode" would probably make the UI overly complicated. If you also allowed drag and drop on that interface, it would make the targets a lot smaller which could negative effect on task performance.

Answer 2

Which do you think is a better solution in terms of UX?

Of the two, I'd choose the first.

Whilst I appreciate that moving many rows of books forwards and backs as the user moves the element around is 'noisy', that's still better than 'clumping', because at least it signals to the user the results of their action before they commit to it.

It messes up user's order of books before an action is even completed.

On the contrary. It re-orders the books to the order they're going to take anyway - it just does it earlier so the transition is less jarring.

[clumping] will balance overflow's negative impact on user's order of books with user's conscious decision to change it by placing a book in the middle of a packed shelf.

You could try user testing this design, but I'd expect it to make the user expect to see 5 elements on a shelf. Then, as the user disengages, the 5 elements will suddenly change to 4. Given that the user may have stopped paying attention, it's highly likely that they won't spot how the shelves have changed.

What other solutions to the problem described can you think of?

It depends how you expect users to be ordering books. Are they trying to create categories and sections? Abandoning fixed-size groups (shelves) might be the answer. Are they just wanting to put favourite items in easy reach? There might be better ways of supporting that behaviour than re-ordering the library.

Has a similar problem been solved before by someone? How?

Yes. Look at the way Photoshop handles layer movement:

The element that's being moved is made semi-transparent, and duplicated. As the user hovers over placement points, a line appears - a minimized version of the element to place. On releasing the mouse button, the line expands into the full element, and only then are the other layers moved down.

This solution prevents the 'cascading' that you're fearful of - and its associated visual 'noise' - it but still allows users to see what the consequences of their actions will be.

Answer 3

As requested posted comment as answer:

I may be way off base, but why not create a new shelf under the overflowing one that will get the "overflown" book. If the hover goes elsewhere, move the "overflown" book back and collapse/delete the temporary shelf.

In response to GotDibbs: I don't feel it would be noisier. Re-shuffling entire shelves with a possible cascading effect because of full shelfs under the "hover" one would be noisiest to me. Inserting a new shelve is vertical motion only and only one book ever moves around (apart from the one being dragged).

And indeed as Dan already said in the comments: inserting a new shelf doesn't mess with the user's choices about how his/her shelves should be filled - it just makes room for another one.

Answer 4

I would instead suggest looking at how Chrome used to organize* its Most Visited page, or the way TF2 presents the user's backpack.

Your shelf would be arranged in n×5 slots. You can show this with a dashed grid that becomes visible as you start dragging items. Dragging from a slot to another swaps their contents:

In other words, when you drag in item X in a slot to an item Y in another slot, this means X and Y swap places. This might seem arbitrary but completely avoids the problem of overflowing. This also allows you to put gaps in the middle of your shelf.

Chrome hinted at the swapping behaviour by nudging the drop target towards the slot previously occupied by X.

_{*Chrome no longer seems to supports shuffling "Most visited" items around.}