Closed Manikant25 closed 1 year ago
@jingtang10 If you like the feature, then may I start with it.
470 ?
@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.
sure, I will try to send the PR by the end of this weekend.
@shelaghm can you please comment on the UX design of this issue?
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.
@Manikant25 Any updates would you like to share on it?
Looking into it.
This makes sense to me. I assume it will also be important to pair the astericks
*
with instructions that sayrequired 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?
I suggest we use words to explain what * means by addingrequired question
in the instructions text field.
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?
I suggest we use words to explain what * means by adding
required question
in the instructions text field.![]()
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?
@shelaghm what about instructions which get defined in questionnaire form? currently existing implementation only shows instructions if it is defined in questionnaire form.
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:
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
Example that instruction text can be used for more than just basic instructions
@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.
@dubdabasoduba Thanks for your feedback, helpful to hear your experience! Red asterisk it is!
@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".
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.
looking into it.
@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?
@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 :)
@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 thehelp field/entry format
field below the text box. This follows the Material design recommendations.![]()
@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.
@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
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.
@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?
*
and required
is redundant and makes the form look more cluttered.required
is more helpful and meaningful to people than just an *
*
is meaningless to many people without the explanation, so why include to begin withWhy both *
and required
text?
*
as a pattern to indicate required than those we tested it with*
is a common pattern across web forms and many expect it*
symbol is a quick way to notice if it is requiredThanks @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?
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
@santosh-pingle we've made a decision on this issue so you can continue the implementation.
also just confirming that we don't want to show the asterisk in red anywhere right? just following the question text color.
@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.
cool thanks for confirming @shelaghm @santosh-pingle fyi
talked with @shelaghm on wednesday, i think we're thinking of jsut not showing the asterisk at all, and just use the required string.
@rowo What are your thoughts on this?
@dubdabasoduba required questions should have no special treatment i.e * Only optional questions should have special treatment i.e have the tag "optional"
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?
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
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
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?
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)?
@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.
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.
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.
@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
Looking into it.
@shelaghm
@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)
@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
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.
Closing this issue as I have opened issue #1954. thanks!
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.Describe alternatives you've considered NA
Additional context NA.
Would you like to work on the issue? Yes