Let me first say, we validate every field on the server side, so this a question
about client-side usability.
What is the conventional wisdom on exactly when to validate and format html form input fields using javascript?
As an example, we have a phone number field. We allow numbers, spaces, parentheses, and hyphens. We want the field to have ten digits. Also, we want the field to look like (123) 456-7890, even if the user doesn't type it that way.
It seems like we can
Validate and format it when the user
exits the field.
Validate and format
on every character entered.
Intercept keystrokes and prevent the
user from entering characters that are wrong.
Some combination of the above (e.g.
format on entry and validate on exit, prevent on entry and format on exit, etc.)
[Added] Wait and do all the validation and formatting when the user clicks submit.
I've seen it done all of these ways, but I can't find information about what
is best (or even generally accepted) from a usability perspective, and more importantly, why.
[Edit: Some clarification]
We are absolutely not enforcing any format standards. When I say format, I mean we'll use javascript to rewrite things so they look nice. If the user types 1234567890, we'll change it to (123) 456-7890. There are no "formatting rules" that can fail.
I distinguish this from validation because if they don't type enough numbers, we have to make them fix it.
I guess I should rephrase the question as "what is the conventional wisdom on exactly when to validate and exactly when to format...?
Good info in the answers so far!
EDIT: I'm accepting my own answer below in the hopes that others will find the link as helpful as I did.
Validate and format it when the user exits the field.
Yes. Provide noninvasive feedback to the user if validation or formatting rules fail. By noninasive I mean don't popup an alert or modal dialog box, thereby forcing the user to click something. Rather dynamically display a message adjacent or underneath the field where validation or formatting failed.
Validate and format on every character entered.
No. I think that hinders usability. Instead provide the user with a tooltip or some other hint as to what the formatting rules are or validation rules are. E.g. for a "required" field the practically ubiquitious asterisk, and for fields with formatting tell the user up front what the expected format is.
Intercept keystrokes and prevent the user from entering characters that are wrong.
If you are going to prevent the user from entering invalid characters, tell the user why you just blocked their input, noninvasively. Also,do not steal focus of the field.
So for me the general principles are:
Inform the user up front about your validation and formatting rules.
Do not assume the user is sighted, so keep web accessiblity and screen readers in mind. (Unless you are developing a web site that has a limited target audience such as an Intranet.)
Provide the user with noninvasive feedback, meaning do not make the user click on an alert box or modal dialog upon each failure.
Make it obvious which input box failed validation or formatting rules, and tell the user why their input failed.
Do not steal the mouse/pointer focus, when providing feedback.
Keep tab order in mind, so that when keyboard oriented users complete a field, they can hit tab and go to the next logical input/selection field.
I was going to describe various options but it may be beneficial just to use an existing js framework to handle input masks. Here is a good run down of various options
bmb states that they are accepting any format, and changing it to the desired format (xxx) nnn-xxxx. That is very good. The question is the timing of A) the format change, and B) the validation.
A) The format change should be done as the user exits the field. Sooner is annoying and later defeats the purpose of displaying the change at all.
B) Validation is most appropriately performed either on exiting the field or on submitting the form. Sooner is frustrating and confusing to the user. In a long and complex form, with more than one screen, I would favor doing validation on exiting the control to make corrections easier. On a short form, I would do it upon submit to avoid breaking the flow of filling out the form. It is really a judgment call, so test it with real users if at all possible.
Preferably you are testing your work with real users anyway, but if you do not have budget or access for that, a quick and dirty "user" test can help with decisions like this one. You can grab a handful of people who did not work on the software (as close a match to your real end users as possible) and ask them to fill out the form. Instruct them to enter things a specifically to get an error and then watch them correct it. Ask them to talk aloud through what they are doing so you don't need to guess at their thought process. Look for where they have issues and what seems to confuse/annoy them most.
By far the best answer so far was not an answer but a comment (see above.) I'm adding it as an answer in case anyone misses it in the comment.
See the following article on A List Apart.
Inline Validation in Web Forms by Luke Wroblewski
It depends per field. But for something like a phone number, it's generally pretty nice to prevent someone from even entering non-digits.
That way, when typing you'll notice that your 1-800-HELLOWORLD phone number isn't showing up correctly and realise that the field only accepts numbers (which you can also highlight with some sort of information field alongside the input field).
That seems to me to be a lot more inuitive and friendly than an awkward modal dialogue, pop-down error field or server-generated message displaying after you're done filling it out.
Of course, always balance the ultimate client-side validation with the ultimate technical requirements to build it. If you start down the path of, say, validating image uploads with Ajax before the page submits, that can be a pretty long road.
Edit: also, consider your audience. The more technically minded are going to be more accepting of "dynamic" forms than, say, people who are more accustomed to the non-Ajax approach to the Internet.
Personally I think formatting and validating on exit is the least bothersome to the user. Let them enter the number in whatever format they like (and there are a lot of these for a phone number) and then change it to the format you like. Don't force the user to conform to your preferences when you can handle the data in their preferred format.
Also, validation messages when I'm not done typing are annoying, and not being able to put a certain character in a text field is super-annoying.
The only exception I can think of is "is this value available" situations (such as creating a unique username) - in that case immediate feedback is really convenient.
I find the first three options to be really annoying. There's nothing worse than being interrupted in the middle of typing something.
Your user's main goal is getting through the form as fast as possible and anything you do that slows them down is just one more reason for them to give up on it entirely.
I also hate being forced to type something like a credit card # or phone # is exactly the right format to satisfy the form. Whenever possible, just give the user a box to type stuff into and don't make them deal with the formatting.
In the case of your phone #, let them enter it however they want, strip out anything you don't like, try to put it back together into the format you want ( (124) 567-8901 ) and throw an error if you can't.
If you absolutely must validate something to a specific format, do it when they submit the form and then highlight the fields that have problems.
The most user friendly way I've seen to do validation is to have an indicator that shows up next to the input field to indicate the value is invalid. This way you don't interrupt the user as they're typing and yet they can continually see whether or not they've typed a valid entry. I hate having to type information into a long form only to have the thing tell me at the end "Oh, you need to go back and fix field 1".
You can have the indicator be show/hidden as the user types. I use a warning icon when the value is invalid and I set a tooltip on the icon that explains why the value is invalid.
If you have the screen real estate, you could just put text such as "Valid" or "Must be in format XXX-YYY-XXXX".
Keep in mind that when you do per keystroke validation you also need to catch pasted text.
In addition to this, you should also prevent invalid keystrokes to be entered in the first place.
For usability best practices, I suggest reading How To Design The Perfect Form (more precisely Context & Assistance) and Beautiful Forms.
For a form validation framework, check the fValidator and iMask combo, they are complementary and thus work perfectly together.
Related
I've got a question which would be applicable to an MVC based platform, but I guess also applicable to any web based platform which handles user form inputs.
What are the best practices, and ideal stage from which to remove trailing/leading whitespace from user input?
I see this could happen at a few stages:
Immediately Upon User Form Input - ala Javascript functions to strip as they type/pre-submission
Inside the Controller on Params Submission
Intermediate Model/Attribute Methods
Prior to or upon Database Persistence
What is best practice in this regard, and specifically the pro's/con's for doing it at a certain stage, or multiple?)
I think it depends on the type of application:
For a standard web app, I would say you definitely want to clean data on the browser sometime before submission so that you can validate it (for ex. an email would fail validation if it has a leading space or a length check). It is better to validate without sending data to the server when possible.
If you are writing an API, especially a public one, I would definitely clean the data server side or return an error. You can't trust clients to send you clean data. I would probably do it in the model before validation which shouldn't be to hard to do automatically.
If bad data can cause a security issue (XSS or SQL injection) then you want to clean it on the server as well as the client. Even on a web app there is nothing stopping a malicious user faking a request from a web browser. If spaces in the data won't break anything then this may not be necessary (if someone 'maliciously' adds a leading space to their blog title it might look weird but it is only going to harm them)
This is a very opinion based question I think. It would depends on the persons who is implementing and also the application.
If you don't have to clean immediately after user input, I would say avoid #1 since it will be confusing to your users while they are typing, and also it can have a performance impact on slower/smaller devices.
#2 and #3 will both be very similar, a nice thing about #3 is that if you're using the same property in many places, your logic for trimming will live in only one place, but both will run on your server which takes away the perf hit from client device.
#4 depending on your DBMS can be very easy or difficult to implement.
I would personally choose #2 or #3, but again that's my opinion and someone else can have a completely different one than mine.
Also you certainly don't need to do it multiple if you get one stage right.
Why is this browser allowing me to type these characters [ ' ~] beyond the numbers ? How can I solve this?
The image of my problem is here:
On Google Chrome this works:
<input type="number" pattern="[0-9]" name="points">
allowing only enter numbers, but iceweisel ( firefox) not.
As you know, IE does not support that field type. It's as simple as that.
If your question is how this problem can be overcome, then one solution is to take a more verbose Javascript approach. Once the user submits, or leaves the field, grab its value with JS, check it, and show an alert to the user if it is wrong. You should also check it server side if it is important. Patterns are not yet a secure way of guaranteeing user input - only really providing input hints to the user.
You can also look at Polyfills, which can replicate new functionality in old browsers.
I'm not a big fan of email validation regexes as I myself have come across a lot of sites that have too strict regexes and as a result have not been able to user my preferred email.
Basically I use only .+#.+ just to make sure they are not forgetting the #.
What I'd like to do though is to give the user hints if he/she has entered an email that LIKELY is incorrect. Like typos or weird characters.
So if they enter for instance mike3292#hotmaik.com then I can ask the user if he is sure, and maybe even hint to the right solution in some cases.
So basically what I want is to know if there is any existing source of top email providers and common spelling mistakes. Also maybe a regex for unusual characters to warn the user about, asking him to double check.
Regex is really bad for validating emails. If you want to do a full/real validation you'll need a very complicated expression
What I would recommend is to simply make sure it's .*#.*\..* which would check for ---#---.---
And have the user enter it twice.
It makes it easy for you, easy for the user, and not annoying. I wouldn't like it if a pop-up suggested my name was an invalid email address.
I am doing a bit of preliminary investigation for my school (I work for the IT department as a student). The students here have to change their passwords every 6 months, and many of them struggle with the (many) password rules that are enforced. That is, they often have to make several attempts at setting a new password.
The rules are:
Must be 8 characters or more in
length
Must contain 3 of 4 types of
characters (capital, lowercase,
number, special character)
Must not contain the user's first,
last or middle name
Must not contain the user's username
Must not match any password used
before
User must type password in twice, and
typed passwords must match exactly
I have a few questions:
Is it possible to create a web-based
password checker that provides
real-time feedback as the user types
in their new password? I am
imagining a checklist on one side of
the web-page where green checkmarks
are activated as the password meets
more criteria.
Is it possible to do perform this
checking securely and entirely
client-side?
Where would one start on such a task?
Is there a guide you can recommend?
Please keep in mind that I am not a web developer. Also, please leave any witty comments like "change the password policy" or "they're just dumb users" out of here.
Is it possible to create a web-based password checker that provides real-time feedback as the user types in their new password? I am imagining a checklist on one side of the web-page where green checkmarks are activated as the password meets more criteria.
Yes.
Is it possible to do perform this checking securely
As the lights go green, it exposes information about where in a password the requirements are met. That will leak data about the password to anyone who can see the screen.
and entirely client-side?
Yes.
Where would one start on such a task?
A list of rules in the HTML document with a FAIL image next to each one. Programatic versions of the rules in JS. Then just test each rule in turn in a loop on each keypress event on the password input and swap PASS and FAIL images depending on if the rule is followed or not.
You'll need to hit the server with an XMLHttpRequest object to check if a password has been used before. Make sure you only store hashed and salted passwords there though.
Please keep in mind that I am not a web developer.
Then I recommend you get one or become one.
Also, please leave any witty comments like "change the password policy"
Fine, leaving the wit aside and sticking to the serious issue:
If people have problems coming up with passwords that conform to the policy, then they will have problems remembering them. This will lead to an increase in people having to have them reset (more work for the IT dept) and in people writing them down (which is probably going to be less secure then a password that is easier to guess / brute force).
Most of the rules you specify can be checked in real time using javascript, more specifically using regular expressions. Checking whether the password has been used before should be done on the server side to be secure.
Is it possible to create a web-based password checker that provides real-time feedback as the user types in their new password? I am imagining a checklist on one side of the web-page where green checkmarks are activated as the password meets more criteria.
Yes, but you will need to know some javascript to do it.
Is it possible to do perform this checking securely and entirely client-side?
No, and yes, or yes and no, but not both. You can do the check entirely client-side (except for checking against previous passwords, which would need database access). But nothing, NOTHING, on the client-side is ever secure. Anything you do on the client-side should be considered a help to the user. All validation must always be made again on the server.
I don't want to be a smart-ass and tell you to change the password policy, and doing so because validation would be "hard to do" would be a bad choice, but I would like to recommend the following article to the one that has decided on the password policy: http://www.baekdal.com/tips/password-security-usability
Must not match any password used before <--that one is the only one that has to be performed server side, but can be done securely using hashes or some form or encryption, because a client side copy of said passwords would not be a good thing.
Regexp's are probably where you'd wanna start. If you're unfamiliar with regexp's in web development, I'd suggest you start here: http://www.w3schools.com/jsref/jsref_obj_regexp.asp. If you truly have no experience in web development, I'd have to ask how you got stuck with a job where you'd have to learn a new language to accomplish a relatively simple task. You'll definitely need to have an understanding of javascript to do something like this all client side. Oh, and I wouldn't recommend testing
Must not match any password used before
It's too risky to do this in a simple way client side and complicated to do it securely without bringing in help from outside libraries, etc. Hope this helps and good luck!
As far as I read from here, the fact that captchas are not 100% secure.what can be used instead of captcha? As a programmer what do you think? how to solve this issue?
Edit: thanks for all answers.
This is an unsolved problem, and will become more unsolved as time passes. The better the OCR tools get, the smaller the gap between humans and computers, and the harder it will be to tell them apart. Eventually, computers will be indistinguishable from humans, and then the game will be up.
If your server wants to make sure that a human is at the other end of a TCP pipe, there isn't a turing-test in existence that won't eventually be defeated (and there probably never will be one). CAPTCHA is doomed, it's just a matter of how soon.
Of course, that doesn't mean it's all over as far as human authentication is concerned. It just means that automated turing tests, as convenient as they are, won't be an effective way to achieve this for very much longer.
Captcha involving human reflexion (like calculation, really simple question, and the like).
Session tokens
randomly generated hidden input which requires to be null, on the server side generate a random identifier, keep it in a session for a while. If the input is filled and not null, then it might have been filled by a robot, do your users will fill an hidden input ?
I think it really depends on what you are trying to control over the use of captcha.
Further explanation of a suggestion made by Boris:
randomly generated hidden input which requires to be null
The idea is that your form contains several invisible inputs, their type should probably not be set to hidden, but they should be invisible to a human (e.g. set width or height to 0). The initial content of these fields should be empty. If a human fills out the form, the field will be empty, because the human cannot see the field in order to enter anything into it, but if a bot fills out the form the field will (possibly) not be empty, because bots usually just blindly enter something into every field.
Thus, you can distinguish between a bot and a human based on whether the content of this field is empty.
Although captchas can be broken, Capthca's only add to security reCapthca is very good, and a trained OCR like Tesseract is going to have very limited success in breaking it. However, there are outfits that use Human Computation to break them for pennies. But this makes attacks against your system more expensive, and thats the best you can hope for. Cryptography can be broken with brute-force. All password hashes are breakable, but we still use them because it makes it harder for the attacker.
Most of the "solutions" on this thread are "Security Though Obscurity" and you should be wary of these quick fixes to a very complex problem.
Captcha's are used to determine that an actual human being is doing the request, not a machine. Captcha's and captcha-like systems will upgrade, and so will the technology to break them.
So how do you proof that you're talking to a human and not a computer? You could for instance require users to engage in a chat session and have small conversation. There's no AI nowadays that pass the turing test.
So the answer is, no system is perfect. Don't try to solve this issue, but try to find a way to reduce the impact of this.
In the long run government could run openid servers as digital passports for their citizens.
It would be a clean way to identify human beings and prevent sockpuppeting.
At the moment on my website I opted for simple questions. Some questions I've used in the past:
What is two to the power of one?
What is 2+2? (this one was hacked though so don't use it)
What is the name of this website domain?
What is the sum of two and two?
Some other nice ones could be
type in 'stuff' to this box as a spam check
What does 1337 look like? (using only letters)
the current year is?
The best way I can think of is using something unconventional, like a special hidden field that should be null (or another specific value) that robots will mess with.
If some robot maker adjusts his robot for your site, you'll have to quickly change the captcha to something different. It will (hopefully) take a good while before another robot maker adjusts his robot for your site.
Basically, it's a security through obscurity that has to constantly change to remain obscure.
This won't work very well if someone is specifically targeting your site.
Its just an idea, id used that in my application and works well
you can create a cookie on mouse movement with javascript or jquery and in server side check if cookie exist, because only humans have mouse, cookie can be created only by them
the cookie can be a timestamp or a token that can be validate
Gets the coordinates of the mouse, determine whether the coordinates have changed, you can determine whether it is a robot.
Then encrypt the coordinate data.