Validators with Formatters in a Stateful Form

I’ve released a project on GitHub called Form & Function. I build this project and then used for a large Eligibility Application for a client, where it proved pretty useful. The problem domain I was dealing with dealt with how to develop a large, forms based application where user-feedback needs to be rock-solid and the feedback needs to happen constantly, to ensure as many fields get completed in a single setting as possible.  

In a nutshell, what does it do?
Form & Function
reminds a user that their time-investment matters to you and your organization by giving the best possible experience when filling out a form.

In brief technical jargon, what does it do?
Form & Function creates the relationship between a validator, a formatter, and a restrictor for the most popular form types, and then notifies the developer and user about a form’s validity.

Who does it help?

  1. For developers, it simplifies building complex forms.
  2. For users, it helps them complete long forms.
  3. For project managers, it’s a milestone met.
  4. For user experience designers, it’s a starting place for a conversation.

Where can I find Form & Function?
The code base is hosted on code.google.com. Feel free to download the latest version of Form & Function from the Subversion trunk. Over the next few months, the project will be in a “Bleeding-Edge” release, and should not be considered backwards compatible from day-to-day.

What problems can Form & Function solve with my Flex Project?

Problem 1: The standard Flex Validators are too generic
Let’s start from the top and talk about the Adobe Flex validators. The types of validators Flex currently offers are:

  • CreditCardValidator
  • CurrencyValidator
  • DateValidator
  • EmailValidator
  • NumberValidator
  • PhoneNumberValidator
  • RegExpValidator
  • SocialSecurityValidator
  • StringValidator
  • Validator
  • ZipCodeValidator

Adobe gives you all the hooks you need to build your own validators using the Validator class and the RegExpValidator class (and both are used liberally with Form & Function).

The more specific validators, such as the CreditCardValidator, won’t validate credit-card security codes, only credit-card numbers). While a Merchant may not require the user enter a security code, the ability to validate against a security-code that’s tied into the card-type, should have been there all along, along with a CreditCardFormatter for user legibility.

Form & Function has validators that either improve upon, or plain-old, don’t exist in the latest Flex SDK.

Problem 2: Some Form Items require a linear Work Flow
Some form items require a linear workflow. For example, the mx:CreditCardValidator doesn’t force a linear workflow, because it’s left to the developer to implement a  workflow, most likey using States, but I prefer Convention over Configuration, and strongly prefer a consistent approach that 99% of developers are going to implement. In short: A user should be forced to select a card-type before he’s validating a credit-card-number (or the credit-card-security-code) against a null credit-card-type.

With your own application, I expect you may have similar workflow needs: The user shouldn’t be able to select one type of field until he’s selected another type of field, because there’s a dependency (maybe you have to load data for a “Region” only after the “Country” is selected).

Form & Function has ‘hooks’ on the FormItem level, as well as the Form level, to make implementing a linear workflow a relatively straight-forward process.

Problem 3: The Field restrictions aren’t implemented for popular Field-Types
When you use one of the Adobe Flex validators, you’ll notice there’s no association between the input-restrictions and the validation-routines. For example, a user should never be warned that the name of the event he’s posting exceeds the maximum length allowed. It’s better to just limit the number of characters he can enter, and if the name of the event has to be pretty short, give him a character countdown (4 more [characters] allowed…3 more [characters] allowed). A user is going to be pretty frustrated to see an error the developer let slide in the first place (“Why are you wasting my time letting me enter bad data? Just stop it from happening in the first place and let me finish my task so I can go back to doing something I actually enjoy!”).

If you have two views with the same field-type, Form & Function takes care of all the sub-classing for you, so you and the other developers know that the password field on your ‘Registration’ page has the exact same requirements as the password on your ‘Update Password’ page. I’ve seen many cases where developers may have re-used a validator, but they differed on the character restrictions, and the users couldn’t update their password once they registered because the ‘old’ password was invalid.

Form & Function restricts character limits and character types, using the most popular standards (and you can override these limitations to suit your own needs in a granular or global fashion). To add a password to your Form, you’ll only need to specify the type=”password”. That’s it. Form & Function takes care of the validation routines, the character restrictions and the maximum character limits.

