Validate while typing or after entry?

Coordinator
Sep 9, 2008 at 11:42 PM
Edited Sep 9, 2008 at 11:47 PM
Do you think the control should call the validation service periodically while the user types the desired username, or only after the user types it and moves to another field?

We could implement it as an onchange handler or an onkeyup handler that triggers the validation call after ~500ms of inactivity in the field. 

Which would you prefer, if you were using the control?
Sep 10, 2008 at 12:21 AM
I would actually prefer both, whichever event comes first (put it on timeout onkeyup and also onchange, and when onchange fires, check if it's already been validated by onkeyup and if not, stop the timeout and validate right away). If I stop typing for a second, I'm probably done entering so it should validate. If I tab away and the field loses focus, I'm done enterins so it should validate. In any case, I would like to get confirmation of username availability ASAP after I'm done entering, and having it wait half a second or a second to start contacting the server after I tab out (if the only implementation is to do it onkeyup after a timeout) would cause the appearance of lag.
Sep 10, 2008 at 4:03 PM
I see no advantage in verifying while typing (*).   What we are doing here is very different from an autocomplete, where a partial name brings the desired name closer.  Here a partial name is useless to us.  We should only be looking up a complete name, and the only definite way to know the user is done is on blur.



(*) One exception to this:  Verifying while typing could be useful if we were to provide a "list of unavailable usernames similar to what you've entered", e.g., I type in "James" and am shown a list stating that "James", "JamesJr" and "James4ever" are already taken.  But I think that's a bit beyond what we hope to do here.
Coordinator
Sep 10, 2008 at 9:35 PM
James, I think suggested available usernames would be a great feature, if we can come up with a reasonable algorithm for suggesting the alternatives.

If I tried DaveWard, it was unavailable, and the app suggested DaveWard01, that wouldn't be very helpful to me.  I'm really not sure what automatically generated options would be useful, for that matter.
Developer
Sep 11, 2008 at 12:30 AM
If I were using the control, I don't think I would want it to wait for me to leave the control before it validated the entered username. In a crowded membership environment, if I have a common name, e.g. Dave Smith, the username DSmith is going to be unavailable. So I might try DASmith, DaveSmith, DaveASmith, etc. before I'm able to find a username that's available. If I have to leave the control each time in order for it to check availability, that'd bother me a bit.

I also think a 500ms wait on the keyup event is too long. If I'm changing a character here and there to find a username that's available, 500ms is a long time to wait. I think an instantaneous request is better. The control can be smart enough to know if the response that it received is the response from the latest request it made and if not, ignore the response. This means that while I'm typing, it's not constantly updating my validity. Not until I stop typing for long enough for the response received to be from the most recent request, will it update the validity of the control.

I also think that James' auto-suggest idea is a great idea, but as Dave stated, the control would need more information for it to be smart enough to make a reasonable suggestion.

If I tried the user name JRumerman and that wasn't available, I would want it to suggest RumermanJ, JoelRumerman, RumermanJoel, JPRumerman, etc. In order for it to make those smart suggestions, it would need to have other data available such as the current values of the first and last name textboxes.

As a future enhancment, maybe this control can take a list of arbitrary element ids and use their current values to base the auto-suggest values on? If no auto-suggest helper elements are supplied, the auto-suggest feature wouldn't be available.
Sep 11, 2008 at 1:03 AM
JRumerman has a point in that the user would like it to know if the username is available right away. I would add that the control should not auto-validate starting from the first character, but wait until at least three characters, as I'm sure every single combination of single and double letter usernames will be taken on a moderately heavy trafficked site (if it allows such short usernames). Maybe add a property as to how many characters minimum that the auto-validate should kick in (especially if there's a minimum character policy for usernames, then the developer would be able to set it to start validating after that many characters have been typed in and not send a request to the server for each character before that).

Also, I would propose adding a property to enable/disable this auto-validation on keyup so that the site owner has control over how many requests this thing generates. Maybe also have a property to set the delay (in ms) as to how long after keyup it should validate.

