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

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

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

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

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

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

Что делать?

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

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

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

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

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

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

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

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

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

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

Капча

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

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

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

Фоновая музыка (она же - таймер для викторины)

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

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

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

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

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

Пример фоновой музыки для информационного навыка

Используем второй вариант из списка выше (вступительный текст, музыка для дополнительных расчётов, текст ответа):

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

Пользователь услышит собранные в один сэмпл синтез текста и указанные вами аудиофайлы (указывать каждый из них можно более одного раза, по аналогии с конкатенацией строк): текст + аудиофайл + текст.

Пример для викторины

А теперь составим более сложный и интересный паровозик: зададим вопрос, вставим таймер на половину времени ответа, дадим подсказку, запустим вторую половину таймера, и расскажем правильный ответ:

tts = "Итак, что осталось на трубе? <speaker audio='dialogs-upload/metronom30sec.opus'> Подсказка: давайте предположим, что на трубе сидело больше двух букв <speaker audio='dialogs-upload/metronom30sec.opus'> К сожалению, вы не успели ответить. Правильный ответ - буква и"

Общие примечания к разделу

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

Интерфейс загрузки аудио на момент создания статьи:

(в правой нижней части над кнопкой "Скопировать" указан URL загруженного аудио, а нажатие на кнопку скопирует этот URL в буфер обмена).

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

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

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

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

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

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

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

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

Интересный факт или сопутствующий совет

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

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

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

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

Напомним, что размещать рекламу в ответах и описании навыка запрещено, но допустимы графические рекламные RTB-блоки РСЯ.

Оптимистичный ответ

Этот подход использует Мой Секретарь. Подход спорный, но в некоторых случаях самый оптимальный. Секретарь пишет сказанное вами в календарь Google, однако API Google частенько не успевает ответить за положенные 2-3 секунды. Но навык спроектирован так, чтобы пользоваться им было удобно буквально одной фразой, без каких-либо ожиданий и дополнительных переспрашиваний. Что же делать? Решение: говорить пользователю, что всё хорошо, даже если мы пока ещё не знаем об этом.

Навык запускает процесс записи в Google параллельно формированию ответа пользователю. Если результат от Google API за 2 секунды будет получен, пользователю приходит честный ответ об успехе или провале. А если не будет получен... пользователю приходит ответ об успехе. Навык наивно надеется, что, скорее всего, записал всё правильно. При этом фейл запоминается в системе, и о нём говорится пользователю при любом следующем запросе с его стороны.

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

1. Чтобы у залогиненного пользователя каким-то образом оборвался логин в Google (токен возобновляемый, так что это редкий сценарий -- например, если вы сами разлогинили все приложения в настройках аккаунта Google). Причем, произойти это должно между входом в навык и фразой о добавлении в календарь.
2. Чтобы Google API не успел ответить за 2 секунды.
3. Чтобы пользователь при этом всём ничего не спросил у навыка в ближайшее время.

В одном крайне маловероятном сценарии навык ведёт себя плохо и непредсказуемо для пользователя. Зато в остальных 99.999% сценариев работает быстро и удобно с точки зрения UX. Использовать ли этот метод -- решать только вам.

Но главное - оптимизация навыка и данных

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

А проблему лучше не бороть мужественно на выходе, а аккуратно исключить сразу на входе.

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

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

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

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