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

Одна из главных технических претензий к прогрессивным веб-приложениям (PWA) — они не дают тот же UX, что и нативные мобильные. Наш опыт показывает, что это вполне устранимо. Рассказываем, как этого добиться и от каких привычных взглядов на проектирование будет полезно избавиться.
Прогрессивные веб-приложения сейчас снова привлекают к себе внимание по целому ряду причин: они легкие, просто устанавливаются, хорошо работают оффлайн, а их обновление раскатывается по пользовательским устройствам моментально и не требует длительной процедуры подтверждения. Ну и главное для компаний, которых могут выгнать из магазинов приложений за аффилированность с подсанкционными компаниями и лицами, — с PWA они ни от кого не зависят.
Но у технологии в ее «ванильном» виде есть и недостатки. Обычно при сравнении PWA с нативными мобильными приложениями в ход идет аргумент про отсутствие у прогрессивных веб-приложений встроенной поддержки жестов.
Это совершенно справедливое замечание, если рассматривать PWA в его минималистичной реализации — обычный сайт плюс манифест на JSON. Но даже если жесты реализовать с нуля, они будут лишь малой частью того, что составляет UX на мобильных устройствах. Здесь есть более высокоуровневые моменты, без которых даже с жестами дело не заладится. Вот о них и поговорим.
Мы в RooX делаем сложные веб-проекты (интернет-банки, личные кабинеты, порталы поставщиков и т.д.) и предлагаем переход на PWA, как страховку от удаления мобильных приложений из сторов.
Это, пожалуй, самое важное. Если задача сайта — информировать и продавать, то бизнесовое мобильное приложение — в первую очередь транзакционное. Попытка утоптать в PWA блог со сторителлингом и развестистые продуктовые лендинги в принципе обречена на провал. Исходите из того, что на экране всегда должны быть доступны понятные целевые действия. Все прочее можно без зазрения совести предать анафеме.
Главное следствие из предыдущего пункта — не надо пытаться проектировать PWA по старинке как в вебе — страницами. Все нужное пользователю всегда должно быть на экране. Даже если вы выводите пользователю, допустим, список действий с банковским счетом за текущий месяц и просто вынуждены сделать скролл, у вашего приложения всегда должны быть видны на экране самые важные транзакционные и навигационные элементы. В примере выше это скорее всего будет виджет перехода на другой месяц и переход на соседние экраны (список счетов, платежи с выбранного счета и т.п.).
В вебе для аутентификации как правило применяется пара логин/пароль.
Для мобильных устройств любая минимизация ввода с виртуальной клавиатуры — благо. Можно использовать автоматический разбор входящих SMS-сообщений на предмет одноразовых кодов, но само применение сервисных SMS ляжет грузом на ваш бюджет. Подумайте о биометрии и Apple Passkey.
На сайте движение пользователя линейно и двумерно: он может кликать по ссылкам и кнопкам для перехода дальше, либо уходить назад, нажимая кнопку возврата. Этим навигация в вебе, в принципе, исчерпывается.
В мобильном приложении пользователь серфит многомерно — свайпы на все четыре стороны, лонгтапы, шторки и прочее. К проектированию PWA нужно подходить с пониманием этой многомерности.
Мало спроектировать их с расчетом на свайпы, хорошо бы их запрограммировать. Вспомним скриншот в начале статьи — родных жестов и правда нет. Придется изобрести свои.
- Кое-что переопределить. Например, вместо стандартных браузерных переходов вперед/назад нужно определить свои переходы между экранами. В противном случае может поломаться навигация. Например, при попытке вернуться на предыдущую страницу пользователя может выкинуть на страницу входа в приложение.
- Много чего дописать: лонгтэпы, свайпы вверх и вниз и многие другие.
Из-за тактильного взаимодействия пользователи ждут от мобильного приложения мгновенной реакции на жесты. Поэтому после того, как распознавание касаний готово, важно оптимизировать код в PWA. Чтобы свайп был свайп, а не сваааааайп или свайп-п-п-п-п, чтобы не было мерцания при переходах (болезнь iOS) и так далее.
Подвешивание загрузки страницы на сайте обычно сопровождается специальным довольно однообразным курсором. Показывать его мобильному пользователю — рисковать потерей внимания. Чтобы продолжать его удерживать, пока данные подгружаются при переходе между страницами, лучше рисовать скелетоны.
Прохождение длинных сценариев с заполнением формы подбешивает даже на десктопе, где есть большая физическая клавиатура. Особенно если пользователь где-то ошибся и теперь ему надо вернуться на несколько шагов назад и что-то исправить. На мобильных устройствах это совсем больно.
В PWA некоторые шаги в таких сценариях можно и нужно реализовать в виде всплывающих окон, шторок и т. д. Такой путь будет казаться пользователю короче.
В вебе даже сайты с адаптивной версией приспособлены только для мышки и клавиатуры. На маленьком экране взаимодействовать пальцами с полями и экранами неудобно. При выборе элемента раскрывающегося списка очень легко ткнуть не туда. Поэтому выпадающие списки лучше делать на отдельном экране: при тэпе в поле на форме выполняется анимация, поле уезжает наверх, а все другие поля скрываются. В этом случае нет перекрытия других полей, а высота списка и размер его элементов достаточно большие для выбора пальцем.
Если нет автоматического перехода при заполнении полей, в вебе предполагается, что пользователь должен ткнуть мышкой в следующее поле или нажать Tab. В приложении тоже желательно делать автопереход там, где это возможно, а где нет — сделать переход по тэпу.
В жизни возникает миллион ситуаций, когда нужно посмотреть какую-то информацию, но мобильного интернета и WiFi нет:
- найти номер трекинга в разговоре с оператором службы доставки (третий день все никак не доедет к вам, в примеру, документ с апостилем);
- выбрать удобное отделение или банкомат и построить до него маршрут (построить в зоне отельного WiFi, а идти уже без него);
- посмотреть свой страховой полис при аварии, травме или болезни (тьфу-тьфу-тьфу);
- изучить предложения оператора мобильной связи, прилетев в зону действия роуминга (кто ни разу не забывал разобраться с роумингом до поездки, киньте в нас камень в коментах).
Во всех этих случаях нужна возможность получить информацию в личном кабинете оффлайн. Технология работы с кешем в PWA это позволяет.
Необходимость поработать офлайн появляется у людей намного чаще, чем это может казаться. И, как показывают примеры выше, отсутствие связи может быть довольно болезненно для пользователя.
В RooX PWA логин офлайн возможен за счет поддержки входа по биометрии.
- Главное — транзакции
- Экраны, а не страницы
- Аутентификация без клавиатуры
- Многомерная навигация
- Обработчик жестов: спроектировать, запрограммировать, оптимизировать
- Скелетоны при загрузке
- Формы: сделать субъективно короче, выпадающие списки на отдельные экраны, автопереходы между полями
- Офлайн: вход и работа
Подписывайтесь на блог RooX. Мы специализируемся на цифровых каналах взаимодействия с пользователями (порталы, личные кабинеты, приложения, в том числе, в виде PWA) и управлении доступом к ним (RooX UIDM).
И еще мы несколько дней назад завели русскоязычное сообщество в ТГ по вопросам аутентификации и авторизации. Пока там тихо, но мы всех приглашаем присоединиться и задавать вопросы.
Источник: VC.ru
iTrend начал работу с одним из лидеров российского рынка разработки решений на базе нейросетей — компанией «Наносемантика»
20 сентября 2023«Наносемантика» входит в ТОП-10 российских компаний, занимающихся нейросетями, по версии CNews.
Стоп-фразы, или Что никогда нельзя писать в текстах - разбираем на VC
20 сентября 2023Вот лишь поверхностным взглядом слова и фразы-мусор, которые мы стараемся не допускать в текстах.
Маркировка рекламы создаст новую профессию? Комментируем тему для Ъ
13 сентября 2023Рекламщикам понадобились маркировщики: новые правила создали новую специальность
Как мемы и юмор помогают бизнесу. Комментируем для "Делового Петербурга"
29 августа 2023Digital–директор iTrend Ася Шабалина поделилась своим мнением об использовании мемов и юмора в маркетинге.
Открыта вакансия "PR-менеджер в iTrend"
23 августа 2023Мы в поисках любопытного, активного и общительного PR-менеджера для работы с ИТ-проектами.