The error is not UIAlertController

Yaroslav Morgachev
Apr 26, 2020 · 5 min read

Designers I work with often consider error messages in iOS as something obvious. Exactly — as UIAlertController.

Pre-installed Apple apps set this trend. Therefore interface designers consider this approach to be native and correct.

In this article, I will talk about the results from inappropriate use of UIAlertController. I will share my opinion about alternative ways to report errors to the user and the actual need for UIAlertController.

This article is for experienced users. This is why I don’t talk about what the user experience is and its interruption, how the average session length affects the app’s income, and why it is important to keep the user’s finger movements to a minimum.

Contents

  1. Interrupting the user experience and hidden choice.

Interrupting the user experience and hidden choice

The Apple Human Interface Guidelines have a couple of interesting lines:

Minimize alerts. Alerts disrupt the user experience and should only be used in important situations like confirming purchases and destructive actions (such as deletions), or notifying people about problems. The infrequency of alerts helps ensure that people take them seriously. Ensure that each alert offers critical information and useful choices. — Apple, Human Interface Guidelines, iOS, Views, Alerts.

Prefer nonintrusive status messages over alerts. Alerts disrupt the user experience. List error messages inline with content instead of displaying them in alerts. — Apple, Human Interface Guidelines, Architecture, Error Handling.

But if you download several apps from small developers right now, you will either not see any error messages at all, or you will see them in alerts.

The reason for this is that most designers don’t pay much attention to Apple’s current guidelines before starting product development. But they should.

And here’s why.

Imagine a UIAlertController that tells the user that the server connection is lost. It contains two buttons: “Try again” and “OK”.

While the alert is being displayed, the user cannot continue using the app until he closes the alert. It turns out that the app blocks the user’s actions and puts an ultimatum forcing you to select one of the alert buttons.

Almost all the designers assured me that in this situation, the user has only two options — as well as the number of buttons in the alert. I don’t agree with that.

He has at least one more button in front of his eyes — “Home”.

This is called a hidden choice.

When there is a connection problem, the user may decide that he will return later. He will simply close the app and forget about it for the next few hours or days.

As a result, we reduce the average session duration and lose income ourselves because of the alert. And this is not what we need.

Alternatives to UIAlertController

Apple recommends showing errors along with content. Let’s see how this looks in practice.

Let’s start with the most radical error — losing the Internet connection.

Often, the app has already downloaded some of the content before losing the connection. When the user finishes viewing this content, there is a chance that the Internet connection will be restored. In this case, he may not even know that the problem existed at all.

Why interrupt the user with an error message if it doesn’t bother him?

That’s right — there’s no need.

With errors when only part of the content is not loaded, everything is even easier. Don’t draw attention to them. It’s better to let the user try downloading them again if he needs to.

Another example is the account login screen. In my experience, this is the most frequent case where an error causes an inappropriate UIAlertController.

This is what an error might look like when user entered an incorrect username or password. Everything is clear without alerts.

To sum up: most often, unobtrusive display of the error “inside the content” will be a better solution than showing UIAlertController.

However, there are options when alerts will be the correct solution.

UIAlertController as a tool for attracting attention

Apple recommends using UIAlertController for destructive user actions.

Why? I think the reason is that the user must pay close attention to his action when deleting something. And here the interruption of the user experience is quite justified.

The app seems to stop the user and says: “Are you sure what you want to do?”

You can see this alert from Apple when you delete a contact in the Phone app or when you delete photos from the Photos app.

However, if deleting something is a normal and everyday action, then using UIAlertController is not necessary. A clear example is the Mail app on iOS.

Imagine if every time you delete an email, the app asks you if you are sure in your actions. That would be terrible! You might have given up the standard email client in favor of an alternative from the App Store.

In such cases, it is better to offer the option to cancel the deleting than to interrupt the user experience. This solution is also used in standard iOS apps like watches, notes, and reminders.

Show UIAlertController for destructive and irrevocable user actions only if deleting is not one of the daily tasks.

Conclusions and recommendations from other articles

I hope that I was able to draw attention to the problem or encouraged you to your own thoughts on this matter.

If you are involved in the application development that uses UIAlertController as the main way for displaying errors, you can implement analytics for interest that will show the ratio of choosing one of the options to closing the application.

I think you will be very surprised. You can share these statistics in the comments to the article.

I also recommend reading other articles about errors in mobile and web interfaces:

  1. https://developer.apple.com/design/human-interface-guidelines/carplay/architecture/error-handling/

Wish you great projects!

Tap the 👏 button if you found this article useful!

Any questions or Feedback? Connect via Apparat

Apparat

Guides and best practices based on experience in our mobile…