Validation/filtering survey

[beetle]

Hey all

At this time, I'd like you to draw on your experiences as developers as well as users, and let me know what you think on the following topic. Please refrain from responses like "Why would you do that?" et al. I'm on a fact-finding mission, not a should-I-do-this mission.

For interactive data filtering in regards to forms, what do you think is appropriate?

P.S. This is strictly in regards to active filtering, and NOT onsubmit-triggered validation.

[brothercake]

Interesting ... I wonder how you could do on the fly validation for screenreaders :confused:

[beetle]

Originally posted by brothercake
Interesting ... I wonder how you could do on the fly validation for screenreaders :confused: You couldn't :thumbsup:

[liorean]

On-the-fly validation should, according to me, be done using onchange, not onblur, if you need it. Using key or mouse events might be the only way that works in some special cases, but if your case isn't one of those, keep your distance. Focus events (onfocus, onblur) can provide strange effects on non-graphical, non-pointer-controlled interfaces such as a text<->speech crossinterpreter or sequential interfaces (e.g. CLI, some other TUIs), and shouldn't be used for thing that onchange can do.

It's preferable to announce that the user didn't enter correct data to editing that data in a try to make it correct. You should make the field able to take as many diffent commonly (and uncommonly) used forms for a certain thing as possible, though. For instance: Phone numbers can be written in a number of ways, with varying lengths and positions of eventual splitting characters ( -./). Also, any of the digits 8,9,0 SHOULD be stripped from the ara code if they are the first in an international number, to achieve the general form (+countryCode) areaCode phoneNumber.

[RadarBob]

Format data via onblur
If the formatting is *extremely* standarized; and you don't throw out input just because the program couldn't fit it into the format. The underlying assumption is that the visual format and the actual data store are not necessarily the same thing.

Format data via onkey(up | press)
Again, depends on what it is. Long strings of digits would generally be no problem. Visually touch typing text might be. But very short text input might be ok - like "Y"

Format data if fully entered
This might be a nice feedback mechanism telling the user that the data is entered correctly (or not); especially if the user is very familiar with your format.

Warn or indicate to user via onblur of erroneous input
Personally I like the "all at one time" approach. Stopping the user "onblur" suggests that THIS data item must be filled in without error before the next, or any other subsequent, field is even allowed to be entered. Unless there is in fact such an interdependancy, personally I would tend to not do this. Even then such interdependent fields should have some indication of a relationship - like boxes around them and appropriate text.

Maybe I want to fill out other fields and come back to this one.

Clear field if data not fully entered or "unformattable"
Generally very very bad. Erase my entry then tell me it's wrong? How the ach-ee-double-toothpicks am I going to fix it if I don't know what I entered?



In general you don't want to modify (add, change, delete pieces of) the user's input to force it into a desired format. You especially don't want to modify the input and then tell the user it's in error. What's wrong? "Well, if the computer didn't add that stuff then it wouldn't be wrong" (computers are stupid, I'm smart). You'll confuse and frustrate users very quickly. If there are standardized prefixes or suffixes required in the data (sometimes ending digits or check digits of account numbers) but users don't know or need to know - then don't even add it on the screen. Just append in the background.

Partial formatting (along w/ appropriate error messages) could be a very effective error-highlighting technique. It could help the specific problem area stand out.

Finally, ask yourself "why format anything unless it aids the user in accurate data entry (like phone numbers) or his understanding of the information?" If the computer needs it formatted (like all upper case aids in proper sorting or comparing), format it behind the scenes. Why force the user to comply with the computer's requirments or shortcomings?

Even something as simple as changing 'y' to 'Y' might cause the user to pause, lose his pace or train of thought... "I thought I was typing lower case; what happened?" or "is the caps lock light burnt out?"; or "I didn't hit that shift key, did I?"

[RadarBob]

The question is invalid. There's no "none of the above" option. Only if I think at least one of the options is "acceptable" am I allowed to vote.

[beetle]

So you guys (et gals) know, I'm working on my 2nd client-side validation library that will provide interactivity to the validation process, such as active filtering.

I'm developing it so that the same validation code used by fValidate will be used to provide the filtering. Example, someone wanting to validate a number to this following spec

- US and similar numbers only
- area-code optional
- format: (area) phonenumber

They would use the code "phone|(a?) p-s"

or with an optional extention "phone|(a?) p-s +x?"

or something similar

I want all of you to know that I'm HIGHLY visible to the concerns of accessibility et usability, so I won't be doing anything that is overly restrictive or similar. liorean, thanks for the heads-up re: onblur. In fact, I'm already using onchange in my error-control process, so I should be okay sticking with that.

What about onkey(up|press) ?

[beetle]

RadaBob. Thanks for your comments, but the last part of your post strayed into the "why" area I asked you folks to avoid. I'm not after that information, as I am already very well aware of it.

I'm not doing this of any one specific purpose, but am doing it to make it available and make it done right. I KNOW this is highly context-sensitive, but this script is for distribution, and the context is what I am not privy to. I leave that up to the people that use it. Most of the regulars here darn well know that there are applications for everything, regardless of it's zaniness, such as intranets or whatever. So please, I don't want/need lectures on application. I want to know, in general, what you like and don't.

About the "none of the above" thing - sorry, I can't modify the poll. I tried to cover all the bases, including what I don't agree with, but I missed this important "catch-all". Moderator?

[brothercake]

Originally posted by beetle
About the "none of the above" thing - sorry, I can't modify the poll. I tried to cover all the bases, including what I don't agree with, but I missed this important "catch-all". Moderator?
There you go :)