How to communicate Allowable Form Characters?

[DoubleDee]

What is the best way to communicate to a User which characters are allowable in a Form?

If space wasn't an issue, then you could write a book to eliminate ambiguity. However that is rarely the case!

Here are some different Error messages all trying to susinctly communicate the same thing...

$errors['username'] = 'Username must be 8-30 characters (A-Z0-9_- )';

$errors['username'] = 'Username can only use Letters, Numbers, Underscore, Hyphen, Period.';

$errors['username'] = 'Username can only use: a-z A-Z 0-9 _ - .';

$errors['username'] = 'Invalid Username. (see valid characters)';

The last one could take them to a page with LARGE FONT spelling things out.

As a developer, I think #1 is the best, however it may not be intuitive to your average person.

As Jane User, #2 is the clearest, but it also is really l--o--n--g, and if you had 8-10 special characters you allowed, then you would have wrapping issues!!

Anyways, what do you think?!


Debbie

[itmitică]

The messages should be extremely specific to what the problem is instead of being generally instructive. That is, you should first process the input, and then you should respond specifically.

No user wants to read a book just to sign up. Chances are he'd find it so bizarre he'd be spooked off by that. So the best way to do it is to refrain from giving too much (probably unwanted and unnecessary) info until it's needed, and to keep out any irrelevant info from your error messages when you display them.

If, for example, the username is too short or too long, say that: 'Username too short, 8 chars minimum', 'Username too long, 30 chars maximum'. If it has a character you don't approve of: 'The character "x" is not allowed in username'.

<hr>

Messages like 'must', 'can only', 'Invalid Username' should be avoided. Positive attitude helps you more with the user instead of trying to procure him with a coronary event.

And trying to make him look at a table of approved characters ('see valid characters') is quite the opposite of yummy delicious chocolate taste: he won't remember any!

[DoubleDee]

Interesting response...

The messages should be extremely specific to what the problem is instead of being generally instructive. That is, you should first process the input, and then you should respond specifically.

No user wants to read a book just to sign up. Chances are he'd find it so bizarre he'd be spooked off by that. So the best way to do it is to refrain from giving too much (probably unwanted and unnecessary) info until it's needed, and to keep out any irrelevant info from your error messages when you display them.

Pardon me for getting technical here for moment...

In the past I have been big on Regular Expression because they validate data in a "one-stop-shop"!

However, the down side is that you can't provide customized error messages. Just like you mention above.

If, for example, the username is too short or too long, say that: 'Username too short, 8 chars minimum', 'Username too long, 30 chars maximum'. If it has a character you don't approve of: 'The character "x" is not allowed in username'.

I'm not sure how to easily program the last one of "The character "x" is not allowed" but I can see your first two points.

Messages like 'must', 'can only', 'Invalid Username' should be avoided. Positive attitude helps you more with the user instead of trying to procure him with a coronary event.

So please provide more examples of what wording you feel is "positive"...

And trying to make him look at a table of approved characters ('see valid characters') is quite the opposite of yummy delicious chocolate taste: he won't remember any!

Hmm... okay.


Debbie

[itmitică]

[...] you can't provide customized error message [...]

I don't agree. It takes a little more programming time, that's it.

<hr>

I'm not sure how to easily program the last one of "The character "x" is not allowed" but I can see your first two points.

For the user to perceive it like a simple and easy interface it asks for complex developer work.

So I'm not saying it's done easily. However I do propose that a developer has to work harder to make it easier for the user. At least, that's what I try to do.

A user, much like an employer, doesn't care much for your struggles. He's strongly judges your results though. And it must appear so simple and easy to him that he'd go and say: "I could've done the programming on that myself".

That said, this is a simple untested, incomplete solution:

$illegal = implode( ", ", preg_replace('/[a-zA-Z0-9]/', '', $username) ); 
if ($illegal) {
  $errors['username'] = 'These characters you\'ve used are not allowed in username: ' .  $illegal;
}

<hr>

So please provide more examples of what wording you feel is "positive"...

I'll follow my own advice and wait for you to provide input first, analyze it, and get back to you with specific answers.

But as a general picture, no strong wording that suggests strict boundaries or grave errors.

[itmitică]

Re examples of what wording I feel is "positive"...

$illegal = implode( ', ', preg_replace('/[a-zA-Z0-9]/', '', $username) ); 
if ($illegal) {
  $errors['username'] = 'Please provide a username without the following characters: ' .  $illegal . '. Thank you.';
}

