Scott
Если сеанс заканчивается посреди заполнения формы, главное сообщение — не «Вы вышли из системы». Человеку нужно понять, сохранилась ли работа, как снова получить доступ и куда он вернётся. Хороший сценарий восстановления отвечает на эти вопросы и не создаёт впечатления, что повторный вход отправит незавершённую форму.
Состояния входа и способы восстановления доступа по-прежнему важны, но здесь прерывается уже начатая работа. Проектируйте путь возвращения так же внимательно, как экран авторизации.
Проведите одну незавершённую заявку через прерывание
Представим приложение для заявок поставщикам. Сотрудник редактирует заявку SR-208: ввёл название организации, добавил примечание к доставке и прикрепил документ. Заявка ещё не отправлена. В приложении действует согласованная политика сохранения черновиков, а для продолжения требуется вход в систему.
Пользователь отходит от компьютера во время проверки формы. К его возвращению сеанс завершается. Нужный результат — снова открыть SR-208, проверить сохранённый черновик и решить, отправлять ли его, а не оказаться на главной странице и восстанавливать заявку по памяти.
Различайте в тексте и визуальном оформлении три события: черновик сохранён, сеанс завершён, заявка отправлена. Они могут происходить в разное время. Сохранённый черновик не означает, что поставщик что-либо получил; успешный повторный вход не означает, что заявка завершена.
Выясните, какой срок показывает интерфейс
Уточните у ответственного за аутентификацию, что вызывает завершение сеанса. Ограничение по неактивности, максимальная продолжительность сеанса и истёкший срок проверочного запроса — разные условия. Продолжение ввода может влиять на одно из них и не влиять на другое. Не обещайте, что любая активность сохранит вход, если приложение работает иначе.
Рекомендации OWASP по управлению сеансами различают тайм-аут неактивности и абсолютный тайм-аут и относят контроль их соблюдения к серверу. Обратный отсчёт показывает состояние пользователю, но сам не определяет, действителен ли сеанс.
Это особенно важно при работе в нескольких вкладках. Пользователь может продлить сеанс в другой вкладке, а сервер — завершить его раньше из-за события безопасности. Определите, как текущая страница сверяет уведомление с реальным состоянием. Старый таймер не должен утверждать, что редактирование ещё разрешено, когда сервер уже отклонил сеанс.
Универсального времени ожидания для всех продуктов нет. Зафиксируйте политику, доступный способ продления и события, после которых нужен новый вход. Затем стройте уведомление вокруг реального действия, которое приложение может выполнить.
Решите, что разрешено сохранить, прежде чем обещать восстановление
Фраза «Ваша работа сохранена» слишком широка, если сохранены лишь некоторые поля. Для заявки поставщику нужно отдельно определить, какие данные хранятся, как долго, в чьей учётной записи и что после входа придётся ввести заново.
| Данные | Решение в этом примере | Что должен сообщить интерфейс |
|---|---|---|
| Название организации и примечание к доставке | Хранятся в сохранённом черновике пользователя с соответствующим доступом по политике приложения. | Указать SR-208 и время последнего подтверждённого сохранения черновика. |
| Вложение | Сохраняется, только если подтверждены загрузка файла и его привязка к черновику. | После возвращения показать подтверждённый файл и отдельно отметить тот, который ещё нужно загрузить. |
| Данные для аутентификации | Не сохраняются в составе черновика формы. | Предложить поддерживаемый шаг входа, не обещая восстановить ранее введённые данные аутентификации. |
| Последнее неподтверждённое изменение | Возможность восстановления зависит от фактического механизма сохранения. | Не называть изменение сохранённым только потому, что оно ещё видно в поле. |
Это правила данного упражнения, а не рекомендация сохранять каждое поле любого продукта. Сам черновик может содержать чувствительную информацию. Его хранение, доступность и срок действия требуют той же осторожности, что и исходная форма. Нельзя решать проблему восстановления, незаметно помещая секреты или закрытые сведения в незащищённое хранилище браузера.
Предупреждайте, пока пользователь ещё может действовать
Если продление поддерживается, объясните, что скоро произойдёт, и предложите понятное действие, например «Остаться в системе». Укажите, что будет, если не ответить на предупреждение. Для SR-208 правдивое сообщение может сказать, что сеанс скоро завершится, а подтверждённый черновик можно будет открыть после входа.
Используйте последний проверенный статус сохранения, а не обнадёживающую фразу, одинаковую во всех предупреждениях. Если последнее примечание к доставке ещё сохраняется, текст должен отражать эту неопределённость. Запрос на продление тоже может завершиться ошибкой; ожидание ответа нельзя показывать как успешное продление.
Критерий WCAG 2.2 2.2.1 «Настройка времени» относится к уровню A и описывает варианты управления временными ограничениями, а также исключения. Когда применяется вариант с продлением, у пользователя должно быть не менее 20 секунд для простого действия, а продлить время нужно позволить не менее десяти раз. Нельзя сводить критерий к универсальному правилу «показывайте обратный отсчёт на 20 секунд».
Сделайте действие доступным с клавиатуры, а сообщение — понятным без наблюдения за каждой секундой. Видимый таймер может помогать одним людям, но постоянное озвучивание отсчёта мешать другим читать предупреждение. Если используется диалог, определите, как в него попадает фокус, как человек выбирает действие и куда фокус возвращается после продления.
Возвращайте к узнаваемому черновику, а не к мнимому успеху
После завершения сеанса экран восстановления должен объяснять, что требуется вход. Показывать сведения о доступном для восстановления черновике можно лишь в пределах, разрешённых без аутентификации. Не оставляйте чувствительное содержимое формы видимым за наложенным окном: само окно не является контролем доступа.
Когда тот же пользователь успешно войдёт и его права будут проверены, откройте SR-208 на нужном шаге. Покажите статус «Черновик» и сохранённые значения. Если загрузка вложения не была подтверждена, отметьте именно этот пробел. Оставьте окончательное действие «Отправить заявку» для осознанного решения, не повторяя его автоматически.
Критерий 2.2.5 «Повторная аутентификация» рассматривает продолжение работы без потери введённых данных после повторного входа. Это критерий уровня AAA, а не требование AA. Его цель полезна для данного сценария, но механизмы хранения и проверки доступа всё равно должны определить продуктовая команда и разработчики.
Зафиксируйте адрес возвращения как часть доверенного процесса приложения. Разработчики должны проверять его, а не принимать произвольное внешнее перенаправление. Дизайнеру нужно указать нужную заявку, шаг и контекст, а не только нарисовать общую кнопку «Назад».
Разберите прерывание и возвращение в Pixso
Разместите в файле Pixso четыре фрейма для SR-208: редактирование с предупреждением, завершённый сеанс, возвращение после входа и восстановленный экран проверки черновика. Название организации и примечание к доставке должны совпадать в доступных пользователю состояниях до и после входа. Меняются доступ и статус задачи, а не длина формы ради удобства макета.
Свяжите нужные экраны для пошагового просмотра. Попросите коллегу продолжить работу с заявкой и объяснить, отправлена ли она. Если возвращение после входа выглядит как экран завершения, уберите текст об успехе и верните признаки черновика. Добавьте отдельную ветку для вложения, которое не успело загрузиться, чтобы основной сценарий не скрывал незавершённую работу.
Спроектировать возвращение к черновику в Pixso →
Успешный вход не всегда означает правильное восстановление
Если человек вошёл в другую учётную запись, не раскрывайте ему черновик прежнего пользователя. Объясните, что текущая учётная запись не может открыть запрошенный черновик, и предложите подходящий способ сменить аккаунт или безопасно вернуться. Не показывайте в этом объяснении закрытые названия организаций или вложений.
Даже та же учётная запись могла потерять права за время отсутствия. Аутентификация подтверждает личность предусмотренным способом, но не возвращает отозванную роль. Сценарий восстановления доступа разбирает эту отдельную границу. Не превращайте совет «Попробуйте войти ещё раз» в бесконечный круг для человека, у которого больше нет прав.
Также различайте окончание срока хранения черновика и завершение сеанса. Если SR-208 больше не хранится, сообщите об этом точно и предложите разрешённый следующий шаг. Не показывайте пустую форму с заголовком «Черновик восстановлен».
Проверяйте момент завершения сеанса, а не только готовые экраны
Сложные случаи возникают между состояниями: предупреждение появляется во время ввода, ответ на продление приходит с задержкой, файл ещё загружается или сеанс заканчивается сразу после нажатия «Отправить». В последнем случае приложение должно установить результат исходной операции, прежде чем предлагать повторную отправку. Одно сообщение «Вы вышли из системы» не доказывает, что заявка не отправлена.
Разберите эти переходы с разработчиками и специалистами по доступности. Проверьте, что сохраняется, что видно до входа, какая учётная запись может восстановить данные и когда именно выполняется окончательное действие. Красивый диалог об истечении времени полезен только тогда, когда путь возвращения выполняет эти обещания.
