Skip to content

No one wants to be a little old lady

February 26, 2011

KitchenPC attempts to construct the perfect shopping list by taking into account the various forms an ingredient may be used across multiple recipes and converting those amounts into the form said ingredient would usually be purchased in at a grocery store.  This works fairly well in theory, as your shopping list will say “all-purpose flour: 9oz” and as you browse the baking aisle at the store, all the various bags of flour will indicate their size in ounces.  If the shopping list expressed flour in cups, you’d really have no idea how much flour you need and just buy a large bag just in case.  This problem would be compounded if you were cooking large portions of recipes and needed like 465 cups or something.

The flour example “sells” nicely because almost every recipe uses flour in a volumetric form and almost every flour brand sells flour by weight.  Actually, pretty much everything that isn’t a liquid is sold in weight as the volume can shift and settle during transit.  However, it became clear that every ingredient in the database isn’t so cut and dry.  For example, tomatoes are also sold by weight and will be weighed by the cashier at checkout.  Your grocery store doesn’t really care if you buy a bunch of small tomatoes or a few large tomatoes, the total weight is what will be ringed up.  A KitchenPC user, however, might not like shopping for “13.5oz of tomatoes” though.  Imagine a scenario where a user adds a recipe that calls for 3 tomatoes, and another recipe that calls for 2 tomatoes.  What they would probably enjoy seeing on their shopping list is “tomatoes: 5”.  With the current implementation, what they’ll instead see is “tomatoes: 22oz” – Well great, now they have to either guess how many tomatoes that is, or use those hanging scales at the grocery store like some little old lady.  Ok, to be honest I’ve never actually witnessed anyone using those scales but I imagine they’re only used by little old ladies who are also the same ones holding up the line with eight million coupons to give to the cashier.

That’s no good.

The solution?  Well, this sounds like another opportunity to use my new and improved (actually just improved) form conversion engine that went online a few days ago.  This code gives me the opportunity to convert pretty much anything in the database to anything else I want.  Two modifications were made to the shopping list.

Tooltip for an ingredient in the shopping list widget

First, when you hover over an ingredient in your shopping list, KitchenPC attempts to express it in other helpful ways.  For example, if the ingredient is expressed in weight and there’s a default volumetric form available, it will show that conversion in the tooltip.  If the ingredient is expressed in whole units (such as bananas,) KitchenPC will show the actual weight of bananas you require.  This would hopefully prevent someone from not buying enough bananas for recipes that call for “mashed bananas” because the bananas they bought were all too small.

Second, the printed version of the shopping list has a new column for these estimates as well.  Hopefully, this will make reading the printed shopping list at the store much easier.

I actually would like to go a step further with this design to make it even more powerful.  One feature I have in mind is a rich “hover-over” panel that pops up when you move the mouse over an ingredient anywhere on the site, similar to hovering over someone’s name on Facebook.  This panel would show convenient equivalent amount information, as well as a picture of the ingredient (pulled in from Google’s Image Search API) and quick links to find other recipes that use that ingredient.

Printed shopping list

Another improvement this new code allows me to do is start to cater the unit types in the shopping list to really target what the user wants rather than cater to programmatic limitations.  The real reason that ingredients such as “red tomatoes” are listed in weight by default is the system was designed to eventually integrate in with online vendors.  The shopping list schema needed weight information because that’s what a third party vendor would require within the order information.  This technical requirement is now less than necessary as weight conversions can be done on the fly.  In theory, I can connect to a third party vendor and “order” tomatoes in either weight, or whole tomatoes; whatever the vendor accepts.  For this reason, I plan on actually changing many of the KitchenPC fruits and vegetables over to whole units when appropriate.

These new features are now live on the website for those who want to check them out, but keep in mind a lot of the database metadata isn’t really “optimized” yet to really take advantage of this ability, so some ingredients will be a bit off or not display estimated amounts.  Hopefully, one of these days I’ll get the chance to go fix up the database; or at least the more common ingredients.



From → Business

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: