Structured Format

Problem

Users will not know what data input format your application expects.

Solution

Represent input fields in a way that clearly guides the user as to what format to use.

Context

There are multiple formats for the data (e.g., dates, times, currency), and users will likely not know which one your application expects.

Rationale

Even if users know what data is to be entered, there are countless ways to represent much of the data we deal with everyday. For example, phone numbers, dates and times, and currency representations can vary even within the same country. Never assume that users will be thinking about data in any way that relates to how your application expects the data to be represented. Software applications usually expect data in ways that match the needs of some underlying database, which has nothing to do with how people think about and use the same data in the real world.

By simply representing the data input fields in certain ways, you can provide useful guidance to users regarding how to enter the data. Simple clues such as how many characters to use (e.g., for dates and times), what order to use (e.g., dates and times, first and last names) can take the guesswork out for users and will prevent many unnecessary errors.

This pattern is related to the Forgiving Format pattern, which in a way accomplishes the opposite. The Forgiving Format pattern allows users to enter data in a format that makes the most sense to them, and then your application translates what has been entered into whatever format it needs. You may want to consider the Forgiving Format pattern if you think you will be able to make sense of and translate what the user has entered.

Implementation

Think about how people use the data in the real world and use that as a model for how to represent input fields. For example, in the U.S., people tend to think of phone numbers as a 3 digit area code, followed by the first 3 digits of the number, and finally the last 4 digits of the number. Therefore it makes sense to ask for phone numbers in a similar manner.

Beyond simpler cases like phone numbers where at least the ordering of data is always consistent, this pattern becomes even more useful for cases where users will not know the exact order or number of characters to use. Dates are a great example. If you are expecting Month, then Day, then Year, make this clear by using separate fields for each in that order, using a clear label for each field. If you expect 4 digits for the year rather than 2 digits, then use the field label to show this (e.g., use “YYYY” to show a 4 digit year is expected, or “YY” for 2 digits).

You can also place a generic example of the expected input inside the field itself, and have it disappear one character at a time as the user enters data (e.g., you can use “(XXX) XXX - XXXX” for phone numbers, or “MM DD YYYY” for dates).

Help Me Get There

Infragistics has some tools that can jumpstart your efforts to implement this pattern. Broken down by technology, they are as follows.

ASP.NET

Structured Format pattern can implement using any of the following ASP.NET WebEditor controls along with regular labels. Check out the samples browser to see it in action.

Silverlight

You can use the NetAdvantage for Silverlight xamWebMaskedEditor or xamWebNumericEditor controls for this.

Windows Forms

You can use the NetAdvantage for Windows Forms WinEditor controls to implement this pattern.

WPF

You can implement this pattern using the NetAdvantage for WPF xamEditor controls. If you download the NetAdvantage for Win Client bundle, you can find a sample in the xamFeatureBrowser called Input Mask to see it in action.

Sources

Jennifer Tidwell, Designing Interfaces

Tags

Data Entry, Masked Edit, Form.