Ошибка – это не UIAlertController
Дизайнеры, с которыми я работаю, часто рассматривают сообщениях об ошибках в iOS как что-то очевидное. А если конкретно — как UIAlertController.
Предустановленные приложения от Apple задают такой тренд. И логично, что дизайнеры интерфейсов считают этот подход нативным и правильным.
В то же время, многие разработчики под iOS в России и СНГ самостоятельно приходят к отказу от UIAlertController, чем вызывают у меня искреннее уважение и восторг.
В этой статье я расскажу о том, к чему приводит неуместное использование UIAlertController. Поделюсь мнением об альтернативных способах сообщать пользователю об ошибках и о том, когда UIAlertController действительно необходим.
Эта статья для «опытных пользователей». Поэтому я не рассказываю о том, что такое пользовательский опыт и его прерывание, как сказывается средняя продолжительность сессии на доходах приложения и почему важно свести движения пальцем пользователя к минимуму.
Оглавление:
- Прерывание пользовательского опыта и скрытый выбор.
- Альтернативы UIAlertController.
- UIAlertController как инструмент привлечения внимания.
- Заключение и рекомендации других статей.
В Apple Human Interface Guidelines есть пара занимательных строк:
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.
Минимизируйте алерты. Алерты прерывают пользовательский опыт и должны использоваться только при важных ситуациях, таких как подтверждения покупок и деструктивных действиях (например, при удалении), или оповещать людей о проблемах. Редкость алертов помогает людям относиться к ним серьезно. Убедитесь, что каждый алерт содержит важную информацию и полезные варианты выбора. — 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.
Предпочтите ненавязчивые сообщения алертам. Алерты прерывают пользовательский опыт. Показывайте сообщения о ошибках вместе с контентом, вместо их отображения в алертах. — Apple, Human Interface Guidelines, Architecutre, Error Handling.
Но если вы прямо сейчас скачаете несколько приложений от небольших разработчиков, то либо вовсе не увидите сообщений об ошибках, либо увидите их в алертах.
Причина в том, что большинство дизайнеров невнимательно знакомятся с актуальными гайдлайнами от Apple перед началом разработки продуктов. А зря.
И вот почему.
Представим UIAlertController, который сообщает пользователю о том, что соединение с сервером потеряно. Он содержит две кнопки: «Попробовать еще раз» и «ОК».
Во время показа алерта пользователь не может пользоваться приложением дальше, пока не закроет алерт. Получается, что приложение блокирует действия пользователя и ставит ультиматум вынуждающий выбрать одну из кнопок алерта.
Почти все дизайнеры уверяли меня в том, что в такой ситуации у пользователя всего два выхода — как и количество кнопок в алерте. Я с этим не согласен.
У него перед глазами есть минимум еще одна кнопка — «Home».
Это и называется скрытым выбором.
В момент проблемы с соединением пользователь может решить, что вернется позже. Он просто закроет приложение и забудет о нём на ближайшие часы или дни.
В результате, с помощью алерта, мы сами снижаем среднюю продолжительность сессии и теряем доход. А это совсем не то, что нам нужно.
Альтернативы UIAlertController
Apple рекомендует показывать ошибки вместе с контентом. Посмотрим, как это выглядит на практике.
Начнем с наиболее радикальной ошибки — отсутствие соединения с интернетом.
Зачастую приложение уже успело загрузить часть контента перед потерей соединения. Когда пользователь закончит просматривать этот контент, есть вероятность, что соединение с интернетом восстановится. В таком случае он может и не догадаться о том, что проблема вообще существовала.
Зачем прерывать пользователя сообщением о ошибке, если она ему не мешает?
Правильно — незачем.
С ошибками, когда не загружена только часть контента, все еще проще. Не привлекайте к ним внимание. Лучше дайте пользователю попробовать загрузить их еще раз, если ему это необходимо.
Ещё один пример — экран входа в учетную запись. По моему опыту, это наиболее частый случай, когда ошибка вызывает неуместный UIAlertController.
Так может выглядеть ошибка, когда пользователь неверно ввел логин или пароль. Всё понятно и без алертов.
Резюмируем: чаще всего ненавязчивое отображение ошибки «внутри контента» будет лучшим решением, чем показ UIAlertController.
Однако существуют варианты, при которых алерты окажутся правильным решением.
UIAlertController как инструмент привлечения внимания
Apple рекомендует использовать UIAlertController при деструктивных действиях пользователя.
Почему? Думаю причина в том, что при удалении чего-либо пользователь обязан обратить пристальное внимание на своё действие. И здесь прерывание пользовательского опыта вполне оправдано.
Приложение как бы останавливает пользователя и говорит: «Ты уверен в том, что хочешь сделать?».
Такой алерт от Apple можно увидеть при удалении контакта в приложении «Телефон» или при удалении фотографий из приложения «Фото».
Однако, если удалять что-либо — это обычное и повседневное действие, то использование UIAlertController не обязательно. Яркий пример — приложение «Почта» на iOS.
Представьте, если бы при удалении каждого письма приложение спрашивало о том, уверены ли вы в своих действиях. Это было бы ужасно! Возможно, вы бы отказались от стандартного почтового клиента в пользу альтернативы из App Store.
В таких случаях лучше предлагать возможность отменить удаление, чем прерывать пользовательский опыт. Этим решением в стандартных приложениях на iOS также пользуются часы, заметки и напоминания.
Показывайте UIAlertController при деструктивных и безвозвратных действиях пользователя только в случае, если удаление не является одной из повседневных задач.
Заключение и рекомендации других статей
Надеюсь, что смог привлечь внимание к проблеме или подтолкнул вас к собственным размышлениям на этот счёт.
Если вы участвуете в разработке приложения, которое использует UIAlertController как основной способ демонстрации ошибок — можете для интереса внедрить аналитику, которая покажет соотношение выбора одного из вариантов действий к закрытию приложения.
Думаю, вы сильно удивитесь. Можете поделиться этой статистикой в комментариях к статье.
Также я рекомендую почитать другие статьи об ошибках в мобильных и веб-интерфейсах:
- https://developer.apple.com/design/human-interface-guidelines/carplay/architecture/error-handling/
- https://developer.apple.com/design/human-interface-guidelines/ios/views/alerts/
- https://medium.com/s/user-friendly/the-art-of-the-error-message-9f878d0bff80
- https://uxplanet.org/how-to-write-good-error-messages-858e4551cd4
- https://www.kaylaheffernan.com/blog/2014/12/9/error-messages
- https://medium.com/@thomasfuchs/how-to-write-an-error-message-883718173322
Желаю вам прекрасных проектов!
Есть вопросы или комментарии? Буду рад пообщаться!
