19

When using the debounce() operator for form validation how long should the debounce timeout be? I currently have mine set to 400 milliseconds but idk if that is too short.

  • 3
    To clarify, your question is asking "when using real-time form validation, how long of a delay should there be after an invalid input is entered and before a user sees the error feedback?" correct? – maxathousand Jun 7 '16 at 18:13
  • Yes that is correct @maxathousand – toobsco42 Jun 7 '16 at 20:57
  • You might need to experiment and test with a few people to see what they think. Choose three delay times, e.g. 200ms, 400ms and 600ms and see which one people prefer. – SteveD Jun 8 '16 at 10:28
24

TL;DR

Get user feedback, get user feedback, get user feedback. 500ms is a good starting point.


Your answer will most likely vary depending on your application's purpose and platform it's being run on. In general, you want to provide the user feedback as soon as possible on whether they're doing something incorrect (an improperly formatted email address would be a good example). Additionally, the benefit from having quick feedback on form validation is that they know immediately which field is improperly filled out (as opposed to finishing the form and then being notified that some field somewhere is missing).

So with that being said, let's consider various use cases and platforms, and potential pitfalls of having your debounce being too short/long.

Problems with too short of a debounce

If you had a debounce that were to execute in under 200ms, to the average user, this will appear almost instantly. The result would be a user who is just starting to type in their email address, and them instantly being told it's in an incorrect format. Imagine back to when you were a kid, and your parent is mopping the floor, and before they're finished, you say, "Missed a spot!"... They're not going to take too kindly to that. Similar concept here.
Moral of the story, don't make your debounce too short. Give your user some time to fully fill out the field.

Problems with too long of a debounce

Now let's consider the other side of the time spectrum. Again, you're filling out the email field, and it's the last field on the form. You type away (but little to your knowledge, you typed incorrectly), finish the form, click submit, and wait a second as the form submits... Only to then be greeted by the "Incorrect field" error (womp womp).
This is a case of waiting too long. The user entered a field and their focus moved on. To have to drag the user back to a field will make them feel like they're not making progress (you want forms to have a sense of progress, to let the user know they're getting things completed).
Keeping with the household chores example, in this case, imagine you're told to clean your room and the bathroom. You finish your room, and are half way into the bathroom when your parent walks in and says you did a terrible job of cleaning your room (turns out you can't just throw everything under the bed). Now you have to go back to your room, only to then go back to cleaning the bathroom. Doesn't feel like progress is being made.

Balance

So, we have our two ends of the spectrum.
On one end, we have the jabber mouth "You're doing everything wrong" debounce.
And on the other end, we have the "Hey, come back here" debounce.
Both of those are not desirable. Rather, we want a debounce that acts as a guide. As we're doing our job of filling the form out, it tells us (after we've completed task) whether or not we did it correctly. We finish making the bed, and then our parent tells us that we've done a good/terrible job.
So conceptually, that's the problem we're trying to solve.

Answer

Keep in mind that people vary in they're typing speeds. Some people will probably be at the lower end of 20 words a minute, while others will be blazing fast at over 100. Additionally, if you're going to be working with mobile, people generally type slower on mobile than they would on a keyboard (I'd still be typing this up if I were on my phone...). All these things influence your debounce time.

If your debounce time needs to vary significantly due to different typing speeds, alternate approaches might be applicable (such as a 'onFieldLeave' kind of callback).

Without information on what kind of platform/audience you're addressing, a half second (500ms) debounce can be a helpful starting point. You want to give the user time to fill out a field, but capture their attention before they move on past it. 2 second (2000ms) might be too long depending on how fast people type, and 200ms would be an eye blink (both situations we've already covered).

Like @SteveD suggested in the comments, you really should have some user testing to find which debounce time works best for your application. Have a few different times, and get feedback. Nothing beats the cold hard answers you get from user feedback.

Here's a quick article to give you an idea of human reaction times, might prove insightful. https://www.nngroup.com/articles/powers-of-10-time-scales-in-ux/

Update 1

There's a useful site documenting some basic UX laws (https://lawsofux.com). Check out the one on something called the Doherty Threshold, it might prove useful for gauging interaction time.

  • 1
    Great explanation! It's tricky to get this timing right, good that you call out the "blur" event as an option. – looshi May 21 '18 at 19:15
  • Do you have any recommendations for Copy/Paste input fields? I feel that 500ms is too much for those. Suppose the user needs to paste its public key, which is a very long string that nobody types. Is 200ms more reasonable in this case? – aviggiano Jun 1 '18 at 11:04
  • 1
    @aviggiano, if you know that a field is going to be copy/pasted, sure, 200ms would be fine. But you could go the extra mile with javascript to detect when text has been pasted into an input and automatically trigger the 'change' event. – Andrew Jul 6 '18 at 19:43
  • From my experience from 280ms to 320ms (max) is the best debounce timeout. – Ivijan Stefan Stipić Mar 18 at 7:49

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.