Если навыку на ответ надо больше 3 секунд...

Порой возникают ситуации, когда навык не укладывается в необходимые 3 секунды. Данный материал ставит целью помочь разработчикам навыков в решении этой проблемы.

Почему долго ждать – это плохо

Иногда в комьюнити разработчиков возникают вопросы: а почему бы не увеличить лимит ожидания? В пример приводятся «нормативы» в признанных системах, давно существующих на рынке – и 7, и даже 10 секунд. Но эти системы формировались намного раньше, в худших технических условиях, в старых стандартах юзабилити, и по этим (или другим, собственным) причинам дали такие большие паузы на ответ. Сегодня же совместимость с изрядно обросшей экосистемой против людей, которые всё более нетерпеливы, скорее стала не плюсом, а наоборот - т.н. "legacy" грузом и для системы и для её пользователей.

Посмотрим с другой стороны. Как уже давно известно, пользователь покидает сайт, если не обнаружил нужную ему информацию в среднем за 7 секунд. А ведь при этом он отвлекается и на баннеры, и на иллюстрации, и сопутствующие тизеры. Не говоря уже о соседних вкладках браузера. Ничего этого в голосовом интерфейсе нет. Только тишина, в которой пользователь ощущает себя идиотом, не понимающим, работает ли навык, или завис, или вообще выпал.

То же со стороны разработчика. Как думаете, что будет, если почти в 3 раза увеличить время ответа, в масштабах системы? Будет ли большинство разработчиков добросовестно стремиться уложиться в минимум, зная, что у них впереди целых 7 секунд? Вряд ли. Скорее всего, основным результатом станет падение динамики общения, общая деградация навыков и неизбежная потеря интереса к ним со стороны пользователей, в чём уже совсем никто не заинтересован. Конечно, со временем эта проблема исчезнет сама собой, если протокол станет асинхронным (хотя бы частично, в плане обновления ответа во время процесса его выдачи). Но как лучше поступить прямо сейчас?

Что делать?

Единого решения, как "развлечь" пользователя во время длительного ожидания, нет.

• Во-первых, ситуаций и контекстов очень много, и только автор для своего конкретного случая может выбрать верный способ (и порой только после тестирования на пользователях).
• Во-вторых, навык может зависеть от внешнего сервиса и не знать заранее, как долго будет возвращать результат этот внешний сервис. Да и разброс времени возврата может быть довольно большим.
• В третьих, критична важность ответа навыка для пользователя. Если пользователь не согласен несколько лишних секунд ждать ответа от калькулятора, то для расчёта оптимальной цены на авиабилет и минута может оказаться приемлемой.
• В четвёртых, сам характер навыка (игра, онлайн-оплата, доступ к информационному сервису) играет немалую роль в том, как именно сделать паузу комфортной для пользователя.

Приведём несколько примеров (больше натолкнуть на новую и лучшую идею, чем дать какой-то "идеальный" вариант).

Итак, как лучше замаскировать ожидание?

Перезвоните через пару минут

Самое простое, казалось бы. Но и тут есть несколько подводных камней:

• Не стоит дополнительно озадачивать пользователя, давая ему строгий интервал ожидания ("Подождите 8 секунд", "Ответ будет готов через 2,5 минуты"). И сам ответ лучше построить дружелюбно: скажите
  • "Я подготовлю ответ через несколько секунд, только спросите меня: Алиса, готово?",
  • "Уточняю информацию, спросите меня через минутку: Алиса, как у нас с парковкой/нашлись билеты?".

• Если дать достаточно длительное время ожидания, то:
  • пользователь может и забыть, что он в навыке.
  • к колонке обратится другой член семьи, не зная об активном навыке.
  • за это долгое время навык сам закроется.

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

В плюсах – это самый лёгкий в реализации способ. В минусах – всё перечисленное выше.

Капча

Часть решений переносит в голосовой интерфейс хорошо известные элементы интерфейса графического. Например, в каталоге существует навык, который просит пользователя решить простой математический пример, как аналог капчи на сайтах. Многие пользователи с пониманием относятся к ним, понимая это как защиту от злоупотреблений или попыток нарушить работу сервиса. При этом настоящая причина – необходимость дополнительного времени для формирования ответа – остаётся в тени и не создаёт негатива. Кому-то может и понравиться между делом слегка размять мозг.

В минусах – есть пользователи, которые капчи ненавидят (правда, в основном за их повысившуюся сложность; простые капчи их не отталкивают).

Кстати, в упомянутом навыке капча даже не валидируется (можно сказать всё, что угодно) :)

Фоновая музыка

Ваш звонок очень важен для нас... И да, такой вариант имеет полное право на жизнь.

Негромкий успокаивающий аудиотрек (или метроном, или шум вокзала, по ситуации), и паузу «протянуть» поможет, и создаст у пользователя приятный эффект присутствия в той или иной обстановке.

Важно добавить текстовое пояснение до запуска фона, либо - что лучше - и в начале и в конце, например:

• «Мне понадобится немного времени на расчёты. Как только доиграет музыка – спросите меня “Алиса, готово?”» (начинается трек).
• «Мне понадобится немного времени на расчёты... (звучит трек) ...я готова озвучить ответ. Начинаю?"

Вторым вариантом мы напоминаем пользователю, что происходит, и одновременно наводим его на правильные ожидаемые нами формы запроса.

Технически это выглядит так:
Через несколько секунд я подберу лучшие варианты <speaker audio="dialogs-upload/relax-railways.opus"> мой ответ готов. Продолжим?

Все аудиофайлы (в примере условное название "relax-railways.opus") должны быть заранее загружены через платформу Диалоги, а затем их URL скопированы из вкладки "Ресурсы" -> "Звуки" и вставлены в соответствующие фрагменты кода аналогично примеру выше.

И конечно, навык должен уметь обработать ситуацию, когда нетерпеливый пользователь переспросил слишком рано, сообщив о продолжении работы над ответом и перезапустив музыкальный (шумовой) фон.

«Индикатор прогресса»

Ещё один аналог широко известного GUI-элемента получится, если к предыдущему варианту с фоновой музыкой добавить озвучку диктором этапов, которые навык обрабатывает в данный момент:

• Соединяемся с внешней базой данных...
• Передаём запрос...
• Ожидаем ответ...
• Ещё пару секунд...
• ...готово! Для продолжения скажите "Дальше".

Такой способ решает сразу несколько задач:

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

В плюсах: кажется, максимально комфортное решение для пользователя.

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

Оптимизация навыка и данных

Да, банально, но – хороший хостинг, оптимизацию кода и запросов, сокращение внешних зависимостей никто не отменял.

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

Будет хорошо замерять время прихода ответа и, если он успел вовремя (до "точки невозврата") – сразу отдать его пользователю. И только в случае сильного запоздания отклика от стороннего сервиса – запустить сценарий ожидания.

Может показаться полезным вынести заранее извинения о нестабильности времени ответа в "Помощь", рассказав о тяготах жизни бота, но это сомнительное решение по ряду причин:

• Пользователь на самом деле может и не испытывать дискомфорта при хорошо построенном UX. Зачем заострять на этом внимание?
• Ряд пользователей (включая автора этой статьи) воспримет такое пояснение как неспособность навыка работать качественно. Хотя найдутся и те, кто воспримет его с пониманием.
• Неприятный психологический момент для самого разработчика, который может испортить мотивацию и по улучшению навыка, в котором он заранее расписался в бессилии, и вообще к разработке сложных навыков в будущем.