Scott
При изменении порядка элементов человеку важно понимать две вещи: куда переместится выбранная строка и сохранился ли новый порядок. Если задача уходит с четвёртого места на второе, точка вставки должна быть видна ещё до отпускания указателя. После перемещения нужно показать итоговую последовательность и статус сохранения. Одна плавная анимация этих вопросов не решает. И тот же результат должен быть доступен человеку, который не может или не хочет перетаскивать элементы.
Разберём одну очередь приоритетов операционной команды — от первого перемещения до ошибки сохранения. Чтобы обсудить с коллегами состояния для мыши, клавиатуры и подтверждения до разработки, можно связать соответствующие экраны в прототипе Pixso. Здесь речь о проектировании поведения рабочего приложения; сам по себе прототип не сохраняет порядок его реальных задач.
Сначала определите смысл порядка, затем рисуйте маркер перетаскивания
Допустим, в очереди пять задач: «Проверить счёт», «Связаться с поставщиком», «Сверить остатки», «Проверить договор», «Опубликовать обновление». Координатор перемещает четвёртую задачу, «Проверить договор», на второе место. Итог: «Проверить счёт», «Проверить договор», «Связаться с поставщиком», «Сверить остатки», «Опубликовать обновление». Запишите эту последовательность до проектирования: тогда у дизайна и реализации будет один проверяемый результат.
Решите, кому принадлежит порядок: одному координатору, всей команде или только текущему сеансу в браузере. Для общей очереди сообщение о сохранении должно отличаться от сообщения для личной. Определите и момент записи: после каждого перемещения или по отдельной кнопке «Сохранить порядок». Если карточки уже поменялись местами, а после перезагрузки молча возвращаются назад, интерфейс вводит человека в заблуждение.
Положение должно оставаться понятным и при длинных названиях задач. В короткой очереди помогают номера; в большом бэклоге важнее могут оказаться названия групп. Не передавайте результат только сменой цвета. Сообщение «Задача „Проверить договор“ перемещена на место 2 из 5» точнее, чем краткая фиолетовая вспышка.
Показывайте место вставки до отпускания элемента
Маркер перетаскивания должен выглядеть как элемент управления именно этой строкой и находиться в одинаковом месте у каждой задачи. Оставьте достаточно пространства между ним, флажком, меню и ссылкой на детали. Когда координатор поднимает «Проверить договор», сохраните контур на старом месте и проведите линию вставки между «Проверить счёт» и «Связаться с поставщиком». Предпросмотр не должен выглядеть так, будто перемещаемая задача заменит соседнюю или откроет её.
При проходе через другие строки показывайте предполагаемый порядок непрерывно. Если элементы слишком резко прыгают, линия вставки отрывается от указателя и теряется ориентир. В прокручиваемом списке удерживайте назначение в поле зрения; автопрокрутку должно быть легко остановить. На телефоне обычная прокрутка конкурирует с жестом перетаскивания. Явный маркер или другое осознанное начало действия помогает различать эти жесты.
Не всякий список можно упорядочивать свободно. Верхняя задача может быть закреплена, этап согласования — заблокирован, а права пользователя — ограничены. Покажите доступный диапазон до отпускания. Нельзя сначала нарисовать допустимую точку вставки, а затем без объяснения отвергнуть перемещение. Если ограничение можно проверить только на сервере в конце, покажите причину отказа и путь восстановления.
Дайте полноценный способ изменить порядок без перетаскивания
Перетаскивание не должно быть единственным способом. Практичный вариант — меню каждой строки с командами «Переместить выше», «Переместить ниже», а для длинной очереди ещё и «Переместить на позицию…». Человек с клавиатурой переводит фокус на строку, открывает меню, выполняет действие и продолжает работу с предсказуемого места. Команду, невозможную на первой или последней позиции, последовательно отключайте либо убирайте; нажатие без видимого результата недопустимо.
В сообщении о результате называйте задачу и новое место: «„Проверить договор“ перемещена на место 2 из 5». Если порядок ещё не сохранён, сообщите и об этом. Одной перестановки элементов в DOM может быть недостаточно, чтобы пользователь скринридера понял результат. Для собственного виджета определите роли, перемещение фокуса и действия осознанно. Паттерн списка W3C полезен как ориентир для клавиатуры и фокуса, но не является универсальной готовой реализацией любого переупорядочиваемого списка. Проверяйте конкретный интерфейс с клавиатурой и вспомогательными технологиями.
Пути с мышью и клавиатурой должны приводить к одинаковому сохранённому порядку. Нельзя сделать «клавиатурный режим», который меняет только копию на экране или требует незаметного дополнительного подтверждения. Рекомендации Atlassian по доступности drag-and-drop помогают продумать альтернативу указателю; точный контракт всё равно нужно испытать в своём продукте.
Подтверждайте порядок и помогайте восстановиться после сбоя
После отпускания покажите новую последовательность и оставьте фокус на «Проверить договор» либо её маркере. При автосохранении сначала покажите ожидание, а подтверждение — только после ответа сервера. Локальную перестановку нельзя называть сохранённой, пока запрос ещё выполняется. Если нужна кнопка «Сохранить порядок», обозначьте несохранённое изменение и сделайте действие заметным до ухода со страницы.
Ошибочное перемещение должно быть обратимым, особенно если карточка перескочила через несколько позиций. «Отменить» должно вернуть не только визуальную последовательность, но и хранимый порядок. Если другой участник команды тем временем изменил общую очередь, объясните, какая версия сейчас действительна. При конфликте дайте просмотреть свежий порядок и применить задуманное перемещение заново, не перезаписывая молча чужую работу.
Для неудачного сохранения выберите и ясно обозначьте одну из двух честных моделей: оставить предложенный порядок с пометкой «Не сохранено» и действиями «Повторить»/«Отменить» либо вернуть последнюю подтверждённую последовательность с объяснением. Исчезающее уведомление при оставшемся на экране неподтверждённом порядке не решает проблему. Видимое состояние списка и принятые сервером данные должны в итоге совпасть.
Проверяйте состояния, а не только анимацию
Прогоните один и тот же переход с четвёртого места на второе через все пути, включая неудачное сохранение. Небольшая таблица состояний помогает обнаружить пропущенные решения до реализации.
| Состояние | Что видно человеку | Что проверять |
|---|---|---|
| До действия | Устойчивый порядок, различимый маркер или команда перемещения | Для каждой задачи есть одинаковые пути |
| Во время перемещения | Метка прежнего места и точная линия вставки | Прокрутка и касания не приводят к случайному отпусканию элемента |
| Перемещено, не сохранено | Новая последовательность и статус ожидания либо несохранённости | Поведение после перезагрузки соответствует выбранной модели |
| Сохранено | Подтверждение рядом с задачей или списком | Порядок сохраняется после повторного открытия |
| Отказ или конфликт | Повтор, просмотр свежей версии либо возврат к прежней | Экран не расходится молча с сервером |
| Отменено | Прежняя последовательность и подтверждение отмены | Данные, фокус и озвученное сообщение согласованы |
Проверьте этот контракт мышью, касанием, клавиатурой, скринридером и на узком экране. Механика ввода может различаться, но новое место и статус сохранения должны быть понятны в каждом случае. Визуальные рекомендации Atlassian пригодятся для сравнения вариантов обратной связи; окончательное решение принимайте по тестам своего продукта.
Соберите сценарий перемещения и восстановления в Pixso
Нарисуйте связанные состояния: до действия, предпросмотр места вставки, перемещено, но не сохранено, сохранено, ошибка. Добавьте меню клавиатурных команд к тем же пяти задачам, а не к другому примеру. Названия задач и переход «с четвёртого на второе» должны оставаться одинаковыми на всех экранах: тогда обсуждение сосредоточится на поведении, а не на расхождениях в содержимом.
На встрече попросите коллег предсказать ответ до каждого действия: какая задача переместится, куда именно, завершилось ли сохранение, что произойдёт при отказе? Если без объяснения дизайнера это неясно, экрану нужны более явные подсказки. Согласованные состояния затем послужат ориентиром для разработки и приёмки.
Проектируйте не эффектное движение, а надёжный результат
Главное в изменении порядка — не само движение карточки, а надёжный переход от прежней последовательности к задуманной новой. Предусмотрите равнозначный путь без перетаскивания, покажите место вставки заранее и не смешивайте видимую перестановку с подтверждённым сохранением. Тогда очередь останется удобной не только в идеальной демонстрации, но и при ошибках.
