Веб-приложение: чем оно отличается от сайта и когда нужно бизнесу

Красивого интерфейса для приложения мало

Анимация и кнопки ещё не объясняют, зачем компании веб-приложение. Так называют программу, с которой пользователь работает через браузер: создаёт заявки, рассчитывает параметры, меняет данные или получает документы. Бизнесу нужно выбирать её по повторяющейся операции, которую клиент сможет завершить без переписки с менеджером.

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

Граница между сайтом и приложением не установлена количеством страниц или модным названием технологии. В объяснении MDN о PWA показано, как веб-технологии дают поведение, похожее на отдельную программу. Для заказчика полезнее другой вопрос: какое состояние работы сохраняется после закрытия окна и кто отвечает за него на стороне компании, когда клиент открывает кабинет снова и ожидает продолжить заявку с прежнего места.

Что меняется по сравнению с обычным сайтом

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

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

Браузер, сервер и учётная система

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

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

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

Когда нужен ярлык на телефоне

Установку на главный экран часто принимают за главный признак приложения. Для постоянного клиента ярлык действительно сокращает путь к кабинету. Однако пользоваться веб-приложением можно и по ссылке. Установку оценивают отдельно от основной операции.

В руководстве MDN по установке PWA описан манифест в формате JSON. Он передаёт браузеру сведения о названии и значке приложения. Для продвижения установки в Chromium документация указывает значки размером 192 и 512 пикселей. Это задача исполнителю по подготовке приложения, а заказчик принимает узнаваемый значок и правильный вход в кабинет на целевых устройствах.

За способ открытия отвечает параметр display. Значение standalone позволяет открывать приложение без привычной рамки браузера. Адрес запуска задаётся через start_url. Названия нужны в задании только для разговора об ожидаемом поведении: клиент нажимает значок и попадает к нужному действию, а не на случайную публичную страницу, после которой снова ищет вход. Для установки через описанный в документации путь также требуется HTTPS.

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

Что получится сделать без интернета

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

MDN объясняет сохранение ресурсов PWA через локальный кэш — копии данных на устройстве. За получение сохранённого содержимого может отвечать Service Worker, отдельный сценарий браузера. Для владельца кабинета это повод разделить данные по сроку актуальности: инструкция может открываться из сохранённой копии, а статус заявки требует обращения к серверу, потому что сотрудник мог изменить его после последнего визита клиента.

Работу без связи лучше ограничить черновиком, если отправленная заявка связана с ценой, доступностью или занятостью сотрудника. Человек видит, что подготовил сведения, и отдельно получает подтверждение передачи после восстановления интернета. Такой порядок проще объяснить, чем незаметную очередь отправок с неопределённым временем исполнения. В приёмке пригодится обычное отключение сети на телефоне. Заказчик смотрит, сохраняется ли заполненное, какой текст видит пользователь и не возникает ли повторной заявки после возвращения связи. Это проверка обещания интерфейса, а не экзамен по устройству браузера.

Права доступа определяют доверие к кабинету

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

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

Для первого выпуска разумнее ограничить набор ролей реальными обязанностями. Сложная матрица доступа пригодится только тогда, когда руководитель способен объяснить различие прав на конкретной операции и назвать того, кто поддерживает список пользователей. Восстановление входа тоже входит в разработку веб-приложений. Клиенту нужен понятный способ вернуть доступ, сотруднику поддержки — процедура помощи без раскрытия чужих данных. Продуманный кабинет остаётся удобным и тогда, когда человек забыл пароль или сменил рабочий адрес.

Как выглядит задание на первую версию

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

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

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

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

Соседние задачи лучше вынести из первой версии, если они не нужны для завершения повторной заявки.

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

Цена ошибки растёт вместе с доверием пользователей

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

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

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