VEU
/
VEU.WathBody
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
VEU.WathBody/1-docs/3-tech/ui-ux-recommendations.md

17 KiB
Raw Permalink Blame History

UI/UX-рекомендации для разработки WatchBody

Версия 1.1 · 2026-10-17, УТВЕРЖДЕНО (ревью №2, З-28: синхронизация — UUID PK клиентских сущностей (Р2-Б); ввод RPE/боли — на телефоне, не на часах)

Основа: исследование книг и гайдов по wearable- и mobile-UX (Sullivan «Designing for Wearables», Wroblewski «Mobile First», Nielsen/Budiu «Mobile Usability», Krug «Don't Make Me Think», Norman «The Design of Everyday Things», гайды Android Wear OS, ProtoPie, UsabilityGeek, MDPI 2024). Ниже — применение этих принципов к составу WatchBody: приложение на часах (Garmin Fenix 6X, Connect IQ), компаньон на телефоне, веб-админ-консоль владельца.

1. Общие принципы (все клиенты)

  1. Glanceable, а не readable. Любой экран читается за 1–2 секунды. Одно число — один экран. В тренажёрном зале пользователь смотрит на часы между подходами, часто в движении и при ярком/тусклом свете.
  2. Одна задача — один поток. На часах нет «навигации ради навигации»: линейный поток «подход → отдых → следующий подход». Не вкладывать больше двух уровней.
  3. Минимум ввода, максимум предзаполнения. Вес, повторы, упражнения подставляются из плана и истории; пользователь только подтверждает или корректирует. Правило Круга «Don't Make Me Think»: выбор из списка предпочтительнее ручного ввода.
  4. Ошибкоустойчивость. Все деструктивные действия (завершить тренировку, удалить подход) — с подтверждением; отмена последнего действия доступна в течение сессии.
  5. Прерывистость — норма. Тренировка прерывается (подошёл тренер, звонок, отдых затянулся). Состояние сохраняется на часах и синхронизируется; возврат в контекст — не глубже одного экрана.

2. Часы (Fenix 6X, Connect IQ)

2.1. Аппаратные ограничения учитываем как данность

  • Экран 280×280, MIP-дисплей (64 цвета,Palette), читаемость на солнце — плюс; в помещении — высокий контраст, крупные шрифты (минимум ~22–26 px для ключевых цифр; системные шрифтовые константы Connect IQ — Graphics.FONT_LARGE, FONT_NUMBER_*).
  • Взаимодействие: только 5 кнопок (START/BACK/UP/DOWN/LIGHT), тачскрина нет. Каждый экран проектируется под «вверх/вниз — выбор, START — подтвердить, BACK — отмена/выход». Никаких жестов, требующих точности.
  • Ремешок: рука вспотевшая, перчатки — целевые зоны кнопок крупные, «случайные» нажатия (LIGHT в кармане) игнорируем/обрабатываем.

2.2. Поток тренировки

  • Во время подхода — не требуем никакого взаимодействия: часы показывают текущее упражнение/сет и вибрируют по завершении отдыха.
  • Ввод RPE/боли по сетам — упрощённая шкала (кнопки UP/DOWN ±, подтверждение START). Примечание (З-28): к форме «поле данных» неприменимо — кнопки обрабатывает Garmin (Ф-2.5–2.6); ввод RPE/боли выполняется на телефоне (Ф-13.3).
  • Отдых между подходами — крупнейший таймер на экране, вибрация за 5 с и в конце; на том же экране — следующий подход («3×10 · 40 кг»), чтобы атлет готовил вес заранее.
  • Safety-пороги (по техтребованиям): предупреждение — вибрация + экран с крупным текстом и одной кнопкой «OK»; порог «стоп» — красный/инвертированный экран, требующий явного подтверждения. Никаких предупреждений очередями.
  • Экран пробуждения/приветствия перед стартом тренировки: название тренировки дня, кол-во упражнений, ожидаемое время — и START.

2.3. Что НЕ делаем на часах

  • Планирование, история за период, графики, настройки порогов — всё это на телефоне/вебе. Часы — только исполнение тренировки и подсказки.
  • Свободный текстовый ввод — исключён.

3. Телефон (компаньон)

  • Mobile-first (Wroblewski): проектируем от узкого экрана, а не «десктоп, ужатый в телефон».
  • Одна рука: ключевые действия (старт/пауза тренировки, отметка подхода) — в нижней трети экрана, в зоне большого пальца.
  • Целевая аудитория 45+: базовый размер шрифта ≥ 16 pt, контраст по WCAG AA (≥ 4.5:1), крупные цели касания ≥ 44×44 pt, без тонких шрифтов и «серого на сером». Это же лечит использование в зале при ярком свете.
  • Ввод данных: числовые поля — пикеры с шагом (2.5 кг), а не клавиатура; последний использованный вес — значение по умолчанию; для RPE/боли — сегмент-контролы, не слайдеры.
  • Офлайн-first: все данные тренировки пишутся локально и синхронизируются позже (sync — UUID PK клиентских сущностей, Р2-Б; см. архитектуру); UI честно показывает статус синхронизации.
  • Уведомления — только значимые: напоминание о тренировке, итоги, нарушение Safety-порога. Никакого «стreak-спама».

4. Веб-админ-консоль владельца

  • Десктоп-first, но без сломанной верстки на планшете.
  • Главные экраны: план на неделю, прогресс (простые таблицы и линейные графики, а не «дашборд из 20 виджетов»), редактирование программы, приём FIT-файлов.
  • Подтверждение LLM-плана: diff-представление «что изменилось против предыдущей недели» + явные кнопки «Принять / Отклонить / Править» (Krug: явный выбор вместо подразумеваемого).
  • Экспорт/бэкап данных — всегда доступен одной кнопкой.

5. Доступность и здоровье (специфика проекта)

  • Пользователь 45+, гипертония: крупные цифры ЧСС/давления, красный/зелёный дублируем текстом или иконкой (не только цветом — дальтонизм и яркий свет).
  • Все единицы (кг, повторы, пульс, RPE по Боргу) — как в утверждённых метриках проекта; не вводить синонимы на разных экранах.
  • Медицинские предупреждения формулировать спокойно и конкретно («Пульс 165 выше порога. Отдохните или завершите»), без тревожной лексики.

6. Конкретика из изученных источников

6.1. ProtoPie — гайд по smartwatch-UX

  • Экран часов — ~30 % площади смартфона: проектируем «at a glance», взаимодействия длительностью в секунды.
  • Целевое состояние — мышечная память: пользователь действует не глядя. Для Fenix 6X это означает неизменную семантику кнопок на всех экранах (UP/DOWN — выбор, START — подтвердить, BACK — отмена), даже ценой менее «оптимальных» отдельных потоков.
  • Избегать иерархических деревьев; работают линейные потоки и страничная модель.
  • Анимации — минимум и только лёгкие: тяжёлые анимации тормозят бюджетные устройства и съедают батарею; медиа (например, короткая анимация техники упражнения) — на телефоне, не на часах.
  • Мгновенный отклик на любое действие — главный критерий; медленная система на запястье воспринимается как сломанная.
  • Не показывать чувствительные данные (давление, пульс покоя) на всплывающих уведомлениях, видимых окружающим.
  • Хаптика (вибро-паттерны разных типов: подход выполнен / отдых кончился / предупреждение) — канал информации без затрат экрана.
  • Тестировать на реальном железе с ранней стадии, а не только в симуляторе Connect IQ.

6.2. Android Wear OS design principles (Material 3 for Wear)

  • Design for critical tasks: на часах — только 1–2 ключевые задачи (исполнение тренировки + ввод RPE/боли; для формы «поле данных» ввод RPE/боли неприменим — кнопки обрабатывает Garmin, Ф-2.5–2.6, ввод — на телефоне, Ф-13.3). Всё остальное — на телефоне/вебе.
  • Optimize for the wrist: задача на часах должна решаться за секунды — иначе эргономический дискомфорт и усталость руки (для атлета под штангой это критично).
  • Glanceable surfaces: основное содержимое — в виде «взгляд-поверхностей» (у Garmin аналог — data fields в активити и watch face complications: можно вывести «текущее упражнение / подход X из Y» прямо на циферблат в дни тренировок).
  • Always relevant: контент подстраивается под контекст (время суток, день недели, запланированная тренировка).
  • Works offline: часы и телефон обязаны полноценно работать без сети (спорт-сценарий) — совпадает с офлайн-first требованием проекта.
  • Полезные референсы из этого гайда: non-scrolling layouts для потоков «подход/отдых», confirmation overlay для подтверждений, dialogs/steppers/pickers как канонические компоненты — переносить паттерны на кнопочную навигацию Fenix (ввод RPE/боли — на телефоне, Ф-13.3).

6.3. MDPI 2024 — исследование юзабилити смарт-часов

Методика: 11 кастомизированных эвристик (6 из Нильсена: self-descriptiveness, consistency, минимализм, снижение нагрузки на память, соответствие реальному миру, error tolerance; 5 из Motti & Caine для носимых: privacy, ease of use, flexibility/efficiency, features, satisfaction) + SUS-опросник. Результаты: лучшие часы набрали SUS 87,4; чаще всего проблемы обнаруживались именно в «ease of use», «flexibility/efficiency» и «features».

Применяем к WatchBody:

  • Чек-лист эвристик для ревью каждого экрана — тот же набор из 11 пунктов; баг-репорты по шкале серьёзности 1–5 (косметика → катастрофа).
  • SUS ≥ 80 как целевой порог качества релиза приложения (средний по индустрии — 68).
  • Типовые проблемы из исследования, которых избегаем:
    • сообщения об ошибках исчезают быстрее, чем их успевают прочитать (GW4) → все предупреждения Safety закрываются только явным нажатием кнопки;
    • нет автоматического переподключения после разрыва связи (типовая жалоба) → устойчивый reconnect часы↔телефон↔сервер и честный индикатор статуса;
    • нельзя поменять размер шрифта → настройки размера шрифта на телефоне;
    • сброс настроек/сопряжения после обновлений → хранение конфигурации на сервере, а не только на устройстве (id передаётся в UUID-ключах записей — Р2-Б).

7. Процесс проверки

  • Прототип часов проверяем «на запястье»: одна рука занята, экран гаснет, взгляд 2 секунды; симулятор — только для разработки, приёмка — на реальном Fenix 6X (ProtoPie).
  • Эвристическое ревью по 11 эвристикам из 6.3 на каждом экране + SUS-опрос после первых юзабилити-сессий; порог релиза SUS ≥ 80.
  • Критерий готовности экрана часов: ключевое действие за ≤ 3 нажатий кнопок и ≤ 5 секунд, с работающей мышечной памятью после ≤ 3 сессий.

8. Источники