waistline
waistline copied to clipboard
davidhealey
Question about some of the features
Hi David and all,
First of all, thank you for this amazing piece of software.
I was trying to find out four things, please let me know if I overlooked existing documentation or there is a better place to ask this:
-
What does the chain icon on the top right of a food item? I can check it to cut it or not, but I can't find anywhere what it is for.
-
I don't understand well the difference between Meal and Recipes. I have successfully assembled recipes out of the food list, but I'm left wondering what I could use Meal for.
-
I don't understand well how the information I add on waistline, after logging in on the OpenFoods via Waistline, can be relayed to OpenFoods. Currently, when I find information missing (e.g. a photo), or incorrect on Nutrinional Facts, I switch to the OpenFoods app or log to their website via browser, fix it, and then re-scan a codebar via Waistline to get the updated information (since the intent is OpenFoods to also be updated). Am I overlooking a simpler path?
-
When I do item 3 above, I noticed updating "Food" items nutritional value via the OpenFoods app, and then re-scanning via Waistline, updates my Food log (the old entry is overwritten), but not update my "Daily" log, despite being the same food item. It's as if the Daily food item links to a now ghostly copy of the old item. However, it seems when a photo was uploaded using the method in 3), Diary was updated. I was wondering if this is intended? The same seemed true for Food items added to Recipes (i.e. it will not update).
I'm hoping to use the app for the coming months since I can play with the json exported data on my own, so any clarity on the functionality or better workflows would be greatly appreciated.
Thank you!
Hi,
1: It links/unlinks the values in the food editor. When enabled (linked) making a change to one number, the quantity for example, will update all of the nutritional data to match the new quantity. And changing a nutritional value will update the quantity and the other nutritional values.
2: A meal is a collection of food and recipe items. Let's say you make a sandwich out of bread, butter, cheese, and ham. When you add this meal to the diary the individual items will be added to the diary.
A recipe is a collection of food and recipe items that make a new item. Let's say you make bread by adding flour, water, and salt. When you add your bread item to the diary it is added as a single item, bread. And you can use this to make your sandwich meal :)
3: Waistline is not an OFF editor. Any changes you make to items in Waistline are local and will not be reflected on the OFF website. The only exception to this is when you scan an item that isn't in the OFF database you are able to add it to the database.
4: It should update. All data for diary/recipes/etc. is drawn from the main food list, there isn't a separate copy. The only thing that is separate in the diary is the serving size/quantity.
Since this thread isn't really and "issue" I don't want to leave it open. However you have brought up some good questions so I think we should use this as a jumping off point to create and FAQ or wiki. I'll look into doing that when I have some free time and in the meantime I'll leave this thread open.
@carlosparadis
Some thoughts about question 3:
I switch to the OpenFoods app or log to their website via browser, fix it, and then re-scan a codebar via Waistline to get the updated information (since the intent is OpenFoods to also be updated). Am I overlooking a simpler path?
Maybe it would be easier to first correct the information within Waistline and add the item. Then you can simply tap on the barcode in the food editor to open the corresponding OFF entry in the browser and fix it too. This way you don't need to switch apps or re-scan the barcode.
About question 4:
It's as if the Daily food item links to a now ghostly copy of the old item
You can check which food item the diary entry links to by looking at the json export. Maybe you indeed have two copies of the food item, one of which is marked "archived".
This way you don't need to switch apps or re-scan the barcode.
But you would have to make edits in two places then. Only seems useful for very small changes.
Maybe you indeed have two copies of the food item, one of which is marked "archived".
If this is the case then there is a bug. Barcodes should be a unique key for food items so this situation can't happen.
Maybe you indeed have two copies of the food item, one of which is marked "archived".
If this is the case then there is a bug. Barcodes should be a unique key for food items so this situation can't happen.
I checked for this on the .json file, but it seems the only thing archived was a "lasgna test" (my first entry). By the way, how do I delete this for good?
As for the actual problem, I tried doing the process again and the older entry is still there. Here are the steps I did:
- Create a food entry in the waistline via code scan to get OFF data (mine had a unit for a Bai in OZA).
- Add to Diary
- Update the food entry via OFF app / website
- Re-scan via Waistline to get new info on food entry (my new entry had Oz this time and nutritional facts changed)
- Check Diary (it shows old OZA, which from what you said it shouldn't).
From here I tried doing the following to see what would happen: I added the same item from the updated food list category. Now my diary show the same product, the Bai, with Oza, and the new one, with Oz. Json-wise, I don't see an archived true there, but I do see the entries in the diary look a bit different:
The above is the 2 entries under "Diary". So it seems to me, in storing the unit directly in the diary entry, rather than pulling from the food entry itself, it remains locked unable to update. Trying to choose the entry from the Diary interface will not let me edit it either (it's grayed out). There is one more thing I noticed here that I don't understand how it is happening: When I choose the OZA entry from Diary, I don't see Sodium being shown. However, for the new Oz entry, Sodium is shown. It makes sense that Sodium is now shown since I added it in the Oz entry, but I don't understand how from the json alone it can decide whether to show Sodium or not, since both entries refer to the same ID 4, and I see no archived version of it.
I forgot to ask one item 5 behavior I noticed:
- When trying to add an item with minimal information (e.g. i think a photo but no nutritional facts), a warning from waistline will say it doesn't exist (even though it does). However, adding more information to the entry via the OpenFoods app (I believe again was the nutritional facts), will make the entry work. Is this intended, or should it download whatever information it should have, even if just a photo? (I was particularly curious about this since I didn't see a way to add a photo directly to waistline, only via the step 3 process above).
the only thing archived was a "lasgna test" (my first entry). By the way, how do I delete this for good?
Deleted food items are kept internally (marked "archived") in case any old diary entries still refer to it. If that isn't the case, you could remove it from the json and then import to get rid of it.
- Re-scan via Waistline to get new info on food entry (my new entry had Oz this time and nutritional facts changed)
Did you really get the new info just by re-scanning the product barcode? As far as I know, if the item you scanned already exists in the local database, it displays the local information.
So it seems to me, in storing the unit directly in the diary entry, rather than pulling from the food entry itself, it remains locked unable to update.
You are right about that. Since the unit is stored directly in the diary entry, when you change the unit for the food item, the diary still shows the old unit. That's a bug (a minor one though, and it should be easy to fix). But despite that, the diary entry should account for the updated nutrition values. Is this not the case for you?
When I choose the OZA entry from Diary, I don't see Sodium being shown
That's probably because the "OZA" entry only has a portion size of 8 which is too little for the sodium value to appear. Only values greater than zero are shown in the diary entry (and note that values get rounded).
When trying to add an item with minimal information (e.g. i think a photo but no nutritional facts), a warning from waistline will say it doesn't exist (even though it does)
Waistline is a calorie tracker. OFF entries without at least calories are therefore ignored. It doesn't really make sense to import just the product name and image.
Did you really get the new info just by re-scanning the product barcode? As far as I know, if the item you scanned already exists in the local database, it displays the local information.
I'm pretty sure I changed this so it updates from OFF when you rescan - someone made an issue requesting it. Or I could have imagined it :)
That's a bug (a minor one though, and it should be easy to fix). But despite that, the diary entry should account for the updated nutrition values. Is this not the case for you?
Maybe we shouldn't store a unit in the diary at all.
Yes yes yes please do that faq. I had all these same questions. Had to go back and redo all my food enries.
Thank you so much for all the clarifications! A wiki FAQ would be great, it was the first button I went after on this project.
I found one more thing:
I tried to edit the "Diary" serving size of my example above which had Oza as unit (note, I edited the serving size, not the unit), and doing it made the Diary data update from Oza to Fl Oz. That is, it seems editing older entries Diary's Serving Size field will make the app check the "food entry" and update the unit if a re-scan change it, which adds to my confusion (if it is going to update anyway the unit if I edit some other field via the diary, maybe it should update when the food entry is updated). Also, I noticed the recipe data portion does not seem to store a unit field like the diary does in the json either.
To be honest, I am somewhat confused about why Serving Size (which is information you get from the box when adding a Food entry), is editable when you add it to the Diary, as a unique new field, Number of Servings, is made available only in the Diary menu. The first time I saw it, I thought editing it would edit the Serving Size on the food entry too. However, I think if an item serving size unit were to change in the future in OFF and were to be re-scanned (e.g. from 85g to 1 Bowl as I seen on OFF), storing the original information of serving size, its unit, and the number of servings would make sense if the nutritional facts would also be copied. As it is now though, I think in such a situation the old Diary entry nutritional facts would be interpreted as 85 bowls if Food's unit was updated (?). Maybe I am confusing myself with the fields.
About question 1: I had the same. It took me a while to figure it out myself. And I am very accustomed to the chain icon in image editors, where it serves the same purpose. I do not know a more intuitive location for the chain, but maybe you can display a little message that says "Servings and nutritions are now unlinked" and the other way round, which would explain it when tapped out of curiosity.
Deleted food items are kept internally (marked "archived") in case any old diary entries still refer to it. If that isn't the case, you could remove it from the json and then import to get rid of it.
That's totally user unfriendly, please add a simple delete button in that long press menu.
@hacksenwerk Why do you care? If you archive an item it will be gone, you won't see it anymore unless you explicitly request to show archived times from the flter menu. It's as good as being deleted.
@EmilJunker That is just waste of space! That's why.
I really wonder why the devs of this app are complaining about functions that are default behaviour for most apps.
Well, Waistline is unlike most apps. And there are good reasons why we archive items instead of deleting them. I use this all the time to create updated copies of old items for which the nutrition information has changed.
Of course we could add an option to delete items for good, but not doing so saves us the hassle of having to deal with references to nonexistent items.
I think the only use case I can see to permanently delete items (without leaving orphan references) is when archiving we can run a check to see if the item is referenced, and if it isn't we can delete it.