KISS me…

I ran across an interesting UI problem the other day, one which made me have to stop and think for a bit rather than rushing in to code (as most programmers are all too eager to do.)  An important paradigm within KitchenPC is the organizational relationship between a shopping list (representing what a user needs to purchase) and a pantry (what the user has available.)  However, keeping these two lists in sync is somewhat of a challenge.  Imaging a user adds a recipe calling for 5 eggs to their shopping list.  Normally, said user would expect to see a list created listing 5 eggs.  However, if the user’s pantry had 3 eggs, only 2 eggs need be purchased.  Should we take the user’s pantry into account when creating a shopping list, and only add 2 eggs to the list?

This was a direction I was pondering.

However, after considering the importance of understanding the varying discipline levels of users, I decided this approach could end up horrendously bad.  Not only does this make an assumption about the validity of the user’s pantry, attributing a sense of narcissism to my software (of course every user will slave away all day creating accurate pantries!) but also makes an assumption about the user’s desired way of working.  After reading my earlier post about Microsoft Project, one may have a more well defined appreciation of this concept.

Ok, let’s make our first decisions about what not to do.  We will not assume the user’s pantry is accurate or that the user wants to deduct inventory from their pantry when creating a shopping list.  We do not want seemingly random results to appear on the shopping list with no indication that KitchenPC was just “being smart” and utilizing your so-called inventory.  However, we are meal planning software and designed to manage inventory, suggest meals that are possible to create with your inventory, and attempt to provide accurate information on what you need to acquire to make your meal plan possible.  Thus, there needs to be a feature set that makes possible the scenario of comparing a set of recipes to what you have, and ascertaining what you need.

One solution I considered was to make this behavior optional.  When you add a recipe to your shopping list that contains 5 eggs and your pantry contains 2, the UI could present the user with a choice: “Hey user, your pantry contains 2 eggs and this recipe calls for 5.  Do you wish to subtract the 2 eggs from your pantry and add the remaining 3 eggs to your shopping list?”  This has the following problems:

1. It’s annoying.  If I click on a button I want stuff to happen.  If anything pops up, studies suggest no one actually reads it and they’ll just assume it’s an error case.  If there’s a Yes button, they’ll immediately click on it just hoping it’ll do the thing they wanted to get done in the first place.
2. It doesn’t scale.  If I add a recipe with 50 ingredients, I don’t want this massive UI to settle “conflicts” between my pantry and shopping list.
3. It doesn’t adapt to all UI paradigms.  Adding a single recipe to a shopping list through a toolbar might be okay, but dragging recipes onto the shopping list should be seamless, not spawn questions for the user to answer.
4. It assumes a finality of decision.  I shall explain this.

Point #4 is the one that led me to rethink my logic.  Dragging meals onto a calendar, creating shopping lists, removing items from the shopping list, etc, are all what I consider “draft actions.”  That is, they’re intermediary steps taken by the user during the process of assembling a final meal plan.  Imagine if I subtracted items from the user’s pantry for a certain recipe, then they removed said recipe from their shopping list or meal plan.  Do I “restock” their pantry with the items I took away?  Oh boy, this could get confusing real fast!  In actuality, doing anything at all was premature at this stage.  This made me realize that I was missing a dirt simple solution that solved all the problems above.  Let the user tell me when to “balance” the shopping list and pantry.

The implementation that, in the end, made the most sense to me is a single button on the shopping list widget.  Clicking on this button subtracts any amounts from the pantry from the shopping list.  If the shopping list contained 5 eggs and the pantry contained 3, the eggs would be removed from the pantry and the shopping list would be updated to 2.  If the shopping list contained 1 apple and the pantry contained 3, the apple would be removed from the shopping list and the pantry would be updated to contain 2.  This has the following advantages:

1. It’s optional.  If the user doesn’t like or use the pantry, they need never click this button.  A user who never discovers this button would not be inconvenienced by an assumption made about the way the user uses the product.
2. It’s intended to be used as a final step.  The user can meal plan all day long, or all week and not mess with this button.  When the user is about to head to the store, only then will they click this button.  They can even go through their pantry first and make sure everything’s up to date.
3. It explains exactly what’s going on.  The button, once clicked, would explain to the user exactly what it’s doing.  Since the action is not linked to an unrelated feature (such as adding a recipe to a shopping list), assumptions are not made about any popup alert that appears.  A user clicking on this button either has no idea what it will do and will tread carefully, or they will be aware of the feature and know how to use it.

In my mind, this is a prime example of KISS.  Keep It Simple Stupid.  Trying to make the system too smart, or “merge” features in with other features, often just leads to confusion, or bad assumptions about the scenarios those features are based on.  An advanced feature such as “pantry balancing” (no, I’m not attached to that name) is one that should exist on its own and not try to “pop up” when it wasn’t invited.

Mike