I’ve mentioned input masking before, and Tim Buntel demoed the use of masking in his Flash based election form at MAX. But we haven’t spent a lot of time talking about the specifics of this feature, and having used it extensively the past few days I just have to spill the beans.
Here’s the big idea. Almost all form field validation in Web applications occurs once the form has been filled in. Then, either using client-side or server-side validation (or a combination thereof), any errors are caught and displayed, and users make their corrections. So, if a field requires a numeric value, and a user enters alphabetical characters, that would throw an error requiring the user to make a correction. Which begs the question, if certain characters are not allowed, or if a specific input format is required, why not simply prevent the user from entering bad data in the first place? If a form field required digits, why not simply prevent the user from entering anything else? If phone numbers were wanted in a specific format, why not enforce that format at data input time? Simple, right? Well, not really. While the concept is indeed simple (and is the norm for forms in desktop applications), the code required to implement this type of data validation is not trivial.
Until Blackstone, that is. Blackstone introduces a new attribute to
For example, to accept a 3 digit age you could do the following:
Only digits will be accepted by the 9 filter, and so only digits will be allowed. If a user entered anything other than a digit that input would simply be ignored.
Similarly, to accept a U.S. style phone number, in the format (123)456-7890 you could use the following code:
The 9’s allow only digits, and the other characters are inserted automatically.
For a Canadian postal code you could use:
You get the idea. Input masking does not negate the need for input validation, but it does make for a far better user experience.
Oh, and input masking in Blackstone is planned for both HTML and Flash forms.