Main Page Content
Usable Forms For An International Audience
With members across the planet, evolt.org would collectively have a wealth of experience when it comes to designing, building, and using contact forms. Almost everyone, and this is especially the case when one is accessing a form designed (often accidentally) without users from another country in mind, will have come up against a form which either by client- or server-side validation, seems determined to not let correct information through.
These forms are those that ask for a first name, last name, any middle names, email address, postal address, phone number, fax number, or more. They are usually named contact or enquiry forms, and their goal is to get your details either into a database, or delivered to someone via email. However, either by over-enthusiastic input splitting, validation, or length constraints, many forms are a hindrance to some users. In many cases, those users are from a country other than that of the designer.
Beyond a local audience
There is obviously a growing interest in providing services to an international market. Whether you are a North American company wanting to sell overseas, or within Australia or Europe and wanting to service a massive US market, you absolutely have to consider the differences in information likely to be provided by your users. Without doubt, validation can be an impediment to users. It is critical that you do not leap into designing a form without prior thought: how can you create a form that is usable by your local or primary audience? Additionally, how can you create a form that is usable by an international or secondary audience?
Stop and think about the last contact form that you designed, or consider this the next time you have the opportunity:
Are you designing for your users? or Are you designing for your database?
Typical barriers to form usability
There are compromises that must be considered when it comes to the:
- length constraints on information
- content or style constraints
- required elements
- splitting of elements
Length contraints
An obvious example of the usually employed length constraint is the HTML input attribute of maxlength which can restrict the content of an element to a desired length. Specifically, an Australian developer might limit a postcode field to 4 digits and frustrate an American user with a postcode of 5 digits. Likewise, an American developer could implement a limit of 5 digits, and hinder a Canadian user inputting 6.
Client- or server-side validation can provide a similar function, server-side validation with an annoying repercussion: it requires posting of an HTML form to discover the constraint in place. And even that assumes that an error message will be appropriately worded to provide insight into the constraint in place.
Before you design and implement another form from which you expect any enquiries from international users, I suggest that you browse the almost insanely comprehensive Frank's compulsive guide to postal addresses.
Content or style contraints
Validating the content of the aforementioned postcode to include numeric values only could also present problems with some country postcodes using an alphanumeric set. An additional example is limiting phone numbers to a numeric set and stopping someone entering their number in the valid international format of "+61 8 8123 1234", or Australian STD format of "(08) 8123 1234". It would even stop a user entering the explanation "I don't have a phone number." or "Please email rather than call."
You can find a small number of posts on the topic of varying phone number formats on the CHI-WEB listserv: Search results - "number".
Another common problem area is restricting input to a certain set of values, whether by validation, or by using a select box with pre-filled values. An input requiring a user's state abbreviation which is restricted to those valid in the United States, obviously blocks any others.
Required elements
Requiring specific content may well serve a task of filling a membership database with information to please any advertising consultant, but is it serving your purposes at the expense of the patience of your users? Marking an email address, phone and fax number as all required will not help your users without a fax number, or who would prefer to omit a phone number to ensure communication is by email. You should evaluate whether your priority lies with filling your membership database (and enabling you to bombard users with advertising by every possible means), or successfully welcoming a member or customer.
Such requirements will often lead to user frustration, and any form and database combination requiring an unreasonable amount of data should expect users to enter valid, but incorrect data. So many users needing to pass forms requiring an email address, but not wishing to be contacted, enter junk data such as asdf@asdf.com that the owner of the domain has a page online to explain their inability to use the address themselves.
Similarly, non-American users attempting to partake of an American service often enter the only US postal code they know: 90210. I can imagine many statistics staff scratching their heads at trends which show an amazingly disproportionate number of users coming from Beverly Hills. Sorry boss, we can't include Beverly Hills in our new graphs as there's no way of determining how many users were being serious!
Any compromise must take into account this issue of data purity. If you need accurate data (for example to plan direct marketing campaigns to specific suburbs), then you absolutely must minimise chances of users becoming frustrated and entering incorrect information!
The key to this is to carefully consider which fields must be required, or controlled.
Splitting of elements
As with the other constraints, over-splitting inputs can waste the time of, and frustrate, users. For example, breaking an address field into StreetNumber, StreetName, and StreetType requires three separate inputs rather than one. This is an instant usability issue: typing their address freeform is a familiar task for a user, but thinking about entering it into multiple fields is an unnecessary delay.
And for what purpose? I've seen this done before, and I cannot imagine how this data would be used, besides more accurately ascertaining whether more people reside on a Street or an Avenue. When coupled with a content restraint, such as use of a select box to enter a StreetType from a defined list, these forms can be particularly impossible to correctly populate. It also makes no provision for those needing to specify apartment numbers, or floor levels.
Input splitting may not serve a form well when it crosses national or cultural boundaries either. Likewise with element naming; to ensure that more users are well supported, naming a state input as "State or Province" immediately expands its understanding. However, use personal judgement -- if your form is likely to be used in 99% of cases by Australians, then using this title might risk confusing 50% of that majority to serve the 50% of the remainder who would not think of entering their province in a field marked "State". To summarise, it could be sensible to use generic or multiple terms to increase the value and understanding of an input.
Asking for FirstName and LastName is another example. Unless you have specific requirements to separate these two accurately in parts of your web application, consider using a single name field. A user will enter what they feel comfortable with, whether that is a full name, a first name only, or even a nickname. It's their problem if your sales team has to embarrass them by calling their parents house to ask for "aardvark". ;)
This is especially relevant to designing for an international audience. Information Architect, Jonas S�derstr�m notes in the CHI-WEB forum Many styles exist around the globe. Russians and some other Slav people have the patronymic inserted between first and last name. In some regions in Sweden, an integral (and first) part of people's name, still is the name of their farm.
From Peter Boersma in the same forum: The tradition of having middle names is not a global tradition. I've had to think up a middle initial several times when entering personal information in a US-centric website.
Excuses, excuses ...
On occasions, constraints are excusable when required by a database for a specific purpose, but should nevertheless be evaluated on a case by case basis. Is it more important that your application is able to refer to a user by their first name only for personalisation/welcoming purposes, or perhaps to enable members to be sorted and listed by their surname? Or is it of vital importance that you keep your membership sign-up form as straightforward as possible to maximise membership growth?
Never forget that you can always allow valuable, longer-term users (often those providing the majority of your income or visitor numbers) to enter more detailed information at a later date. Don't turn users away with an epic voyage of registration; only ask them to enter the information required for them to complete a specified task. For a simple site registration, that might be an email address and a password. For a competition, you could ask for a phone number or postal address (you need to post out the prize, right?).
Large forms which definitely require large amounts of information should be split to make the process for a user less daunting. This also gives you the opportunity to ask for a country of origin early, and customise later steps, if your development budget allows for this.
Far less excusable are forms posting to an email address which unnecessarily require a multitude of contact inputs or personal details. If it is not being stored in a database which needs all of these fields, a user should generally only be required to enter a name (in whatever form as explained earlier), their preferred method of being contacted (email address, phone number, etc), and a query or comment. If they desperately want to specify alternate details like fax numbers or after-hours phone details, the query field can be the place for this.
It's for the sake of the users
You might want to tell me that users are stupid, and that your validation and input splitting is to stop them making mistakes. But users aren't stupid (well, not all of them anyway). They are rushed, distracted, and apprehensive. Anything that you can do to make things easier for them will ease the process. Simplify your forms and, if possible, encourage them to input the correct data, rather than implement overly strict validation without forethought. An example: a state abbreviation field sized to allow two visible characters, but not maxlength'ed, coupled with a sidenote would encourage users to enter "OR" rather than "Oregon", without penalising an Australian wanting to enter "NSW".
At times you should consider post-form data cleansing as part of your server-side scripting. Direct mail companies can provide data cleansing services, but you can minimise your costs, or your time (if you're cleaning data yourself). Consider entry of a credit card number: don't place strict validation restricting entry of spaces every four digits, or require hyphens as separators. Accept any format initially, and clean or insert spaces/hyphens as needed.
Evaluation and compromises
Questions when evaluating a decision regarding a split of, or constraint on, inputs must consider each opposing side:
- the entering of data
- the usage requirements of data
From the responses you can make an appropriate decision.
Remember, you will want to ask yourself or your development team these questions with each compromise; that is, with each element:
THE ENTERING OF DATA
- When entering data, will users take longer to do so?
- Someone will take longer to enter "31 Otter Crescent" in three form fields than one.
- Are they more likely to become confused or frustrated, and abandon the process?
- After attempting to enter an Australian state abbreviation "SA" into a form validating US states, a user may receive the message: "Your state is invalid. Please enter a valid state abbreviation." Such a message is confusing as "SA" *is* a valid state abbreviation. Leaving the field blank to avoid impacting data purity could return the message: "You must enter your 2-letter state abbreviation." At this stage, the confused and frustrated user will either abandon the form, or enter a fake state abbreviation.
- Are they more likely to input invalid data, and is valid data critical?
- If you're categorising users by location, then valid state information is preferable. Using a select box allowing only specific values is a common solution, but guarantees some invalid information. Adding an "other" option is a possibility, but reconsider the first time-based question: Is it faster for a user to browse to the bottom of the select box and select "other" (and then optionally enter their preferred option), or to simply enter their preferred option? In the case of a two-letter abbreviation, the latter is, without doubt, faster.
- Is invalid data more damaging than no data at all?
- In most specific cases, any data will prove to be more useful. For example, weeding through server/email logs to find the invalid email addresses might be a small cost to pay to build up the contact database. But consider a wider trade-off: if by demanding a fax number, a percentage of users are becoming frustrated and abandoning a sign-up procedure, you may wish to dump the fax number. Required fields may also have little bearing. A mass of optional elements would also be somewhat of a barrier to users.
THE USAGE REQUIREMENTS OF DATA
- Is this information to be received by a database via SQL, or a recipient via email?
- Obviously, in the latter case, a structured filter or validation is less critical.
- Is it essential that data is available in the first instance of a membership application, or could it be solicited at a later date?
- A membership sign-up form might require an email address for password verification purposes, but you could probably wait and get a fax number or postal address later (if at all).
- Need the data be split for purposes of sorting or automation?
- If you plan to accurately sort users by their surname, or automate emails sent to specific suburbs or states, then you will need separate form inputs for these items (or some complicated parsing code). Of course, weigh up the consequences of this before implementation.
- Are plans for the process or application likely to be altered in the future?
- "Futureproof" is the word. If you automate contact procedures, and wish to extend this beyond email to fax and recorded phone messages, then it might be more important to request this info. If you can see email covering your needs, then perhaps go with that alone and be happy. Dealing with international enquiries via email is certainly more cost effective than racking up long-distance charges by phone or fax.
Testing
If you have the resources, then test your proposed form. Have colleagues try to spot areas of frustration for users, or ask the above questions of a team of people in a brainstorming session. Finally, run a batch of users (the more reflective of your target audience the better) through the form under suitably limited and distracting conditions. Give them a time limit, and some screaming kids to deal with at the same time. Few people ever have to book accommodation in a different country while seated in a peaceful lab.
I encourage anyone with questions or information relevant to this article to comment below. Do you have, or have you seen, a method which you think works? What are you or your clients doing to make your site useful for people coming from a different country or culture? Do you think more sites are now focusing on a specific, local audience instead of continuing with often ineffective attempts to push localised-content on a wider audience?
www.triplezero.com.au