The anatomy of a text input field
There are two interface interface elements of typical mobile user interfaces that does the heavy lifting. That is the Text Input Field and the List. I thought I'd share with you some of the usability considerations that is going into Text Input Fields at mBricks.
The keypad is well suited to number entry, but ill suited to text entry. Entering text on a mobile phone is hard, and people tend to avoid it if they can. The less text input you have, the better. But you can't avoid it all together.
Text input fields are suitable for plain text, numbers and passwords. For entering specific data types like date, time, number ranges etc. you should not use a text input field. Instead use Multi-field Input or a selection widget like a Calendar.
Elements of the Text Input Field
Full screen editing
Full screen edit
Edit-in-place is preferable in most cases. A person can see the context, and the visuals is consistent. Full screen editing is preferable when the user is likely to enter a large amount of text. Predictive text (T9, etc) may only be available in full screen edit.
All phone OS'es offers a full screen editor. Use a visual clue like the one above (to the left) to indicate that the full screen editor will open.
Vertical and horizontal layout
Most input fields consists of the control itself and its label. Screen layout may be horizontal or vertical.
In a vertical layout the label is positioned above the field, and both the label and the input field are left aligned. In a horizontal layout the label is right justified and the input field is left justified.
Input prompt
Instead of a label, you can use a prompt displayed inside the field itself. The prompt takes less screen real estate, but is only visible when no text is entered.
Error prevention: constraining input
When the input is to be consumed by a human being, the only limitation is what the system is capable of storing and transmitting. If you send your birthday to another person, the format does not matter as long as the person in the other end is able to understand it. "I was born on Christmas eve 1980" is completely understandable by a human.
However, people are smart and computers are dumb. For most applications, input has to be understood by a computer and the computer needs the information in some predefined format. The application has to tell the person entering data what it expects and can understand.
There are several ways to help humans and computers to understand each other better: Bound Input, Active/passive validation and Formatting.
Bound input
A Text Input Field can alternate between alphanumeric and numeric.
When input is constrained, for example to numbers only, the widget must indicate what the constraints are. People are ok with this arrangement, as long as it is easily to see and understand what the active constraints are.
Active Validation and Passive Validation
Active validation is done character by character as the user types.
Passive validation is performed after the entire input is complete. Either because the data has no meaning until the entire input is entered, or because validation has to be performed at the server.
A field that will be validated should visually indicate this.
Feedback should highlight the error and provide information about what the problem is.
A different approach. The user don't have to select the credit card type. As they type in their credit card number, the right card type is chosen (based on the card number). Looks cool, but I don't know if this has actual merit. Example from Masabi.
Formatting
Sometimes data is commonly displayed in one format, but stored inside the database in a different format.
An example could be a credit card number or a phone number. To make it easier for human beings to read a 16 digit credit card number, it is displayed in blocks of four digits. The human readable form of a date or phone number is probably not identical to the way it is stored in your internal database. Do not allow lazy developers to mess with this, make sure that the application displays data in the appropriate format.
It is worth stressing this issue because the problem is common. Companies print serial numbers or registration keys with spaces and hyphens but do not accept them when a user enters them into a form as they are printed.
The application can strip out any spaces or hyphens as the user types, or before validating.
Overwrite mode
Wherever appropriate, prefill form fields with your best guesses at the values the user wants. Overwrite mode selects all text, so it is easy to type in something else, without having to erase the suggested text.
For more about good defaults, visit Jenifer Tidwells pattern collection. Even better, buy the book.
Autocomplete
This is a large topic, it needs its own post, but the general idea is to guess what a person is about to enter and offer to complete the text. Combine a text input field, a popup list and some logic. Typically seen in URL address fields. Most decent mobile browsers offers autocomplete. This example is from Yahoo! Go:
Handling overflow
Text lines that are too long to display in full can be truncated. This is done by removing characters until the remaining text plus an ellipsis (three dots) fits the screen space. The ellipsis signals that data extends beyond the field boundary.
- Text should be right-truncated, i.e. characters are removed from the end of the string.
- Numbers should be left-truncated, i.e. removed from the beginning.
Text that is too long can also be displayed as marquee text or auto-scrolling text.
The text moves toward left (opposite direction of reading) and is clipped at both ends. The text starts with a (1 second) pause and then moves smoothly to the left (about 7.5 characters per second). When the text is back to its starting point, it pauses again for 1 second before continuing.
Only the text field that has focus is scrolled, when the text looses focus, the text is immediately reverts to its truncated and static form.
Interface texts like labels or alerts should not be scrolled. And don’t scroll very long texts.
States
A general purpose text input field needs five editable states and five non-editable states.
Anything that can ease the pain
Text input is not straightforward on a mobile and anything that eases the pain of entering text is likely to make your application more successful.
There is many additional aspects not covered here. Especially if you work with touch-screen keyboards where you might be able to provide context specific shortcuts.
A good resource for more info is the Mobile Design Resources wiki at Little Springs design.
Subscribe in a reader
Very good article. I like the section on passive vs. active validation, either of which are far better than no validation. ;-)
Posted by: James Marzano | June 25, 2008 at 18:44
Great post - thanks for the inclusion of our credit card validator! The article also sums up the current version of our text fields too, in particular the points on validation.
One slight correction - we avoid asking explicitly for the credit card type because this is redundant information, and we want to minimise data entry. The principal aim of the icons is to give a visual clue to the user if they have got the number wrong - as they type, we eliminate card logos that could not be valid, so if they see only 'Visa' and they're entering a Mastercard it might prompt them to fix the mistake. We also explicitly indicate if the number does not validate with standard CC checksums, but allow the user to send it in anyway as you never want to trust client validation absolutely!
Posted by: Tom Godber | June 24, 2008 at 18:24