17

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?
9
  • 1
    Related: ux.stackexchange.com/questions/281/…
    – GotDibbs
    May 19, 2012 at 15:51
  • 4
    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. May 19, 2012 at 17:14
  • @Marjan: This is a very simple solution I haven't thought of. Would you please post it as an answer instead?
    – Dan
    May 19, 2012 at 17:40
  • 1
    When I first answered this question, I dismissed the costs of triggering 'cascade' animations, as I didn't think seeing an element move from one line to another would create a problem. Using your demo, however, I saw the real issue: that when I dragged an element across several rows, it triggers not one, but a great many 'noisy' animations. It just goes to show how useful examples and demos are in questions! May 19, 2012 at 17:46
  • @MarjanVenema That seems like it might be even noisier to me. Creating a whole other row might be confusing in that you get the initial reaction/feeling that the row will be permanent and not temporary -- even if its grayed out or semi-transparent. Even showing the item that will wrap just slightly popped off to the side of the shelf feels a bit clunky.
    – GotDibbs
    May 19, 2012 at 17:51

4 Answers 4

3

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:

mockup

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.

3
  • Thanks for pointing out that this is the iBooks behavior, I'll get my hands on an iPad in a day or two to study it myself. I just realized that iOS home screen behaves this way as well so it makes perfect sense to mimic this established behavior. However, cascading overflow issue is not really a problem in iOS because there are just four rows. When there are eight rows, flying books will take longer to animate and they will probably be more distracting to watch.
    – Dan
    May 19, 2012 at 16:17
  • It seems like in your example, I only see a handful of rows above the fold as well. Are you expecting to make the books and rows smaller? I ask because you may be able to get away with only animating the objects that are in view, and just move the objects that aren't in view.
    – GotDibbs
    May 19, 2012 at 16:20
  • 1
    Why, this is a very reasonable point. I also noticed that iOS home screen drag-n-drop doesn't animate immediately. Such delay nicely solves the problem of “overflow noise”.
    – Dan
    May 19, 2012 at 16:29
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:

enter image description here

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.

2

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.

5
  • I also find it entertaining that this is exactly what happens when the last shelf is being overflown in the current version of live demo. It'll need a sort of believable animation though.
    – Dan
    May 19, 2012 at 19:11
  • @DanAbramov: The "hover" shelf cracking and splitting in two? If possible just in front of the last book. Right part dropping down and growing left, original shelf growing right. Growing the shelves could be accompanied by the books moving but that might be a bit too much. May 19, 2012 at 19:19
  • 2
    I just can't see this design working. I think it's a novel idea, though. May 19, 2012 at 21:03
  • I think this is probably a good solution. I also am fine with the solution currently offered in the live demo. HOWEVER, one glaring issue I see, is when the hover causes books to flow onto another/new shelf, moving the book back where it came from doesn't undo the previous move. If I just want to rearrange books on a shelf and accidentally drag too far down over a full shelf, a new shelf will be created, or a cascade will happen to the whole library below. But when I correct my movement and drag the book back onto the shelf I want, that cascade/new shelf stays. I don't believe it should. May 22, 2012 at 19:38
  • @Gidgidonihah: I agree, it shouldn't. May 23, 2012 at 6:35
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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