Skip to content
This repository has been archived by the owner on May 2, 2022. It is now read-only.

Question design #430

Open
bertrandlalo opened this issue Mar 28, 2020 · 1 comment
Open

Question design #430

bertrandlalo opened this issue Mar 28, 2020 · 1 comment
Assignees

Comments

@bertrandlalo
Copy link
Contributor

(France) Many users have given me those feedbacks:

  • Symptoms should be dated (either roughly, or one by one)
  • Symptoms could be more precise
  • Users should be able to manually add other symptoms they add (even if not common)
@bertrandlalo bertrandlalo added enhancement New feature or request design labels Mar 28, 2020
@bertrandlalo bertrandlalo self-assigned this Mar 28, 2020
@fossecode
Copy link
Member

Thanks for valuable feedback! I have some thoughts/questions:

  1. If you check that you have a symptom, you will get a datapicker for selecting symptom start. That is although shared for all the symptoms, it could possibly be valuable to select start date per symptom. This would however require quite a lot of changes in or data structure, design etc. But absolutely something we should discuss.

  2. Do you mean to add more options, or could you be more precise in the translation of the options?

  3. After attending a GDPR course, I learned that free text input fields are in general very risky in cases such as this. You risk that the person writes something that is PII, and that is something we do not want (or are allowed to store). It is also harder to use unstructured data for analysis and predictions, as we would either have to try and classify the input or have an expert manually classify them.

@fossecode fossecode added discussion and removed design enhancement New feature or request labels Apr 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants