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

Материал из База знаний
Перейти к навигации Перейти к поиску



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


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

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

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

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


Что делать?

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

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

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

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


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

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

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


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

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

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


Капча

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

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

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


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

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

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

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

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

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

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

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

Диалоги - загрузка аудиофайла.jpg


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


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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

  • Пользователь на самом деле может и не испытывать дискомфорта при хорошо построенном UX. Зачем заострять на этом внимание?
  • Ряд пользователей (включая автора этой статьи) воспримет такое пояснение как неспособность навыка работать качественно (хотя найдутся и те, кто воспримет с пониманием).
  • Неприятный психологический момент для самого разработчика, который может испортить мотивацию и по улучшению навыка, в котором он заранее расписался в бессилии, и в целом к разработке сложных навыков.
Источник — https://wiki.yaboard.com/index.php?title=Если_навыку_на_ответ_надо_больше_3_секунд...&oldid=5163 // MOD ext links // End MOD