Power vs Usability: The Never Ending War

Sometimes there exists a disconnect between usability and power, and visions of flawless code design don’t bode well for actual human interaction.  I talked a bit about this concept in my article, “We all want to be normal[ized].”  The idea in this article was that KitchenPC is predicated on the concept of ingredient normalization.  Rather than each recipe containing its own ingredient data, recipes point to a finite set of available ingredients.  These two approaches are at war with each other, as both cannot be achieved simultaneously, and each has its own strengths and weaknesses.  Ingredient normalization has some incredibly powerful advantages, for example the ability to accurately represent relationships between recipes that use a common ingredient.  It’s this ability that KitchenPC takes advantage of to deliver features such as ingredient aggregation and conversions across forms.  It’s this ability that makes possible ingredient blacklisting, trend analysis on favorite ingredients, and recipe modeling.  However, this design comes at a huge disadvantage in terms of usability.

A database design that allowed users to enter any ingredient they want (as most recipe websites employ) would allow for incredibly simple recipe entry; simply type stuff.  We could even have a simple auto-complete mechanism that would guess what the user is typing, but not limit the user to a set of finite choices.  Not limiting the user to a certain form of ingredient (such as cheese must always be in weight, shredded, melted, or diced) adds the flexibility required to easily import recipes from other sources, such as many of the popular recipe aggregators out there that simply link to other recipe websites.

Until recently, I’ve been fine with my “power over usability” approach, since to my knowledge no one has really done this before and I wanted to try to do it right and gain some competitive advantages.  Plus, the entire business plan depends on this approach, and changing it would basically send me back to the early stages of the drawing board.

As of lately, my mind has been hijacked by Polish designers pressing me on usability issues and thus liberating the right side of my brain to stand up for the people.  It’s become apparent that I might have to step up and be the long-awaited “coding diplomat” and attempt to divise a strategy that can offer a middle ground between these two waring factions.

Right now, I can think of three possible avenues to explore.

The Do Nothing Approach

Ooo, I like the sound of that.  Doing nothing is easy, and makes me want to go take a nap.  Or perhaps go watch “Burn Notice.”  The idea here is that my design is fine the way it is, and though it can cause headaches in the short term, eventually the data necessary will exist and problems will be rare.  After, say, ten thousand recipes are entered and missing ingredients or forms are noticed and corrected, the idea of a custom ingredient or form would almost be completely unnecessary.  After all, a very small percentage of users even ever enter a recipe on a recipe website, so this feature should take a back seat to the potential awesomeness of the rest of the site.

Furthermore, these headaches are expected during a beta period of any product, and early adopters are used to running into a few hassles here and there.  I fully expected to spend a lot of time entering in recipes, and am even considering outsourcing this data entry to anyone who could use the work.  Part of this effort will result in the completion of a deadly accurate and finely tuned ingredient database that will address the needs of 99.9% of users entering recipes in the future.

The “Oh, Did We Mess Up?” Approach

This approach requires doing the minimal work to feign interest in the user’s dilemma, but not really solving their problem.  One implementation of this approach would be to put a small link in the ingredient picker that says “Cannot find an ingredient?  Click here”.  The link would result in some sort of reporting form the user could fill out to let us know that something is missing.  After submitting the form, the user would be promised the ingredient would be added to the database within 24 hours.  I’d have a team of some sort of trained circus monkeys responding to these reports around the clock (ok, it would probably be me doing that.)

This approach is a bit more friendly, and acknowledges that our database is not perfect and we are striving to fix that.  It’s a bit of a turn-off to the user as they may have entered half a recipe and now have to wait a day to complete their work, most likely having to start all over again at that point.  However, the details in implementing such a system are minimal and don’t affect any existing architecture.

The Hybrid Database Approach

This approach truly admits defeat by requiring me to rip apart half my database schema and invent the concept of a custom ingredient.  Since data integrity is crucial to my database design (and one of the strengths of PostgreSQL at that), the idea of a recipe ingredient usage that doesn’t point to an ingredient entity makes me cringe.  Being able to represent an ingredient usage against a non-existant ingredient would be hacky at best, and the very need for this design means admitting the impossibility of an accurate ingredient database, ever.  However, it’s an option to consider as it potentially could result in an awesome usability experience.  One approach is to link such recipe ingredient usages to a “Custom” ingredient entity that would be in the database, but hidden from any UI.  The ingredient usage row in the database would contain an optional field for the custom ingredient name as entered by the user.  When a recipe is displayed with this ingredient usage, the code would be special cased to display the user entered ingredient name.

With this approach, I would have the ability to filter for recipes that point to this special custom ingredient entity, fix my database, and then re-link the recipe to the newly entered “real” ingredient.  This would happen seamlessly within 24 hours, potentially by said circus simians, and during that time, certain aggregation features wouldn’t be available with these recipes.

This approach has a major implementation cost, especially so late in the game, and a big test cost as well.

So, Which One?

Hmmm, I’ll have to get back to you on that.  And here you were thinking I had all the answers!  I’ve been thinking the “Do Nothing” idea is less and less of an option, however I’m not quite sure if I’m ready to start on a major database re-architecture until I really understand the nature of how the product is used.  One idea is to hold off a bit on this, until the private beta stage.  We can see how common missing ingredients are, and how users respond to various levels of frustration related to these limitations.  The idea of this level of re-design is also scary during a beta period, since the idea of beta is usually “Ok I think I have this working, now you guys test it”, so part of me is tempted to just get this redesign out of the way now and not have to worry about it again.

I apologize for this blog post resembling more of a brain dump than any actionable items or finalized opinion, but it’s something I’ve been thinking about all week so thought it best to get it out there and potentially hear from other people who might have faced similar challenges.