The White Whale of Usability

Over the past couple weeks, I’ve been working hard on usability improvements for the new version of the site.  This effort has been mainly spurred by my recent testing on UserTesting.com, however I also took the opportunity to throw in a few extra bells and whistles inspired by what I had learned.

I figured I’d write a quick post on a few of the changes I made, and why I believe these relatively minor changes will make a huge difference in the next round of testing.

Quit Trying to be Fancy with Non-Standard UI

One of the great things you can do with KitchenPC search results is check off multiple results and save them as menus.  This feature is  unique to KitchenPC (as far as a I know,) as most search engines just display your search results and say, “good luck” from there.  I wanted to make these check boxes big and bold and easy to click on.  For this reason, I used huge check mark graphics that would change color as they were clicked.  Huge mistake.  Pretty much no user even noticed them since they did not look like the typical HTML checkbox people are used to.

Original Prototype

Standard HTML checkboxes

Not as pretty, but the average user will be more likely to notice they can check on results.  I also now include a text blurb above the results mentioning that you can check individual recipes to add them to a menu.

Give Users a Place to Click On

One thing I learned is users love their mice.  If you give them a text box, but nothing to click on when they’re done typing, they usually click outside the text box to indicate they’re done.  Almost no one will press Enter, or try to tab away.  This caused huge issues with my search interface, which efforts to find recipes as you enter data, rather than making you click a “Search” button when you’re done.  I decided to stick with the real time result updating, since I believe people will catch on after using the site for a few minutes, but I added buttons to click on near each text input field to provide the illusion of submitting data.

Original Search UI

Improved Search UI - Now with Buttons!

There are a few aspects of this interface worth pointing out.

1. On the original UI, users would often enter text into the Quick Search and then grab the mouse and click on one of the meal icons below, wanting desperately for that to be some sort of Submit action.  This would work okay in certain cases, but cause all sorts of frustration when the user then changed their query and wanted to re-submit.  The new UI has a “Go” button to the right of the text box.  Clicking “Go” or pressing Enter will update the results.  Just for kicks, users can also click on a meal icon to update the results, even if that meal icon is already selected.
2. Both the Ingredient Include and Ingredient Exclude lists also now have a “+” icon to add input.  Another huge change made here is I completely got rid of the auto-complete mechanism and now parse input through the natural language parsing engine instead.  The number of usability issues auto-complete caused was absolutely mind-boggling.  Users would refuse to select an item from the list, or just click on something else on the screen when they were done.  Without the auto-complete, it’s a little more typing now, but it’s quite obvious how the interface works.

Huh?  Why Do I Need to Rate That Recipe?

New wording for de-queue dialog

The Queue allows users to queue up recipes that they’re interested in without having to formally organize these recipes into menus.  When you de-queue a recipe, it’s assumed that you probably made it and KitchenPC takes this opportunity to ask what you thought of it.  This was an attempt to counter the fact that only around 2% of KitchenPC users would ever rate a recipe, since the site can do all sorts of nifty things when it has ratings.

It turned out this assumption was bad, and asking users to rate recipes on de-queue was confusing.  Rather than completely doing away with this concept, I attempted to re-word the de-queue dialog to be a bit more clear about what was going on.

Did Clicking On That Do Anything?

One other common issue that came up was with users adding recipes to a menu, especially when they were creating new menus.  When the user would click on “Add To Menu“, then create a new button and click “Ok“, a popup would show, “New Menu Created!”  Many users were unclear that the recipe was also added to their newly created menu, so they would try adding it again.  It also didn’t help that the recipe viewer doesn’t indicate whether a recipe is added to any menus.  I decided to address both issues.  First, the popup tip will now say, “This recipe has been added to a new menu.”  Second, the recipe viewer itself now shows a count of how many menus the recipe appears in.  When a recipe is added to a menu, this count updates instantly (using a cute animation of course) which provides further feedback that the action indeed did something.

Tell Me When I Mess Up!

The problem with text input boxes is it’s very hard to control exactly what the user types in.  If this is just a keyword search, this might not matter.  If it’s someone’s name or address, this might not matter.  However, if it’s an instruction for the server to parse and take action upon, it’s critical that user input is gathered in an expected format.  Search parameters such as “Ingredients to include or exclude” as well as the “I have…” text box suffer from this problem.

During testing, a lot of users would enter invalid input in the Ingredient to Include text box.  For example, “12 eggs” or even “bananas, eggs, pears“.  Since this text box was ruled over by an evil auto-complete system (which would basically ignore you when you messed up,) understanding what was expected was near impossible.  Using natural language parsing for each of these inputs is a great step forward (provided my NLP engine actually works well,) but I also decided the user needs more feedback when they enter something that isn’t understood.

Error message if input cannot be parsed

I decided to return an error when an ingredient or ingredient usage could not be parsed, even if it might frustrate users at first.  I do log invalid input, so I can keep an eye on what users are typing in and improve the database over time.  I also now greet them with a friendly error message that offers to take users to a help page or perhaps a video demonstration on how the feature works.  I also changed a lot of the verbiage on the site to make it more clear that ingredients need to be entered one at a time.

Small Fixes go a Long Way

Most of the other changes to the site were minor changes of wording.  The Queue page now includes a full description of what the Queue actually is.  The Menus page now includes instructions, and tells users they can drag recipes between menus.  I’ve also included several new tooltips, and changed the wording of several popups to be more clear and address specific issues that I’ve seen users have.

I also took the opportunity to change the behavior of a couple of site features:

1. The Popup Recipe viewer will now “tag along” as you scroll the page up and down.  This will hopefully prevent the recipe viewer from getting lost if the user scrolls back up to the top of the page without first closing the viewer.  This happened to at least 2 or 3 people during testing, though they did realize their mistake after a few seconds.
2. Sort can now only be done in one direction.  Allowing users to flip the sort order between ascending and descending sort order only complicates the UI, and provides almost no benefit.  After all, why would anyone want to sort “Cook Time” by maximum time first, or see the lowest rated recipes at the top of the list?  This allows me to grey out the currently selected sort order, making it a lot more clear what’s going on.  I also now show the “Total Time” on each line to be consistent with the fact you can sort by total time.

The next step will be to do yet another usability study with ten more users.  I’m confident that the next round will show a massive improvement, but I’m also nervous that I’ll simply uncover a huge list of even more major issues that need to be corrected.  I’m sure I could go on forever, hunting for that perfect user interface like Captain Ahab hunting his white whale.  With any luck, the next set of usability results will instill me with the confidence I need to declare this UI go for launch, and I can start working on building site content.  Fingers crossed!