Results of Group Design Project on Rating Three Candy Bars

Last week I proposed a little design challenge: design a small part of an interface which allowed a user to rate three candy bars in order of how much they liked them. Quite a few folks took a stab at it. I’d like to round up what I feel were the best entries for discussion and then pick the “winners” (and remember, this is just me picking my favorites, not necessarily what would absolutely work the best in every app in the world).

The very first entry by Jesse Shawl was just three dropdown menus:

I’m glad Jesse posted this because it highlights an important aspect of this challenge. The design is very simple, which is good (although I’d work on the spacing to make it more clear what goes with what). But it allows a user to make a mistake. The user can rate each candy bar, but that user can choose the same rating for each candy bar, which doesn’t solve the problem of rating them in order.

Also utilizing dropdown menus is an entry by Moritz:

View

At first only one dropdown is shown, with all three choices. After you choose from the original dropdown, a second dropdown is shown with only the remaining two candy bar choices, and lastly a third dropdown with the final choice. I’d critique that the last choice isn’t needed, but it does complete the flow.

---

An entry by David Booth is clever in that it uses the candy bar itself as a bar chart to reflect its current rating.

Unfortunately it falls victim to the same problem as Jesse’s solution in that a user could rate two or more candy bars the same rating. It also doesn’t utilize any known web affordances. Yes, it says “Click a candy bar”, but that’s a rather unusual request that isn’t intuitive. Also a bit strange how it requires 5 clicks to go through a cycle when there are only 3 possible ratings.

---

Nate was the first to try out a drag-and-drop interface.

This solves the problem of each candy bar having a unique rating. In other words, it’s not possible to have the candy bars in an invalid rating order state.

There are similar drag and drop solutions Martin Blackburn, Josh, stursby, Kyle Sevenoaks, Remco Hendriksen, Óscar Mario Víquez, Michael Crawford, and Kirby. Cooper also did a drag and drop technique, which has the neat feature that a notification message pops up quickly summarizing the change.

Another by Todd Wolfson who also attempted a variation: select-and-drop. Zach Smith created “wells” for which the candy bar icons can be dropped, with an “X” option to move them back out in case you make a mistake. Daniel again with the wells.

A word on drag and drop

Drag and drop has been around in computer operating systems for a long time. Users know how to do it and feel comfortable doing it. But drag and drop is far newer on the web. It’s not all that common and (I don’t have any data, but I would wager) that many users don’t even think to try it on the web.

But darn if drag and drop isn’t useful! Particular in cases like this. I’ll put forth that if we choose to implement it, we should do all we can to tell the user what we expect of them. Some options:

1. The mouse cursor should be set to “move”:

   .move {
      cursor: move;
   }

2. Text explaining what to do (e.g. “to change the order of the candy bar ratings, drag the one you wish to move to the number you wish it to be.”).
3. The design should scream “drag and drop”. Perhaps a little handle by which to drag them and a dotted-line “well” for which to drop them.
4. Have an alternative interaction besides drag and drop that can accomplish the same goal (if more cumbersome). This is particularly important for mobile, since there is no mouse. It’s possible for a tap-drag-tap thing to work, but it’s certainly not an established pattern.

In Wufoo, in the Form Builder, we offer drag and drop to add new fields to your form and rearrange the current ones. We explain it via text and show the correct cursor. But everything that can be done via drag and drop can be done just through clicking as well. It’s more cumbersome in that all new fields go to the bottom and you need to click over and over to position how you want it, but it’s possible. Drag and drop just makes things easier if a user bothers to try and learn it.

---

A similar UI to drag-and-drop, but allowing for clicking instead was done by Rafał Krupiński.

Rolling over the second or third candy bar reveals an arrow, which when clicked, moves that candy bar up one spot. Very simple. As a slight improvement I might suggest making the “move up” arrows even more obvious (so as not to require explanatory text) and visible at all times. (Alternative with text). Offering only an up arrow is also slightly weird in that it might not jive with a user’s own mental model. What if they think to themselves “Snickers, ewww!” and want to move it down. They can only do that by moving something else up, the opposite of what they are currently thinking.

---

prabhu.webdev tried out a voting system where there are up and down arrows for each candy bar which affect a numeric value.

It’s nice to see a totally different approach to the UI, but unfortunately this again doesn’t solve the problem that two candies could be rated the same. If this idea was extended to having a group decide which candy bar was best, this might be just the ticket.

Similar “voting” concept by Tauseef Jamadar.

---

Richard Bland tackled a number of the problems with drag and drop with this “winners block” idea:

This UI makes the concept of drag and drop a bit more intuitive since most users likely understand the concept of a winners block and that each contestant should occupy one tier. Unfortunately dragging each candy bar onto a block isn’t overly satisfying (it’s hard to tell if you “did it right”) and there is nothing preventing multiple candy bars from sitting on the same block, or deactivating unused blocks.