In general, I like using controls that can be customized with properties (while at the same time having pretty sensible defaults, so I don't have to set all the properties every time I want to use it).
Developer
Sep 11, 2008 at 4:55 AM
Edited Sep 11, 2008 at 4:58 AM
vbtwo31984 had like 4 great points in the last message.

Three needed properties:

1. Minimum number of characters before validation begins property
2. Enable/Disable keyup validation property
3. Keyup delay property

and sensible defaults. There's nothing worse than a control that I can't drag and drop from my toolbox and see how it works without setting a bigillion (technical term) properties first.
Sep 13, 2008 at 11:57 PM
I think we would need to provide a property for auto validating... I would prefer on my sites that it only validates when the user has completed typing, that way i'm not hammering on my server for requests that might not be useful to the user.
Coordinator
Sep 14, 2008 at 1:22 AM
Edited Sep 14, 2008 at 1:23 AM
Right now, there's a boolean property, ValidateOnKeyPress, to handle that.

If ValidateOnKeyup is true, then we should fire a validation request after KeyPressDelay milliseconds have passed (if another validation request isn't already in progress).

If ValidateOnKeyup is false, then we should only fire validation requests for the client-side onchange event (when the field loses focus and its contents have changed during the time that it held focus).

The remaining edge case would be if ValidateOnKeyup is true, but the user changes field focus in less than KeyPressDelay milliseconds.  We should probably ignore the delay and validate onchange immediately at that point.

With that in mind, I suppose it would make the most sense to always validate onchange and make the onkeyup validation optional, additive functionality.

Does that sound reasonable to everyone?
Developer
Sep 17, 2008 at 6:54 AM
That sounds pretty good to me, except that if I linger long enough in the textbox with keyup validation enabled such that the validation has occurred for the current value, and then I leave the textbox without altering it anymore, the onchange validation seems to be unnecessary as I've already validated the current value.

I don't want to complicate things, but if we could somehow maintain the "last checked value" and then compare this to the value we have when we begin to execute the onchange validation handler and if they're the same not perform the extra validation that would be best. I don't know, that might be overkill. An extra AJAX call to the server isn't that big of a deal.

Thoughts?
Sep 17, 2008 at 11:59 AM
That wouldn't be too hard to implement, just keep a private variable with the last value (if we want to really be smart about it, we can keep all of the validated values with their results, so if the user deletes something to go back to something he typed in before, it won't have to call the web service to revalidate again).
Developer
Sep 17, 2008 at 7:11 PM
Unfortunately, I don't think keeping a list of checked usernames would work. The case it doesn't is an extreme-edge case, but still exists.

I check a user name "JayRu" and it's available, but I want to see if "JayRumerman" is available so I type that in also. It isn't available, so I go back to "JayRu." In the meantime, another nafarious user has snatched up "JayRu" and it's no longer available. Because my client side check won't fire again, I won't know that it's not available until the server-side validation kicks off on the post. It's an extreme edge case, but could happen.

Another similar edge case that we can't avoid is roughly the same thing. I type in "JayRu" and client validation says its available. When I post to the server, somebody else has grabbed the username so the server side validation will have to catch that one. There's no way for client validation to catch it.

I don't know, I might be grasping at edge-cases here that don't really exist.
Coordinator
Sep 17, 2008 at 10:59 PM
I think both sides of that issue are valid concerns.

Since it's more stringent and easier to implement, maybe we should stick with validating every onchange for the first release.  Registration forms are typically not high traffic areas of a site, so one extra web service call shouldn't be terribly significant.
Developer
Sep 18, 2008 at 8:02 PM
Agreed.
Sep 19, 2008 at 12:55 AM
Well ValidateOnKeyPress on my opinion isn't critical. Usually it is required to validate for UserName availability after you finish typing your UserName. So after finishing (onchange, or onblur) Validation should take place. If the UserName is not unique, then the focus should return to the UserName TextBox.

OnKeyPress validation is usally reasonable when checking password complexty, but not is such case of chekcing username availability.

Sep 19, 2008 at 1:15 AM
I would not want the focus to return right away after onchange validation. After I tab, I start typing whatever is required for the next field, and if it would focus back on the username field, it would be confusing.$0$0$0Also there's another problem with changing the focus back right away. Usually in registration forms, the order of the fields is username, password. If I tab and start typing a password I'd like to use, and it changes the focus back, I would most probably type the password in the username input field which would show it in plain text to everyone around me (a much bigger concern in public places such as Internet cafes).$0$0$0$0$0The only time that I find it acceptable to focus on a field with an error in it, is after I click the submit button (before doing the submit to the server obviously). All the other times, it usually just gets in the way of filling out a form.$0$0