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.
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.
BAD HELP TEXT IMPLEMENTATION
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.
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.
BETTER HELP TEXT IMPLEMENTATION
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=''" ...
MUCH BETTER HELP TEXT IMPLEMENTATION
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.
BEST HELP TEXT IMPLEMENTATION
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.
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.
KEY DESIGN POINTS
- Most empty text fields can benefit from help text.
- Users expect help text to not interfere with the text field itself.
- Help text should be present until a value is entered into the field (not just focus).