Closed pautva closed 2 years ago
@bgsandan Are these controls to have query linked params that allow pre-population from a link?
If we can make it sensibly work it would be nice please 😊
When switching between these options, will the previously selected food items stay selected?
And if you go back to "Composition Change" after going to "Consumption Change" say, do you expect to see the previous "scenario composition" selection?
As in stay selected so you could switch back to a previous option and see your previous selection?
I'm happy for switching between the different modes "Composition", "Consumption", "Food Item" to wipe out the previous selection so when you switch mode you get a fresh empty selection (ideally with an 'are you sure you want to do this' type dialog/warning first). I assume that would still be simpler than trying to maintain/store all permutations?
Given that if params are part of the URL a user could save/share a scenario to get back to it, don't think they need to persist between mode changes.
Happy to hear other thoughts/opinions though :smile:
The "food items" are consistent between the three modes, so we could keep them, but persisting those without the values might seem inconsistent.
That would mean it's all or nothing, and if you're happy with nothing (initially), then so am I. :-)
I agree with Andy that some warning message would be useful in case the selection gets deleted. If somebody adds more than 10 items and then loses their progress, that could be frustrating :)
If we have an option to save a URL with query params, we could add "Bookmark scenario" button next to "Share Page".
We'll probably need to alert on changing the option and have a "canDeactivate" route guard too then.
I agree with Andy that some warning message would be useful in case the selection gets deleted. If somebody adds more than 10 items and then loses their progress, that could be frustrating :)
If we have an option to save a URL with query params, we could add "Bookmark scenario" button next to "Share Page".
There's certainly the potential to frustratingly lose a lot of configuration there!
Is it not likely that they will want to change from "Composition" to "Consumption" with the same food items selected?
@LouiseAnder see above conversation - what are your thoughts on the likelihood of a user wanting to switch from "Composition" scenario to "Consumption" scenario and maintain the same list of food items?
this is a good question - I am also concerned that if we are allowing a large number of simultaneous changes we support the user diverging from anything vaguely realistic / achievable in a food system. I tend to think that Andy's suggestion where they are (with prior warning) wiped, keeps it very clear what the user is altering too. Like that there is some URL/bookmark way of returning to scenarios though.
Not sure if this should be a separate issue, but will these permutations be captured somewhere on any downloadable output @bgsandan ?
Any idea how the API will deliver the food groups and items? Will it be a single call for everything, given the micronutrient, with the response being an array of food groups with a nested food items?
Open for discussion/requests! Assuming that sort of structure works for you that is probably more efficient than a separate call to get the food items for each food group?
Open for discussion/requests! Assuming that sort of structure works for you that is probably more efficient than a separate call to get the food items for each food group?
@bgsandan Would this be dependant on anything or more like a dictionary call (no params).
Good question. The food groups/food items probably more of dictionary. The call to get "current" value will need to pass either the consumption data source id or composition source id depending on the mode along with the selected fooditem. Make sense?
I'm currently trying to get some api endpoints and mock data in for this.
Good question. The food groups/food items probably more of dictionary. The call to get "current" value will need to pass either the consumption data source id or composition source id depending on the mode along with the selected fooditem. Make sense?
Where are the consumption data source id and composition source ids obtained from?
The data-source endpoint called to populate the bottom select option in the sidebar. e.g. https://devapi.micronutrient.support/data-source/ZAF/diet
The data-source endpoint called to populate the bottom select option in the sidebar. e.g. https://devapi.micronutrient.support/data-source/ZAF/diet
So they're not different things, just the data source id (as opposed to "consumption data source id" and "composition source id")?
Sorry, caused confusion yesterday with inaccurate terminology when typing on my phone!
In "Composition Change" mode, there will be an API to get the 'Current composition' value. That will take as input the compositionDataId
parameter from the above URL and an id for the fooditem selected e.g /diet/scenario/composition/?foodItem=123&compositionDataId=XYZ
(url TBC)
In "Consumption Change" mode, there will be an API to get the 'Current consumption' value. That will take as input the consumptionDataId
parameter from the above URL and an id for the fooditem selected e.g /diet/scenario/consumption/?foodItem=123&consumptionDataId=XYZ
(url TBC)
Is that clearer? Happy to chat otherwise :)
@Sveouu It's probably not completely obvious from the conversations on this issue that this task really is just selecting the mode (consumption/composition/food item), and there are other issues for the options associated with those selections.
I hope I haven't confused matters too much by starting conversations here that should maybe have been on other issues. I know that @Fuhji is looking at the composition options task #506, so I just wanted to ensure that there isn't any duplication of effort.
@bgsandan @pautva
Not really associated with this task but as it spans all three modes it seems the best place for it.
Can we tweak the UI for the options panel so that when you "Add Food Item" it makes the previously selected food items un-editable?
Otherwise updating the available options in all of the active selects will be complicated. The scenario value can still be editable.
As in:
?
In which case i think that is fine.
With multiple fooditems we may want to be able to delete/remove one of them though.. Happy to allow removing only the latest one (thus 'unlocking' the selection box for the previous item) if that is easier and fits with the above model though
Should be:
- Steps 1-4 apply to selection no. 2
I don't see a problem with being able to remove any of the previous rows.
The "All" option will complicate matters, and will only be available if nothing from that group has previously been selected.
On the subject of the "ALL" option, I'm working on the assumption that that will need expanding to a full group of individual food item selections for the API call and that there won't be a shortcut way to send a group id instead. Is that correct.
Sending a full group of id's will certainly work. Though we could look at an endpoint that takes a group id if we think it would be useful
Sending a full group of id's will certainly work. Though we could look at an endpoint that takes a group id if we think it would be useful
It would have to be the same endpoint since they might have selected item A from group 1 and All from group 2.
I'll still assume expanding the "ALL" to include all food item IDs.
Figma prototype status
User story
As a policymaker, I want to explore various dietary change scenarios so I can make evidence-based recommendations.
Summary
The card will allow you to toggle between:
The scenario details are addressed in separate issues.
Figma prototype
Location
Diet Data > Explore Simple dietary change scenarios
Part of scenarios page:
499
Scenario options:
Reference
Other Scenarios issues
![gloomap_002be100](https://user-images.githubusercontent.com/72566636/120618179-ba7c4200-c452-11eb-86d8-919e5051f0a7.png)
Acceptance criteria