Практика GrantTap · · 16 мин чтения
Понятное и доступное управление агентом с телефона
Практические проверки статусов, прокрутки, увеличенного текста, голосовых черновиков, уведомлений и восстановления после перерыва.
Управление агентом с телефона — сначала задача внимания, а уже потом размера экрана. Человек открывает запрос между встречами, возвращается после обрыва связи, читает длинную команду с увеличенным шрифтом. Маленькая цветная точка, мимолётная анимация или кнопка с изменившейся целью делают обычное решение трудным. Для пользователя экранного диктора, голосового ввода или с ограниченной точностью движения те же недостатки оказываются ещё существеннее. Удобный интерфейс должен помогать понять состояние и выбрать действие в реальных условиях, когда внимание ограничено и человек не помнит каждое сообщение длинного разговора.
Ниже — практикум оценки мобильного управления через GrantTap. Он не является заявлением о проведённом формальном аудите доступности всех экранов. Мы проверяем понятные статусы, стабильную навигацию, восстановление после прерывания и честное подтверждение результата. Эти принципы пригодятся при approval, отправке сообщения и решении отложить сложный diff до большого экрана. Обнаруженное ограничение записывается как ограничение. Красивый скриншот не доказывает удобство настоящего взаимодействия. Для достоверного вывода нужны конкретное устройство, сборка, настройки и последовательность действий, которую другой человек сможет повторить без догадок о том, что именно проверялось и почему.
Начните с решения человека
Выберите реальную задачу: например, разрешить подготовленную команду в конкретной рабочей папке. Назовите минимальные факты для решения — действие, цель, execution, непосредственное последствие и значимую неопределённость. Они должны быть доступны перед элементами выбора. Transcript помогает понять фон, но не должен оставаться единственным местом, где видно настоящую директорию команды. Если цель определить невозможно, ускорять подтверждение преждевременно. Сначала нужно представить достаточный контекст. Хороший критерий: человек способен объяснить своими словами, что произойдёт и где, не открывая несколько не связанных с запросом экранов и не вспоминая старую настройку выбранного компьютера.
Для первого упражнения подготовьте безвредный fixture-запрос в непродукционной папке с известным результатом. Отметьте тестовый характер данных. Сначала пройдите обычный путь, затем добавляйте увеличенный текст, уменьшение движения и экранный диктор. Сохраняйте конкретные наблюдения. Формулировка «путь цели обрезан при таком размере текста» даёт разработчику задачу. Общая оценка неудобства становится полезной, когда связана с решением, которое человек не смог завершить. При этом не требуется реальная публикация или разрушительная команда: свойства навигации, чтения и подтверждения можно исследовать на изолированном примере, не затрагивая чужую текущую работу на компьютере.
У каждого статуса должен быть читаемый смысл
Статус объясняет наблюдённый факт. Сохранённое сообщение, получение компьютером и активность агента — разные состояния. Они разобраны в главе доставки. Если экран показывает working, когда сообщение только сохранено relay, человек обоснованно думает, что агент уже начал. Откройте детали и установите подтверждённый этап. Несоответствие сводки и свидетельства — конкретная проблема поведения интерфейса. Не пытайтесь лечить её новым цветом прежней надписи: сначала выясните, какой источник разрешает выставить это состояние и какое событие должно его убрать. Иначе визуальная правка сохранит прежнее неверное ожидание пользователя.
То же относится к approval и настройке. Отправить решение и получить подтверждение его применения — разные моменты. Их нужно различать после disconnect и возврата из background. В упражнении намеренно прервите тестовую связь и посмотрите, что человек ещё понимает. Потерянный ответ нельзя превращать в успех. Явная неопределённость полезна: она направляет проверить исходный запрос вместо повторных нажатий с неизвестным эффектом. Если интерфейс не позволяет выяснить исход, запишите это как отдельную проблему восстановления. Человеку нужен доступный следующий шаг, а не бесконечная анимация, которая одинаково выглядит и при нормальном ожидании, и при окончательно потерянной операции.
Цвет должен дополнять информацию
Индикатор помогает просмотреть список, но значение должно сохраняться без цвета. Посмотрите экран в оттенках серого или попросите описать состояние только по тексту и форме. Зелёная точка компьютера может сообщать о соединении, не подтверждая авторизацию каждого provider и активность каждой execution. Подпись должна называть реальный факт. Легенда в другом разделе плохо помогает человеку, который прямо сейчас выбирает действие. Отдельно проверьте тёмную тему и слабое освещение: полезность контраста оценивается в настоящем чтении, а не только на идеально ярком дизайнерском изображении с короткими демонстрационными строками.
Примените тот же тест к queue и ошибкам. Различимы ли saved, received, waiting, failed и unknown без сравнения близких оттенков? Понятно ли, к какому сообщению относится индикатор? Сохраните пример двух существенно разных состояний, которые выглядят одинаково. Цель не в количестве badges. Важные различия должны читаться благодаря короткому тексту, устойчивому месту и доступной семантике. Вторичные технические детали остаются под рукой для расследования. Если текст сокращён, человеку нужен способ открыть полное объяснение, сохранив выбранный элемент и не потеряв контекст, из-за которого он вообще обратил внимание на этот статус.
Сообщайте изменения без захвата внимания
Пояснение W3C к статусным сообщениям WCAG 2.2 описывает доступность важных обновлений вспомогательным технологиям без необходимости переводить на сообщение фокус. Принцип полезен и в работе с агентом: подтверждение доставки должно быть заметно, но не вырывать человека из чтения команды. Для native app проверяйте реальное платформенное поведение. Копирование веб-приёма не устанавливает эквивалентный spoken-результат на iPhone. В практикуме достаточно выбрать несколько важных переходов и убедиться, что человек получает смысл обновления, сохраняя возможность продолжить начатое чтение с нужного места и без случайного выбора нового элемента.
Начните читать запрос экранным диктором, затем вызовите изменение статуса с тестового компьютера. Послушайте, объявлено ли оно, сохранилась ли позиция и не мешает ли частый progress. Запишите устройство, ОС и build. Simulator screenshot не устанавливает поведение речи физического устройства. Если объявление отсутствует или повторяется слишком часто, опишите конкретный переход. Это позволяет исправить проблему, не превращая каждый фоновый heartbeat в прерывание. Особенно важно различать завершение значимого действия и очередной технический сигнал живого соединения: полезность для пользователя у них разная, хотя в реализации оба могут выглядеть как очередное обновление состояния модели экрана.
Сохраняйте позицию чтения
Новые события не должны постоянно отнимать у человека читаемый участок. Откройте длинный transcript, перейдите к прежней команде и дождитесь новой активности. Проверьте сохранение позиции и понятный способ вернуться к последнему сообщению. Повторите в длинном выборе репозиториев и Files, где обновления могут менять порядок. Если список всё время возвращается наверх, нижний элемент невозможно выбрать независимо от красоты оформления. Запишите, какое событие сбрасывает прокрутку: получение данных, смена статуса, появление клавиатуры или пересоздание sheet. Это уже воспроизводимая задача для разработчика, а не абстрактная претензия к анимации списка.
Разведите намеренный переход и случайный скачок. Открытие определённого запроса вправе переместить к нему; background refresh не должен незаметно заменять выбор. В отчёте укажите состояние клавиатуры и причину обновления. Короткая запись экрана иногда полезнее фотографии, потому что сбой зависит от времени. Перед передачей уберите приватный контент. Критерий приёмки: человек продолжает читать или выбирать при поступлении новых данных и сам управляет переходом. Если после исправления список стабилен только без поиска или только при одном размере текста, это оставшееся ограничение нужно сохранить, а не объявлять весь маршрут полностью исправным по одному удачному проходу.
Используйте настоящие длинные данные
Проверяйте длинное имя репозитория, реалистичную команду, путь с несколькими каталогами и поддерживаемые языки. Увеличьте размер текста системной настройкой. Короткий demo-title не выявляет перекрытие кнопок или clipping. Важно по-прежнему определить цель, прочитать эффект и добраться до решения, когда клавиатура занимает низ sheet. Просмотрите также сообщения с несколькими абзацами: перенос строки и размер контейнера могут вести себя иначе, чем короткая подпись. Реалистичность fixture помогает найти проблему до того, как она возникнет в важном запросе, который человек пытается обработать на ходу и не может пересоздать ради удобства интерфейса.
Уменьшение шрифта не является автоматическим ответом на плотный контент. Команде может понадобиться область деталей, корректный перенос и доступ к полному значению. Сводка должна сохранять важную цель даже при длинном аргументе. Иногда лучше показать компактное пояснение и точные подробности по запросу, чем пытаться вместить каждый байт одновременно. Зафиксируйте, что сокращено и как восстановить значение до выбора. Человек не должен одобрять действие, точный target которого можно увидеть только после отправки решения. Именно доступность проверки перед действием отличает полезную компактность от скрытия важной части содержимого под слишком короткой подписью.
Глагол кнопки должен описывать эффект
Refresh, Retry, Send now, Stop, Cancel и Dismiss не взаимозаменяемы. Refresh проверяет исходное состояние без новой операции. Повтор связан с идентичностью прежнего действия и настоящими правилами восстановления. Stop относится к поддерживаемому running-процессу, Dismiss может только скрыть уведомление. Сверяйтесь с очередью сообщений и восстановлением запросов. Важно текущее поведение устройства, а не только желаемый смысл слова. Если один и тот же элемент в разных состояниях выполняет разные операции, контекст должен позволять предсказать выбор без изучения технических подробностей каждого перехода перед каждым нажатием.
Попросите второго человека до нажатия объяснить ожидание от кнопки. Сравните его с фактическим результатом fixture. Если Send now оставляет дубль или Refresh создаёт сообщение, проблема поведенческая. Новая подпись не исправит двойную операцию. Сохраните исходный ID, переход и количество итоговых элементов. Это защищает от косметической подмены исправления. После изменения повторите тот же сценарий с быстрыми последовательными нажатиями и потерей ответа, если именно они участвовали в исходном сбое. Приёмка должна проверять действие и наблюдаемое состояние, а не только наличие нового текста, красивой иконки или корректной анимации после взаимодействия.
Дайте место для осознанного касания
Проверьте управление одной рукой, увеличенный текст и открытую клавиатуру. Особенно внимательно смотрите соседние действия с разными последствиями: открыть детали и удалить queued item. Маленькая иконка выглядит аккуратно на макете, но может вызывать ошибочные попадания. Для формального вывода о размерах используйте соответствующие платформенные требования и измерения, а не визуальную оценку. В практикуме важно наблюдать возможность выполнить намеренное действие без постоянных исправлений выбора. Учитывайте и расположение sheet: доступный вверху элемент иногда становится труднодостижимым после появления дополнительного предупреждения или длинного содержимого запроса, изменившего высоту всей формы.
У disabled control должна быть доступная причина. Человек должен понимать, ждёт ли он компьютер, не поддерживается ли действие провайдером или отсутствует ввод. Бледный цвет этого не объясняет. В удалённом администрировании непонятный отказ особенно провоцирует повторные нажатия и сомнение в отправке. Содержательная обратная связь уменьшает и раздражение, и дубли. Если причина находится в другом разделе, дайте понятный путь к нему с сохранением контекста. Не заставляйте пользователя закрыть запрос, найти настройки, восстановить доступ и затем вручную искать тот же запрос в длинной истории, не зная, остался ли он ещё актуальным.
Рассматривайте голос как редактируемый черновик
Голос облегчает подготовку сообщения, но технические названия, пути и отрицания требуют проверки. Ошибка между «не публикуй» и «публикуй» существенно меняет scope. Продиктуйте fixture с именем репозитория, provider и явным ограничением. Прочитайте черновик и убедитесь, что отправка остаётся отдельным намеренным действием. Глава Files и voice описывает текущий путь. Наличие микрофона не доказывает качество распознавания в вашем языке и шумном окружении. Не делайте вывод о точности на основании одной короткой фразы без технических терминов: она не представляет обычный способ постановки инженерной задачи с телефона.
Проверьте исправление отдельного имени без потери всего текста. Пользователь должен видеть, какая Task получит сообщение. При сбое записи или транскрипции сохраняйте доступный черновик и поясняйте проблему. Частичный transcript нельзя автоматически превращать в команду. Для многоязычной команды используйте настоящий набор обычной речи и терминов, включая переключение языка. Успешная английская фраза не устанавливает то же качество для русской или украинской. Результаты запишите как наблюдения конкретного теста. Если часть сценария зависит от внешнего распознавания, доступность сети тоже относится к условиям, и отсутствие ответа не следует маскировать успешной пустой строкой или беззвучным исчезновением draft.
Уведомление ведёт к контексту
Notification сообщает о запросе, но даёт ограниченный вид работы. После открытия проверьте нужный запрос и актуальное состояние. Старое уведомление может относиться к уже завершённому, истёкшему или обработанному в другом месте действию. Переход должен восстановить контекст, а не приглашать к повторному решению по устаревшим данным. Глава уведомлений помогает определить ожидаемый маршрут. Для проверки пригодятся harmless fixtures с узнаваемой подписью: по ним легко установить, открылся ли правильный запрос, не читая всю историю и не рискуя случайно принять действие, которое относится к другой задаче или другому компьютеру.
Проверьте locked phone, открытое приложение и background. Фиксируйте наблюдаемый путь, не предполагая одинакового поведения всех входов. Если encrypted request ещё не получен, loading должен объяснять ограничение и оставлять восстановление. Навсегда disabled Retry — плохая конечная точка. Решение остаётся pending до появления настоящего содержимого. Пользователь не должен угадывать разрешение по обрезанному заголовку notification. Если запрос уже обработан, покажите результат и связь с исходным действием. Тогда человек поймёт, что опоздал к решению, но не потеряет возможность узнать исход, который уведомление всё ещё предлагает открыть на его устройстве.
Ограничьте роль часов информацией для решения
Watch удобны для своевременного сигнала, однако размер и ввод имеют свои границы. Оцените поддерживаемый маршрут по главе Devices и Watch и реальной companion-конфигурации. Не считайте, что любая phone-кнопка есть на часах или что длинную команду разумно читать там. Иногда полезное действие — заметить запрос и продолжить на телефоне. Это не недостаток маленького устройства, а соответствие поверхности объёму нужной информации. Для практикума заранее решите, какую часть сценария вы ожидаете пройти на часах и где переход к более подробному экрану является нормальным запланированным действием.
Проверьте сохранение Task и request identity при таком переходе. Если часы не получили актуальное содержимое, cached summary не должен становиться новым основанием разрешения. Запишите observed-условия связи и companion. Не называйте проверенной всю watch-функциональность после одного доставленного сигнала. Содержательный результат описывает именно пройденный путь и оставшиеся ограничения. Приёмка может установить, что конкретное уведомление открывает правильный запрос на телефоне, но не подтверждает чтение каждого сложного аргумента на часах. Чем яснее эти границы в отчёте, тем меньше риск, что последующее изменение интерфейса незаметно нарушит нужную связь между поверхностями управления.
Восстанавливайте намерение после перерыва
Работу прерывают звонки, переключение приложений, потеря сети и временно недоступный компьютер. Начните читать approval, уйдите из app и вернитесь после изменения исходного запроса. Экран должен объяснить нынешнее состояние и сохранять неподтверждённый ввод там, где это поддерживается. Возврат приложения в active не должен сам отправлять решение. Если запрос уже недействителен, нужна причина и следующий шаг, а не sheet с обманчиво активными кнопками. Проверьте также состояние после перезапуска клиента: локальная сохранность контекста и получение свежего исхода — отдельные свойства, которые не следует выводить одно из другого.
Для settings на выбранном компьютере действует тот же принцип. Restart и sign-in сохраняют понятную цель после навигации. Текущие ограничения описаны в главе обслуживания устройств. Пользуйтесь некритичными fixtures вместо перезапуска компьютера с чужой работой. Критерий: после возвращения человек понимает намерение, отправленный запрос и подтверждение компьютера без восстановления событий по памяти. Если ответ потерялся, интерфейс должен позволить проверить прежнее действие. Предложение сразу повторить опасно, когда уже неизвестно, остановился ли runtime или только не пришла квитанция о его перезапуске. Понятная неопределённость помогает выбрать корректную проверку состояния.
Разделяйте разные виды находок
Необъявленный статус, недостижимая кнопка и неподдерживаемая provider-функция — разные проблемы. Записывайте их отдельно с build, устройством, настройкой, интеграцией и минимальным сценарием. Fixture-наблюдение называйте fixture-наблюдением. Проверку физического устройства не распространяйте на все ОС и устройства. Доступность опирается на конкретный опыт, а не на универсальную фразу о поддержке любого пользователя. Для каждой находки назовите не только внешний симптом, но и сорванное решение: что человек хотел сделать, какой факт не смог получить и какой понятный путь позволил бы продолжить работу без догадки о скрытом состоянии приложения.
Сохраняйте отчёт достаточно коротким для действия. Скриншот помогает показать clipping, запись или заметки взаимодействия — timing и focus. Перед передачей проверьте приватные команды и account details. Хорошо подготовленный багрепорт направляет coding-agent к нужному экрану и переходу, оставляя человеку оценку полезности исправления. Не требуйте отдельный огромный документ на каждый мелкий визуальный дефект, если двух наблюдений и условий достаточно. Но там, где проблема связана с гонкой или потерей состояния, последовательность событий важнее количества фотографий. Включите её так, чтобы разработчик мог воспроизвести исходную трудность и затем сравнить поведение после изменения.
Проверьте поиск и отсутствие подходящего объекта
Длинные списки нуждаются не только в устойчивой прокрутке, но и в понятном поиске. Введите часть имени, проверьте найденный объект и очистите запрос. Затем попробуйте строку без совпадений. Пустой результат должен отличаться от загрузки и недоступного каталога. Если нужного репозитория вообще нет, интерфейс не должен делать вид, что любой Task обязан выбрать один из существующих элементов. Поддерживаемый сценарий обычной папки или отсутствующей привязки нужно представить честно. Конкретный путь зависит от текущей функции, поэтому оценивайте его по документации соответствующего экрана и реальному поведению, не придумывая универсальную возможность там, где её нет.
Посмотрите, сохраняет ли поиск введённый текст при background refresh и можно ли выбрать нижний результат с открытой клавиатурой. Проверьте название на другом языке и длинную общую часть нескольких имён. Критерий не сводится к наличию поля Search: человек должен найти и выбрать правильную цель, понимать отсутствие совпадения и уметь отказаться от неверной привязки. После изменения списка ранее выбранный элемент должен оставаться узнаваемым. Если источник удалён или недоступен, это отдельное состояние, а не повод автоматически выбрать первый доступный объект и продолжить действие с иной целью, чем предполагал пользователь.
Закончите полным обычным маршрутом
После исправления повторите исходную последовательность: открыть запрос стандартным входом, установить цель, посмотреть детали, выбрать действие и дождаться реального подтверждения. Включите нужный размер текста или assistive technology. Unit test и preview поддерживают изменение, но полный путь показывает совместную работу частей. Сохраните оставшиеся ограничения. Если проверка выполнена только в Simulator, прямо укажите это. Если важны звук, уведомление или watch companion, соответствующий физический маршрут требует собственной проверки. Не превращайте список предложенных сценариев в отчёт об их прохождении: план приёмки и фактический результат должны различаться по формулировке и источнику свидетельства.
Хорошая мобильная поверхность позволяет понять состояние агента, выбрать конкретное действие и восстановиться после потери связи или внимания. Это полезно всем, включая людей, не считающих себя пользователями специальных возможностей. Уменьшается число загадочных статусов, случайных повторов и решений без достаточного контекста. Включайте такие проверки в обычную продуктовую работу, а актуальный гайд используйте как справочник выпущенного поведения. Практические рекомендации остаются рекомендациями до проверки. Именно эта честная граница делает улучшение измеримым: команда видит прежний сбой, наблюдает новый результат и понимает, какой пользовательский путь теперь действительно стал понятнее и доступнее.
