Files
rf4-spotter/docs/UI_UX_AUDIT.md
T
ik aeef99920a
CI / backend-and-migrations (push) Canceled after 0s
CI / astro-build (push) Canceled after 0s
CI / compose-e2e (push) Canceled after 0s
feat: shorten mobile path to activity
2026-09-07 08:10:07 +07:00

14 KiB

UI/UX-аудит RF4 Spotter

Дата проверки: 5 сентября 2026 года. Проверены живые страницы Astro на desktop и при ширине 390 px: главная, рекорды, форма улова, detail точки, модерация и очередь внешних источников. Аудит оценивает понятность, непротиворечивость, мобильный путь, доступность и состояние без данных.

Краткий вывод

Визуальная система уже цельная: выразительная типографика, ограниченная палитра, ясные карточки, заметные CTA и согласованное оформление публичных и административных страниц. Интерфейс адаптируется без горизонтального переполнения на 390 px, изображения имеют alt, основные формы размечены label.

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

Найденные проблемы

P0 — исправить до пользовательского пилота

  1. Противоречивая оценка активности. При activity_score=7 карточка показывает «Низкий», объяснение говорит «Низкая активность», но блок лидера пишет «Клёв хороший». Причина — бинарное условие >=70 ? отличный : хороший. Нужна одна общая шкала и один formatter для карточки, лидера и detail-страницы.
  2. Обещание формы не соответствует объёму. Текст «Полминуты» предваряет длинную форму из обязательных и необязательных параметров. Следует либо сократить основной сценарий до пяти обязательных полей с раскрываемым блоком «Дополнительно», либо заменить обещание честной оценкой времени.

P1 — основной UX-пакет

  1. На мобильном результат расположен слишком глубоко. Hero, изображение и четыре вертикальных фильтра занимают больше первого экрана. Пользователь приходит узнать, где клюёт, но первую точку видит только после значительной прокрутки. На ширине до 720 px нужен компактный hero, сворачиваемые дополнительные фильтры и краткая строка активных условий над результатами.
  2. Неправильные формы числительных. В интерфейсе встречаются 1 точки, 1 уловов, 1 наблюдениях, 1 игроков. Нужен общий helper русских форм для точки/улова/игрока/наблюдения и тесты значений 0, 1, 2, 5, 11, 21.
  3. Рекорды требуют знания slug. Поля pike и vyunok понятны разработчику, но не игроку. Следует использовать справочники рыб и водоёмов, показывать русские названия, оставить slug только значением option и добавить явный сброс фильтров.
  4. Мобильные записи теряют контекст колонок. Заголовок таблицы скрыт, а значения раскладываются в две колонки без локальных подписей. Нужны семантическая таблица с адаптивным скроллом либо карточки с видимой подписью каждого значения.
  5. Пустое состояние рекордов обращено к разработчику. Команда python -m app.cli import-records не должна быть основной подсказкой публичному пользователю. Публичный текст: «Данные ещё загружаются»; эксплуатационную инструкцию оставить в README/admin-интерфейсе.
  6. Форма улова не помогает вводить игровые данные. Для координат нет примера и пояснения диапазона, вес требуется только в граммах, необязательные поля визуально почти равнозначны обязательным. Добавить примеры 71 : 92, переключатель/подсказку кг↔г, явную маркировку «необязательно» и сохранение введённых значений после серверной ошибки.

P2 — доступность и полировка

  1. Нет общего :focus-visible. Выраженный focus есть у полей формы улова, но не гарантирован для навигации, CTA, карточек-точек, ссылок и административных действий. Добавить единый контрастный outline и проверить весь путь только клавиатурой.
  2. Цвет не должен быть единственным сигналом. Статусы импорта и активности используют цветные точки. Сохранить текстовый статус, добавить доступное имя и проверить контраст muted-текста и мелких uppercase-подписей.
  3. Главная дублирует выбранную точку. При малом числе результатов карточка и большой блок «Лидер активности» повторяют почти одни данные. Показывать sidebar только при достаточной выборке или превратить его в действительно дополнительный контекст: динамика, лучшие часы, доказательства.
  4. Административным действиям не хватает защиты от ошибки. Удаление визуально соседствует с одобрением/отклонением. Нужны подтверждение удаления с названием рыбы/точки, обязательная причина для отклонения и сообщение о результате, доступное через aria-live.
  5. Навигация на узких экранах не масштабируется. Сейчас она помещается на 390 px за счёт горизонтального контейнера, но нет признака прокрутки и нет проверки 320 px. Для MVP достаточно теста 320 px и компактных подписей/overflow-индикатора; бургер для трёх пунктов не обязателен.