Richard updated it to utilize some “drop zones” and snapping behavior, which conceptually is a good idea but came out a bit buggy.

---

Raphael Lopes utilized drag and drop but in a unique way: by making the candy bars into vertical sliders.

This felt a little more natural to me than some of the other drag and drop solutions, but I wish there were more affordances going on, like the browser default UI of a slider, a move cursor, or some helpful text.

---

This one by Thomas Dybdahl Ahle I quite enjoyed because he brought some mathematics into it. This one requires the least number of actions to complete the task (2) by just offering two comparisons.

I wish that, visually, it didn’t look like it was going to be a three-step process. I think it would be nice if it literally told you it was going to be a two-step process. It would only show you the first comparison, then reveal the second comparison on completion of the first.

Similar click-to-vote idea by Zach Malone. More by Pablo Botta, William Blanchette, and IJas require three clicks to “finish”.

---

Damon combined the idea of voting with a bar graph:

Neat idea, but it is victim to the early problems we discussed like being able to vote the same candy bar the same rating and is a bit too complex, allowing 1-10 values rather than just rating in order.

---

Baylor Rae’ implemented something very similar to the “Radio Buttons with Two Way Exclusivity” idea:

View

I quite like the use of simple form elements. My biggest critique is that the two-way exclusivity feels like kind of a bummer as a single click can sometimes deactivate multiple previous selections if there are conflicts. An improvement would be to use value-swapping, which feels nicer as it deals with conflicts by swapping instead of deactivating.

Baylor also updated this technique. It falls back on the radio button grid, but when JavaScript is enabled, goes with the two-click ordering system.

---

Another version of the click-to-rank system is from Remi:

Two clicks to rank all three. It does rely on a hover effect (important to remember how mobile doesn’t really have hover). But that could probably be cleared up with some text.

---

This technique from Peeter combines stuff from a lot of the others. It looks like the radio button grid at a glance, but it’s more like a click-to-vote in practice, and the result looks like the bar graphs.

Peeter wasn’t the only one to implement UI that forced people to choose extremes like “Awful!” and “Delicious!”. I was more interested in simply ranking them rather than applying labels. With extreme labels like these, it might detract from a user filling it out at all, if they disagree with them. For instance, someone might really love all three but one slightly more than the others and one slightly less (LIKE ME).

---

This technique from Caio Dettmar used actual sliders:

View

Sliders are pretty established patterns but this has the same issue as many earlier in that you can slide two candy bars to the same value. Also why the editable input? The slider doesn’t seem to change when you change that value. Typically, a slider is used when the actual numeric value isn’t important (like it isn’t in this case).

---

The most imaginative and “out there” idea was by David Booth who created the “Candy Bar Sniper”:

It’s like the Winner Stand idea, but balloons float overhead carrying the candy bars. You click the balloon (popping it) and the candy bar falls into the trophy, rating it. If the goal is speed and practicality, of course this it out, but whatever, this is super clever and fun! Using an idea like this may just be a huge hit with users encouraging engagement and sharing. For instance, when creating a new Wufoo account, right after you are done with the forms and before you see the app screens for the first time you are taken to a screen that says “Assembling Wufoo Powers” where a series of abstract icons flash up in a row. This isn’t because the site needs time to create your account (it’s already done by that point), it’s because it is super fun and makes the experience of creating an account more special.

---

I wasn’t too concerned about the technology behind the design, but Richard came up with a clever way to rearrange the candy bars in order of preference using only CSS. The especially cool part is that it uses radio button inputs, so theoretically this could submit the data like a real form.

A similar mostly-CSS technique was done by mike, with just a touch of jQuery to prevent duplicates.

---

In an extreme attempt to reduce the number of clicks to solve the problem, this UI by David Herrera only requires one click:

View

Clearly not scalable (as David said himself) but it’s interesting to see the extremes.

Closing Thoughts

It was amazing to see all the ideas roll in. There was lots of interesting submissions. Sorry if anyone was missed here. A few I just couldn’t get to work or were just too far off-the-mark. If you are itching to view more, read through the whole comment thread.

This accomplished just what I had hoped: to highlight how many different ways even the simplest user interface mechanism can be done. Next time you need to design a bit of user interaction, think of this and how complex even the seemingly simplest things can be.

One surprise for me is that no single practical solution stood out as “clearly the best” in my mind. Perhaps that’s to be expected since we had so little context to work with.

“Winners”

Remember, not an indication of the best possible UI for any app, but these three I thought did an exceptional job.

• Baylor Rae’ – Simple click-to-rank with non-JavaScript fallback.
• David Booth – Candy Bar Sniper
• Richard – Mostly-CSS click-to-rearrange that was a real <form>

Congrats ya’ll – let’s do this again sometime.