Why is recipe software so hard to write?
November 29, 2006 7:32 AM Subscribe
Why is recipe software so hard to write?
We've had at least a couple of questions around here in the last few months from people looking for good quality software, be it an online service or actual code you install on your own computer: I need recipe software that doesn't suck!, Help me manage my recipes.
The real question seems to be this: given that this kind of software obviously has broad appeal (most people cook a little, right?) and great demand for a good piece of software, why hasn't any enterprising foodie/programmer gotten busy and made the software we all long for?
I only know some things about programming, but I can't for the life of me figure out why this kind of software is so difficult to write that few try it, and those who do produce unusable and/or ugly dreck. If you've got the technical scoop, or the business reasons I haven't seen, I'd love to hear them!
We've had at least a couple of questions around here in the last few months from people looking for good quality software, be it an online service or actual code you install on your own computer: I need recipe software that doesn't suck!, Help me manage my recipes.
The real question seems to be this: given that this kind of software obviously has broad appeal (most people cook a little, right?) and great demand for a good piece of software, why hasn't any enterprising foodie/programmer gotten busy and made the software we all long for?
I only know some things about programming, but I can't for the life of me figure out why this kind of software is so difficult to write that few try it, and those who do produce unusable and/or ugly dreck. If you've got the technical scoop, or the business reasons I haven't seen, I'd love to hear them!
It's a problem that looks simple at first sight, but in reality it is completely ill-defined. The same is true for content management systems in general. Nobody is ever happy with their blogging software, for example.
posted by dhoe at 8:06 AM on November 29, 2006 [1 favorite]
posted by dhoe at 8:06 AM on November 29, 2006 [1 favorite]
I've spent some time thinking about this problem since I've been wanting to use software to organize this kind of information. The technical barrier I've seen almost every one of these products come up against is that recipes are essentially only semi-structured information, but people who write software fail to realize this.
I've seen some fair attempts at decent recipe box software, but nearly all of them have fallen down simply because it's a tremendous pain in the ass to translate any given recipe into a simple database.
Not to mention that many of the more complex recipes don't fit well into the "list of ingredients, prep steps, cook, serve" formula. Often a recipe calls for partially preparing Subcombine A, working through part of Subcombine B, using some of the resulting ingredients to complete Subcombine A, and so on. Handling subcombines, sauces, and such requires recording the steps in a counterintuitive manner or lumping an entire dish into a single mega-recipe without subcombines.
On top of all that if you ask ten people to describe their idea of perfect recipe software you'll wind up with twelve different sets of conflicting requirements. The ideal software described in the "doesn't suck" thread above, for example, sounds absolutely horrible to me. I don't care about shopping lists, nutritional information, precise ingredient measurements or tracking what I've cooked in a week, but skimping on download, import, and parse plain text recipes would be a total deal-breaker for me!
As it stands, I keep all my recipes in Notational Velocity as short four or five sentence descriptions of how to make a dish.
posted by majick at 8:09 AM on November 29, 2006 [1 favorite]
I've seen some fair attempts at decent recipe box software, but nearly all of them have fallen down simply because it's a tremendous pain in the ass to translate any given recipe into a simple database.
Not to mention that many of the more complex recipes don't fit well into the "list of ingredients, prep steps, cook, serve" formula. Often a recipe calls for partially preparing Subcombine A, working through part of Subcombine B, using some of the resulting ingredients to complete Subcombine A, and so on. Handling subcombines, sauces, and such requires recording the steps in a counterintuitive manner or lumping an entire dish into a single mega-recipe without subcombines.
On top of all that if you ask ten people to describe their idea of perfect recipe software you'll wind up with twelve different sets of conflicting requirements. The ideal software described in the "doesn't suck" thread above, for example, sounds absolutely horrible to me. I don't care about shopping lists, nutritional information, precise ingredient measurements or tracking what I've cooked in a week, but skimping on download, import, and parse plain text recipes would be a total deal-breaker for me!
As it stands, I keep all my recipes in Notational Velocity as short four or five sentence descriptions of how to make a dish.
posted by majick at 8:09 AM on November 29, 2006 [1 favorite]
Speaking as a programmer, it's a fairly complex data model, with a possibly complex work flow for each item. Those aren't trivial to capture in software, especially when it's of limited use to the actual programmer. Now it may actually be more simple in the end, but you'd really need to know the process to simplify it. But you know, if you post some of your requirements here, some enterprise soul may help you out with that.
posted by blue_beetle at 8:09 AM on November 29, 2006
posted by blue_beetle at 8:09 AM on November 29, 2006
It's like that episode of the Simpsons where Homer was given carte blanche to build his perfect car. One person's ideal recipe program is another's abomination. Add to this the fact that a large component of a program like this would be the user interface, and the fact that amateur / hobby / "spare time"-types are absolutely atrocious at building good UIs.
posted by Rhomboid at 8:41 AM on November 29, 2006
posted by Rhomboid at 8:41 AM on November 29, 2006
I once read a book on writing recipes. It was a pretty good lesson in just how complex the task of defining what a recipe is is, and (more relevant here) the difficulty in codifying the parts.
Let's say I have a recipe that calls for garlic.
Is that a clove of garlic? And ounce of garlic? A teaspoon of garlic?
Okay - a clove.
Now is that a large clove or a small clove?
Okay - Small clove.
How is that defined? Is there a standard? No? Just anyone's guess? Okay.
So is it mashed, pressed, diced, sliced, whole?
You get the idea. Extrapolate that to thousands of ingredients. The coding task is huge. Seriously huge. The data model is deceptively hard.
But it doesn't stop there. I'm a programmer as well as a cook. And one of the big challenges for an application is getting a user interface that people will actually use. For the recipe application I need it to be searchable and filterable. Which means each piece of info needs to be entered separately. People hate that. They'd prefer to have two boxes to enter data. One for the ingredients, and one for the instructions. But that makes it useless for users searching for recipes.
And you need meta data as well. Recipes need tags, categories, cuisine type, cooking method, etc. More bother which would be easy for casual users to screw up if you don't have mini apps do walk them through it.
Bottomline - No one wants to spend 30 minutes entering a recipe they could write on a post-it note in 5. But without that level of data complexity the application isn't useful enough. Said another way - If you build it, no one will come.
posted by Bael'Gar at 8:46 AM on November 29, 2006 [1 favorite]
Let's say I have a recipe that calls for garlic.
Is that a clove of garlic? And ounce of garlic? A teaspoon of garlic?
Okay - a clove.
Now is that a large clove or a small clove?
Okay - Small clove.
How is that defined? Is there a standard? No? Just anyone's guess? Okay.
So is it mashed, pressed, diced, sliced, whole?
You get the idea. Extrapolate that to thousands of ingredients. The coding task is huge. Seriously huge. The data model is deceptively hard.
But it doesn't stop there. I'm a programmer as well as a cook. And one of the big challenges for an application is getting a user interface that people will actually use. For the recipe application I need it to be searchable and filterable. Which means each piece of info needs to be entered separately. People hate that. They'd prefer to have two boxes to enter data. One for the ingredients, and one for the instructions. But that makes it useless for users searching for recipes.
And you need meta data as well. Recipes need tags, categories, cuisine type, cooking method, etc. More bother which would be easy for casual users to screw up if you don't have mini apps do walk them through it.
Bottomline - No one wants to spend 30 minutes entering a recipe they could write on a post-it note in 5. But without that level of data complexity the application isn't useful enough. Said another way - If you build it, no one will come.
posted by Bael'Gar at 8:46 AM on November 29, 2006 [1 favorite]
I've always assumed it was because of a limited market. I love to cook. I like computers. I don't have a computer in my kitchen. If I have to print recipes and take them to the kitchen, I might as well just buy a book.
posted by dobbs at 9:54 AM on November 29, 2006
posted by dobbs at 9:54 AM on November 29, 2006
I suspect dobbs has a point. I would add that the market is limited also by the fact that there are so many recipes on line. I have a number of favorites that I just look up and print out whenever I can't find them.
The hurdles to writing a good program could be overcome if it were lucrative enough, but not enough people would actually buy expensive recipe software to make it worthwhile.
posted by TedW at 9:58 AM on November 29, 2006
The hurdles to writing a good program could be overcome if it were lucrative enough, but not enough people would actually buy expensive recipe software to make it worthwhile.
posted by TedW at 9:58 AM on November 29, 2006
I'll add to the chorus by saying that it's an issue of one piece of software never satisfying everyone, or even more than a few people.
I've thought about various programs (or about rolling my own using a lightweight database like FileMakerPro), but importing data is what gets to me. I'd want a program where I could scan in hundreds of paper recipe cards and then tag them, rather than typing each recipe in by hand. Since I really only ever look up recipes by title (e.g., 'I know I want "Hungarian Beef Goulash" now where is that f*#@ing recipe card?') the loss of searchability by more fine-grained criteria wouldn't bother me.
I think you're more likely to find recipe-managment products in more well-defined use cases, for example in commercial kitchens, or even particular types of commercial kitchens (e.g. bakeries, breweries) where you need to have all your recipes in particular units and scale them up and down, and there's a well-known workflow. Making software for that process is at least a tractable problem, where you can determine requirements and acceptance criteria and develop from there. Going after the home market would be a lot harder.
posted by Kadin2048 at 10:29 AM on November 29, 2006
I've thought about various programs (or about rolling my own using a lightweight database like FileMakerPro), but importing data is what gets to me. I'd want a program where I could scan in hundreds of paper recipe cards and then tag them, rather than typing each recipe in by hand. Since I really only ever look up recipes by title (e.g., 'I know I want "Hungarian Beef Goulash" now where is that f*#@ing recipe card?') the loss of searchability by more fine-grained criteria wouldn't bother me.
I think you're more likely to find recipe-managment products in more well-defined use cases, for example in commercial kitchens, or even particular types of commercial kitchens (e.g. bakeries, breweries) where you need to have all your recipes in particular units and scale them up and down, and there's a well-known workflow. Making software for that process is at least a tractable problem, where you can determine requirements and acceptance criteria and develop from there. Going after the home market would be a lot harder.
posted by Kadin2048 at 10:29 AM on November 29, 2006
Most recipe collections I have seen of any use are boxes of collected stuff. And I've always wondered why someone hasn't just set up a database that lets you scan that image in at a decent resolution and then let you put your own notes at the bottom in both a loose format ("mom's recipe for fritters!") and more detailed fields that you could easily adjust and add on to to accommodate for some strange but recurring actions or measurements. This thread elucidates why that is difficult. :)
For a non-programmer you could almost certainly put something together with FileMaker Pro that would do the basic things you want that worked exactly the way you set it up to work. (Which is what I ended up doing for a job search database when I I needed one to track jobs I sent out resumes for - which is nice when you want a uniform system to collect data from dozens of different types of job hunting sites that present that data in different ways on every site). Mind you, it wouldn't be complex. It would be a flat data structure, but I bet you could get it to work for you.
posted by smallerdemon at 11:42 AM on November 29, 2006
For a non-programmer you could almost certainly put something together with FileMaker Pro that would do the basic things you want that worked exactly the way you set it up to work. (Which is what I ended up doing for a job search database when I I needed one to track jobs I sent out resumes for - which is nice when you want a uniform system to collect data from dozens of different types of job hunting sites that present that data in different ways on every site). Mind you, it wouldn't be complex. It would be a flat data structure, but I bet you could get it to work for you.
posted by smallerdemon at 11:42 AM on November 29, 2006
I'm with you (I am the second question you linked to). I simply don't understand either. I am basic programmer but not good enough to write anything marketable. I wonder the exact same things you ask.
All we need is a itunes for information (rather than songs) with something smart enough to read ingredients etc. from highlighted web pages (for importing). Just like itunes has Genre, Artist, Album, I can easily see Cuisine, Main Ingredient, Meal as a way to browse. And on the left, playlists! (Connoisseur for macs does what I describe)
The one software that I can somewhat stomach (despite the 1995 interface) is BigOven but even that one really sucks.
posted by special-k at 1:28 PM on November 29, 2006
All we need is a itunes for information (rather than songs) with something smart enough to read ingredients etc. from highlighted web pages (for importing). Just like itunes has Genre, Artist, Album, I can easily see Cuisine, Main Ingredient, Meal as a way to browse. And on the left, playlists! (Connoisseur for macs does what I describe)
The one software that I can somewhat stomach (despite the 1995 interface) is BigOven but even that one really sucks.
posted by special-k at 1:28 PM on November 29, 2006
Oh and another point is that I don't care for software that comes pre-loaded with recipes or collections that exist online. All I want is for a way to manage ones that I already have. I assume you're thinking along the same lines?
posted by special-k at 1:30 PM on November 29, 2006
posted by special-k at 1:30 PM on November 29, 2006
Pretty screenshot here.
="http://thelittleappfactory.com/software/connoisseur/screenshots/connoisseur12main.png">
posted by special-k at 1:33 PM on November 29, 2006
="http://thelittleappfactory.com/software/connoisseur/screenshots/connoisseur12main.png">
posted by special-k at 1:33 PM on November 29, 2006
Honestly, why not just use the web?
If you put the question, why isn't there a way to organise all the magazines, newspapers, newspapers articles, academic publications and encyclopedia sections I'd like people would say this is just what the web is. As people have pointed out, recipes vary a lot and there is no standard way to express them and there is unlikely to be such a thing as the data model would have to be so flexible.
There are lots of good recipe sites, using those, coupled with google and bookmarking the ones you want works well. If you want to save things you can save the pages on your system. It works for many of us.
posted by sien at 2:18 PM on November 29, 2006
If you put the question, why isn't there a way to organise all the magazines, newspapers, newspapers articles, academic publications and encyclopedia sections I'd like people would say this is just what the web is. As people have pointed out, recipes vary a lot and there is no standard way to express them and there is unlikely to be such a thing as the data model would have to be so flexible.
There are lots of good recipe sites, using those, coupled with google and bookmarking the ones you want works well. If you want to save things you can save the pages on your system. It works for many of us.
posted by sien at 2:18 PM on November 29, 2006
Response by poster: Thanks to everyone for such great responses! In no particular order:
* For me, having a shopping list is far less important than a useful way to browse, sort, and order my recipes (exactly like special-k's iTunes suggestion, actually!). So my required data model is a lot simpler than those who absolutely must generate a shopping list from a selection of recipes. Sure, a shopping list is a nice-to-have, but having a pretty, functional interface would be so worthwhile that I could deal with making my own list.
* I also agree 150% with special-k about it coming with a database of recipes filled in. Sure, OK, put in one or two samples - but would I be needing this software to organize my recipes if I didn't already have too many? And I've never found an easy way to delete them all at install time, either.
* Tagging would be a big thing for me, even if it was an installed piece of software.
* Scanning would be huge! I love Kadin2048's idea for this. Who needs OCR, even? I grew up with recipes pulled out of magazines pasted into sticky-back photo albums, which means I'm used to identifying a recipe visually. As long as I could tag it, why *couldnt* a recipe be just one big image?
* Dobbs suggests the one big sticking point, which is the book vs. computer in the kitchen problem. But a) I have a laptop and a kitchen table nearby, so that's less of an issue, and b) I'd like to be able to print out from the program recipes that are so complex that I'll feel better with a piece of paper right beside me.
* I appreciate the suggestion of the Mac software! Alas, I'm a PC girl, but it definitely looked to fit the bill in terms of a pretty interface. [pout]
* For now, I've been using a Wordpress blog, which lets me create separate entries every time a find a new recipe I'd like to try, as well as longer posts where I list my own creations, notes on how it was made, photos, etc.
posted by twiki at 2:32 PM on November 29, 2006
* For me, having a shopping list is far less important than a useful way to browse, sort, and order my recipes (exactly like special-k's iTunes suggestion, actually!). So my required data model is a lot simpler than those who absolutely must generate a shopping list from a selection of recipes. Sure, a shopping list is a nice-to-have, but having a pretty, functional interface would be so worthwhile that I could deal with making my own list.
* I also agree 150% with special-k about it coming with a database of recipes filled in. Sure, OK, put in one or two samples - but would I be needing this software to organize my recipes if I didn't already have too many? And I've never found an easy way to delete them all at install time, either.
* Tagging would be a big thing for me, even if it was an installed piece of software.
* Scanning would be huge! I love Kadin2048's idea for this. Who needs OCR, even? I grew up with recipes pulled out of magazines pasted into sticky-back photo albums, which means I'm used to identifying a recipe visually. As long as I could tag it, why *couldnt* a recipe be just one big image?
* Dobbs suggests the one big sticking point, which is the book vs. computer in the kitchen problem. But a) I have a laptop and a kitchen table nearby, so that's less of an issue, and b) I'd like to be able to print out from the program recipes that are so complex that I'll feel better with a piece of paper right beside me.
* I appreciate the suggestion of the Mac software! Alas, I'm a PC girl, but it definitely looked to fit the bill in terms of a pretty interface. [pout]
* For now, I've been using a Wordpress blog, which lets me create separate entries every time a find a new recipe I'd like to try, as well as longer posts where I list my own creations, notes on how it was made, photos, etc.
posted by twiki at 2:32 PM on November 29, 2006
I did an uber-simple back-end for a small cooking website (now offline) that ended up with about 260 recipes.
From that experience, I believe the most useful model is a "unit" consisting of an ingredient list (lets call it List) and one or more paragraphs of instructional text (aka Text).
A "recipe" could be as simple as one set (List + Text), but it could have sub-processes (eg a marinade or a sauce) , so a recipe could consist of more than one set. It can also be recursive - eg a List refers to the "sauce", which refers to the List + Text for making the sauce.
This simple model covers the basic recipe structure, i think; the remaining task is to add basic references (title, author, yield, date submitted) and tags (eg vegeterian, seafood, BBQ, calorie-reduced, kosher, Christmas), ingredient searches, ingredient amount scaling for desired yield, and so forth.
I'm available for commissions, Pillsbury, if you're listening... ;^)
posted by Artful Codger at 2:48 PM on November 29, 2006
From that experience, I believe the most useful model is a "unit" consisting of an ingredient list (lets call it List) and one or more paragraphs of instructional text (aka Text).
A "recipe" could be as simple as one set (List + Text), but it could have sub-processes (eg a marinade or a sauce) , so a recipe could consist of more than one set. It can also be recursive - eg a List refers to the "sauce", which refers to the List + Text for making the sauce.
This simple model covers the basic recipe structure, i think; the remaining task is to add basic references (title, author, yield, date submitted) and tags (eg vegeterian, seafood, BBQ, calorie-reduced, kosher, Christmas), ingredient searches, ingredient amount scaling for desired yield, and so forth.
I'm available for commissions, Pillsbury, if you're listening... ;^)
posted by Artful Codger at 2:48 PM on November 29, 2006
As both a home cook, a software guy (7 years at Microsoft Corp, 3 at Expedia.com, MS in Comp Sci from Stanford, undergrad from CMU, etc.) and a founder of BigOven (www.bigoven.com), I find this thread both fascinating and useful!
To me, the problem is well summarized by both majick and bael'gar. It's both the data normalization problem and the "everyone has slightly different features" problem.
In 2002, when I left Expedia.com, I took a good look at the recipe software problem and felt there wasn't really anything that met my needs out there. It was all too modal, and it often required you to do things like define all your meal plans in advance before you could do an ad-hoc grocery list. BigOven, currently in its version 1.9 state (free trial at www.bigoven.com) is the result of that effort. There's a lot more work to be done, but it's a start.
The approach we're taking with BigOven is to have a massive, shared archive (160,000+ recipes at the moment) that is peer-produced content, highly reachable via the web, which is undergoing constant "normalization", plus ratings, plus pretty powerful recipe software. You can import any recipe with a single click, drag and drop recipe cards onto a shopping list (it currently groups your items by aisle, but doesn't yet add plurals/etc., but it will over time).
You can define favorites online, you can post recipes to the shared archive, you can get Nutrition Facts (from the USDA database) for any recipe, you can drag and drop recipes onto a meal plan, create shopping lists from recipes, etc.
Take a look and drop by www.bigoven.com when you get a chance... help us make it even better!
posted by stevemur at 4:23 PM on November 29, 2006
To me, the problem is well summarized by both majick and bael'gar. It's both the data normalization problem and the "everyone has slightly different features" problem.
In 2002, when I left Expedia.com, I took a good look at the recipe software problem and felt there wasn't really anything that met my needs out there. It was all too modal, and it often required you to do things like define all your meal plans in advance before you could do an ad-hoc grocery list. BigOven, currently in its version 1.9 state (free trial at www.bigoven.com) is the result of that effort. There's a lot more work to be done, but it's a start.
The approach we're taking with BigOven is to have a massive, shared archive (160,000+ recipes at the moment) that is peer-produced content, highly reachable via the web, which is undergoing constant "normalization", plus ratings, plus pretty powerful recipe software. You can import any recipe with a single click, drag and drop recipe cards onto a shopping list (it currently groups your items by aisle, but doesn't yet add plurals/etc., but it will over time).
You can define favorites online, you can post recipes to the shared archive, you can get Nutrition Facts (from the USDA database) for any recipe, you can drag and drop recipes onto a meal plan, create shopping lists from recipes, etc.
Take a look and drop by www.bigoven.com when you get a chance... help us make it even better!
posted by stevemur at 4:23 PM on November 29, 2006
PS: Forgot to add... if you think BigOven has promise and realize it is only in version 1.x, and you want to help us make it better with design input/beta-testing, etc., just jot us a note at sales-at-bigoven.com with a reference to this thread, and we'll send you a discount coupon. We've got some features already mentioned on this thread (e.g., tagging) and several more in the works for future versions (e.g., scanner support), and we can always use help from this highly-involved lead-group of users.
BigOven isn't so much a push for a financial windfall, it's a labor of love. Would love to have your help. Thanks much, and happy cooking.
posted by stevemur at 4:30 PM on November 29, 2006 [1 favorite]
BigOven isn't so much a push for a financial windfall, it's a labor of love. Would love to have your help. Thanks much, and happy cooking.
posted by stevemur at 4:30 PM on November 29, 2006 [1 favorite]
PPS: Link above was broken -- real link is here. Thanks
posted by stevemur at 4:31 PM on November 29, 2006
posted by stevemur at 4:31 PM on November 29, 2006
They'd prefer to have two boxes to enter data. One for the ingredients, and one for the instructions. But that makes it useless for users searching for recipes.
Parse the data in the ingredients box, format it into items for them, and ask for approval that the items are right?
posted by jesirose at 9:46 PM on November 29, 2006
Parse the data in the ingredients box, format it into items for them, and ask for approval that the items are right?
posted by jesirose at 9:46 PM on November 29, 2006
now I feel bad for slandering stevemur's product in my earlier question. Perhaps I just need to give it a little time.
posted by Mr. Gunn at 10:49 PM on November 29, 2006
posted by Mr. Gunn at 10:49 PM on November 29, 2006
They'd prefer to have two boxes to enter data. One for the ingredients, and one for the instructions. But that makes it useless for users searching for recipes.
??? Absolutely not the case. There's no reason why separating ingredients and method makes it harder/impossible to search. Makes it EASIER to search, IMO.
posted by Artful Codger at 9:27 AM on November 30, 2006
??? Absolutely not the case. There's no reason why separating ingredients and method makes it harder/impossible to search. Makes it EASIER to search, IMO.
posted by Artful Codger at 9:27 AM on November 30, 2006
Some final thoughts before this thread dies:
a) I agree with most of what majick has to say too but not this part:
On top of all that if you ask ten people to describe their idea of perfect recipe software you'll wind up with twelve different sets of conflicting requirements.
Isn't that true of most software? I mean, if developers were bogged down with this problem there really wouldn't be anything out there.
b) As twiki points out, shopping lists are quite secondary. People that cook regularly usually have most of the ingredients for a meal and just need to run to the store for a couple of items. So we would end up scratching off most items on a software generated list anyway.
c) The approach we're taking with BigOven is to have a massive, shared archive (160,000+ recipes at the moment) that is peer-produced content, highly reachable via the web, which is undergoing constant "normalization", plus ratings, plus pretty powerful recipe software. You can import any recipe with a single click, drag and drop recipe cards onto a shopping list (it currently groups your items by aisle, but doesn't yet add plurals/etc., but it will over time).
This again seems like a disparity between what cooks want and what developers think we need.
twiki: but would I be needing this software to organize my recipes if I didn't already have too many?
exactly!
we hate preloaded recipes just as much as itunes coming pre-loaded with the best music in each genre.
d) b & c seem to be things that aren't a big priority on the end-user list but end up being big selling points for recipe software writers.
e) Connoisseur (although I have never used it but so blown away that I am considering a mac as my next computer) looks great. I don't use a mac & would easily pay $50+ for a similar windows product.
f) As much as I like to rail on BigOven, it does a spectacular job importing recipes from the web. kudos. I loved how you could just select text, hit import and easily have it in your database.
g) Some have suggested simply using delicious to track recipes on the web. I've tried it only to find out that the awesome marinade I discovered a year ago is now gone [on a side note, does anyone know of a tool that would take a delicious tag and fetch all those pages to a local folder]
h) I guess the best solution as of now is just to have your own wordpress blog? sigh
posted by special-k at 9:45 AM on November 30, 2006 [1 favorite]
a) I agree with most of what majick has to say too but not this part:
On top of all that if you ask ten people to describe their idea of perfect recipe software you'll wind up with twelve different sets of conflicting requirements.
Isn't that true of most software? I mean, if developers were bogged down with this problem there really wouldn't be anything out there.
b) As twiki points out, shopping lists are quite secondary. People that cook regularly usually have most of the ingredients for a meal and just need to run to the store for a couple of items. So we would end up scratching off most items on a software generated list anyway.
c) The approach we're taking with BigOven is to have a massive, shared archive (160,000+ recipes at the moment) that is peer-produced content, highly reachable via the web, which is undergoing constant "normalization", plus ratings, plus pretty powerful recipe software. You can import any recipe with a single click, drag and drop recipe cards onto a shopping list (it currently groups your items by aisle, but doesn't yet add plurals/etc., but it will over time).
This again seems like a disparity between what cooks want and what developers think we need.
twiki: but would I be needing this software to organize my recipes if I didn't already have too many?
exactly!
we hate preloaded recipes just as much as itunes coming pre-loaded with the best music in each genre.
d) b & c seem to be things that aren't a big priority on the end-user list but end up being big selling points for recipe software writers.
e) Connoisseur (although I have never used it but so blown away that I am considering a mac as my next computer) looks great. I don't use a mac & would easily pay $50+ for a similar windows product.
f) As much as I like to rail on BigOven, it does a spectacular job importing recipes from the web. kudos. I loved how you could just select text, hit import and easily have it in your database.
g) Some have suggested simply using delicious to track recipes on the web. I've tried it only to find out that the awesome marinade I discovered a year ago is now gone [on a side note, does anyone know of a tool that would take a delicious tag and fetch all those pages to a local folder]
h) I guess the best solution as of now is just to have your own wordpress blog? sigh
posted by special-k at 9:45 AM on November 30, 2006 [1 favorite]
special-k writes:
>> d) b & c seem to be things that aren't a big priority on the end-user list
We all see different parts of the elephant, I guess.
BigOven users rank the existing shared recipe archive -- being able to discover new recipes and find virtually any recipe given ingredients, title, cuisine, etc., #1 on their favorite-features list, from correspondence to our support desk, and "easy shopping list creation" #2. Adding tags to recipes, easily entering recipes from text sources, and general search features are next on the list in user feedback.
Stay tuned though, -- we've only been on the market a couple yeras, and have just begun innovating here.
posted by stevemur at 10:28 AM on November 30, 2006
>> d) b & c seem to be things that aren't a big priority on the end-user list
We all see different parts of the elephant, I guess.
BigOven users rank the existing shared recipe archive -- being able to discover new recipes and find virtually any recipe given ingredients, title, cuisine, etc., #1 on their favorite-features list, from correspondence to our support desk, and "easy shopping list creation" #2. Adding tags to recipes, easily entering recipes from text sources, and general search features are next on the list in user feedback.
Stay tuned though, -- we've only been on the market a couple yeras, and have just begun innovating here.
posted by stevemur at 10:28 AM on November 30, 2006
Response by poster: Don't know if this will get picked up by anyone or whether it's now officially a "dead" thread, but it seems maybe like there are two sets of requirements out there. There are already a lot of programs out there with shopping list generation and shared recipe archives, but these are the programs that many of us on this thread are cranky about.
Perhaps the point is we need a next-gen, that focuses on *different* features?
Stevemur, it sounds like your user base is excited about your features. But in all honesty, I'm curious: are they excited because those features exist? If, for example, your product had other features that performed their task brilliantly, would you also see the same level of feedback on *those* features?
I don't mean to pick on you directly, it was just always a question that came up for me as a UX designer.
And yes, I guess for now I'm sticking with my new Wordpress blog. I've only had it a couple of months but for now I guess it will have to do.
posted by twiki at 6:36 AM on December 1, 2006
Perhaps the point is we need a next-gen, that focuses on *different* features?
Stevemur, it sounds like your user base is excited about your features. But in all honesty, I'm curious: are they excited because those features exist? If, for example, your product had other features that performed their task brilliantly, would you also see the same level of feedback on *those* features?
I don't mean to pick on you directly, it was just always a question that came up for me as a UX designer.
And yes, I guess for now I'm sticking with my new Wordpress blog. I've only had it a couple of months but for now I guess it will have to do.
posted by twiki at 6:36 AM on December 1, 2006
Response by poster: [belated] thanks again to everyone for responding!
posted by twiki at 6:37 AM on December 1, 2006
posted by twiki at 6:37 AM on December 1, 2006
Actually, I guess I take issue with the premise here... there are actually very few there programs that have both shopping list generation from a desktop application and a live, shared recipe archive where people can post new recipes and search in the archive. BigOven is a bit unique in that it's a richly featured recipe website PLUS desktop recipe software that works pretty seamlessly with it. Other offerings are either one or the other (i.e., website or desktop software.)
What we hear from customers is that they very much like the ability to search the archive for ways to use up what's in their fridge (i.e., the leftover wizard). This requires a giant recipe archive to work best, complementing one's own recipe collection. People also tell us they like the fact that they can search for virtually any recipe, and build their own collection, discovering new favorites, and they can discover ways to replicate recipes they may have had in a restaurant or at a friend's house, if they know 3 or so ingredients in that recipe.
However, advanced cooks and recipe collectors -- those who already have their own collection -- tend to want recipe tagging, easy recipe entry, advanced search features, nutritional analysis, and menu planning, all of which we also offer in our version 1.x product.
>> are they excited because those features exist? If, for example, your product had other features that performed their task brilliantly, would you also see the same level of feedback on *those* features
Yes to both of those questions. I've mentioned this before, but please remember that we're only a couple years old, and we have several additional features many people would like to see. Those features include both features for their desktop recipe software, as well as for the shared archive.
Thanks for all the great ideas on this thread!
posted by stevemur at 7:44 AM on December 1, 2006
What we hear from customers is that they very much like the ability to search the archive for ways to use up what's in their fridge (i.e., the leftover wizard). This requires a giant recipe archive to work best, complementing one's own recipe collection. People also tell us they like the fact that they can search for virtually any recipe, and build their own collection, discovering new favorites, and they can discover ways to replicate recipes they may have had in a restaurant or at a friend's house, if they know 3 or so ingredients in that recipe.
However, advanced cooks and recipe collectors -- those who already have their own collection -- tend to want recipe tagging, easy recipe entry, advanced search features, nutritional analysis, and menu planning, all of which we also offer in our version 1.x product.
>> are they excited because those features exist? If, for example, your product had other features that performed their task brilliantly, would you also see the same level of feedback on *those* features
Yes to both of those questions. I've mentioned this before, but please remember that we're only a couple years old, and we have several additional features many people would like to see. Those features include both features for their desktop recipe software, as well as for the shared archive.
Thanks for all the great ideas on this thread!
posted by stevemur at 7:44 AM on December 1, 2006
*heh* So, it sounds like some folks want a Delicious Library for their recipes. :)
You could always go retro and use the descendant of HyperCard and use SuperCard to point and click your way through your own recipe keeper. ;)
(I'm not belittling the effort of BigOven though. It sounds very cool, and I've seen previous apps try and fail at what they are trying to do. Now here's to hoping it's not platform specific.)
posted by smallerdemon at 10:33 AM on December 1, 2006
You could always go retro and use the descendant of HyperCard and use SuperCard to point and click your way through your own recipe keeper. ;)
(I'm not belittling the effort of BigOven though. It sounds very cool, and I've seen previous apps try and fail at what they are trying to do. Now here's to hoping it's not platform specific.)
posted by smallerdemon at 10:33 AM on December 1, 2006
This thread is closed to new comments.
posted by smackfu at 7:57 AM on November 29, 2006 [1 favorite]