Замена загруженного файла без потери замечаний: UX-сценарий

Замена файла после отправки — не то же самое, что повторная попытка загрузки. Исправленный документ может быть верным, но если вместе со старым файлом исчезнут замечание проверяющего и история согласования, проверку придётся начинать заново. Главный вопрос для интерфейса: что остаётся привязанным к заявке, когда её актуальный файл меняется?

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

Начните с уже принятой заявки, а не с пустого поля загрузки

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

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

До подтверждения покажите обе версии и последствия

Экран подтверждения должен отвечать на три вопроса: какой файл активен сейчас, какой станет активным после замены и что произойдёт с прежней версией и обсуждением? Разместите имена рядом, при необходимости добавьте размер и время загрузки. Сравнение этих сведений не означает, что система сравнила содержимое PDF. Если надёжного сравнения документов нет, интерфейс не должен создавать такое впечатление.

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

Не отрывайте комментарии от заявки

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

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

Определите поведение при одновременной проверке

Пока автор выбирает новый файл, проверяющий может читать старый. Нельзя без предупреждения подменять документ в уже открытом сеансе. Один возможный вариант — дать завершить проверку прежней версии и заметно сообщить о появлении новой. Другой — приостановить утверждение до окончания замены. Нужное правило зависит от того, идёт ли речь о неформальном отзыве, регулируемом согласовании или юридически значимой записи. Выберите его явно, иначе два человека будут по-разному понимать слово «текущий».

Допустим, проверяющий открыл старый PDF в 10:02, а автор завершил замену в 10:04. Комментарий к шестой странице должен остаться связанным с версией, которую проверяющий действительно видел. Если в 10:05 он нажмёт «Утвердить», интерфейс обязан объяснить, будет ли утверждена старая версия, новая после повторного просмотра или пока ни одна. Метка версии рядом с действием полезнее неопределённого зелёного значка. Проверьте этот сценарий в двух сеансах браузера до передачи макета в разработку.

Разведите ошибки, отмену и успешную замену

До передачи файла можно обнаружить неподдерживаемый формат, пустой файл или превышение лимита. Во время передачи индикатор показывает именно измеренный прогресс передачи; он ещё не доказывает, что сервер проверил документ и сделал его активным. После передачи серверная проверка может отклонить файл. Разделите эти этапы, чтобы пользователь не увидел «Готово», пока новая версия ещё не принята.

Если связь пропала на 78 %, скажите, что исходный файл по-прежнему активен, и предложите безопасный повтор. Если исправленный PDF отклонён после передачи, укажите конкретную причину и дайте выбрать другой, не теряя замечание. Отмена до подтверждения должна вернуть к неизменённой заявке. Руководство по интерфейсу загрузки файлов (на английском) рассматривает выбор, прогресс и ошибки передачи; дополнительная задача здесь — сохранить уже принятую запись и её проверку.

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

Сообщайте о статусе не только цветом

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

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

Проверьте путь решения в прототипе Pixso

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

Попросите проверяющего пройти по макету с настоящим по смыслу замечанием: «Где теперь мой прежний комментарий?» Спросите автора: «Если передача сорвётся, какой файл увидит проверяющий?» Если ответ приходится угадывать, уточните подписи состояний до работы над анимацией. Макет можно передавать в разработку, когда команда способна объяснить для каждого результата активный файл, сохранённый контекст проверки и способ восстановления.