How to Highlight Required Fields on Mobile Forms

I got a little challenge the other day from one of our PMs, Sarin:

Distinguish between Required vs. Optional fields on mobile forms without overcrowding the form 

Problem Statement

Consider a mobile form where most fields are mandatory with a ‘Submit’ button. This button is in disabled state until user enters valid data in all fields. These days, many mobile apps follow this practice. However, users might be in grief, not knowing what they have to do for the button to get to enabled state. I have drawn inspiration from Luke Wroblewski’s great body of work on forms  and Erin Walsh to outline few approaches I think are useful to solve above problem:

1. Colored Borders

Few mobile forms follow an approach wherein all required fields are highlighted with a colored border by default, when the user lands on the screen.  The colored border goes away once user enters valid data in corresponding fields. In some cases, colored borders can blink or glow to garner attention.

Cons

• Mobile forms appear overcrowded due to colored borders, if most fields on the form are required, hence creating visual noise
• User might be shocked to see so many errors, as soon as he lands on the screen, even though he has not started to do anything on the form, yet

2. Secret Asterisks

Asterisks have existed in web development world for decades to indicate required fields. A general rule of thumb is to put an asterisk symbol next to a required field label with a tiny note in the header/footer saying, ‘* symbol indicates this field is required’ message.

Cons

• Users hardly pay attention to asterisks on mobile forms.
• Non-tech savvy users might wonder what the asterisk symbol means, especially if they don’t notice the ‘* symbol indicates this field is required’ message or if this message is absent.

3. Using Auxiliary Labels

Another approach to highlight required fields is to add auxiliary text ‘(optional)’ or ‘(required)’ at the end of label to indicate whether this field is required or optional.

Cons

• Too much of content for labels has issues if forms need to be localized in multiple languages
• This approach has content overload issue if forms have too many fields. Imagine a form with 15 labels where 12 are optional and 3 are required. The form gets heavily overcrowded due to auxiliary text. Vice versa, imagine a form with 10 required and 5 optional fields. Same problem pursues.

Auxiliary approach appears reasonable in few ways, provided following improvements are considered.

1. Use ‘(optional)’ or ‘(required)’ based on which of these field types are fewer in number. For e.g. if most fields are required and very few are optional, indicate ‘(optional)’ for optional fields only as they are fewer in number. Vice versa, use ‘(required)’ for required fields if required fields are fewer in number
2. Another rule of thumb is to eliminate optional fields on mobile forms, if that is a feasible option

4. Information Messages

An information message is placed in the header and/or footer that reads, ‘Please enter data in required fields to proceed’ or a similar one.

Cons

• There is a risk that users do not notice this message due to placement, font style, size and color.

5. Animation

If mobile form has too many fields, having visual cues like asterisks, auxiliary labels or colored borders may not really help. This is usually the case where forms are lengthy and user is either at the top of bottom of the form. In such instances, it might be good to do the following:

Introduce an animation where text field moves left to right for a few interactions. This can be combined with mobile device vibration feature for better effect. Booking.com mobile app uses this approach on login form below:

Another way might be to time the behavior. If user hasn’t entered any information on the form for let’s say, 5 seconds, user focus can be taken to the required field where animation effect is displayed.

Cons

• Animating all required fields might lead to chaos; they may have to be defined in a methodical way
• Timing animations may or may not work depending on user behavior and demography

What is a suitable approach?

After analyzing above 5 approaches, I was still with the same problem in hand statement and no solution yet. When I proposed these approaches to few developers, they shared their views on pros and cons of each approach. At this point, it dawned on me to use a combination of multiple approaches to solve the problem I set out to solve rather than hanging onto one approach.

1. A message, ‘Please enter data in required fields to proceed’ is displayed at the footer near the disabled action button
2. Fields are indicated as optional or mandatory fields [Use ‘(optional)’ or ‘(required)’ based on which of these field types are fewer in number. For e.g. if most fields are required and very few are optional, indicate ‘(optional)’ for optional fields only as they are fewer in number. Vice versa, use ‘(required)’ for required fields if required fields are fewer in number].
3. If user is on the form for 3-5 seconds and :

          a. User does nothing because ‘Continue’ button is disabled

          b. User taps on ‘Continue’ even knowing that it is disabled

In (a) and (b) above, required fields glow with a sky blue colored border to indicate that these fields are required for user to enter. If user is at the bottom of the screen, focus is drawn to the first required field on the screen. Blink is better than glow effect, but from accessibility point, blinking is bad for photosensitive users.

As you notice, we have used Information Messages, Auxiliary Labels and some Motion Design to accomplish desired effect. Several times, we may have multiple approaches or techniques to solve a problem. The challenge is to pick the right approach and validate if selected approach solves the problem in its entirety. Customizing a suitable approach by collaborating with different stakeholders helps in coming up with a good solution that is good enough, if not great. An iterative development process helps refine the identified solution over a period of time.

Have you faced a similar problem before?

Mobile Calendar Essentials for Flight Booking Apps

Choosing travel dates is one of the frustrating experiences for travelers while booking flights, hotels or taxis using mobile apps. Few super-slick calendars and date pickers are abundantly available, yet the nightmarish experience of date selection remains.

General Guidelines for Calendar Behavior

I have used calendar feature in different contexts - booking appointments, hotels, buses and amongst others. I faced many problems, I have got confused and frustrated, sometimes, literally stalling my task and walking away. This post is a result of those experiences and questions I asked myself about the workings of a calendar while using flight booking apps.

There are several guidelines to consider while designing calendars for a seamless experience. Some of them are:

• Date selection screen could be a single screen where user can select Departure and Return dates at one go (tabs or segmented controls or other ways)
• Calendar highlights current date, departure and return dates. Current date has a text ‘Today’ below the date for memorability purposes in addition to a color background (Note that colored background alone could be hard on color blind people)

• Months are scrollable using swipe gestures. Icons like <, <<, >, >> are not a good fit for mobile
• Travel dates need to be highlighted once selected with a range. I.e., if 29th June and 2nd July are selected, the days in between these dates need to be highlighted to represent the range or the number of days.
• Drag and Drop of dates is supported. However, do not force the user to drag and drop for dates that are far apart, because it might be hard on the user to drag and drop instead of selecting in such a case

• Clean interaction / animation is defined and executed for each transition / behavior change / state change on date picker [This is a broad and vague goal that needs a separate blog in itself]
• Ability to modify departure or return date independently. Tapping on departure date field should show date picker screen with focus on Departure Date tab and similarly for return date.
• For round trips, user has to be prompted to select a return date using suitable animation that provides a strong visual cue
• Provide Cancel and Done button on calendar screen to give freedom and control to user. This is debatable because is some user tests, it was found that users expected the screen to auto-close once date selections were made. In few other tests, users were wondering why the screen closed without any action from their side. Such tradeoffs are very common while solving UX problems.
• Keep buttons, tabs and other critical information on top of the screen for better visibility. This is valuable from an accessibility point of view as differently-abled users are also used to finding critical information at the top.
• Local timezone (place of booking) is considered for date selections. Note that flight dates will be local time zones of respective countries where the user is visiting.

The above list is a set of guidelines, not hard written rules. Hence, they may not be applicable in all contexts. You need to pick the ones that suit most to your context.  

What's Your Experience With Calendars?

P.S: Special Thanks to Suresh Chelliah, Binoy Vijayan and Mohanraj for their review comments on this article.