План работ

Визуальный язык — выполнено

  • Добавлен единый набор тонких рыболовных SVG-иконок без внешней библиотеки.
  • Unicode-символы навигации, метрик, координат, времени и приманки заменены тематическими пиктограммами.
  • Кольцевая диаграмма лидера заменена авторской шкалой-поплавком: высота поплавка и воды связана с индексом активности.
  • Добавлена деликатная рябь и покачивание с учётом prefers-reduced-motion.

Пакет A — достоверность интерфейса

  • Вынести шкалу активности и пользовательские формулировки в общий helper.
  • Устранить противоречие карточки, sidebar и detail для всех диапазонов 0–100.
  • Добавить helper русских числительных и unit-тесты граничных значений.
  • Проверить тексты состояний «мало данных», «нет данных», «источник недоступен» на непротиворечивость.

Критерий: одно значение во всех представлениях имеет одинаковый уровень и объяснение; в UI нет строк вида 1 точки.

Пакет B — мобильный путь «найти точку»

  • Уменьшить мобильный hero и приблизить список результатов к первому экрану.
  • Оставить водоём и рыбу основными фильтрами, период и сортировку поместить в раскрываемый блок.
  • Показывать применённые фильтры и отдельную кнопку сброса.
  • Проверить 320, 390, 768 и 1280 px, длинные названия рыб/водоёмов и 0/1/10 результатов.

Критерий: на 390 px заголовок первого результата или явное пустое состояние доступно не позднее второй высоты экрана; горизонтального переполнения нет.

Пакет C — форма улова

  • Разделить форму на обязательную основу и раскрываемые дополнительные сведения.
  • Добавить примеры координат и помощь с единицами веса.
  • Показывать ошибки рядом с конкретным полем и общий summary с переводом фокуса.
  • Сохранять введённые значения после ошибки создания и отдельно обрабатывать повтор скриншота.
  • Привести обещание времени заполнения в соответствие с измеренным сценарием.

Критерий: новый пользователь без документации понимает формат координат/веса, ошибка не уничтожает введённые данные, обязательные поля визуально очевидны.

Пакет D — рекорды и detail точки

  • Заменить slug-input фильтрами из справочников и добавить сброс.
  • Сделать мобильную выдачу рекордов самодостаточной: подписи значений или доступная таблица.
  • Убрать CLI-команду из публичного empty state.
  • Добавить к уловам detail-страницы дату/свежесть и происхождение, если API их отдаёт.
  • Устранить дублирование карточки и sidebar на малой выборке.

Критерий: фильтрация не требует технических терминов; каждая мобильная запись читается без заголовка таблицы; источник и свежесть понятны.

Пакет E — accessibility и административная безопасность

  • Добавить глобальные :focus-visible, skip-link и заметное состояние текущей страницы.
  • Пройти публичный и административный сценарии только клавиатурой.
  • Проверить контраст WCAG AA, доступные имена статусов и aria-live ошибок/успеха.
  • Добавить подтверждение удаления и обязательную причину отклонения.
  • Запустить axe/Lighthouse и сохранить измеримые результаты.

Критерий: нет critical/serious нарушений axe; все действия доступны с клавиатуры; destructive action невозможно выполнить случайным одиночным нажатием.

Рекомендуемая последовательность

  1. Пакет A — исправляет доверие к данным и мало зависит от вёрстки.
  2. Пакет B — улучшает главный пользовательский сценарий.
  3. Пакет C — повышает число качественно заполненных заявок.
  4. Пакет D — убирает технический язык и улучшает чтение данных.
  5. Пакет E — завершает пилотную готовность и формализует доступность.

Каждый пакет выполняется отдельным коммитом и проверяется Astro build, существующим E2E, клавиатурным сценарием и viewport 390 px. Для пакетов B/D дополнительно проверяется 320 px; для E сохраняются отчёты Lighthouse/axe.