Add a flag to extend validation API support for questionnaire validation.

[aurangzaibumer]

Is your feature request related to a problem? Please describe. Add a flag to validate questionnaire response according to provided validations on submit button onClick event response prior to onPostSave method of QuestionnaireViewModel method.

Describe the solution you'd like A clear and concise description of what you want to happen.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

Would you like to work on the issue? Please state if this issue should be assigned to you or who you think could help to solve this issue.

[aurangzaibumer]

@f-odhiambo @jingtang10 Created a ticket for extending validation API support for questionnaire

[f-odhiambo]

New ticket as a follow up to ticket #1001 CC @Tarun-Bhardwaj

[aurangzaibumer]

based on discussion with @jingtang10

These are the points that needed to be incorporated in this PR

1. Having submit button on the questionnaire where submit flag's logic will imply
2. Having Next/Previous button where pagination flag's logic will imply
3. Need to have two flags that will work as below

submit boolean -> if true -> would not allow user to submit the questionnaire without filling all the required fields pagination boolean -> if true -> would not allow user to move to next page until all required answers are given the configuration (flags) can be controlled by the developer

cc @f-odhiambo

[jingtang10]

@joiskash

[joiskash]

Sounds good, just wondering where these flags will be passed? Is there scope to use the strategy pattern? Such that developers will have more flexibility and can implement their own Strategies apart from the default described above.

@shoaibmushtaq25

[shoaibmushtaq25]

Sounds good, just wondering where these flags will be passed? Is there scope to use the strategy pattern? Such that developers will have more flexibility and can implement their own Strategies apart from the default described above.

@shoaibmushtaq25

Hey @joiskash , I don't have much details about it but I think, @jingtang10 can better comment on that as @aurangzaibumer and @jingtang10 were having these discussions while working on PR#1102

[aurangzaibumer]

hey @joiskash, I'm currently doing research on how I can implement the logic on buttons to apply the validation, once I complete with it, I'll think about how I'll be passing those values to the questionnaire. Can we connect on monday if you are available. Would like to discuss with you the approach. thanks

[joiskash]

Sure you can just ping me on email / google chat - [email protected]

[aurangzaibumer]

Based on discussion with @joiskash

There should be a strategy pattern applied to have a full control by the developer to change the implementation according to the needs, implementation (business logic) that are provided for the buttons.

[jingtang10]

@shelaghm as i just commented in #1301, the correct UI behavior we think should be to grey out the prev/next buttons if navigation is not allowed. The thinking is that we should make the UI as responsive as possible, providing the user instant feedback. so that it's much better to grey out the next button if we do not allow the user to go to next page due to incomplete questions, than to allow the user to click it and then pop up some kind of error message. hope you agree.

[shelaghm]

@jingtang10 Would there be an error message in-line that would give users responsive feedback on what they need to fix in order to move to the next page? Or how would users know what to do to no longer see a greyed-out button?

After connecting with some accessibility designers and learning from what other teams that have done in a similar scenario, there's a recommendation to avoid greyed-out / disabled buttons. I think I've included some greyed-out buttons in the past mock-ups, but after taking the time to learn more I've shifted my perspective away from greyed-out buttons. The recommended behavior is to have an active button and after users click the button show an in-line error message of what needs to be fixed. That way we can give them better guidance on what's wrong and how to fix the problem. The error message preference would be in-line, not in a pop-up message. The other benefit of having a clickable next button is that we can update the error message each time (unless error messages are already responsive and don't require a button to be clicked?)

Why?

• Encountering a disabled button can be frustrating due to the lack of feedback on what they should do. It's often not obvious that it is disabled, so people keep clicking and get no feedback and don't know what to do. Sometimes people abandon the whole flow and start over because they can't figure it out.
• Disabled buttons don't show up on screen-readers / voice over. Alternative here is to code it as a "dimmed button" so it is still discoverable. https://a11y-101.com/development/aria-disabled
• Greyed-out buttons can be hard for people with low-vision or color-blindness to see or if the interface is being used in bright sun conditions.
• An external link that's helpful https://axesslab.com/disabled-buttons-suck/

Curious to hear your thoughts

[jingtang10]

@shelaghm thanks so much for this - super helpful insights.

i think the only concern i have is that if there's enough feedback so the user knows that they're being held on the same page because of the validation errors. we show the validation errors as the user goes through questions. So there might need to be a little bit of additional UX (i've seen on some web forms with flashing errors when you press next... yuk... or an additional summary box on top of the page that lists all the validation errors that need to be fixed. either way it's more work which i don't like.) but i guess this can be P2.

but yes i agree with your reasoning and arguments about disabled buttons - very strong and valid points - thanks for the reply.

@aurangzaibumer let's reflect this in the pr.

[jingtang10]

@joiskash @aurangzaibumer please see https://jira.hl7.org/browse/FHIR-37497

looks like the standard will likely reuse entry mode extension so that the questionnaire can either be answered in a random fashion (you can navigate wherever you like) or in a sequential fashion (you have to answer a question to go to the next question/page).

given this i strongly recommend that we remove the PageChangeStrategy interface and use an enum based approach.

[joiskash]

Ok that seems like the right thing to do !

[jingtang10]

@shelaghm

The inline messages will be displayed along with questions. but here i have a question:

should there also be a global error message that says something like: "please fix errors in the current page before proceeding"? this tells the user what they need to do. instead of just showing a bunch of errors for each question.

if so, where should that be?

also, there is a mode where we do not allow the user to go to the prev page (it's in the fhir standard, called sequential entry mode, where you just answer one quetion after another and can't go back.). in this case, we can reuse the global error message and just explain: you're not allowed to go back in sequential mode. or something.

what do you think? do we need some ux design for this? or should we use something like toast?

[shelaghm]

@jingtang10 In the scenario where the user has errors in the form, I think it will be useful to display a dialog after they click "next" and then show the dialog since they cannot move forward because of the errors. Would we be able to show a bulleted list of what info they need to complete or just a generic message? Would be amazing to list what fields need to be fixed, so it's easier for them to navigate to that part of the form.

I think a dialog is most appropriate here because a banner at the top of the form it might not be seen and there's a specific action we need them to take to move forward. It also gives an immediate explanation for why they cannot move forward when they press next. At first I was thinking we could have a banner at the top (or bottom) of the form with global instructions, but I worry it will be easily missed depending on where you are in the form.

This material design documentation has helpful guidance on when to use a snackbar, dialog or banner See the table.

Regarding sequential entry mode, this seems more like instructions and there's less of an action or decision we want them to make? For this I'm leaning towards a banner that they can dismiss or learn more about. Toast/Snackbar is often meant as a status update and automatically disappears. The auto disappearing can be frustrating for users if they missed it and then have no way of finding the message again. What do you think?

[jingtang10]

Thanks @shelaghm for the useful input.

One thing to clarify is that, the entry mode controls the behavior for next/prev buttons. if entry mode is random -> user can freely navigate to any page if entry mode is sequential -> user can only answer one question at a time, no free navigation (even to go back) if entry mode is prior-edit (i don't like this name) -> user can navigate forward if current page is completed and validated, and user can go back to change answers, but if they haven't completed current page or current page has validation errors, they can't go forward.

so at least for a first version, can we have a unified UI just for ease of implementation? sounds like we might need that bulleted list in either sequential or prior-edit modes?