micronutrientsupport / micronutrient-support-tool

Web front-end for the MAPS Micronutrient Support Tool
MIT License
2 stars 0 forks source link

Scenarios - Scenario options #501

Closed pautva closed 2 years ago

pautva commented 3 years ago

Figma prototype status

status-develop

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:

  1. Food item composition
  2. Food item consumption
  3. Food item comparison

image

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

jon571 commented 3 years ago

@bgsandan Are these controls to have query linked params that allow pre-population from a link?

bgsandan commented 3 years ago

If we can make it sensibly work it would be nice please 😊

jon571 commented 3 years ago

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?

bgsandan commented 3 years ago

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:

jon571 commented 3 years ago

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. :-)

pautva commented 3 years ago

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".

jon571 commented 3 years ago

We'll probably need to alert on changing the option and have a "canDeactivate" route guard too then.

jon571 commented 3 years ago

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?

bgsandan commented 3 years ago

@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?

LouiseAnder commented 3 years ago

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 ?

jon571 commented 3 years ago

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?

bgsandan commented 3 years ago

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?

jon571 commented 3 years ago

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).

bgsandan commented 3 years ago

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?

jon571 commented 3 years ago

I'm currently trying to get some api endpoints and mock data in for this.

jon571 commented 3 years ago

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?

bgsandan commented 3 years ago

The data-source endpoint called to populate the bottom select option in the sidebar. e.g. https://devapi.micronutrient.support/data-source/ZAF/diet

jon571 commented 3 years ago

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")?

bgsandan commented 3 years ago

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 :)

jon571 commented 3 years ago

@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.

jon571 commented 3 years ago

@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.

bgsandan commented 3 years ago

As in:

  1. User selects a food item using the dropdowns
  2. Tool loads the value for 'current consumption' (or composition etc)
  3. User can then update the scenario values
  4. At this point user can change the select box as it isn't 'locked in'
  5. User clicks "Add Food item" to add another option
  6. The select boxes for selection no. 1 are locked so they can't change that food item but can still edit the scenario value
  7. Steps 2-4 apply to selection no. 2

?

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

jon571 commented 3 years ago

Should be:

  1. 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.

jon571 commented 3 years ago

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.

bgsandan commented 3 years ago

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

jon571 commented 3 years ago

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.