Articles Comments

GUI Journal » Controls, GUI Design, Mistakes » GUI Design: Text Field Help

GUI Design: Text Field Help

For years there has been a gradual trend toward providing help text in empty input text fields in GUIs. It became so common that when mobile apps began to be developed, help text was simply expected and is the standard for native mobile apps. Unfortunately, there is a wide variety of implementations in non-mobile environments, some of which are not very well done.



Figure 1 is a combination of portions of screen shots of the Chase® Bank app on iOS 5.1. The upper left graphic shows the login screen before focus is placed in either of the text input fields (User ID or Password). (Note the help text in the User ID and Password input fields.) The lower right graphic shows the screen after text has been entered in the User ID  field and focus is in the Password text field.

iOS App for Chase® Bank before and after focus is placed in User ID input field.

Figure 1. iOS 5.1 App for Chase® Bank

When focus is placed in the Password text field, the caret is shown and the keyboard appears, receiving the focus. The help text is grey, making it more apparent that this is not an entered value. The help text remains even after the field has focus, so long as no text has been entered. This is a mobile app standard and can be found in most mobile apps. This is what is expected.



Figure 2 is a combination of portions of two screen shots of the Install dialog found in various versions of the Eclipse® IDE. (This screen shot was taken from the Eclipse IDE for Java Developers on Windows®.) The upper left graphic shows the default view of the Install dialog. Note the highlighted text “type or select a site” in the Work with: text field. (It’s actually a very convenient control that allows text to be entered, but also has a list of previous and other choices for quick access.) The lower right graphic is the display after clicking into the end of the text field and typing text.

Figure 2. Eclipse® Install Dialog

The problem with this control is that the help text is actually a value entered into the control itself. If the user immediately begins typing, then the selected help text is replaced by the the typed text. But more than once I have accidentally clicked into this text field before typing and ended up with a situation similar to what is shown here.

The funny thing is that this dialog actually does use help text correctly in the next text field. Note that the control has the text “type filter text” which disappears when the control gains focus. The first control should have been implemented in the same way. The inconsistency is unfortunate.



 Delta Air Lines® "Search" control before, during, and after focus is in the control.

Figure 3. Delta Air Lines® Search Control

The web site for Delta Air Lines® has a better implementation of help text for the Search control found in the upper right of its main page (and subsequent pages).

Figure 3 is a combination of portions of screen shots of the Search control before, during, and after focus is placed there.

This implementation is better because the help text does not interfere with the actual text that will be searched for, but it is unfortunate that the help text does not return after focus has been lost. Looking at the page source reveals that the control has been implemented by setting the value of the control to be the help text (value=”Search”), in the same way that the Eclipse dialog was implemented. In this case, however, when the control receives focus, the value is set to blank and is not set back. See the last statement in the code below:

<input type="text" value="Search" onfocus="this.value=''" ...



American Express® Log In controls before, during, and after focus on the User ID text field.

Figure 4. American Express® Log In Controls

The web site for American Express® has an implementation of help text that is even better. Its controls for Search and Log In have help text that appears whenever the control is empty, even after focus was previously on that control.

Figure 4 is a combination of portions of screen shots of the User ID and Password text fields for Log In. Note the help text in both of the text fields in the graphic at the upper left; this is before focus has been placed in either text field. The center graphic shows the display when focus is in the User ID  text field. The graphic at the lower right shows the focus in the Password text field, immediately after moving from User ID. Note that the help text for the User ID is displayed again, because the field is still empty.



The best implementations of help text will mirror what is found in most mobile apps. That is, the help text actually remains visible until an entry has been made in the text field. Many GUIs have implemented help text in this way. Figure 5 is a screen shot of the Sign in panel for the Pandora® web site.

Figure 5. Pandora® Sign in Panel

Note that the help text “Your email” is still visible even after focus has been placed in the text field. In this case, Pandora has actually decided to use help text in place of a label for the text field. This is becoming more and more common, as also seen in Figures 3 and 4. Figure 1 is an example of having both a label for the input field, and a little more description in the help text. In any case, the key is to give the user helpful information without getting in the way of the task they are trying to accomplish.

By the way, looking back at Figure 2 we can deduce that the reason this dialog was implemented as such is because the help text goes away when the text field gains focus. This means that when the dialog is first invoked, because the focus is in the first text field, the help text is never seen. The solution to the Eclipse dialog problem is to keep the help text visible when the text field has focus, removing it only when text is entered.



  1. Most empty text fields can benefit from help text.
  2. Users expect help text to not interfere with the text field itself.
  3. Help text should be present until a value is entered into the field (not just focus).


Written by

Carl Andersen currently works for Micro Focus International as a Senior Development Manager. Carl has led teams at NetIQ, Novell, and WordPerfect and been the principal designer of multiple GUIs which have received analyst acclaim.

Filed under: Controls, GUI Design, Mistakes · Tags: , , , , ,

Leave a Reply


one × = 9

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>