I like the concept and the execution is pretty solid - I particularly like the RDA % and bar charts for a meal. I have a few thoughts though:
1) Search found all the ingredients I needed or pretty close approximations which was cool. Multiple units of measurement was an excellent choice. Food data looks USA - it would be helpful to know that as a UK user.
2) I had to make a username and password which will put off some potential users. Why not make it log in with Facebook/Google as an option?
3) I entered a quantity of tortillas and couldn't amend it without deleting the item. Was I doing something wrong?
4) As an active 6'2" man I suspect I need more calories than average. How about activity level/height/weight options? Kudos for having 'pregnant' and 'Breastfeeding' as options. However they would be more powerful as flags - my wife is both pregnant and breastfeeding! Or even 'add person' so one can look at nutritional info for cooking for a family.
I'm interested to see how this tool evolves! Good work!
1) Yes, it uses a USA gov' database. But I'm curious about why it looks American to you. Could you please elaborate?
2) To be frank, this is django's registration system, off-the-shelf (least effort). If I see enough interest in the site I will add simplified login. Thanks for highlighting it.
3) You did nothing wrong. I've stripped the interface down to the most basic functions.
4) You're totally correct. Adjusting the targets for body shape and activity is a priority item. As far as pregnant + breastfeeding, the source database has data for each but not both.
Is there a comparison to MyFitnessPal? I use that and it's able to import recipes from a link, or scan products using a barcode. How are you getting all of the data for different products? I tried looking up my two favorite brands of yogurt and they weren't there.
Thanks for checking it out. In my understanding, MyFitnessPal is oriented toward the fitness crowd, with a focus on daily energy consumption.
After a lot of exploration I decided to limit the scope as much as possible and target home cooks and food bloggers, with a focus on recipes.
I spent a few weeks of my spare time trying to get the parsing of free-text recipes to work (essentially MFP's import from link). The results were decent, but I realized that if it's only 90% accurate I still need a lot of user interface functions (like MFP) to let users edit/fix the inaccurate bits. It started smelling bad so I decided to strip it down to its most basic function.
I have no plans for now to use databases of branded products - the ones I saw were quite expensive and would be more useful for sites like MyFitnessPal, perhaps less useful for recipes/cooking.
> I spent a few weeks of my spare time trying to get the parsing of free-text recipes to work (essentially MFP's import from link). The results were decent, but I realized that if it's only 90% accurate I still need a lot of user interface functions (like MFP) to let users edit/fix the inaccurate bits. It started smelling bad so I decided to strip it down to its most basic function.
As a regular MyFitnessPal user I have to say, their recipe importer leaves a lot to be desired. Whenever I use it, I inevitably have to make corrections because it mapped the parsed ingredient to the wrong item. (And their UI for making corrections is not particularly great either.)
It's probably a good idea that you decided not to go down this road.
I've changed it so that you can try the calculator without creating an account. Login is only required for saving recipes or for changing the nutrition targets.
I'm pretty familiar with the USDA SR dataset, and here are my thoughts (examining data with one of my experiments diarytail.com)
1) People in the enterprise space will be willing to deal with the weird nuances of the USDA-SR data. For example writing 'beef cooked' vs' 'beef raw'.
2) In the general consumer space, there is a huge problem in getting the general public to find ingredients they use. I found lots of people typing in brand name ingredients not matching what is in the USDA data set.
To me, the problem is partially solved with My Fitness Pal's huge dataset of user generated data. However the flip side is it is missing most of the micros as they are entered via a nutrition label.
Another solution might be to reference nutritionix.com 's dataset (I think the joyapp.com uses it also)
Unfortunately nutritionix has only basic nutritional data as well, the sort of thing you find on a product label. Not bad but not great. Have a look at their sample data. Plus it's around 10k/year or 50k/license.
I'm thinking home cooks would get a lot of value from the tool, and reasonably good data even if they use raw instead of cooked (as an example).
Interesting, is there any plans on opening up your calculator/analyzer to an API. I just launched http://imadefood.com a week ago, and there could be some mutual beneficial scenarios here. Let me know!
I don't think I can offer much of an API. As I mentioned in another comment, I gave up on trying to parse a free-text recipe. I avoid a lot of headache by directing users to enter ingredients from the database list only.
That being said, I'm open to talk about it - see my HN profile for email.
I like your imadefood site. Reminds me of a kind of jsfiddle for recipies.
edit: @phugold - I like the idea of your site, but you might want to take note of the ability to immediately see recipies without having to register. It's great to be able to just dive right in rather than hitting a wall requiring login.
Yeah, I do a recipe app and would be willing to pay (very little) for something like this too. We could even go so far as edit the ingredient data storage to suit the API.
Very cool. I wonder does this take cooking into account? Meaning you slice up a potato and fry it you end up with different nutritional results than baking a whole potato for example.
For many ingredients, you have the option of selecting raw or cooked. For popular items like potatoes there are dozens of options including fried, baked, salted, etc.
I would have signed up and tried the service, but I'm allergic to quotes like the following in a privacy policy, particularly when they are not disclosed on the sign up page.
If you are a registered user of recipelab.org and have supplied your email address, recipelab.org may occasionally send you an email to tell you about new features, solicit your feedback, or just keep you up to date with what’s going on with recipelab.org and our products. If you send us a request (for example via a support email or via one of our feedback mechanisms), we reserve the right to publish it in order to help us clarify or respond to your request or to help us support other users.
Contrast that with:
When you register for recipelab.org, we collect certain personal information (ie - your email address and name). We will only use this email address to send you {monthly||weekly||daily} requests for feedback or updates on the product.
If you send us a support request, we may publish it to help us support other users. However, before we publish it, we will strip out any personally identifiable information.
Thanks for bringing this to my attention. I have no intention of spamming users or of publishing their info. I will take another look at the text when time permits.
Yes, that site does a pretty good job. At first glance the copy/paste approach is promising - in practice it's a bit more hassle and less precise than what recipelab does in my opinion, plus I'm starting from a clutter-free UI that works great on mobile devices.
I'd really prefer seeing a full example before signing up. You're not providing enough information about what I'll get out of this save a few tiny cropped screenshots.
Do you think a full screenshot might be interesting?
But a simple screenshot image would not work for all cases, because the calculator page renders differently on mobile devices. On the other hand, if I offer a full working version without sign-up, there would be no reason to sign up. If I show a "frozen" version of the full calculator, normal users might get the wrong idea from that as well.
No, a screenshot would not be interesting enough IMHO.
It seems that you want to prevent people from experiencing your site without signing up first. Why is this? If you hide the value of your site behind the sign-up link, hardly anybody will bother signing up.
With a site like this, I would suggest enabling all features for anonymous users, except the ability to save recipes. Users can play around with the site and make their own recipe. The natural step after creating a test recipe would be to save it - this would be the best place to prompt for signup. I'd also recommend changing your on-boarding flow so that I do not need to confirm my email address immediately.
I've changed it so that you can try the calculator without creating an account. Login is only required for saving recipes or for changing the nutrition targets. Thanks again for the advice.
1) Search found all the ingredients I needed or pretty close approximations which was cool. Multiple units of measurement was an excellent choice. Food data looks USA - it would be helpful to know that as a UK user.
2) I had to make a username and password which will put off some potential users. Why not make it log in with Facebook/Google as an option?
3) I entered a quantity of tortillas and couldn't amend it without deleting the item. Was I doing something wrong?
4) As an active 6'2" man I suspect I need more calories than average. How about activity level/height/weight options? Kudos for having 'pregnant' and 'Breastfeeding' as options. However they would be more powerful as flags - my wife is both pregnant and breastfeeding! Or even 'add person' so one can look at nutritional info for cooking for a family.
I'm interested to see how this tool evolves! Good work!