google / android-fhir

The Android FHIR SDK is a set of Kotlin libraries for building offline-capable, mobile-first healthcare applications using the HL7® FHIR® standard on Android.
https://google.github.io/android-fhir/
Apache License 2.0
465 stars 245 forks source link

Add "required" text for required fields in Questionaire #544

Closed Manikant25 closed 1 year ago

Manikant25 commented 3 years ago

Is your feature request related to a problem? Please describe. No this is just an enhancement.

Describe the solution you'd like Asterisks symbol can be added for the fields which have an attribute "required": "true". * indicates required fields as seen in the sample below.

Screenshot 2021-06-11 002613

Describe alternatives you've considered NA

Additional context NA.

Would you like to work on the issue? Yes

Manikant25 commented 3 years ago

@jingtang10 If you like the feature, then may I start with it.

epicadk commented 3 years ago

470 ?

Manikant25 commented 3 years ago

470 ?

470 does not show an asterisk for required fields.

jingtang10 commented 1 year ago

@Manikant25 thanks for raising this - this is now an urgent need from two implementers.

@Manikant25 please feel free to send a pr asap - if you don't have time @santosh-pingle will work on this.

Manikant25 commented 1 year ago

sure, I will try to send the PR by the end of this weekend.

jingtang10 commented 1 year ago

@shelaghm can you please comment on the UX design of this issue?

shelaghm commented 1 year ago

This makes sense to me. I assume it will also be important to pair the astericks * with instructions that say required question. We are planning to test this in an upcoming usability study to learn if people are familiar with what * means.

From a UX perspective I recommend making the * the same color as the question text. In an error state it can be red to indicate that a response is missing to a required question.

santosh-pingle commented 1 year ago

@Manikant25 Any updates would you like to share on it?

santosh-pingle commented 1 year ago

Looking into it.

santosh-pingle commented 1 year ago

This makes sense to me. I assume it will also be important to pair the astericks * with instructions that say required question. We are planning to test this in an upcoming usability study to learn if people are familiar with what * means.

From a UX perspective I recommend making the * the same color as the question text. In an error state it can be red to indicate that a response is missing to a required question.

@shelaghm Does it require to show in instructions if required field is true, as it is already being shown in question text? if yes, also is it ( in instructions) required to show in red color if it's in error state?

shelaghm commented 1 year ago

I suggest we use words to explain what * means by addingrequired question in the instructions text field.

Screen Shot 2022-10-04 at 10 37 57

Error state should look something like this screenshot. I don't think the asterisk needs to be red in error state, only the instructions text. What do you think?

Screen Shot 2022-10-04 at 10 40 29
santosh-pingle commented 1 year ago

I suggest we use words to explain what * means by addingrequired question in the instructions text field.

Screen Shot 2022-10-04 at 10 37 57

Error state should look something like this screenshot. I don't think the asterisk needs to be red in error state, only the instructions text. What do you think? Screen Shot 2022-10-04 at 10 40 29

@shelaghm what about instructions which get defined in questionnaire form? currently existing implementation only shows instructions if it is defined in questionnaire form.

jingtang10 commented 1 year ago

yeah agreeing with santosh we need to resolve this question: if there's already an instruction do we override it? or do we show both?

late to the party, but my experience as a user (i think mostly with html web forms) has been that the asterisk is always red. i think this is consistent with google forms too:

Screenshot 2022-10-07 at 11 59 04
shelaghm commented 1 year ago
  1. I'm convinced, let's make the asterisk red
  2. If there's already an instruction, I think we should show original instructions and display the error message below.

Rationale for 2 is an assumption that it will make it easier for users to know how to complete the question by showing the instructions and that we cannot rely on that the questionnaire builder to write an error message that will include comprehensive enough info. Do you agree with this assumption or have a different perspective? @santosh-pingle @jingtang10

Examples

Screen Shot 2022-10-07 at 11 58 43

Example that instruction text can be used for more than just basic instructions

Screen Shot 2022-10-07 at 11 59 55
dubdabasoduba commented 1 year ago

@jingtang10 @shelaghm @santosh-pingle I would advocate for the asterisk to also be in red. Most web forms and mobile forms use the red asterisk to denote required fields.

This would be easy to use for users since they are already used to it in the different apps and web forms they interact with.

shelaghm commented 1 year ago

@dubdabasoduba Thanks for your feedback, helpful to hear your experience! Red asterisk it is!

jingtang10 commented 1 year ago

@aditya-07 commented that when there's no question text, having an asterisk is very strange. i think @shelaghm and @santosh-pingle agree.

@shelaghm please advise how to proceed - we could either use flyover when there's no question text. or we can just add another line (maybe similar to the instructions) to explicitly say "Required".

