Input field validation (success)

[Porlin]

The specific questions I have are...

• How can I style the input success validation to align with Paste?
• Are there any concerns with how I've designed the success validation?
• Is this pattern used in Console? why or why not?

Background: We want to include the input field validation (success) pattern in Flex. This enables the user to see whether or not the input field is valid or if there is an error. This is to confirm to the user that the action they have taken is successful or not.

This pattern combines a 'tick icon' with text in the applicable color (green), and lives underneath the input field.

Stage of design: High-fidelity and exploration
Research: Ongoing
Previous usability testing for the Plugins Dashboard ‘Pending release’ panel
Links to mockups or prototype: In situ examples in Flex

[TheSisb]

Hi @Porlin,

How can I style the input success validation to align with Paste?

All you can do right now is pass a "success" colored icon to the HelpText under the input field. It isn't possible to change the input border color since we don't allow that currently. It is possible to wrap the HelpText with a Text component to change the color, but this doesn't pass color contrast ratios for accessibility so we don't suggest doing that either. Would changing the color of the icon in the HelpText be enough?

Are there any concerns with how I've designed the success validation?

A few thoughts:

• One concern is that the success icon may confuse users into thinking the field was saved in some cases, before hitting the save button on the form. This pattern is more commonly seen for fields that save immediately, without an explicit form submit action, which I didn't see in the mockups. In the case of fields that save immediately (onBlur), then I think a Toast may be a better UX solution.
• I'm curious what user research/usability results come out of this pattern. Are users getting sufficient information by seeing the form fields not turn red when there's an error, or is a specific success state also necessary to reduce anxiety? How are you thinking about when to surface the success state and when to just leave the field in the default state?

Is this pattern used in Console? why or why not?

This pattern is not used in Console. I believe it's because of the concern I listed above, in that it can cause users to think the field was saved without hitting the "Save" button on the form.

---

While we haven't seen any demand for this pattern thus far, but we'll be monitoring to see if there's any need in the future.

[Porlin]

Hey Shadi,

Thanks for the reply. I have made an example of your suggestion for the "success" coloured icon to the HelpText under the input field - see example 'Input field validation-1a.mov'

I do think it works and might be enough however, feel it would be helped with a green border. My concern is that it's not as noticeable now. I made 'Input field validation-1b.mov' that includes a darker green for the border so it's clear on white. This pattern is for fields that save immediately before a user hits 'submit' or 'enter.' This is to confirm to the user that the action they have taken is successfully valid or if not the red error state would appear.

From previous testing in the plugins dashboard it was clear for users that they needed to take action on the input fields (ie. enter a friendly name and enter a description that was more than 2 words in length) The tick validation made it clear to some users in testing what's going to happen when they click on the 'Submit' or 'Enter' button.

Let me know your thoughts on the examples attached.

Input.field.validation-1b.mov

Input.field.validation-1a.mov

Porlin

[TheSisb]

Hi @Porlin,

This pattern is for fields that save immediately before a user hits 'submit' or 'enter.' This is to confirm to the user that the action they have taken is successfully valid or if not the red error state would appear.

I'm a little confused by these two sentences. The first sentence describes the field saving on change (saving to the server), while the second contradicts the previous sentence by claiming this functionality is for validation. If the field saves on change, I think a toast may be a better interaction.

The tick validation made it clear to some users in testing what's going to happen when they click on the 'Submit' or 'Enter' button.

So if the green success variant is for validation as mentioned here, we must consider when to validate. Is it on keypress (every time a new character is entered into the input) or on blur (when the user tabs or clicks outside of the input)? It wasn't possible to determine the exact behavior from the video because of how it cut and jumped.

If it's on keypress, it's unlikely that the validation will be server-sided. It will likely only be client-sided, meaning the validation runs in the browser. In this scenario, the user may still receive an error when submitting the form, since the server is the source of truth, and the client is only a best guess. In other words, client-sided validation will tell users that an email is is correctly formed (has an @ and a .), but won't tell the user that the email is already taken until submit.

If the validation happens on blur, you can likely fire a request to the backend to display full validation. I still have some concerns in this scenario:

• I haven't seen any implementations of this at Twilio so far
• It requires additional work from engineering to build an endpoint for validation, and the UI has to handle network request error states and long response times with a spinner.
• This may only benefit sighted users, since keyboard users will have to tab to the next field for any updates to happen, so they'll miss the information.

Generally, there's still the concern I mentioned in my initial message that some users may misinterpret the validation for a real-time save, which will cause them to exit the modal from clicking outside or by clicking the X without saving.

Hope this helps clarify some of my thinking further.

[Porlin]

Thanks for the feedback Shadi. And to clarify - this functionality is for validation.

So if the green success variant is for validation as mentioned here, we must consider when to validate. Is it on keypress (every time a new character is entered into the input) or on blur (when the user tabs or clicks outside of the input)? It wasn't possible to determine the exact behavior from the video because of how it cut and jumped.

I just added a screen recording of the plugins dashboard implementation in Flex and it's on blur - see attached.

Input.fields.1.mov

We're not using toast at the moment in Flex but will have a conversation with the team about it.
I also plan to do testing for the username/password screens you seen above, I'll frame some questions about the validation. It may well be that a lack of an error message should be enough to assure a user that their entry is valid.

[serifluous]

Some very quick 2¢: If the customer needs the validation on blur and you're finding that the green icon alone isn't strong enough, you also have the option of bolding the help text and changing it to a darker color, like the default text color ($color-text).

[Porlin]

Thank you @serifluous will try that too :)