Provide re-ordering buttons

[wbreeze]

On mobile browsers the drag and drop does not work so well. It's also essentially a hidden feature on desktop browsers that might not be intuitively discovered. (The second is a UI issue that might benefit from some intearction hint.) To provide something visible, and which works on mobile, add buttons to the items that move them up and/or down in the order.

There are two types of up/down. One moves the item into a group with the item or group following it. The other moves the item below the item or group following it. Thus:

• On an individual item somewhere in the middle there are four buttons:

  • up above item preceding
  • up into group with item preceding
  • down into group with item following
  • down below item following

• If there is no item following (as in the last item) the last two listed buttons ought to appear disabled (not disappear entirely) so as to maintain alignment with the buttons in other items.

• Likewise if there is no item preceding (as in the first item) the first two listed buttons ought to appear disabled.

• For an item already in a group, which group is somewhere in the middle, there are four buttons: (These might have different appearance; however that is not a requirement.)

  • up into group with item preceding the group
  • up above the group
  • down below the group
  • down into group with item following

• The first or last of these ought likewise to be disabled for a group which is first or last in the partial order.

[wbreeze]

Possibly #13 is a prerequisite

[wbreeze]

I tried out a paper prototype of this with half a dozen people. I had them try the existing interface first.

People wanted to drag and drop on the cell phone. Many people wanted to do the same with the paper-- they wanted to rearrange the strips. One person couldn't help it, even though I kept telling them that they could only poke.

• Everyone was able to figure-out grouping and rearranging with only the existing poke behaviour.
• When prompted with the task, everyone was able to figure-out rearranging the items by grouping and reselecting.
• People understood what it meant when items are grouped.
• When asked to reorder or combine items into a group, some peop le resisted because the suggested "what-if" didn't align with the truth of their preference.
• The initial interaction in all cases was to poke in order of preference, a validation.
• A number of people wanted to submit. I told them not to because I don't submit when I mess with it. It was wrong to ask them not to submit.
  • For them it was a valid thing to do, and a reward.
  • I would have learned what people think of the page they get after submitting
  • It would have served to let them see what the app does
  • We would have captured preferences on the task, which is the idea.
  • They would have become more engaged and invested
  • They might have been less resistant to trying what-if scenarios after submitting their true choice.
• The buttons on the paper prototype were not helpful. This is possibly because I had let them try the working interface first.
• One had the expectation that the up arrow moved the item to the top. Another that the up arrow with the bar moved the item to the top.
• One said, too many buttons. I like the simple one where you just poke the items.

The experiment was enough to show that the arrow buttons might not be an improvement. And also provided validation for the existing interface. It's possible that other button designs might help. Here are some ideas:

It's a little strange and awkward to try a paper prototype after trying a working system. People want to interact with the paper as if it is paper, not a simulation. Of course, the way they try to interact with paper does provide some clues. I got two for one, validation of the existing interface and indication that this proposed change wouldn't be an improvement.