$illegal = implode( ', ', preg_replace('/[a-zA-Z0-9]/', '', $username) ); 
if ($illegal) {
  $errors['username'] = 'We\'re sorry, but characters like ' . $illegal . ' are not allowed in username.';
}

$illegal = implode( ', ', preg_replace('/[a-zA-Z0-9]/', '', $username) ); 
if ($illegal) {
  $errors['username'] = 'Characters like ' . $illegal . ' make for a hard to remember username. Thank you for not using them.[/B]';
}

Chances are less savvy users wouldn't use fancy chars anyway while savvy users would understand from the specifically short list of illegals in their input from the message above what chars are out. All that from a specific message, without using full tables of permitted chars or complicated guides.

[itmitică]

Aside from error messages, you could also suggest corrected usernames, based on the user input, stripping off fancy chars and converting UTF-8 to US-ASCII too, if you don't care for i18n.

[Stomme poes]

I personally like letting people know what's expected before telling them they're wrong, but that's me.

That is, for a password field I'd want to generally tell them what I'm looking for. I think Mitică's tactic works a bit better when you have client-side validation (since you can give the response right away instead of the user being told their Submission didn't work, which'll lose you people with form abandonment), but I steer as much away from trial-and-error with forms as possible. Every time someone's told they are wrong, they see hassle and are that much more likely to walk away.

That said, as Mitică mentioned, nobody wants to read a book to fill out a form. I find long explanations don't belong in a form. In an ideal world, people would actually read the instructions or the explanations for what questions mean *before* filling out the form. In reality, people don't. So you guide them to get it right as much as you can with how you build your form, word your labels and deal with your help/error text.

He's also correct in that ideally, any error messages should be as specific as you can get away with. Tell people what the problem is, and how they can fix it.

There's nothing wrong with your example messages above generally. You could do like:
<label for="username">Username:</label>
<p id="usernamehelp">Username can be any combination of letters, numbers, underscores, hyphens and periods." </p>
<input aria-describedby="usernamehelp" ...
or
<input id="username" name="username" pattern="[-a-zA-z0-9_\.]{8,30}" placeholder="(any combination of letters, numbers, underscores, hyphens and periods)">
(though I know people who, strangely, do not know what - _ and . are called. One friend of mine calls each of those "dash" "underline" and "dot".)

This explanation is not uncommon on most forms, including signing up for things like Gmail. At least for passwords, which is where it matters the most. For usernames, you know what most people want to know is okay? A space.
And for a label who just says "Username" where spaces aren't allowed, that'll be your biggest error I'll betcha.
As Mitică mentions, this could be an ideal place to simply silently allow - and _ and . and disallow & or % purely via error messages (because they are unlikely), but I'd tell people up front about no spaces for the reason I mentioned. If the username is taken, when people get that error message ("This name is taken, please choose another"), this is a good time to let them know that extra characters are allowed. Because at this point, people are thinking "how can I keep my username mine now?"
So for something like an online username, I'd just have the hint tell people "No spaces in username please." or similar. And be aware of unusual possibilities like last names beginning with apostrophes.
(example: Marie van 't Hof. Marie is the first name. Van is called a tussenvoegsel (inbetween addition thingie). 't Hof is the last name. Though Anglicised people would tend to lump the tussenvoegsel with the last name.) Can she use her last name as a username? No. She would have known that if there was a hint, but now she needs to find out via an error message.

Of course, user testing will really tell you what you "need". You can try a form with minimal or no hints (so, a clutter-free version) and a version with some hints, and see which forms get filled out the fastest and most successfully.

So please provide more examples of what wording you feel is "positive"...

Mitică is right on the ball with this. Even if a user made a clearly stupid and obvious mistake, and even if the user sees it and immediately realises it was them being stupid, "friendly" error messages are the way to go if you can finagle it.
Sorry these are in Dutch, but the examples should still be readable:
http://www.schrijvenvoorinternet.nl/...foutmeldingen/
No idea what the pic of the woman is doing there, she's useless to the article (and not the writer of it).
The Hyundai example tells the user they are at fault, and say in bad Dutch for example "Initials is not correctly filled in". Would that not piss you off, as a user?

Een foutmelding is een crisismoment. Voor de klant, want hij kan niet verder (hij heeft haast). En voor jou, want je loopt het risico dat de klant afhaakt.

Praat daarom op een menselijke, geduldige toon. Op een crisismoment wil je klant geen robot-achtige opmerking naar zijn hoofd krijgen!

Translated:
"An error message is a crisis moment. For the customer, because he can't go further (and in a hurry). And for you, because you run the risk that your client quits.

Speak then in a human, patient tone. During a crisis moment, you don't want the client to get robotic comments thrown at their head!"

Also (English): http://webusability-blog.com/user-fr...ssages-7-tips/

For things like postal codes, names, addresses and birth dates, it's good to avoid telling people they put in the "wrong" information. People tend to know their birthdates and the such, and usually what they got "wrong" was just the format (or you don't allow their correct information! Like when I can't fill in a "state" or a certain format postal code on a form that expects 'Merkins but actually can do international shipping). Correct their format then.

So when they type in the date as 21/04/2012 instead of "You entered the wrong date" you can try "Use this date format: mm/dd/yyy". Because it's possible to have a date like 21/04/2012 though I would definitely tell people how you expect the date! Or, try an input that only allows selection of months, or forces the month to be written out (we used select dropdowns though I'm generally not in favour of those. But they did enforce correct formats! Also possible, the HTML5 input type="date" as well).

However unlike Mitică I would rather state this in the label or as additional text (be aware, additional text that is not in a form control ought to have at least an aria-describedby attached to the input or label though, like in my example above). That is, when presented with a date input, I'd like to know myself before spending my Sweet Precious Time how you would like the date entered.

The other option is a very complex back-end validation system that accepts many many many date variants, and converts all these valid dates to whichever version your back-end uses. This is most user-friendly, but due to Americans being silly about date orders, I would still tell users which format up-front anyway. It doesn't have to be wordy, and this could be the place where placeholders (as in, HTML5 placeholder attributes) shine.

[itmitică]

That is, for a password field I'd want to generally tell them what I'm looking for. I think Mitică's tactic works a bit better when you have client-side validation (since you can give the response right away instead of the user being told their Submission didn't work, which'll lose you people with form abandonment), but I steer as much away from trial-and-error with forms as possible. Every time someone's told they are wrong, they see hassle and are that much more likely to walk away.

That said, as Mitică mentioned, nobody wants to read a book to fill out a form. I find long explanations don't belong in a form. In an ideal world, people would actually read the instructions or the explanations for what questions mean *before* filling out the form. In reality, people don't. So you guide them to get it right as much as you can with how you build your form, word your labels and deal with your help/error text.

He's also correct in that ideally, any error messages should be as specific as you can get away with. Tell people what the problem is, and how they can fix it.
[...]
Of course, user testing will really tell you what you "need". You can try a form with minimal or no hints (so, a clutter-free version) and a version with some hints, and see which forms get filled out the fastest and most successfully.

[...]

However unlike Mitică I would rather state this in the label or as additional text (be aware, additional text that is not in a form control ought to have at least an aria-describedby attached to the input or label though, like in my example above). That is, when presented with a date input, I'd like to know myself before spending my Sweet Precious Time how you would like the date entered.

The other option is a very complex back-end validation system that accepts many many many date variants, and converts all these valid dates to whichever version your back-end uses. This is most user-friendly, but due to Americans being silly about date orders, I would still tell users which format up-front anyway. It doesn't have to be wordy, and this could be the place where placeholders (as in, HTML5 placeholder attributes) shine.

What I try do is this:

1. Beside short labels, I set tooltips (title attribute) for the fields in the form and an informative hint at the top of the form about those tooltips.

2. I return very explicit error messages from server side.

3. By progressive enhancement (Javascript), I display the tooltip automatically with the focus and add client side validation and helpers for field validation, like calendars for date fields.

[Stomme poes]

3. By progressive enhancement (Javascript), I display the tooltip automatically with the focus and add client side validation and helpers for field validation, like calendars for date fields.

You could increase chances of tooltips showing on focus with CSS too.

input[title]:focus:after (or :before) {
content: " " attr(title);
}
or similar, and style for more readability.

[itmitică]

Nice tip. Thanks!

[DoubleDee]

Stomme poes and itmitică,

Good conversation. Thanks for the tips. But this went too deep for me right now. (Gotta get my site done first and then come back to these issues.)

I'll pick up on this as soon as I can...


Debbie

[Stomme poes]

Don't overly stress over this. Common sense and letting someone else with a fresh eye take a look will do wonders.