shelaghm commented 1 year ago

I recommend using the flyover/ label text field to display the asterisk. Ideally also include *required in the help field/entry format field below the text box. This follows the Material design recommendations.

Screen Shot 2022-11-11 at 15 21 17
santosh-pingle commented 1 year ago

looking into it.

santosh-pingle commented 1 year ago

@shelaghm Some views does not have flyover attribute to show * in the view e.g boolean choice, single choice, multiple choice... Any thought how can we show asterisk in those views? may be instructions text or separate text line?

shelaghm commented 1 year ago

@santosh-pingle For all of these (boolean choice, single choice, multiple choice) I think there's a much higher likelihood that they will have a question title as it will be hard for people to know what they are answering without a question title. My recommendation would be to use instructions text field to show required question

Mocking it up, it looks a bit strange with no title, but with instructions showing required question My perspective is that this is an edge case I think developers should avoid and we should encourage the use of question titles :)

Screen Shot 2022-12-12 at 07 21 21
santosh-pingle commented 1 year ago

@shelaghm @jingtang10

Are we still going to show *required just below the view like

I recommend using the flyover/ label text field to display the asterisk. Ideally also include *required in the help field/entry format field below the text box. This follows the Material design recommendations.

Screen Shot 2022-11-11 at 15 21 17

@shelaghm @jingtang10 We had offline discussion in one of the internal developer call, where Jing, Omar and other internal developers discussed whether it is required to show *required text when * is shown in the flyover text, we did not have concrete conclusion yet, but you can help us to conclude on it.

shelaghm commented 1 year ago

@santosh-pingle Yes, show *required below.

In our usability testing we found that most participants either didn't notice or didn't know what the * means. So I recommend always showing required when there is a `` This is also consistent with material.io guidance

jingtang10 commented 1 year ago

can we just say required then without using *?

i feel asterisk is a shorthand for required when explained at the beginning of the questionnaire, if people don't understand it and we have to explain it every time, we might as well just simply say required every time without using asterisk.

shelaghm commented 1 year ago

@jingtang10 This is a good point. Hadn't considered removing the * until now. My only hesitancy is that many people are familiar with what * means and would expect to see it? But maybe it doesn't matter as it will reduce visual clutter and using the word required is much more meaningful. I'm open to removing the * and only using required instead. @jingtang10 What do you think? Any risk in removing the asterisk?

Why only use required text?

Why both * and required text?

jingtang10 commented 1 year ago

Thanks @shelaghm for the writeup!

