7

I've seen two types of behaviour circulating; one where the error state disappears as soon as you start typing a new input (so when the input field is in focus), and one where it stays until the input is 'accepted' (for example, a valid email format is typed).

I can imagine it is beneficial to keep the error state's context until the user has fixed their input, but my team has built it the other way around.

Which interaction is preferable and why?

Edit: Here's the error state I currently use: Error state of input field

Currently the built version removes the error state (and returns it to its normal state) as soon as it is in focus. I intended for the error state to stay until the input of the field had been 'corrected'.

Improve this question
4
  • 3
    As error messages should contain enough information for the user to know how to fix it, the message should stay until it is fixed.
    – jazZRo
    Jul 2, 2019 at 9:43
  • Yes, that was my reasoning behind wanting it to stay as well, but I started to doubt my choice as my team built something else instead...
    – Wendy Wojenka
    Jul 2, 2019 at 13:09
  • This is good but the word Invalid Input must not be inside the field it must replace the error message below the field. and keep what inside the field as it is until the user changes it. bad thing to replace your message instead of the user text.
    – Khalil Hanna
    Jul 2, 2019 at 13:36
  • This was just an example of the component @KhalilHanna, I'd never dare to edit a user's input without their strict desire to do so.
    – Wendy Wojenka
    Jul 2, 2019 at 13:51

3 Answers 3

Reset to default
8

The error message should stay.

There is a design principle 'recognition rather than recall'. Meaning the user should not be forced to remember things but rather give the information (or options) needed to complete the task. Someone could argue that often the error is quite easy to understand like 'insert a valid email address' or the like. But it can also be more complex like password rules (well, they should actually be communicated before but just as an example). A user might need this reference while typing. Taking away this information is a pain for the user.

So it is better to show the error message up until the input is valid. The validation info should disapear as soon as the input is correct (do not wait until the 'lost focus' this would be confusing).

Improve this answer
2

Great question, I partly agree with @BrunoH here.

The 'Recognition rather than recall' heuristic makes it easier for the users to remember what they did wrong. However, there is a 'bad' side to this. If the user is interrupted during the error correction process, for instance: They get a phone call, the doorbell rings etc. they might think the current input is wrong.

This is where the heuristic 'Visibility of system status' comes in to play, I believe the notification should change when a correct input has been given to something that confirms they did the right thing.

enter image description here

I've created an example with what I mean, if I got interrupted after changing the input I would see an error message. With the notification of the system status I would see that my input is correct.

As a final note, I would try to incorporate the previous error in the status text ('Recognition rather than recall'). So in my example I say 'is not taken' while the error message was 'username is taken'.

Improve this answer
0

I think better to let the system listen to your keyboard, the moment you start filling the field it starts to check. For example, you need to fill your email, when you start to type it will keep the outline red around the field until you type "@" sign and after. This way already in use and you can apply it. Please check the images:

Before the @ sign

enter image description here

After the @ sign

enter image description here

For Clarification: You can't apply this approach for all types of forms this is just to show one of the on-fly verification techniques used for limited purposes like applying for a new job form, which depends mainly on the email.

Complicated forms used for example in banking systems can't use this type of verifications, it will keep it until you hit submit.

Improve this answer
7
  • Can you elaborate your answer? I'm not making any use of pop-ups or messages with close buttons, just a red coloured border around the 'offending' input field with an error text underneath associated with the input field. My issue is mainly that I decided to go with having the state stay until the input was corrected to something valid, but my team built something different and that caused me to doubt whether I made the right choice. I'll edit my question a bit to make it more clear.
    – Wendy Wojenka
    Jul 2, 2019 at 13:12
  • I am a little confused. So when do you display the error and the border becomes and stays red? Once the user navigates to the field and start typing you display the error and have the border red till the "@" is typed?
    – Mo'ath
    Jul 2, 2019 at 16:55
  • Actually yes, this field type start with a red line around, and it will keep showing red until you type the first character after the "@" sign, so in this case, the system will detect that the field will include an email
    – Khalil Hanna
    Jul 2, 2019 at 17:07
  • 1
    One problem with this approach could be that if you also use the same validation style for business rule violations decided on the server, then you would also need to do those validations as the user is typing. Which could be difficult if the business validations take longer than a few miliseconds, or if they are based on the combination of several different user input fields. What you want to avoid is some error messaging changing as the user types (like your email example above) where other error messages stick until a real post back.
    – Graham
    Jul 2, 2019 at 17:28
  • You are right I agree that it's not a practical thing to apply this mode of checking on all field which needs special verifications for complicated forms, and the solution is to keep the checking on the end when moving to next step or in submission. For this reason, this type is used for simple forms like submitting your CV for a recruiting agency so the number of the field is limited and the email very important. So every case has its own circumstances.
    – Khalil Hanna
    Jul 2, 2019 at 19:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.