PWA как нативное приложение — что это такое и как его спроектировать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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