Problem 4: The Flex Validators aren’t associated with the Flex Formatters
With the Adobe Flex forms, there is no association between the field-formatter and the field-validator. If the developer is going to require data-entered be in a specific format, the field-formatter’s value has to be the same as the format value of the field-validator. For example, if your phone formatter is formatting to (###) ###-#### and the validator is validating against (###) ### ####, problems for the developer, business and the user start to bubble up.

Form & Function tries to help the lack-of-association-problem by using a single touch point (the same format property) for the validator and formatter, and restricting characters that aren’t allowed as part of the format.

Problem 5: It’s not easy to know when a Form is Valid or Dirty
There is no simple approach to tracking an entire form’s validity. As a developer, you typically have to run a long operation to test the validity of each control, based on whether the field is, or isn’t, required, and add the error messaging. I’ve typically seen this done in an array of concatenated strings, and for a long form, the operation might be 100s of lines long.

Then, there’s the dirty-flag. A developer needs to know when the form is modified from the original state. If the form is different, you’re going to want save the data (either in intervals, or based on milestones) and only so many times.

Form & Function is going to help you by offering a built in validity checker and dirty flag handler for each form item that you specify is required.

Problem 6: The Long Form has disappeared (and users liked the Long Form)
I’ve worked primarily on large ‘transactional’ applications using Flex, and in most of our user-experience studies, we’ve found that users prefer one, long form to a wizard. Why? Well, for starters, the Flex Wizards actually made form entry more daunting, because the user doesn’t know how tedious the next form is going to be. Think of it like “Let’s Make a Deal”, where the contestant stands up and guesses correctly twice, and then he gets to door number 3 and can either quit and go home, or take the mystery prize. It could be a donkey, or it could be a new car. When you see a form longer than the one you just spent 10 minutes working on, you feel like you just won a the donkey. You worked through two challenges, and on the third challenge, you been slapped down.

Problem 7: The standard Flex Forms Layout isn’t easy to read
Users look at a form and they use visual reference points to determine what needs to be done. If the visual reference points aren’t there, users lose track of what they need to do next. Form & Function provides a symmetrical grid, so labels, controls, format hints and colors are consistent from line to line.

Problem 8: Users aren’t working against a milestone
So why not just build a long form? Well, to begin with, long-forms are harder to develop. You end up with one form that has to account for so much logic, with so many validators and formatters, that the code becomes unwieldy. Those same problems make a long-form hard to test and debug, too. Form & Functionencapsulates this logic, giving  you a simple tag-based approach to building a robust, long-form.

From a user-perspective, a long form needs to provide even more feedback about how far along the user is in the completion process, and what’s wrong as they go along. The user may have scrolled so far down the form after a few minutes that he never notices the “First Name” field is incomplete.

Form & Function also gives a visual hint within its own field-column. Basically, if a social security number has to be entered in a specific format, Form & Functionprovides an example that should be visually recognizable as an example. If you need to add more information, you can omit the example and replace it with a built-in “More Info” link. Consider the  “More Info” link as a very tiny help center for each field. The link either opens up a simple text file that you specify, or you can have Flash open a new HTML Window if you have considerably more information to specify.

More importantly, Form & Function is a Graphical Feedback Tool. It incorporates a Graphical Animated Feedback Indicator (GAFI), as well as form items that change their color based on their validity-state. So users are always aware which form items are valid, which are invalid, and which items haven’t had any interaction yet. And the GAFI keeps the user aware how many items he has left to complete.

For Adobe, and most companies for that matter, it would be hard to dictate all the field types for the various languages and locales used throughout the world. But I’m less concerned with an internationalized product, and more concerned with building something that ensures 50% of my user-base is going to complete the task at hand, and 100% are going to complete it with confidence. And for me, 99% of my user-base comes from the old US of A (and if you’re not using the project for the en_US locale, it’s easy to tailor it to suit your own needs).

  • What Does Form & Function Do for Users?
    • It helps them keep a sense of state. As users enter data in a field, the surrounding background color changes to reflect the form item’s validity.
    • Small visual clues hint to the necessary data format.
    • There’s a visual reward system. As users move along, a progress indicator gives the user a graphical and numeric indicator, letting them know how much more work they have to do before they’re done.
  • What Does Form & Function Do for Developers
    • It saves time. As a developer, you no longer have to write a validator, formatter, restrictor, character limits, dirty flag handlers, or multiple form item names.
    • It’s adopted Convention over Configuration. The accessing of data, the setting of data, and the field types are all straight forward. If you want to change the behavior, you can, but for the most part, everything is straight-forward, using the most conventional approach to development.
  • What types of fields does Form & Function support?
    1. Address 1
    2. Address 2
    3. Captcha
    4. CheckBox
    5. ComboBox
    6. American ExpressDiscoverDiner’s ClubVisaMasterCard
      • Credit Card Expiration Date
      • Credit Card Number
      • Credit Card Security Code
      • Credit Card Type
    7. Currency
    8. Date
    9. Email
    10. File Manager (including the previewing of image files)
    11. First Name
    12. Last Name
    13. Generic Input
    14. Numeric Stepper
    15. Password
    16. Phone Number
    17. Radio Button Group (confirming the user Selected 1 choice)
    18. Rich Text Editor
    19. Social Security
    20. Time
    21. Website
    22. Zip Code (with or without Extension)
  • How Can I customize Form & Function?
    1. Most methods that makes up the Base FormItem Class can be overridden. There’s also a generic input that allows you to specify generic string restraints & requirements. I’ll be working to add some interfaces to help you along for performing extensions, along with sample code.
    2. The styles are externalized so you can easily change the feedback colors, form-item colors, and more.
    3. The Graphical Animated Feedback Indicator (GAFI) is optional.

Leave a Reply

Your email address will not be published. Required fields are marked *