Pages

23 March, 2016

Majority of errors on mobile apps occur on input forms. Users can input information with utmost ease and flexibility, if only input forms were designed better. In an old post ‘Contextual Keypad – Engaging Users via Mobile Inputs’, I highlighted the need for displaying context-sensitive keypad based on the input field type – alphabetic, numeric, email, password and so forth. A little after that, I found Luke Wroblewski’s work on design patterns that helps reduce form errors significantly. In this post, I will highlight Luke's three interaction design patterns that help reduce errors form fields:

Inline Validation

Inline Validation provides real time feedback as users enter values into corresponding fields. Let’s consider an example. On Dashlane iPhone app, if a first time user creates an account, the password field has a placeholder text, ‘Enter a strong password’. As user types the input, the app provides real time instructions on what rules the password field should comply with. This helps users to enter password without forgetting to enter a specific value or making a mistake.

Password Hints on Dashlane mobile app

Luke Wroblewski’s team ran a study by comparing forms with inline validation with those which do not have any inline validation. The forms with inline validation had 42% completion rate and a 22% decrease in errors. This shows how a small step towards good user experience helps apps succeed in the real world.

The keypad displayed is not email-friendly keypad. For user to search and locate ‘@’ symbol, he has to change the keypad where ‘@’ symbol is present (note that the keypad complexity increases further if many non-English languages are involved)

User might end up typing his first name or user name or the email id before ‘@’ symbol (i.e., if the email id is Parimala@gmail.com, user might enter just ‘Parimala’)

Since there is no real-time validation, user assumes that the given value is correct and taps on ‘Reset password’ button. Boom! An error, ‘Invalid Email: Please provide correct email address’ is displayed.

As you see, changing the input field type to display ‘email’ keypad could avoid user to perform 1st step mentioned above. It might be good to place place holder text 'user@example.com' inside the email field, so user becomes aware of the format. One might ask, ‘what kind of a user would enter invalid values despite knowing it’s an email field.’ It is a valid question. Yet, time and again, it has been proven that many users would do that. As Don Norman says, ‘An error that can be made will be made.’ Hence, we need to validate checkpoints in right fashion, to reduce such errors, if it’s in our control.

Input Masks

Consider a phone number field. Depending on your country, country code, changes. In such a case, phone number field would have 2 components: Country Code>Phone Number>. In below screenshot, can you guess if user needs to enter phone number with country code or not? It’s hard to tell. This could lead to errors.

If formats for input fields are such a big deal, why aren’t we taking them seriously? In ideal scenarios, it is advisable to insist users to enter input values in specific formats by implementing input masks.

Input mask is a mechanism by which one specifies the format in which the input will be accepted. For e.g. Phone number can have 2 input fields: Country code and phone number, as displayed below:

Input masks not only help reduce errors, but also guide the user to enter input in the right format.

Input masks can be taken a step further by revealing the input pattern at the beginning itself. Consider the screenshot below. User would enter a 16 digit card number and keep checking constantly at your credit card and the field just to ensure you have not missed any numbers (Note that the credit card will have space in between every 4 digits). Instead if the below card number field could show 'XXXX-XXXX-XXXX-XXXX', it would be helpful to the user.

To summarize, reduce errors by:

Using Inline Validation

Specifying Input Types and

Using Input Masks for formatting and accuracy

Have you thought about reducing errors on your mobile app forms lately?

10 March, 2016

Murphy's Law states that "Anything that can go wrong will go wrong". While things go wrong, adding a little bit of humor to error messages can lighten up the environment, at least for that moment. Given this context, organizations have started to build error pages with enchanting personalities.

The World of 404s

Consider a common case of 404 Error. Huwshimihas figured an interesting way to display 404 error pages. One of them is this: “A ninja stole this page. You must return when the moon has friends and the fox is borrowed.”

Frye/Wiles Creative Agency, displays the same error using the metaphor of a missing bird.

Frye/Wiles Creative Agency

Mobile App Hipmunk uses their mascot to deliver error messages in a soothing way. When hipmunk app stops responding due to possible internet issues, this is the error message: "Whoops! We can't reach Hipmunk. Please make sure you're connected to the internet, or try again later."

When the app needs additional information, the app asks for it. In below screenshot, the app needs potential travel dates before displaying results. This is asked in a nice way, by mentioning that its difficult to show results based on existing criteria and hence, would need travel dates to show appropriate results.

One anonymous marketer at Everyday IX once, quoted,

“Imagine if all products treated digital communication as a conversation with a real human being that possesses thoughts, goals, and emotions, not just the recipient of a conglomeration of technology restraints? It wouldn’t cure all design ailments, but it would certainly soothe frustration along the way.”

As quoted above, An error message is a sensitive conversation the product initiates with a human being, at a time when something has gone wrong, sometimes, terribly wrong. At such a point in time, error message need to be emphathetic, information and helpful. Of course, error messages are life-less and non-human. Yet, they can be made human in the way they work. In short, error messages need to have a strong personality - of being a torch bearer to the user.