Open Blackbaud-ToddRoberts opened 5 years ago
This problem has been asked about several times before, especially around trying to click the "Cancel" button on forms because the whole form shifts down and you end up clicking just above the "Cancel" button.
I think the biggest problem/offender is "required" fields because they trigger validation simply by clicking in/out of the field causing the form to jump as you navigate around. I've noticed that some forms have done away with "required" field messages, and instead only highlight the "required" field. I know the SKYUX design guidelines currently say to always include a message, but I feel like this may be a good compromise for "required" fields. Certainly, forms will still have other field validations which will still cause the form to move around, but they should be less common than the "required" fields and possibly will not fire their validation simply by clicking in/out of fields.
Some other ideas I've heard (but not seem implemented) are:
I've mocked up some examples for reference.
Here is a form with the current error strategy:
Here it is with the errors displayed:
The first suggestion is to reserve the space the error will take up in the current pattern by giving it visibility: none
instead of *ngIf="false"
:
If we're okay with all that spacing in all our forms all the time, then it might be the right method. Though it does look rather odd having seen the original. This one avoids any element position shifting by always taking up the space it might take up.
Here is a little mock up of the popover error:
The two suggestions here are either have the popover show up and always display next to or below the errored field (until resolved). Or have an icon show up and either hover over it or click it to see the popover. This one should completely avoid any element position shifting since the popovers will be above the page instead of inline.
@Blackbaud-ToddRoberts Are there any updates on this issue?
We're running into this too. Is there any guidance here?
No updates, if you have a designer you can work with to go through the pattern process for this that'd be the quickest approach, if you don't have a designer let me know and I can try again to find someone to pick it up.
I have a fraction of a designer who's also a manager 😛. Any help would be welcome.
@Blackbaud-ToddRoberts Any updates on this issue? Now that a few teams have weighed in on having run into this?
Still trying to find a designer to pick it up
My team just wanted to +1 this issue. We'd like to resolve the less than ideal experience that affects so many modal experiences across the whole solution.
Are we still just waiting on a designer to pick it up?
@Blackbaud-ToddRoberts Any more updates here? Would really like to start using popovers or something instead.
FYI: we have a UX designer actively working on a solution to this. We'll update the issue as soon as we hear anything.
Thanks, Steve! :D @Blackbaud-KrisMahon It's happening!
If a field has validation set to fire on loss of focus, if a user tries to click on a field or button below the click will not always register as the field/button shifts down when the error message for the above field appears. Look at alternative ways to display error messages that won't lead to shifting fields/buttons.
Problem raised by @blackbaud-conorwright