Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error catching in user_categorisation.R #82

Closed
RayStick opened this issue Apr 10, 2024 · 2 comments · Fixed by #104
Closed

Error catching in user_categorisation.R #82

RayStick opened this issue Apr 10, 2024 · 2 comments · Fixed by #104
Assignees
Labels
enhancement Feature improvement or addition

Comments

@RayStick
Copy link
Member

RayStick commented Apr 10, 2024

'Categorise this data element into one or more domains, e.g. 5 or 5,8:'

No input will break the code (it accepts anything and reads it in as a string) but it would be good to catch silly input errors and feedback to the user, so they don't get saved in the csv. However, the review stage mitigates this somewhat (i.e. a user may spot an error in the review stage and correct it themselves)

@RayStick RayStick self-assigned this Apr 10, 2024
@RayStick RayStick added the enhancement Feature improvement or addition label Apr 10, 2024
@DDelbarre
Copy link
Collaborator

After some user testing, I have a few suggestions related to this issue.

When users are entering codes while using domain_mapping, validating their choices against the list of domain codes would help to improve the quality of the responses by ensuring that only valid options can be selected. Currently, anything the user enters is accepted

@DDelbarre
Copy link
Collaborator

When the user enters multiple options, it would be useful if there could be some control on how the options are interpreted (and subsequently saved in the log file). For example, by stripping out whitespace so that the following would all get interpreted the same way, and also accounting for users accidentally using the wrong field separator:

  • "3,6"
  • "3, 6"
  • "3 6"

Additionally, if one user enters "3,6" and another user enters "6,3", then when the log files are run through compare_csv_outputs, they are currently treated as different sets of options. This could be remedied by having the options sorted before they are saved to the log files (so for the example above, both users would have had "3,6" in their log files even though they entered them differently).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature improvement or addition
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants