How do I best show the format that's allowed for an input?

Question

I can restrict the input on the front-end to certain values or make it match a regex pattern, but the user might be confused about why they can't input certain values unless it's communicated to them in some way what the input restrictions are.

I could try to add a specific explanation about form fields that seem out of the ordinary as far as their restrictions go, but is there a common pattern that's used to communicate the constraints on an input field? Do I just explain the format in a placeholder for the input? Should I display some formatting message in small text below the input? Is there an established convention for this sort of thing?

For example, if I want to show the valid input formats for password fields or for phone/email inputs how should I do that?

Answer 1

There is no "official" way of dealing with that kind of input, as far as I know.

I am not even sure if a "formatted edit field" is part of the regular Windows API (if applicable) or if this is some kind of custom control.

If you have to deal with data that follows a certain pattern, always keep in mind that it is almost guaranteed this format will change or cases occur where the format does not fit / is in the way. For example zip codes in germany got increased from 4 to 5 digits. Introduction of smartphones allowed prefix numbers with more than 4 digits, there are phone numbers with only 4 digits, there are streetnames with roman letter housenumbers, housenumbers with appended letters or no housenumbers at all, etc. etc.

Filtering "wrong key presses / keyboard input" is a nice thought, but on the user side the surprise that some buttons don't work suddenly, outweighs its usefulness - humans are remarkably capable of entering the "right" things into text fields, e.g. not using letters in housenumbers - until they need to do it and realize it is not possible and the only thing in the way is this pattern - the database could store such data without a problem (mostly).

It certainly is a good approach to indicate that your edits follow (and enforce / see below) a certain pattern. Adding a prompt text into date-fields for example is almost mandatory to indicate if a DDMMYY or DDMMYYYY format is required.

Consider the (bad) surprise if a user enters "12.3.87" but the program did not recognize this, because it "stubbornly" wants to have the input "12031987" in this case (leading zeros, no separators, full year) but displays this as "12.03.1987" (with separators). That is (close to) the worst case in terms of UX.

Also a pattern (in a birthdate example) can bring you so far, because it would allow an input like 1492 as a year, even though it is clearly "wrong". Better would be to handle and correct those inputs "behind the scenes". E.g. allowing both/all date inputs but adding a 19 or 20 automatically for the year if only two digits where given, make the assumption that any non-digit is a separator (also just spaces for example), sanity check for mixup between month and day (entering 23 as month for example), check if that "birthday" is not 200 years in the past etc.

Filtering data input given by users (or escaping special characters) is mandatory in business applications in any case. This prevents things like SQL injections into a database for example - this necessity should not (must not actually) rely on the user input though by enforcing "correct" inputs at the frontend. The program has to ensure data sanity for the user in the backend/behind-the-scenes.

Bottom-line: I would prefer showing pattern necessities as prompt-text or next to the input fields and giving the user opportunity to input things their way first but filter/escape/correct/check them behind-the-scenes, giving an inlined error message at the input if corrections are due.