The topic you requested is included in another documentation set. For convenience, it's displayed below. Choose Switch to see the topic in its original location.

TextBox control design guidelines for Windows Phone

[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]

A TextBox control accepts input from the user via the keyboard.


This topic contains the following sections.

A TextBox control is a fixed-height, rectangular block of editable text. When a TextBox control is tapped, a cursor appears and the on-screen keyboard pops onto the screen. Pressing Return on the keyboard usually handles the input in whatever way your app specifies.

Text boxes may display a single line or multiple lines. Multiple-line text boxes will wrap text to the size of the control.

Aside from its length, a TextBox control doesn’t have any inherent visual clues that suggest what input is valid. You should use a label to convey what can and should be entered in the TextBox control. Clear visual cues will ensure fewer error messages and help create the sensation that text entry in your app is quick and painless.

Text boxes may be set to read-only, but should generally be used for editable text.

Gestures supported:

  • Tap – for focus and selection

  • Tap and hold – for precise caret insertion

Use a TextBox control to let the user enter a short amount of textual input. A TextBox control should be used with a constraint, such as a maximum number of characters allowed, or a restriction to numeric values (0-9) only.

The appearance or disappearance of a TextBox control may depend on another control, like a CheckBox control or a Button control, in the same view.

Although Windows Phone has a spacious and comfortable group of on-screen keyboards, it’s still time consuming for a user to enter info by typing. Before you decide to use a TextBox control, consider whether there are gestural controls that might make inputting the info faster, such as a ListBox or Slider control. Where keyboard input is necessary, consider ways to make it quicker. Here are some suggestions:

  • If the input requested by a TextBox control is going to be relative to another quantity in the same view, consider the Slider control instead.

  • If the user is choosing from a set of known quantities, a ListBox control might be faster, especially if those quantities are more than a few characters long.

  • It’s sometimes a good idea to show the effect of a control’s operation in real time as the user adjusts it, such as with a volume or brightness setting. The Slider control may be more appropriate for these purposes.


Consider ways for your app to succinctly and elegantly convey what a TextBox control asks for, and what its constraints should be. This reduces the likelihood of invalid input, and therefore the likelihood of error messages.

Try to use as few constraints as possible on the “front end” of a TextBox control. Instead, put constraints behind the scenes, and handle the error if the input returns invalid. This makes your app easier to localize. If you must use constraints on input, consider the needs of global users when you’re deciding on them. For example, a TextBox control that asks for a postal code and constrains input to numeric values (0–9) won’t work in some localities.

Other considerations:

  • In Windows Phone, it’s not possible to customize the on-screen keyboard, or determine which language version appears when the user taps the TextBox control.

  • If your app disables a TextBox control for any reason, it should also disable any associated labels, instruction labels, and Button controls.

  • To reduce clutter in a particular view, you may choose to make a TextBox appear or disappear with the operation of another control, such as a CheckBox control.

  • To improve the responsiveness of your app, you may choose to make a TextBox control operate automatically as a user enters text. This is useful if the TextBox control is being used to search a list, or to suggest search terms as a user types, because it doesn’t require the user to tap a button to complete the operation.

  • Once the user has entered some text in the control, consider how it will react visually if they tap that same TextBox control again. If a user is more likely to revise the entire value, the control should select all the text in the field. If a user is more likely to edit the value, place the cursor at the end of the text.

  • Use the appropriate keyboard for your constraints.

  • If you find yourself assigning special meanings to specific values in your TextBox control, try the CheckBox or RadioButton controls, which allow for explicit user selections.

  • It isn’t possible to scroll in a TextBox control in Windows Phone.

TextBox controls are rarely used alone. Other visual cues like buttons, labels, and graphics are almost always necessary to instruct the user what kind of information to enter. It’s up to you what these cues will look like.

If you choose to put cues in-line with the TextBox control, it’s usually best to reserve the left side of the TextBox for some indicator of its purpose, such as a label. The right and bottom sides can then be used for additional controls like buttons.

One of the strengths of a Windows Phone device is displaying information in clear, beautiful typography. Take advantage of this design characteristic when advising users on the use of a TextBox control: use succinct and clearly legible words or labels.


One way to clue in users about the purpose of a TextBox control is to use textual prompts inside the TextBox control itself. These short hints tell the user what to enter, and then disappear when the user taps the control to begin typing.