Массовое изменение статуса: выбор, просмотр и частичный результат

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

Разберите одну очередь и одно решение

Представим очередь проверки графических материалов. Сотрудник видит 47 записей по фильтру «Требуют действий», выбирает 12 на двух страницах и задаёт статус «Опубликовано». Десять записей можно изменить. Одну после выбора уже опубликовал коллега; вторая заблокирована за другим сотрудником. Интерфейс должен объяснить, относится ли действие к 12 конкретным записям или ко всем 47 результатам фильтра, остановят ли две неподходящие записи всю операцию и что считать успехом, если обновятся только десять.

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

Назовите область выбора прямо

Флажок в заголовке таблицы нередко выбирает только строки текущей страницы. Отдельная команда может расширить выбор до всех записей, подходящих под фильтр. Это разные наборы данных. Для явного выбора напишите «Выбрано 12 записей на двух страницах». Формулировка «Все 47 записей по фильтру „Требуют действий“» допустима только после отдельного решения пользователя расширить область. Переход между страницами не должен незаметно менять смысл кнопки «Опубликовать выбранные».

Показывайте количество и область действия в одной панели. При изменении фильтра либо сохраняйте точные идентификаторы выбранных записей и сообщайте об этом, либо снимайте выбор с объяснением. Значок «Выбрано 12» рядом с совершенно другим набором строк без пояснения вводит в заблуждение. Если выбор охватывает несколько страниц, дайте просмотреть его до необратимого действия. В руководстве IBM Carbon по таблицам массовые действия выделены в отдельный режим после выбора строк. Здесь важно определить, какие именно строки входят в этот режим.

Покажите изменение, а не повторите команду

Вопрос «Опубликовать 12 записей?» почти не помогает заметить ошибочный выбор. В предварительном просмотре укажите целевой статус и разделите записи по исходу. Для этого случая достаточно следующей структуры:

Пользователь должен увидеть неправильное целевое значение, лишнюю запись или причину исключения до подтверждения. Для нескольких обратимых правок хватит компактного итога. Для важного действия или большого набора стоит раскрыть строки и значения «до → после». Паттерн массового редактирования Basis Design System также предусматривает счётчик выбранного и предварительный просмотр сложных изменений.

Решите, что делать с неподходящими записями

Неопределённое поведение сервера нельзя исправить удачной микрокопией. Команде продукта и разработки сначала нужно согласовать один из вариантов:

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

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

Честно покажите выполнение и частичный успех

После подтверждения зафиксируйте выбранный набор и не допускайте повторной отправки, пока исход первого запроса неясен. Для короткой операции достаточно состояния выполнения и недоступной кнопки. Для долгой — покажите понятный статус, например «Обновляются 10 допустимых записей», и место, где можно позже открыть итог. Индикатор, который движется независимо от реального хода работы, менее полезен, чем ясное состояние задачи.

Если десять записей обновлены, а две остались прежними, нельзя писать «Опубликованы все 12». Напишите «Опубликовано 10; без изменений — 2». Дайте открыть эти две записи и объясните, что одна уже была опубликована, а другая заблокирована. Для заблокированной предложите уместный следующий шаг: открыть запись, запросить доступ или повторить попытку после снятия блокировки. Если во время выполнения не удалось обновить одну из десяти допустимых записей, покажите эту ошибку отдельно от двух известных заранее исключений: причины и способы решения различаются.

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

Проверьте данные, изменившиеся до подтверждения

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

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

Сохраните доступность на узком экране и с клавиатуры

Не обозначайте выбранные строки только цветом: подпишите количество. Флажки строк должны быть доступны с клавиатуры, а панель массового действия — заметна после первого выбора. На узком экране второстепенные команды можно убрать в меню, но область выбора и смысл основной команды должны оставаться ясными. Длинные названия переносите; сравнение статусов «до → после» не должно заставлять прокручивать всю страницу по горизонтали.

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

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

В Pixso возьмите один редактируемый пример таблицы и создайте кадры для выбора двенадцати записей, просмотра с разделением десяти и двух, состояния выполнения и частичного результата. Переиспользуйте компоненты строк и статусов, чтобы имя и состояние одной записи не расходились между кадрами. Свяжите кадры в прототип и попросите команду пройти путь, сохранив в нём уже опубликованный и заблокированный материалы. Массовое изменение статуса здесь — интерфейс приложения, который проектируют на холсте Pixso, а не встроенная команда Pixso для работы с реальной базой данных.

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

Передайте правило, стоящее за каждым состоянием

Для этой очереди спецификация краткая: набор состоит из явных ID, выбранных на двух страницах; просмотр показывает десять допустимых записей, одну уже опубликованную и одну заблокированную. Подтверждение меняет только допустимые. Результат отдельно показывает обновлённые, заранее исключённые и неудавшиеся во время выполнения. Если фильтр меняется, выбранные ID остаются прежними и интерфейс об этом сообщает; если допустимость меняется перед выполнением, просмотр обновляется. Только с такими правилами можно проверить, что аккуратная кнопка «Опубликовать» делает именно то, что обещает.