From MobileDesign

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.

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.

[edit] Elements of the Text Input Field

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.

[edit] 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.

[edit] 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. Make sure the label reappears when information typed is cleared. The label should have a different treatment than entered text; making the label gray, for example, works fine.

For web pages, make sure there is still an inline label. This way if styles do not load (or are not supported) the field will still be clearly labeled. There are additional reasons for correct semantic labeling, including accessibility and SEO.

[edit] 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.

[edit] 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.

Many device OSs have this labelling baked into the basic UI. Make sure to use or emulate that display method from the device so users immediately recognize it, and know how to change the field (if possible).

[edit] 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 doesn'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). This example from Masabi.

Some validation methods, like automatic identification of the credit card (whether shown on screen or not) will get pushback from developers. Often, it's not really impossible, but just "never been done before." Find out the specific objections and you can often get most of what you want anyway.

[edit] 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.

[edit] Masking

Setting an entry field to a password type will cause it to be masked. This makes all user input turn into bullets (•) or sometimes asterisks (*). On most mobile devices, the user may see individual character input briefly, before it becomes masked. Generally, this happens when the triple-tap rules lock the character and move to the next item.

Even with this nod to visibility, masked input is difficult and causes errors. Multiple input fields (as generally used on the desktop web) and other mitigating designs only solve the technical issue, without addressing the root human factors issues.

For mobiles, do not used masked password fields. Small screens and the personal nature of mobile devices mean the risk of over-the-shoulder peeking is essentially zero. This should also allow entry to be sped up tremendously, actually reducing any chance of observed password interception over conventional mobile masking methods.

[edit] 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.

[edit] 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:

[edit] 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.

[edit] States

A general purpose text input field needs five editable states and five non-editable states.

[edit] 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.