Wheels go round and round

One of the major UI hurdles I’ve been trying to overcome (and, by far, the number one complaint I’ve received from alpha testers and recipe enterers) has been the inefficiency of entering recipe ingredients.  The ability to enter custom ingredients and forms was a major stepping stone to overcoming said hurdle, but the fact remains that the cumbersome UI to select an ingredient, choose a form, type in a number, then select an available unit for that ingredient is just too clunky to deal with.  One of my data entry people up and quit the other day because she just wasn’t getting paid enough to deal with this nonsense.  I don’t blame her.  The fact she did this, in terms of product feedback, was probably more valuable than the recipes she would have entered, as it finally convinced me this was a problem I had to deal with.  I took this as a message; “Mike – you can’t even pay people to use your product!”

While talking with a friend of mine over Skype and doing some screen sharing, I took down notes as I watched her struggle with the recipe entering process as a first time user.  Though finding an ingredient is super easy (I wrote a very slick auto-complete drop-down for this), the issue became clear that KitchenPC needs an easier way to express ingredient amounts.  Dealing with dropdowns, multiple text boxes, etc is just a deal-breaker.  After giving it some though, I decided I was dealing with this UI paradigm completely backwards.  Once an ingredient is selected, the first step is to choose a form.  For example, when working with cheddar cheese, the form dropdown contains “By Weight”, “By Slice”, “shredded” and “diced”.  Once the user selects a form, the unit dropdown is populated with units acceptable to that form.  If the user chooses “By Weight”, weight units such as ounces and pounds appear.  If the user selects a volumetric form such as “shredded” or “diced”, units such as cup and tablespoon appear.  Since “Slice” is a unit itself, the user can only enter a numeric value when this form is selected and the unit drop-down is disabled.

The seems reasonable at first, but it has a fundamental flaw; the interface flow is completely contradictory (in fact, entirely inverted) to the standard human thought process.  A user will typically think of an ingredient usage using a common mental template, in this case an amount, a unit, and possibly a form that makes sense to that unit.  My existing user interface asks them to navigate this thought process backwards, starting at the end.  This results in the user wrangling the UI into representing their desired usage.  The user knows the amount, however they have to select a form before they are even allowed to enter an amount.  They know their desired unit, however now they have to go dig through all the forms to find one that permits that unit type.  Since form names can be less than entirely descriptive, in some cases it might not be clear which unit type a certain form might allow.  Not to mention, doing all this requires the use of a form dropdown, a numeric input box, and a unit dropdown.  Novice users will navigate this UI by using the mouse which means:

1. Grab mouse, click the forms dropdown, select a form.
2. Click on Amount text box.  Move hands back to keyboard.
3. Type in an amount.
4. Grab mouse, click on the unit dropdown, select a unit.

A more advanced user is aware of the tab button to navigate web pages.  However, most are not aware of the keyboard shortcuts when dealing with a dropdown list.  Firefox is, of course, superior to IE in this respect as the up and down keys will intuitively open the list.  However, most users will still be tabbing, mousing, and typing all over the place.

If the unit type they want is not available for the form they “guessed”, the user gets frustrated and yells at the screen.  If they haven’t given up by that point, they might mess around with the forms (a concept that really doesn’t make any sense to the average user in the first place) trying to find one that allows their desired unit.

This is crap.

A user interface that mimics how humans actually think would start with the amount.  Regardless of the unit or form, I always need an amount right?  So why not start with this.  The second thought would be the unit type.  Once an amount and unit type have been determined, the user interface should be smart enough to ask for a form if and only if the provided information is ambiguous with multiple form types (rare in most ingredients).  For example, “4 slices” and “2 pounds” is a perfectly acceptable usage for cheese.  When expressed in this way, the form can be ascertained automatically.  If the user says “slices”, they mean the “By Slice” form.  If they say “pounds” they mean the “By Weight” form.  However, if the user enters “4 cups”, this expression presents ambiguity between the “shredded” and “diced” form types.  Only in this case should the user even be bothered to worry about the form of the ingredient, and they should only be bothered with this if and when the information is needed.

The paradigm can be thought of as an inverted tree, slowly narrowing down choices until an acceptable ingredient usage is obtained.  The user is only pestered when more information is needed.  I developed a set of rules to follow when designing this new UI:

1. Don’t bother the user, just let them type.  Don’t change anything automatically or confine them to only being able to type certain things.
2. It should be possible to enter an ingredient usage in a single textbox.  Users should not have to tab around.
3. Help should be provided passively, to “steer” the user along as they type.

The third rule is one I really like, especially this concept of steering the user into describing a valid ingredient usage through natural language.  I thought of a steering wheel, and decided the UI should have a rounded “spinny” feel, like a wheel.  As the user types, a wheel of choices should pop up and rotate as the user nears a valid choice.  Unlike a dropdown, the wheel can describe a set of choices for a certain phrase, such as the unit name or form name.  Imagine something like this:

1. User types in “1 1/2” and presses space to type in a unit.
2. A wheel of units available (across all forms) appears.
3. When the user types “tabl” the wheel spins around to “tablespoons” but does not auto-complete for them (rule #1)
4. The user can optionally press ENTER and the rest of the word is filled out for them.
5. At this point, “1 1/2 Tablespoons” is entered, however this measurement is ambiguous.  Thus, a new wheel pops up with forms that allow volumetric measurements.
6. The user sees the wheel with “diced” and “shredded” and is allowed to type one or select one with the up/down keys.
7. When a form is selected, the usage can now be parsed in KitchenPC “meta” language and stored in the database, thus a nice green checkmark is displayed to indicate KitchenPC likes their entry.

I like this UI because it’s a single textbox and allows the user to express any ingredient usage across any form without taking their hands off the keyboard.  In fact, many times the amount can just be pasted into the textbox, especially since I can parse aliases of unit types (such as “1 oz”, “2 c”, “3 lbs”, etc) and map them to the correct unit type internally.  It also fits in with my existing custom form ability.  If what the user types cannot be parsed, the amount will be used as a custom form and be queued for manual processing.

They say a picture is worth 1,000 words, but I’ve decided to go a step further and attach a video of tonight’s prototype.  I’m hoping this technology can be integrated into the main KitchenPC UI fairly easily and make it into the initial public beta.  I think it’s a huge step forward in usability, and perhaps will lessen the number of my users who yell curse words at the screen.  At the very least, it’s a start.