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

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

Что меняем:
Превращаем 32px неинформативной панели в 56px информативной и функциональной. Как? — вместо понели внедряем "ActionBar". По сути та же панель, но заголовки меняются в зависимости от действий, и добавляюется элемент управления — возврат к предидущему действию.

Такое поведение знакомо пользователям по умолчанию тк используется в iOS и Android ос. Оно более информативно. Главное — такие принципы поведения помогают улучшить сценарии просмотра и создания правил.
Зачем информативность и функциоальность в панели?

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

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

Актуализируем визуальную составляющую этих элементов.
Табы
И формируем элемент Список для интерфейсов создания правила
Модифицируем андроид-подобную табуляцию под нужны проекта и делаем ее Smart — отображаем цифты только там, где есть правила, где правил нет — не ставим ноль, а просто ничего не отображаем. Так визуального мусора будет меньше
С новым стилем табуляции чистим остальные элементы — убираем лишние горизонтальные и вертикальные линии. Смотрим что получилось.
Продолжим работать с этим интерфейсом и избавимся от очевидных лишних элементов которые вызывают логические нестыковки в сценариях
Оставим только 1н CTA
Что у нас с кнопками и зачем их 2. Не мешают ли они друг другу?

В этом интерфейсе пользователь может Создать новое правило или модифицировать текушее. На кнопку Сохранить выбранное правило выпадает 2ве функции: подтвердить изменения в текущих правилах и подтвердить/завершть процесс создания нового. Это перебор и путанница — правильно было вынести процесс создания в обособленный интерфейс и завершать/подтверждать его уже там. Теперь кнопка Сохранить имеет право быть отображенной только когда изменения были сделаны. те по умолчанию в ней нет необходимости.
Что должно занять ее место? — кнопка создать. Изменив интерфейс и неподтвердив изменения пользователь не должен иметь возможности случайно уйти в другое действие такое как создание нового.
Таким образом CTA в интерфейсе остается только один.

Даем анимацию и делаем цветовое кодирование этих разных действие: создания и сохранения.
Что еще - появление и цветовое кодирование кнопки сохранить будет еще являтся индикатором наличия изменений.
Интерфейс по умолчанию: когда в плавила не было внесено изменений. Кнопка создать правило доступна
тот же интерфейс если были внесены изменения в созданные правила
NEW. Родился новый сценарий — можно вносить несколько изменений в разные правила, а интерфейс покажет это. Тут же по гиперссылке интерфейс отобразит измененное правило.
Осталось дело за малым
Выстроить по значимости и зависимости информацию, убрать акцентные цвета из таблиц и будет ок.
Справляемся об иерархии информации.
Приоритет номер — Само правило или список правил.
Сейчас под него отведено очень мало пространства. А он является точкой входа в характеристики. Мняем эту парадигму
Интерфейс стал чище и избавился от лишних элементов. Вместе с тем стал заметен новый сценарий.
Когда правил больше чем одно, вероятность того что при открытии интерфейса отображаемая информация по умолчанию полезна, снижается.

В случае когда правил 10, какова вероятность, что пользователю понадобится срузу увидеть именно характеристики первого в списке правила?

Те отображению выбора прежшествует действие Выбор. До выбора отображение характеристик — лишний элемент (если правило не одно)

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