First of all let me say, if (and I'm not saying that I necessarily think this is the right approach) we do add * and required, I don't think * needs to appear twice. At the moment it's added after the question text e.g Name * and then before required i.e. *required just below the question. This doesn't make sense to me. Having * required is an explanation of what * means at the beginning of the form like a graph legend. I think if we add the text required each time the * is present we should just do required and that's enough.

So now, the question becomes, do we add * after the question text. I think I'm much more open to having it if it's not repeated twice. Let's just do this?

shelaghm commented 1 year ago

Ahh, got it. @jingtang10 I think this is a good approach.

In conclusion: Keep * after the question text . But in hint text remove *required and just say Required

Screen Shot 2022-12-27 at 12 22 50

@santosh-pingle we've made a decision on this issue so you can continue the implementation.

jingtang10 commented 1 year ago

also just confirming that we don't want to show the asterisk in red anywhere right? just following the question text color.

shelaghm commented 1 year ago

@jingtang10 Yes, that's right. A few participants in the usability study were confused and thought since it was red that it meant there was an error. So I recommend changing it to same color as the text string to reduce confusion and not associate it with the error color.

jingtang10 commented 1 year ago

cool thanks for confirming @shelaghm @santosh-pingle fyi

jingtang10 commented 1 year ago

talked with @shelaghm on wednesday, i think we're thinking of jsut not showing the asterisk at all, and just use the required string.

dubdabasoduba commented 1 year ago

@rowo What are your thoughts on this?

HenryRae commented 1 year ago

@dubdabasoduba required questions should have no special treatment i.e * Only optional questions should have special treatment i.e have the tag "optional"

Screenshot 2023-01-13 at 18 34 43

Ideally, 90% of the questions will be required, and we don't want to have these repetitive symbols(worse if they are colored) allover the screen.

@shelaghm any thoughts on this?

HenryRae commented 1 year ago

Adding this here as well.

No, we shouldn't do "*" on very required question. We should only show "(optional)" for questions that are optional. In summary: only questions that are optional will be treated different thus will have optional tag. Required questions shouldn't have anything to show they are required. They should return an error if user tries to submit a form with none optional fields not filled See attached example for all required fields. Only return errors that they need to be filled when user submits a form with one of the fields empty image

Only optional questions should have a tag. And that tag is "(optional)" as shown in the screenshot. When these are not filled(fields with optional), we should allow user to submit the form if there are no other errors image

shelaghm commented 1 year ago

Thanks @HenryRae for adding your thoughts and raising that Optional might be a better pattern to follow. I agree that showing (Optional) is more helpful than required in the scenario where almost all the questions are required and only a few questions are optional. We have this guidance in (our soon to be shared) design guidelines, where we mention using optional instead of required when that is the case.

Required label makes sense in the inverse scenario where most questions are optional and only a few are required. I'm not sure how common this is in these types of questionnaires and if we should support both options (required and optional)?

My question for the group is if there's still value in having the opportunity to mark questions as required?

rowo commented 1 year ago

As a principle for form content, I think (and try to convince health teams) that anything optional should just be removed for CHWs. And it's the case that there are only a few optional questions most of the time I've seen.

Though, it is safer to have an option for marking required questions to cover of all the bases and I guess I could think of times where people would want to use it. Maybe in forms that aren't done often and maybe more for settings/options or communication preferences?

I wonder how much complexity it adds to people trying to configure the app. Are we able to default with the guideline approach? Is this a per form configuration (rather than entire app)?

shelaghm commented 1 year ago

@rowo +1 to

As a principle for form content, I think (and try to convince health teams) that anything optional should just be removed for CHWs. And it's the case that there are only a few optional questions most of the time I've seen.

Thanks for chiming in with your experience and reflections.

From a questionnaire authoring perspective, questions are indicated as required in the code, so that we can show the appropriate error messages if they are incomplete. So for me, the key takeaway is that showing an error message is more helpful than displaying *, required, or optional if someone hasn't completed a required question. Error messages are helpful because it helps people know how to fix the error.

I'm weary of that the FHIR SDK needs to work across different country contexts, use cases and users, so I don't want to hastily remove functionality that's critical for some developers.

Seeing required everywhere gets very repetitive for a form that people are completing several times a day. Which is a bit different from a consumer form where they are completing it only once and then knowing what's required or not is likely more helpful.

I'm leaning towards that the default should be to not show anything additional for required questions (eg no *or required) and instead rely on error messages if something is incomplete.

Will discuss with @jingtang10 when he's back to make a decision on next steps.

shelaghm commented 1 year ago

Aligned with @jingtang10 Our proposal is that this needs to be configurable, so that developers can select if they'd prefer to display required or optional. Default display should be required. Configurable setting for optional.

jingtang10 commented 1 year ago

Let me just add that FHIR by default assumes questions are not required unless stated otherwise. So that is at odds with the pattern Roger described which is that questions should be required by default and there should be as few optional questions as possible.

So I think we probably would have to be a bit neutral here - as in not assuming most questions are required by default, or optional by default. And if we want to do anything, as Shelagh said, we'd probably make it configurable.

shelaghm commented 1 year ago

@HenryRae shared with me that at Ona they would like to add the required asterisk within the placeholder of textfield (not at the end of the question title.) I know we had discussed that if there is no question title that the required label would be displayed as part of the text field placeholder. When thinking about making this component configurable, this would be another aspect to consider where the required label would be placed.

@santosh-pingle Would this be possible in our existing/current approach?

Attaching screenshot below

Screenshot 2023-03-13 at 15 40 02
santosh-pingle commented 1 year ago

Looking into it.

santosh-pingle commented 1 year ago

@shelaghm

santosh-pingle commented 1 year ago

@jingtang10 Considering the approach below, the application will update the bundle with the following value to the questionnaire fragment :

Pass a boolean value of 'true' as an argument in the bundle to differentiate the optional questions. Also, include the optional text as a string value in the bundle (e.g., 'Not required'), if the value is not present, use 'optional' as the default text.

e.g Q.1 National Id (optional)

santosh-pingle commented 1 year ago

@HenryRae shared with me that at Ona they would like to add the required asterisk within the placeholder of textfield (not at the end of the question title.) I know we had discussed that if there is no question title that the required label would be displayed as part of the text field placeholder. When thinking about making this component configurable, this would be another aspect to consider where the required label would be placed.

@santosh-pingle Would this be possible in our existing/current approach?

Attaching screenshot below Screenshot 2023-03-13 at 15 40 02

One approach is to pass 'true' as the value to the 'labelPlaceholder' argument in the bundle for the QuestionnaireFragment. If the value is not present, it will be shown next to the question text.

santosh-pingle commented 1 year ago

Closing this issue as I have opened issue #1954. thanks!