Клиент должен открыть ссылку и сразу оформить заказ. Сотрудник должен провести осмотр там, где пропадает связь. Менеджеру нужно сравнивать документы на большом экране. Все три задачи можно назвать «приложением», но требования к ним разные. В Гуси-Лебеди мы предлагаем выбирать формат по работе пользователя: где он находится, что делает и какой результат должен получить.
Веб-приложение открывается в браузере, мобильное приложение устанавливается на устройство. Веб стоит рассматривать для доступа по ссылке и работы на разных экранах. Мобильный вариант стоит проверять, когда важны конкретные возможности телефона и работа на ходу. Ни установка, ни браузер сами по себе не гарантируют скорость, автономность или рост продаж. Ниже разберём, как выбрать без этих обещаний.
Веб-приложение, мобильная версия сайта и PWA: в чём разница
Веб-приложение позволяет выполнять действия в браузере: вести заказы, редактировать документы, работать с личным кабинетом. Мобильная версия сайта описывает удобство страниц на небольшом экране. Это разные признаки: адаптивный каталог может включать корзину и кабинет, то есть функции веб-приложения. Один только узкий макет не превращает страницу в установленную программу.
В этой статье под мобильным приложением понимаем устанавливаемый клиент для смартфона. Его можно разрабатывать под отдельную платформу или с использованием общих инструментов для нескольких платформ. В любом случае нужно проверить работу на выбранных операционных системах и устройствах. Общий код не отменяет такую проверку.
PWA, или прогрессивное веб-приложение, использует веб-технологии, но может предлагать возможности установленного приложения. Это не отдельная мобильная операционная система и не синоним одностраничного сайта.
| Формат | Как начать работу | Что проверять |
|---|---|---|
| Веб-приложение | Открыть адрес в браузере | Удобство на нужных экранах, вход и сохранение действий |
| Установленное мобильное приложение | Установить и открыть клиент | Доступность установки для аудитории и поддержка её устройств |
| PWA | Открыть веб-адрес; при поддержке можно установить | Условия установки, автономные функции и ограничения браузера |
По документации MDN об установке PWA, поддерживающий браузер может предложить установку, после которой появляется значок и возможен отдельный запуск. Но установка и работа без сети являются разными задачами: наличие значка ещё не означает, что данные доступны офлайн.
Для первого контакта путь по ссылке позволяет обойти шаг установки. Для постоянной работы полезно сравнить оба пути на реальном сценарии. Например, открыть последний заказ, изменить адрес и получить подтверждение. Замерьте сам путь, а не только время появления первого экрана.
Камера, уведомления и работа без интернета: проверяем конкретную задачу
Требование «нужна камера» слишком расплывчато. Сфотографировать повреждение, считать код и вести запись в фоне представляют разные задачи. Веб тоже может получать видео с камеры: getUserMedia требует разрешения пользователя и защищённого контекста. Если разрешение не получено или устройство недоступно, интерфейс должен объяснить, как продолжить.
С геолокацией похожая ситуация: браузер может запросить местоположение с согласия пользователя. Поэтому фраза «нужна точка на карте, значит нужен только мобильный клиент» не является достаточным обоснованием. Для фонового отслеживания, подключаемого оборудования и других специфических функций попросите разработчика проверить именно ваш способ работы на целевых устройствах.
Уведомления тоже нужно описывать через событие: заказ готов, изменился маршрут, пришёл документ. Согласуйте получение разрешения, переход к нужному экрану и запасной способ увидеть событие внутри продукта. Уведомление не стоит делать единственным местом, где хранится важная информация.
«Работает без интернета» должно означать перечень доступных операций. Веб-приложение может показывать подготовленные локальные данные: MDN объясняет автономную работу через service worker и кэш. Свежие сведения с сервера без соединения не появятся. Установленному клиенту тоже требуется отдельно продумать сохранение и обмен данными.
Представим выездной осмотр оборудования. Сотрудник заранее загрузил задания, на объекте внёс замечания и прикрепил фотографии. На экране должно быть понятно: «Сохранено на устройстве, ещё не отправлено». После восстановления сети сервер принимает отчёт и подтверждает получение. Если за это время другой сотрудник изменил задание, продукту нужны правила разрешения конфликта. Это пример требований, а не описание уже выполненного нами проекта.
Такой сценарий полезно проверить небольшим техническим прототипом: отключить сеть, закрыть приложение, открыть снова и восстановить связь. Если потерялась фотография или отчёт отправился дважды, спор о названии технологии не решает проблему. Внешний вид и поведение экранов связаны с задачами фронтенда веб-продукта, но приёмка должна включать весь путь до подтверждения сервера.
Из чего складываются стоимость, обновления и сопровождение
Сравнивать смету большого кабинета с простым мобильным экраном бессмысленно. Сначала выровняйте состав продукта: одинаковые роли, действия, интеграции, требования к данным и поддержке. Затем сравните, какие работы добавляет каждый способ доставки пользователю.
Для веба нужны проверка согласованных браузеров, адаптивные экраны, размещение и управляемый выпуск. Изменения публикуют на стороне сервиса, но открытые вкладки и сохранённые ресурсы могут продолжать использовать старую версию. Команде нужно решить, когда предлагать обновление и как сохранить незавершённую работу.
Для мобильного клиента добавляются сборки под выбранные платформы, правила распространения и поддержка установленных версий. Например, Apple описывает отправку версий на App Review. Этот этап нужно учитывать в плане релиза. Указанная документация не даёт оснований обещать универсальный срок проверки или распространять порядок Apple на все магазины.
Если есть и веб, и мобильный клиент, общие аккаунты и заказы должны оставаться согласованными. Предположим, менеджер поменял статус заказа в кабинете, а покупатель открыл старую мобильную версию. Серверу нужно корректно ответить обоим клиентам. При разработке backend для нескольких интерфейсов такие правила стоит включить в требования до запуска.
- Старт: проектирование сценариев, интерфейсы, серверная логика и интеграции.
- Проверка: устройства и браузеры аудитории, права доступа, слабая связь, ошибки и восстановление действий.
- Выпуск: размещение, сборки, публикация, наблюдение после изменений и возможность исправить неудачный релиз.
- Эксплуатация: поддержка версий, обновления зависимостей, обработка обращений и развитие функций.
Так получается сравнение объёма работ вместо обещания «веб всегда дешевле». Частота использования помогает оценить необходимость мобильного канала, но сама по себе не доказывает, что он окупится. Для этого нужны данные вашего продукта и стоимость его сопровождения.
Как выбрать формат: три сценария и результат, который нужен до разработки
Кабинет поставщика. Представим сотрудников, которые сравнивают прайсы, загружают документы и согласуют заказы за компьютером. Начать проверку разумно с веб-интерфейса для большого экрана. Мобильный доступ может понадобиться для просмотра статуса, но перенос сложной таблицы в маленький экран не должен становиться обязательным условием всей работы.
Инструмент выездного сотрудника. Человек работает со смартфона, связь прерывается, нужны фотографии и сохранение отчёта. Здесь сначала проверяем автономный сценарий и возможности устройства. Если веб-прототип выполняет требования на нужных телефонах, его можно рассматривать. Если необходимое поведение не достигается, сравниваем установленный клиент. Офлайн является аргументом для проверки, а не автоматическим ответом.
Повторные заказы покупателей. Новому человеку удобно открыть предложение по ссылке. Постоянному покупателю может быть полезен отдельный клиент с историей и быстрым повтором заказа. Но сначала посмотрите, где действительно возникает затруднение. Если люди уходят из-за неясной цены доставки, один значок приложения эту причину не устранит.
До выбора технологии мы советуем подготовить короткое описание продукта с одним главным сценарием и его исключениями. Кто выполняет действие, на каком устройстве, при какой связи? Какие данные можно хранить локально? Что пользователь видит при отказе в разрешении, ошибке и успешном завершении? Какие устройства команда обязуется поддерживать?
Результатом обсуждения должны стать проверяемые требования, прототип рискованных функций и сопоставимые оценки вариантов. Для создания веб-сервиса под бизнес-процессы это помогает отделить обязательную работу от возможного расширения. Если нужны оба канала, зафиксируйте общие данные и правила между ними, а последовательность запуска выбирайте по основной задаче аудитории.
В Гуси-Лебеди мы предлагаем возвращаться к простому критерию: сможет ли человек закончить свою работу в тех условиях, ради которых продукт создаётся? Когда ответ проверен на сценарии, выбор между вебом, PWA и мобильным приложением становится предметным.