{
  "index": 192,
  "slug": "editorial-2022-09-practice-mobile-ux",
  "title": "Мобильное действие без скрытого шага: как убрать зависимость от hover",
  "excerpt": "Если главное действие исчезает на узком экране, ищите не «неправильный breakpoint», а потерянный маршрут. Разбираем явный mobile-путь, отрицательную ветку и проверку, которую можно повторить.",
  "contentHtml": "<p>На телефоне пользователь открывает экран заказа, видит сумму, но не находит переход к подтверждению. На десктопе переход появляется при наведении на строку таблицы. В другом варианте кнопка остаётся в последней колонке и уезжает за горизонтальный scroll. Симптом один: человек не может завершить действие, хотя данные уже введены.</p>\n<p>Цена ошибки не сводится к плохому впечатлению. Незавершённая форма создаёт обращение в поддержку. Скрытая команда провоцирует повторный ввод. Если команда временно увеличивает кнопку, но теряет детали перед подтверждением, пользователь получает новый путь с другим риском. Релиз при этом трудно проверить: непонятно, какой элемент владел переходом и при каком состоянии он исчезал.</p>\n<p>Тезис статьи простой: мобильный сценарий нужно проверять как маршрут, а не как набор размеров. У основного действия должны быть видимый контекст, явный переход к деталям и отдельное подтверждение. Hover может улучшать обзор, но не должен оставаться единственным способом добраться до операции. Это правило не доказывает удобство интерфейса. Оно задаёт минимальный контракт, который можно проверить в коде и затем подтвердить в браузере.</p>\n<h2>Сначала восстановите маршрут</h2>\n<p>Возьмём одно действие: проверить данные заказа и подтвердить его. Не переделываем весь экран. Сначала описываем три состояния. <code>summary</code> показывает предмет операции и краткий контекст. <code>details</code> открывает данные, которые нужно проверить до необратимого шага. <code>confirm</code> содержит явный control с понятной меткой.</p>\n<p>Такое разбиение отделяет содержание от раскладки. В узком контейнере строки могут перейти в столбец, а детали — открываться во вкладке или disclosure. Но порядок решения сохраняется. Человек сначала понимает, что изменится, потом смотрит данные и только затем подтверждает. Если компонент пропускает первый или второй шаг, изменение CSS не исправит потерю смысла.</p>\n<div class=\"table-scroll\"><table><caption>Минимальный контракт мобильного действия</caption><thead><tr><th scope=\"col\">Состояние</th><th scope=\"col\">Что должно быть видно</th><th scope=\"col\">Что проверяем</th><th scope=\"col\">Чего контракт не обещает</th></tr></thead><tbody><tr><td>summary</td><td>название операции и краткий контекст</td><td>состояние существует первым</td><td>что любой перевод поместится в одну строку</td></tr><tr><td>details</td><td>явный переход к данным</td><td>переход не требует hover</td><td>что выбранный accordion удобен всем</td></tr><tr><td>confirm</td><td>видимая метка основного действия</td><td>control достижим явным вводом</td><td>размер зоны нажатия и качество текста</td></tr><tr><td>rollback</td><td>сохранённый рабочий путь</td><td>непринятый маршрут не вытесняет текущий</td><td>автоматический откат серверного состояния</td></tr></tbody></table></div>\n<p>Слово «видимый» здесь означает часть проверяемого договора. Оно не означает, что элемент уже имеет правильный размер, цвет, фокус или положение. Эти свойства требуют отдельной проверки разметки и рендера. Контракт не заменяет accessibility review и usability study.</p>\n<h2>Механизм: почему hover ломает действие</h2>\n<p>Hover описывает возможность среды указателя, а не намерение человека. Один пользователь может подключить мышь к узкому экрану. Другой может использовать клавиатуру, экранную лупу или другой способ ввода. Поэтому условие <code>hover: none</code> не равно утверждению «здесь есть только touch». Оно лишь сообщает характеристику pointing device, которую браузер определил для среды.</p>\n<p>Проблема появляется, когда команда превращает эту характеристику в единственный путь. Иконка показывает tooltip только при наведении. Строка становится ссылкой только в <code>:hover</code>. Действие раскрывается по перемещению указателя, но не имеет кнопки и не получает фокус. На экране телефона этот путь может исчезнуть, а на клавиатуре — остаться недостижимым.</p>\n<p>Безопаснее разделить основной control и подсказку. Основной control присутствует в DOM и имеет текстовую метку. Hover может показать дополнительные сведения или подсветить область. Если hover недоступен, сведения остаются достижимыми через явную кнопку или ссылку. Такой механизм работает и на широкой странице: desktop получает ускоренное обнаружение, но не теряет базовый маршрут.</p>\n<h2>Учебный пример с отрицательной веткой</h2>\n<p>Ниже — маленькая модель маршрута. Она принимает три проектных значения: ширина контекста, характеристику основного указателя и доступность hover. Эти строки задаёт тест, а не браузер. Модель не читает <code>matchMedia</code>, не создаёт DOM, не отправляет pointer events и не измеряет людей. Поэтому её результат ограничен проверкой порядка шагов и отказа от hover-only.</p>\n<pre><code>function planMobilePath(profile, action) {\n  const empty = {\n    platform: 'not-observed',\n    usability: 'not-measured',\n    steps: [],\n  };\n\n  const validProfile = profile\n    &amp;&amp; ['narrow', 'wide'].includes(profile.viewport)\n    &amp;&amp; ['coarse', 'fine'].includes(profile.primaryPointer)\n    &amp;&amp; ['available', 'unavailable'].includes(profile.hover);\n\n  if (!validProfile || !action?.id || !action?.label) {\n    return { ...empty, accepted: false, reason: 'invalid-contract' };\n  }\n\n  const explicit = profile.viewport === 'narrow'\n    || profile.primaryPointer === 'coarse'\n    || profile.hover === 'unavailable';\n\n  const steps = ['summary', 'details', 'confirm'];\n\n  if (action.activation === 'hover-only' &amp;&amp; explicit) {\n    return {\n      ...empty,\n      accepted: false,\n      reason: 'hover-only-blocked',\n      steps,\n      rollback: 'keep-current-path',\n    };\n  }\n\n  return {\n    ...empty,\n    accepted: true,\n    reason: 'explicit-route',\n    steps,\n    rollback: 'replace-route-only',\n  };\n}\n\nconst route = planMobilePath(\n  { viewport: 'narrow', primaryPointer: 'coarse', hover: 'unavailable' },\n  { id: 'confirm-order', label: 'Подтвердить заказ', activation: 'explicit' },\n);\n\nconsole.log(route.accepted); // true\nconsole.log(route.steps); // summary, details, confirm\n\nconst rejected = planMobilePath(\n  { viewport: 'narrow', primaryPointer: 'coarse', hover: 'unavailable' },\n  { id: 'open-details', label: 'Открыть итог', activation: 'hover-only' },\n);\n\nconsole.log(rejected.reason); // hover-only-blocked</code></pre>\n<p>Положительная ветка подтверждает только три вещи: входной контракт корректен, шаги идут в заданном порядке, явное действие принято. Отрицательная ветка важнее для ревью. Она запрещает объявить маршрут принятым, если на выбранном профиле единственный переход зависит от hover. Значение <code>keep-current-path</code> не откатывает приложение само по себе. Оно говорит, что текущий путь пока нельзя заменять этим учебным маршрутом.</p>\n<figure><img src=\"/assets/editorial/2022/mobile-ux-2022-route.svg\" alt=\"Схема мобильного маршрута: summary ведёт к details, затем к явному confirm; hover-only на узком профиле блокируется и сохраняет текущий путь.\" loading=\"lazy\" /><figcaption>Иллюстрация показывает границу контракта. Это схема переходов, а не снимок браузера и не результат теста пользователей.</figcaption></figure>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Рабочая таблица диагностики</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Команда видна только при наведении</td><td>hover владеет переходом</td><td>найти DOM-элемент, focus state и visibility rules</td><td>добавить явный button или link</td></tr><tr><td>Кнопка находится в последней колонке</td><td>таблица требует ширины, которой нет</td><td>проверить overflow и порядок данных на узком контейнере</td><td>вынести основное действие из таблицы, детали оставить отдельно</td></tr><tr><td>После раскрытия нет понятного подтверждения</td><td>details и commit смешаны в одном control</td><td>проверить состояния до и после раскрытия</td><td>разделить просмотр и необратимое действие</td></tr><tr><td>Новый путь вызывает сомнение</td><td>замена сделана без безопасной границы</td><td>описать старый route и условия возврата</td><td>сохранить current path до отдельной проверки</td></tr><tr><td>«Мобильный» тест зелёный, UI не проверен</td><td>учебную модель приняли за browser test</td><td>посмотреть, какие данные реально создаёт тест</td><td>добавить отдельную проверку браузера с фиксированными условиями</td></tr></tbody></table></div>\n<p>Таблица нужна для смены уровня разговора. Запись «на телефоне неудобно» не объясняет, что наблюдалось. Запись «в состоянии A переход к details появляется только после hover» уже задаёт проверку. В реальном отчёте добавьте URL или экран, браузер, viewport, масштаб, локаль, способ ввода, начальное состояние и тестовые данные. Не заполняйте неизвестные поля догадками.</p>\n<h2>Порядок исправления</h2>\n<ol><li><strong>Зафиксируйте симптом.</strong> Назовите одно состояние, в котором основное действие не видно или достижимо только через hover. Отделите наблюдение от предположения о пользователях.</li><li><strong>Найдите владельца перехода.</strong> Проверьте DOM, состояние компонента, правила видимости, overflow и обработчики. Не меняйте breakpoint, пока не ясно, какой элемент должен вести дальше.</li><li><strong>Опишите контракт.</strong> Запишите summary, details и confirm. Для каждого шага укажите видимую метку, ожидаемый результат и способ отмены.</li><li><strong>Проверьте отрицательный путь.</strong> Передайте модели narrow/coarse/unavailable и действие с <code>hover-only</code>. Ожидайте отказ с причиной <code>hover-only-blocked</code>. Если тест принимает путь, контракт ослаблен.</li><li><strong>Добавьте явный control.</strong> Оставьте контекст перед подтверждением. Не прячьте ошибку, отмену или важные данные в другом hover-меню.</li><li><strong>Проверьте реализацию в браузере.</strong> Зафиксируйте viewport, zoom, шрифты, локаль, данные, клавиатуру и способ указателя. Проверьте render, focus, keyboard path, раскрытие details и состояние ошибки.</li><li><strong>Определите откат.</strong> До выпуска сохраните способ вернуть текущий путь: флаг, отдельная ветка, revert или ограниченный rollout. Учебная модель не меняет сервер и не выполняет откат за команду.</li></ol>\n<h2>Ограничения и критерий готовности</h2>\n<p>Контракт не выбирает breakpoint и не задаёт универсальный размер зоны нажатия. Он не описывает экранную клавиатуру, поворот экрана, длинные локализованные строки, screen reader, ошибку сети или конкурирующее обновление данных. Он также не доказывает, что человеку понятна метка «Продолжить». Эти вопросы относятся к реализации, доступности и исследованию.</p>\n<p>Нельзя объявлять production-эффектом число успешных assertion. В примере нет пользователей, реального устройства, телеметрии и замера времени. Нельзя называть строку <code>narrow</code> конкретным viewport в CSS pixels. Нельзя трактовать <code>hover: none</code> как запрет мыши. Нельзя использовать учебный отказ как автоматическое решение для серверной операции.</p>\n<p>Сценарий готов к следующей проверке, если выполнены четыре условия. Для основного действия существует видимый control с предметной меткой. До confirm доступен отдельный summary и путь к details. На заданном учебном профиле hover-only отклоняется, а на реализацию не распространяется обещание usability. В браузере другой инженер может повторить описанное состояние по зафиксированным входам и увидеть тот же порядок: summary → details → confirm.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://www.w3.org/TR/2021/CRD-mediaqueries-4-20211225/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C: Media Queries Level 4, Candidate Recommendation Draft</a> — описывает media features <code>pointer</code>, <code>hover</code>, <code>any-pointer</code> и <code>any-hover</code>; это свойства среды, а не измерение удобства.</li><li><a href=\"https://www.w3.org/TR/2019/REC-pointerevents2-20190404/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C: Pointer Events Level 2, Recommendation</a> — задаёт модель событий указателя и типы ввода, но не гарантирует достижимость конкретного действия.</li><li><a href=\"https://www.w3.org/TR/2018/REC-WCAG21-20180605/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C: Web Content Accessibility Guidelines 2.1, Recommendation</a> — содержит критерии для pointer gestures, ориентации и reflow; соответствие конкретного интерфейса требует отдельной оценки.</li></ul>"
}