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 ...
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 ...
I don't think you can guarantee it
If you try to make people mimic how their signature 'should' be, you'll open a lot of cases where people struggle with their device and can't get it to look the same. It reminds me of every time I receive a parcel, and they make me sign that I received it. Even with a pen my signature ends up looking like a 3-year old ...
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.
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 ...
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 ...
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 ...
Validation should not start before input is complete
When the user starts entering a correct value, no errors should appear while typing. The input is considered to be complete when
the input focus is lost (navigating to another field) or
the form is submitted (e.g. autosubmit when pressing enter) or even
after not receiving input for some time (e.g. 3sec ...
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 ...
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.
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 ASCII.
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 ...
My signature is basically habit and muscle memory from repeatedly writing my name with a generally standard sized pen. It varies a bit at the best of times. Even if you ask me to sign on a whiteboard using a marker, that varies a fair bit from my "normal" signature due to the implement being a different size.
When I've signed for stuff in the past using a ...
we often see the 'continue' button inactive
I think this may be false. Read on!
For what it's worth, I'm updating some old research on sign up forms for popular websites at the moment, and have found that quite a small percentage - around 5% or less - disable the Submit button (whether that's the final sign up or a continue type button) until the data is ...
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.
There is no one right answer for this, it depends much on context.
For larger forms it makes sense to have a summary of errors as well as near the specific field that needs fixing, this is ideal for when a user submits a form and the page will reload, they see this at the top and can take action.
Here is a good example of this:
As a bonus, these could ...
Rather than continuously display a red validation message when the user has not met a field's requirements, a nice alternative is to (1) display a tip that tells the user what is expected, and (2) display a green "requirements met" message when the user has entered a valid value. You can go green as soon as the input is OK.
Validate on blur, or on submit. Don't validate while typing, for exactly the reason you describe.
There are studies/observations that show the people generally complete the entire form and then return to values that are incorrect. Even if you validate on blur they will tend to complete all fields and will then return to fix.
Article: Usable error ...
Unfortunately people read less and expect more during action. So regardless if all fields or only a set of fields are required, fields that need input need indication in some form. Every field in your case.
Preventing the user from doing something that you know is wrong is never about preventing keystrokes in a text box. It is about removing the need for typing altogether if possible for that particular input.
Don't validate dates in a text box, get rid of the text entry and use a date picker control.
Have a set number of standard options where ...
I would suggest to mention about the characters that are not allowed, because number of invalid characters is always lesser for any required input. This will help to reduce clutter. See the given example from windows explorer.
Input masks are often done poorly as you describe, but done right they can be very helpful by reducing typing and showing expected formats. Doing them right is key.
Maybe I have an input for social security number, which is always in the form [nnn-nn-nnnn] so I may display the field with the dashes already present in the mask [ - - ] but if I do so I ...
One should not disable the button
Consider the situation from the user's perspective. Divide users into two groups
Those that do not currently believe they can proceed, so are not looking for a way to continue
Those who believe they are ready to proceed, and are looking for a way to do so.
For the former group, disabling the "continue" button is merely a ...
Can we start with the obvious: Why?
Follow up questions:
Are you assuming your app has the same legal power as a "wet signature"? You may be in for a surprise!
Do you have anybody on staff who is a handwriting expert?
Have you seen what other "industry standard" applications do?
E.g. Docusign, credit card readers?