If you feel the 'Confirm Email Address' field is required, but want to prevent people copy-and-pasting it then why not take a different approach?
When requesting the user details and email address just ask the questions once. Then, on the final sign-up / payment screen (depending on your application) add a field on this last page stating:
"We will send ...
I would avoid this behaviour as it's breaking people's basic expectations of being able to copy/paste.
October 2011 - an article by blogger, speaker and serial entrepreneur Boris Veldhuijzen van Zanten on The Next Web (which he founded) - 10 ways to screw up a web form and piss me off
Number 1 - that's number ONE: Don’t ask people to re-type email ...
Typing on mobile is a very arduous and unpleasant process, so we should try keeping it to a minimum.
Sometimes your users will have made just a small error that can be fixed by replacing or adding a character or two (typically they typed something instead of @ in an email address etc.). Sometimes they will have made a big error and they need to retype the ...
Type of the information captured and number of fields required
It really depends on the type and scope of the information you are asking for and the number of fields that need to be filled:
I have tested and used this pattern successfully in login and and password creation. I think because the interface is so simple and the number of fields required ...
Encapsulated flags are the only solution I've found that reach all edge cases. Pointing the flag at the label rather than the input allows for consistency with radio buttons and check mark groups or weird inputs like sliders or sorters.
Highlighting the field with red is also helpful, but not always possible. Example usages below.
download bmml source &...
The moment a date is ambiguous you should not convert it to what you think it is.
For example, in most of the world date formats are DDMMYYYY or YYYYMMDD, but for some (silly) reason the US uses MMDDYYYY. You know that this is likely to be a confusion, so don't convert a date that is ambiguous.
If the date is critical, consider using a date picker rather ...
I came up with another way to handle this scenario which is more clear in cases with arbitrary jumps.
1. Show links below the text input to quickly convey how the bidding system works by listing valid choices which can be chosen with a single click right from the start.
2. Update valid choices as the user types or clicks The user can either type 68 or ...
It seems you're already marking optional form fields instad of required ones. There seem to be no 'required' indicators, but no 'optional'-indicators, too, so I wanted to mention that.
What I like to do on forms is to "micro-gamify" them: For every field in the form provide a "validation-indicator". For simplicity, let's say it's just a small circle. This ...
The way in which validation should be implemented varies based on the
unique needs of the form. However, in general, if the user’s input is
incorrect, the system should inform the user by providing an
identifiable and clear message that aids in correcting the error.
When no text, make the message simply inicate the max number of characters (no mention of the number remaining.
As you type, the number of remaining characters fades from grey to black (very subtle indication)
When you reach the limit, change the border to red; make any excess text a different colour; show a small error icon below and indicate number of ...
You'll often find that users will just fill in all fields on a form regardless of whether they're required or not. People don't really read instructions and don't want to risk encountering an issue if they haven't filled in any fields, so they'll often just fill in them all regardless. (This has been somewhat supported by testing by the Baymard Institute - ...
Here is some advice :
forbid characters only if it is absolutely necessary (I hate when I
cannot use _ in my nickname)
display a message only to the user who tries to use one of these. Other users won't be bothered
if the user enter a forbidden caracter, just don't consider it and explain him why.
download bmml source – Wireframes created with ...
I use the rule server-side validation for security and client side validation for usability.
I can't trust any client, but I can write a standard client which quickly (without the network) validates inputs, so the user can get a response sometimes even while typing.
This also minimizes the wrong requests my client sends to my server.
-- EDIT --
What I ...
The error message should appear before the form field itself (at a minimum in the markup itself, but ideally visually shown this way on the screen too) so that when someone is reading the form they read that the field has errored before they then read the field in question - that way the user is prepared mentally that "the contents of this field I am about ...
Will Company Name be stored in the database with spaces and then a separate URL column will have no spaces?
I would recommend building the URL just below the Company Name as they type so when the user types "Super Duper Acme Co." your app will show:
Your dedicated URL will be: www.superduperacmeco.com
This will cause the user to pay attention and ...
I recently was playing around with a new type of pager control that only uses numbers and doesn't require any localization (next, previous, last, first, all function without any words required in the UI)
I modified it slightly to work in your case here. The idea is to be really clear to the user up front that they can't just type anything they want because ...
Since the email field is unmasked, the confirmation seems redundant to users.
If the user is advanced enough to copy and paste instead of retyping, the user probably knows his/her address. Preventing copy and paste would just annoy users.
When the user copies the email, the user has to look at what he wrote and thus would probably notice a mistake, ...
Having an icon is an extra visual cue to the user that something requires their attention.
This might be useful in places where the page is viewed on low contrast device or if the user has some sort of colour blindness, to draw attention to the message that might otherwise blend in with the rest of the information on the page.
If your design makes it clear ...
From a usability point of view, definately keep their entry there. There is nothing more annoying to users, in our experience, than clearing their entry on failing validation. They need to be able to see what they have done wrong, and if you clear it they are having to use their memory.
I would have to say that this behavior hinders user experience.
If you've ever read Don't Make Me Think by Steve Krug then you will quickly realize that this pattern is breaking the rule stated in the title.
One might ask, Why is this disabled?
There is no benefit to make a user jump through this hoop.
Basically what I am implying is that the user is ...
This is annoying. Your user fills out the form, submits, and gets back "3 mistakes". He corrects those 3 mistakes, submits, and gets back "2 new mistakes" in fields he hasn't changed meanwhile. His reaction:
"Why did you not tell me about those 2 mistakes in the first place"?
And he's right.
Clientside validation was meant to help the user by providing ...
Well, let’s work it from end to beginning:
Lose the exclamation points. Don’t yell at the user. It’s rude and insulting.
Does the user know what an “image file” is? Do they understand “image” or “file”? Conduct some user testing, but I’m guessing “picture” is more appropriate.
And what is not an image file? Maybe the user mis-...
Prevention will likely frustrate a user as they are entering it and it isn't working. Of course this can be fixed with adequate messaging that lets them know why certain characters were rejected.
Some users may also be typing with their heads down and may not see when some characters are rejected. If they are typing 10 characters but only a few within ...
From the standpoint of the person filling out the form, I too recommend not setting any limit on how much information the user is allowed to send.
Unfortunately this isn't actually a realistic goal. What happens when a user submits the form with 100k lines of text? Simply put, you don't want users to abuse the feedback form, as it could be detrimental to ...
Good answers above. Just one more tip, though:
Consider having your application parse and re-write the date the moment the field loses focus. If the user types 091011, transform it into "9 October 2011" (or "10 September 2011" for US users) - your user will instantly see if his entry has been misinterpreted.
I would recommend a No Limit for the text field upon composing but a suitable limit upon listing.
What I mean is that if the user is limited to expressing their opinion in a regulated fashion the true nature of their opinion could be altered. They may need 752 characters to express their opinion but you've set the limit to 500 characters, what should they ...
Yes you should!
Your suggestion about having a validation rule would be a very bad idea. Did you know, the world's most common last name is 王?
Here is a classic article that you need to read: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
All of these assumptions are wrong:
People’s names are written in ...
TL;DR: Don't disable the submit button and wait to present errors until after the user has hit the submit button.
Studies have been conducted showing that users tend to complete forms in full before fixing errors, regardless of error presentation.
One such study looked at how users reacted to different error presentations: Usable error message presentation ...
Inline Field Validation
I would recommend to stay on the same-tab, with validation in-place (inline) like this example:
This is a common design paradigm now that web form internet users are accustomed to. I don't know why you'd need a pop-out or a new tab.