PWA as a native application - what is it and how to design it

Одна из главных технических претензий к прогрессивным веб-приложениям (PWA) — они не дают тот же UX, что и нативные мобильные. Наш опыт показывает, что это вполне устранимо. Рассказываем, как этого добиться и от каких привычных взглядов на проектирование будет полезно избавиться.

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

Но у технологии в ее «ванильном» виде есть и недостатки. Обычно при сравнении PWA с нативными мобильными приложениями в ход идет аргумент про отсутствие у прогрессивных веб-приложений встроенной поддержки жестов.


Это совершенно справедливое замечание, если рассматривать PWA в его минималистичной реализации — обычный сайт плюс манифест на JSON. Но даже если жесты реализовать с нуля, они будут лишь малой частью того, что составляет UX на мобильных устройствах. Здесь есть более высокоуровневые моменты, без которых даже с жестами дело не заладится. Вот о них и поговорим.



Мы в RooX делаем сложные веб-проекты (интернет-банки, личные кабинеты, порталы поставщиков и т.д.) и предлагаем переход на PWA, как страховку от удаления мобильных приложений из сторов.



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

Страницы vs. экраны
Главное следствие из предыдущего пункта — не надо пытаться проектировать PWA по старинке как в вебе — страницами. Все нужное пользователю всегда должно быть на экране. Даже если вы выводите пользователю, допустим, список действий с банковским счетом за текущий месяц и просто вынуждены сделать скролл, у вашего приложения всегда должны быть видны на экране самые важные транзакционные и навигационные элементы. В примере выше это скорее всего будет виджет перехода на другой месяц и переход на соседние экраны (список счетов, платежи с выбранного счета и т.п.).

Аутентификация
В вебе для аутентификации как правило применяется пара логин/пароль.

Для мобильных устройств любая минимизация ввода с виртуальной клавиатуры — благо. Можно использовать автоматический разбор входящих SMS-сообщений на предмет одноразовых кодов, но само применение сервисных SMS ляжет грузом на ваш бюджет. Подумайте о биометрии и Apple Passkey.

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


В мобильном приложении пользователь серфит многомерно — свайпы на все четыре стороны, лонгтапы, шторки и прочее. К проектированию PWA нужно подходить с пониманием этой многомерности.

Жесты
Мало спроектировать их с расчетом на свайпы, хорошо бы их запрограммировать. Вспомним скриншот в начале статьи — родных жестов и правда нет. Придется изобрести свои.

• Кое-что переопределить. Например, вместо стандартных браузерных переходов вперед/назад нужно определить свои переходы между экранами. В противном случае может поломаться навигация. Например, при попытке вернуться на предыдущую страницу пользователя может выкинуть на страницу входа в приложение.
• Много чего дописать: лонгтэпы, свайпы вверх и вниз и многие другие.

Отзывчивость приложения на жесты
Из-за тактильного взаимодействия пользователи ждут от мобильного приложения мгновенной реакции на жесты. Поэтому после того, как распознавание касаний готово, важно оптимизировать код в PWA. Чтобы свайп был свайп, а не сваааааайп или свайп-п-п-п-п, чтобы не было мерцания при переходах (болезнь iOS) и так далее.

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

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

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

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

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

Работа оффлайн
В жизни возникает миллион ситуаций, когда нужно посмотреть какую-то информацию, но мобильного интернета и WiFi нет:

• найти номер трекинга в разговоре с оператором службы доставки (третий день все никак не доедет к вам, в примеру, документ с апостилем);
• выбрать удобное отделение или банкомат и построить до него маршрут (построить в зоне отельного WiFi, а идти уже без него);
• посмотреть свой страховой полис при аварии, травме или болезни (тьфу-тьфу-тьфу);
• изучить предложения оператора мобильной связи, прилетев в зону действия роуминга (кто ни разу не забывал разобраться с роумингом до поездки, киньте в нас камень в коментах).

Во всех этих случаях нужна возможность получить информацию в личном кабинете оффлайн. Технология работы с кешем в PWA это позволяет.

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

В RooX PWA логин офлайн возможен за счет поддержки входа по биометрии.


Чек-лист

• Главное — транзакции
• Экраны, а не страницы
• Аутентификация без клавиатуры
• Многомерная навигация
• Обработчик жестов: спроектировать, запрограммировать, оптимизировать
• Скелетоны при загрузке
• Формы: сделать субъективно короче, выпадающие списки на отдельные экраны, автопереходы между полями
• Офлайн: вход и работа

Подписывайтесь на блог RooX. Мы специализируемся на цифровых каналах взаимодействия с пользователями (порталы, личные кабинеты, приложения, в том числе, в виде PWA) и управлении доступом к ним (RooX UIDM).

И еще мы несколько дней назад завели русскоязычное сообщество в ТГ по вопросам аутентификации и авторизации. Пока там тихо, но мы всех приглашаем присоединиться и задавать вопросы.