Асинхронный поиск в форме: ввод и выбор — разные состояния

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

Сначала определите правила ввода и проверки поля. В нашем примере поле получателя счёта принимает идентификатор одного существующего клиента, а не произвольный текст. Поиск помогает найти запись, но даже точно введённое название ещё не означает, что она выбрана.

Проектируйте выбор записи, а не только поиск совпадающих слов

Представим приложение для выставления счетов с двумя вымышленными клиентами: Northstar Studio с идентификатором C-104 и Northstar Supplies с идентификатором C-219. Сотрудник вводит «North». Подходят оба клиента. В выпадающем списке должно быть достаточно разрешённой к показу информации, чтобы различить их до выбора.

Выделите название клиента и добавьте полезный дополнительный признак. В этом примере достаточно идентификатора. В реальном продукте пользователю может быть понятнее доступное ему местоположение или номер учётной записи. Не раскрывайте закрытые сведения только ради удобства поиска и не рассчитывайте, что маленькая аватарка позволит различить похожие записи.

После выбора Northstar Studio поле должно однозначно представлять запись C-104. Отображаемое название со временем может измениться, но связь устанавливается именно с записью. Продуктовой команде и разработчикам нужно согласовать, как хранится этот идентификатор и что произойдёт, если запись станет недоступна.

Разделите запрос, активный вариант и подтверждённый выбор

Последняя строка предотвращает незаметное расхождение. Если человек заменил Studio на Supplies, а форма сохранила C-104, интерфейс показывает не те данные, которые будут отправлены. Либо представляйте выбранную запись отдельным объектом с действием «Изменить», либо точно задайте, как редактирование отменяет предыдущий выбор. Не оставляйте это поведение на усмотрение случая.

В паттерне комбинированного поля WAI-ARIA различаются редактируемые поля, допустимые значения и автодополнение с ручным либо автоматическим выбором. В этом примере человек явно подтверждает одну запись. Эти правила нельзя без изменений переносить на поля с несколькими выбранными элементами или меню команд.

Список подсказок должен соответствовать конкретному запросу

Поиск на сервере добавляет проблему порядка ответов. Пользователь вводит «North», отправляется запрос A. Затем он добавляет «s», и отправляется запрос B для «Norths». Если ответ B пришёл первым, а ответ A — позже, поле не должно заменять актуальный список устаревшими результатами для North.

Зафиксируйте эту последовательность в описании взаимодействия. Видимые варианты и количество результатов должны относиться к текущему запросу. Разработчики могут отменять ненужные запросы, игнорировать устаревшие ответы или выбрать другой надёжный способ. В макете нужно определить наблюдаемый результат, а не считать, что индикатор загрузки сам решит проблему порядка ответов.

Решите, остаются ли старые результаты на экране, пока загружаются новые. Это может сохранить контекст, но только если они не выглядят свежим ответом на новый запрос и не провоцируют случайный выбор. Для небольшого поля выбора клиента бывает проще сразу очистить список. В любом варианте нельзя показывать окончательное «Клиенты не найдены», пока запрос ещё не завершён.

Отправка запроса после небольшой паузы во вводе может уменьшить число обращений к серверу, но единой подходящей задержки для всех источников данных, устройств и задач нет. Согласуйте поведение с разработчиками и проверьте реалистичное время ожидания. Мгновенный ответ в красивом макете не должен быть единственным рассмотренным сценарием.

Отсутствие совпадений и недоступность сервиса требуют разных действий

Если поиск завершён и среди доступных пользователю записей нет совпадений, напишите точно: «По запросу „Norths“ клиенты не найдены». Оставьте запрос доступным для редактирования. Если не работает сервис поиска, сообщите, что загрузить клиентов не удалось, и предложите повторить попытку, если это возможно. Ошибка загрузки не доказывает, что клиента не существует.

Не добавляйте действие «Создать клиента» только потому, что список пуст. Создание записи — отдельная операция со своими правами, обязательными полями и правилами обработки дублей. Если приложение её поддерживает, визуально отделите её от выбора существующего клиента и возвращайте созданную запись только после подтверждения создания.

Отсутствие результата также может быть связано с ограничениями доступа. Сообщение об ошибке не должно раскрывать скрытые записи. Поиск должен возвращать только информацию, которую человек вправе получить; неактивная строка в списке сама по себе не обеспечивает контроль доступа.

Сделайте подтверждение и закрытие списка предсказуемыми

Опишите клавиатурное управление рядом с состояниями поля. В выбранном здесь варианте стрелки перемещают выделение по подсказкам, Enter подтверждает активный вариант, а Escape закрывает список, не выбирая другую запись. Tab перемещает фокус по форме согласно принятому паттерну реализации, а не делает каждую подсказку отдельной остановкой.

Пример APG с ручным выбором помогает определить взаимодействие и семантику, но не подтверждает доступность готового продукта. Финальный компонент нужно проверить в браузерах и со вспомогательными технологиями, которые поддерживает приложение.

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

Обновление результатов не должно неожиданно перемещать фокус. Если активный вариант исчез, нужен определённый способ сбросить выделение, а не оставить его на другой записи в том же месте экрана. Сообщайте о загрузке, результатах и ошибке уместно, не превращая каждый промежуточный запрос в отдельное прерывающее объявление.

Разберите последовательность состояний поля в Pixso

Создайте в файле Pixso четыре состояния поля клиента: ввод North, актуальные подсказки, выбранный Northstar Studio / C-104 и повторное редактирование без подтверждённого идентификатора. Сохраните общую структуру поля, меняя текст и обратную связь для каждого состояния. Оставьте Northstar Supplies / C-219 среди подсказок, чтобы проверяющий действительно выбирал между похожими записями.

Рядом с фреймами добавьте последовательность запросов North → Norths и отметьте запоздавший ответ для North как устаревший. Эта пометка описывает поведение проектируемого приложения для счетов, а не функцию самого редактора Pixso. Спросите коллегу, какой идентификатор будет отправлен на каждом шаге и достаточно ли просто набрать Supplies, чтобы сменить клиента.

Спроектировать выбор клиента в Pixso →

Выбор записи не отменяет финальную проверку

Между выбором и отправкой клиента могут архивировать, объединить с другой записью или закрыть к нему доступ. Поэтому итоговая операция всё равно требует проверки на сервере. Если C-104 больше нельзя использовать в этом счёте, объясните конкретную проблему и сохраните остальные поля счёта, насколько это допускают правила работы с данными.

Обновление отображаемого названия не должно незаметно выбирать другой идентификатор. Сбой такого обновления не должен стирать действующий выбор, если этого не требуют правила продукта. Определите, может ли интерфейс показывать последнее известное название во время проверки записи, и обозначьте неопределённость до подтверждения счёта.

Проверьте поле с двумя похожими названиями, медленным и запоздавшим ответом, отсутствием совпадений, ошибкой сервиса, выбором с клавиатуры, редактированием после выбора и недоступной при отправке записью. Все эти случаи отвечают на один вопрос: точно ли видимое поле представляет запись, которую приложение собирается использовать?