Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

UI/UX для iOS-разработчика: неочевидные способы улучшить свои hard skills. Часть 2

Усі статті, обговорення, новини про Mobile — в одному місці. Підписуйтеся на телеграм-канал!

Всем привет! Я — Евгения Бондарь, iOS Department TechLead в NIX.

В IT-сфере я уже 8 лет. Начинала с iOS-разработки, но последние пару лет разрабатываю все реже, больше занята супервайзингом людей в нашей команде, оценкой проектов, консультациями.

Я решила порассуждать о том, почему разработчику важно разбираться в азах дизайнерского ремесла. Если вы пропустили первую часть, то по ссылке можете ознакомиться со статьей и узнать о базовых принципах и подходах, на которых строится дизайн приложений.

На этот раз я опишу важные концепты, которые больше связаны с UX. Разберем их на примере приложений от Apple и других разработчиков. Материал будет полезен iOS-девелоперам уровня Junior и Middle.

Модальность

Нередко дизайны попадают к разработчикам в виде набора картинок. И даже если есть некий набор функциональных требований к дизайну, то они далеко не всегда говорят, как эти скрины должны быть презентованы или запущены. Мне иногда попадаются приложения, где вроде и видно работу дизайнера, но сразу понятно: разработчик не задавался вопросом «To push or not to push». Соответственно, он не потрудился понять, когда пушить, а когда презентить экраны. Такой недочет бросается в глаза и добавляет ложку дегтя в бочку меда User Experience. И хоть это не драматично, но все-таки имеет определенное значение.

Использование модальной презентации оправдано во многих случаях. Например, у пользователя есть обособленный таск или набор небольших задач, но надо вырвать его из текущего контекста и внедрить в новый. Или, допустим, произошел форс-мажор, о котором нужно сообщить юзеру. На иллюстрации ниже я привела несколько примеров модальных окон из Snapchat.

Для презентации контента, начиная с iOS 13, существует два нативных способа. Первый — в виде карточек. У такой презентации есть несколько интересных особенностей. Она дисмиссится по свайпу вниз, что очень удобно и, казалось бы, позволяет упростить дизайн. При этом на экране все равно должна быть кнопка для закрытия карточки, ведь свайп не самое очевидное действие. Пусть это уже фишка ОС и это решение имплементят практически все, но многим пользователям все-таки неудобно им пользоваться. Поэтому нужна комбинация — и кнопка, и свайп.

Такой тип презентации отлично подходит для экрана с важным, но не очень сложным действием, необходимым от пользователя. Под появляющейся карточкой видно часть контекста, из которого вырвали пользователя. Это дает ему возможность понять, что новый таск недолговременный и он не потребует большого внимания. А потому пользователь может быстро свайпнуть вниз и уйти с этого экрана.

Второй тип презентации, который был все время до появления карточки — Full Screen презентация. Здесь нет возможности дисмиссить ее по свайпу, для этого предусмотрена только кнопка. Это подходит для сложных тасков, которые требуют максимальной вовлеченности пользователя или займут много времени (например, чтение книги, редактирование фото и т. д.).

Модальность нужно использовать только тогда, когда это действительно имеет смысл и об этом прямо говорят гайдлайны. Конечно, это размытая рекомендация, и интерпретировать ее можно по-разному. Например, сообщения об отсутствии соединения в приложениях Apple показываются как Alert. Но меня как юзера это решение смущает. Мало того, что я не могу ничего загрузить, так еще нужно нажать на кнопку «Да, я поняла, что интернета нет». Как мне кажется, так стоит делать, если речь идет о каком-то важном таске и надо привлечь внимание пользователя, мол что-то пошло не так. Мне кажется более логичным подход, отчасти заимствованный из Android и напоминающий снэкбары. Это всплывающие окна, которые не требуют манипуляции от пользователя для скрытия такого модального вью. На картинке я привела подобный пример из Instagram, где всплывающее вверху сообщение говорит нам, что интернета нет:

Loading

Следующий важный в UX момент — все, что связано с нетворкингом или любой другой подгрузкой данных. Мы часто сталкиваемся с разработкой клиент-серверных приложений, но процесс загрузки порой не отрисован в дизайне. Самое важное, что вам как разработчику надо знать в этом случае — пользователь всегда должен понимать, что происходит какой-то процесс. Поэтому ему нужно показать хотя бы базовый активити-индикатор. Примеров реализации такого элемента интерфейса очень много (несколько можете видеть ниже):

Однако если подгрузка может выполняться довольно долго, а у юзера нет возможности ничего сделать с приложением, то такого активити-индикатора будет недостаточно для хорошего UX.

Существует несколько подходов, которые помогут избавиться от блокирующих заглушек на весь экран и создать более дружелюбный по отношению к пользователю опыт.

