Power vs Usability: Part II

As a follow-up to my recent post titled “Power vs Usability: The Never Ending War“, I thought I’d write a bit about the changes that I’ve implemented recently to address the issues discussed.  It’s fairly easy to agree that the “Do Nothing Approach” just won’t cut it.  There will of course be missing ingredients, and there will of course be users inconvenienced by this fact.  I can’t expect these users to happily report these problems, as they’re more likely to just close their browsers.  In the Dot-Com-Startup world, you really have one chance to wow your customer and keep them coming back for more, and a user who types in half a recipe and then can’t find “plum marmelade” will not be wowed (except for “wow, this sucks”) and will definitely not be coming back for more.

The “Oh, Did We Mess Up?” approach is not all that much better.  As mentioned, it doesn’t actually solve the user’s problem, it simply presents a bug-reporting form that turns users into testers, and assumes they have some sort of active interest in making my site better.  It still presents the deal-breaker scenario where a user enters half a recipe and cannot save it.  It’s this scenario that I’ve determined is the critical issue to resolve.

Redesigning my database to allow recipes to reference non-existant ingredients or ingredient forms was also a design change that I found highly discouraging.  It’s a lot of code and a lot of design changes that target a hopefully seldom used scenario, and these changes ripple through most of the product (shopping lists, meal planning, displaying data throughout the site, etc.)  The approach I found best was one that was isolated to recipe entry and had little or no changes anywhere else within the product, which meant no database changes.

Over the past three days, I’ve implemented a design that I feel acknowledges the root pain point while not warranting a major design overhaul for the entire site.  This solution allows for recipe entry using custom ingredients or custom forms, however stores these recipes in “limbo” until the database can be updated to represent them correctly.  The user can enter their recipe as they see fit, however a process will take place on the backend to manually approve this recipe before it will actually exist in the database.  The process goes something like this:

1. User enters a recipe requiring “plum marmelade”, which does not exist in the database.
2. When typing in this ingredient, KitchenPC will see no exact matches exist and display an option at the bottom of the dropdown titled “Custom: plum marmelade”.
3. The user selects this, and the rest of the ingredient input switches to a freeform mode, where the user can type in any amount and any unit.
4. When the user is finished with their recipe entry, they click Save.
5. On the backend, KitchenPC detects the custom ingredient usage and aborts the normal saving code path.  Instead, the Recipe object is serialized and added to the “PendingRecipes” table.  A message is displayed to the user to indicate this.
6. Later on, this “pending recipe” will be processed through human intervention.  Either “plum marmelade” will be added to the ingredients table and the recipe will be linked to the newly created ingredient, or if the ingredient indeed existed and the user was in error, the recipe will be corrected.  After the links are fixed up, the recipe will be published as normal under the user’s context.

The mechanism also allows the modification of an existing recipe to use a custom ingredient in the same way.  The altered recipe will be serialized with its existing recipe id, and added to the pending recipe queue.

In the case of a missing form of an existing ingredient (for example, say “goat cheese” was missing the “by slice” form), the user can now choose a “Custom” option in the forms dropdown and type any amount they’d like.  When this happens, the recipe once again goes through the pending recipe queue before being published.

This overall approach has a few advantages.  First and foremost, the user is not prevented from entering their recipe.  The fact that the recipe will not appear right away simply acts as a deterrent for users to use custom ingredients or forms where it’s not actually necessary.  In fact, the UI for using custom ingredients was purposely made harder to use.  There is no shortcut key for selecting a custom ingredient, the user must tab to it or select it with the mouse.  This is in contrast to existing ingredients, which have numbered shortcut keys.

The second advantage is this defines a workflow for reporting missing ingredients and improving the database.  The user doesn’t have to click on a special button to “report a missing ingredient”, they simply use the ingredient in their recipe and the database will be improved as a result.  There may come a time where custom ingredients and forms are a thing of the past and the database has pretty much any consumable food product known to man, but for now, this provides a viable approach for dealing with missing data.

I don’t yet have any backend tools for easily dealing with the pending recipes, however I imagine this is something I’ll be able to get to before beta.  This might be a web based “admin” tool that only I have access to, or even a simple command line tool that can be run on any machine with access to the database.

I’m pretty happy with the solution and am glad I took the time to really deal with this problem from the user’s point of view.  I think the site will be overall better for it, and it just goes to show that it doesn’t matter how perfect your architecture is; if you annoy the user, they’ll be going elsewhere.