Changed cultural responsiveness slider to be more descriptive.

[Tbryant117]

Fixes #152. Also removed text description beneath slider

[nicolesylvester]

We might also need to update the filters on the homepage so that they correspond to the new cultural responsiveness options.

[JavadocMD]

Thanks Nicole for the good early feedback on this.

I think our ideal solution here would include removing the old filter values as well. Aside from deleting those three lines from filter.dart, what other changes might we need to make? What difficulties might arise from doing so?

[JavadocMD]

Additionally, I really like the value indicator that shows up when you are mouse-dragging the slider, but unfortunately it does not show up if you adjust the slider using keyboard navigation. (Building in keyboard navigation was an effort and a learning process that we went through before you joined on -- it can be kind of a challenge in Flutter sometimes, sadly.)

Anyway, "show indicator on keyboard focus" could be a relatively big task so I am going to scope that as its own issue (here's the issue: #163). Possibly your next priority after this PR is done.

[Tbryant117]

So an issue that came up when changing the filter options is that the resources previously added do not have the new labels and so cannot be found using the new cultural responsiveness filters. I'm not sure what the best way to go around fixing this issue is.

[JavadocMD]

the resources previously added do not have the new labels

Yes exactly. We created a bit of a pickle for ourselves by storing this field in the database in a "de-normalized" form. Specifically: in this case resources contain both "culturalResponsivness" -- the integer value (unfortunately some typos made it into the implementation) -- and "culturalResponse" -- the label. It would be possible to design the filter queries and display logic to work on the integer value alone; had we done so there would be more front-end changes to make but no data changes required.

Now we could change the values in the database -- synchronized with the deployment we would need to run a script which alters existing records. It has to be synchronized because the previous app version can't run with the new data and the new app version can't run with the old data. And you don't want anything creating new data while you're in the process of deploying the change either. In some circles this is called a "database migration" -- mostly in relational databases which have a fixed schema where you're applying a change from one version of the schema to another, but this can involve transforming the data as well. (And not to be confused with the idea of migrating data from one database server to another, which is a different concept by the same name.) So our script would go through and update the value of "culturalResponse" in every resource document to match the new tag labels.

There's a more advanced form of this where you plan your changes to be backwards compatible which often involves separating changes into multiple stages -- the first deploy adds new data for the new app logic while being compatible with both, and second deploy removes the old data and old logic. This can be the right choice depending on circumstances but is an awful lot of work.

So for us I see two options --

1. change the rest of the client code to ignore the "culturalResponse" label and just use the integer value, or
2. write -- and remember to run at the appropriate times -- a data migration script.

Which would you rather do?

[Tbryant117]

I think changing the client code to use the integer value is probably the more elegant option although it's probably more work to get done.

[JavadocMD]

Yeah, same I think. Go ahead with that implementation. 👍