Прежде всего, искомый контент нужно показывать как можно раньше. Если юзер нажал на кнопку для перехода на экран с подгружаемой информацией, не нужно ставить в этот момент блокирующий активити-индикатор и ждать загрузки. Надо сразу открывать требуемый экран — то есть давать пользователю то, что он хочет от приложения, и уже на этом экране отображать некую индикацию.

Например, это может быть активити-индикатор по центру экрана, как в Slack на иллюстрации ниже. Обратите внимание, что он не блокирует пользователю возможность покинуть экран:

Или же это может быть Skeleton View, как мы видим далее, с серыми прямоугольниками и кругами. Они имитируют layout контента, который появится после загрузки:

Такое решение добавляет предсказуемости. Пользователь понимает, что происходит загрузка данных. При этом мы показываем ему, как будет выглядеть контент после загрузки, что добавляет контекста. И не забывайте: если у вас предусмотрена возможность подгрузить контент заранее или есть кэшированный контент, то лучше показать юзеру хоть что-то из этого, чем не показывать ничего.

Рассмотрим еще один пример — приложение Apple Music. На первой картинке вы можете увидеть стандартный профиль:

Далее на картинке приведен пример, когда пользователь что-то меняет профиле — и после этого становится активной кнопка Done, подчеркивая возможность сохранения действий с вводом данных:

А на этой иллюстрации можно заметить, как после тапа по кнопке Done на ее месте появляется индикатор активности:

Это решает сразу несколько проблем. Такой активити-индикатор не занимает основную площадь экрана. Также пользователь не будет повторно нажимать на Done — ему уже понятно, что процесс сохранения стартовал. А еще обратите внимание: кнопка Cancel по-прежнему доступна. Благодаря этому юзер может отменить свое действие, если что-то пошло не так.

Не забудьте проработать empty state. Если пользователь пытался что-то загрузить и у него не получилось, недостаточно показать простой всплывающий элемент. В момент появления такого сообщения он мог отвлечься и не заметить, как сообщение показалось и пропало. И если юзер увидит просто белый экран, то не поймет, на какой стадии процесс. Это может быть воспринято как баг. Поэтому при любой ошибке в том же мобильном клиенте Slack проблема решается очень просто: в центре экрана располагается сообщение о том, что произошла ошибка, и предлагается повторить попытку еще раз:

Другая схожая ситуация — когда сеть доступна, сервер отвечает, но нет данных. В таком случае тоже стоит избегать пустого белого экрана. Пользователю нужна хотя бы минимальная информация: «Все ОК, все работает, но у тебя нет контента». Затем можно подсказать ему, что делать:

Такая последовательность поможет человеку сориентироваться в дальнейших действиях.

Создать анимации загрузки и проработать empty state в более симпатичном формате вам помогут следующие ресурсы:

Запрос разрешений

Еще один важный момент в теме мобильного дизайна. Это серая область, о которой дизайнеры часто даже не задумываются. Более того, иногда они могут в принципе не знать, что в iOS нужно запрашивать permission на локацию, отправку нотификаций и т.д. Разработчики же в таких случаях могут действовать в лоб: сказали запилить локацию — мы запросим доступ к ней при запуске приложения. Однако учтите: пользователи не хотят делиться с приложением, которое еще даже не видели, такими сенситивными данными, как, например, их месторасположение или информация о здоровье. Поэтому когда юзер скачивает приложение из App Store, а оно сразу на первом скрине просит поделиться такими данными, у пользователя в разы уменьшается мотивация давать положительный ответ на запрос.

Рассмотрим, что можно с этим сделать на примере приложения Nike Run Club. Оно просит разрешения у пользователя на отправку нотификаций, когда пользователь авторизовался, увидел домашнюю страничку, увидел бейдж на вкладке сообщений и перешел в нее. То есть человек наглядно видит, для чего ему давать этот доступ приложению, что он от этого получит.

Таким образом, ваши шансы на увеличение конверсии положительных ответов на запросы разрешений будут значительно выше, если вы с умом выберете момент, когда их показывать.

Больше информации по этим и другим темам ищите здесь:

Выводы

Цель этой и предыдущей статьи — вдохновить разработчиков почаще выходить за рамки своих прямых обязанностей. Так вы становитесь более ценным экспертом и полезным членом команды. Думайте в первую очередь о продукте, который разрабатываете, о своем пользователе и его удобстве. Только держа все это в фокусе, вы сможете вдохнуть жизнь во все идеи и визуал без потерь.

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Наче б то все знаєш, але зайвий раз повторити не завадить.

Порой лишний раз структурировать ранее изученное и, может, по-новому открыть его для себя, может быть очень кстати. Рада, что вам статья была полезна.

Этот материал полезен разве что разработчикам, не курящим маны ^^

Если полезен хотя бы паре человек, значит уже работа проделана не зря. Если у вас есть идеи тем, которые вам было бы интересно читать и изучать — поделитесь. Возможно следующая моя статья будет именно об этом.

Підписатись на коментарі