После нескольких экспериментов с созданием диалога между виртуальным клиентом и виртуальным банковским ИИ я успел заметить несколько вещей.
Во-первых, делать чат с лентой снизу вверх кажется не лучшей идеей, потому что верхняя граница чата часто смещается, и это триггерит внимание. Люди так устроены, что очень хорошо реагируют на сменяющиеся картинки, а если диалог со стороны ИИ становится детализированным, то даже короткие сообщения ведут к частой смене позиций баблов сообщений.
Я подумывал отказаться от цвета, сделать все более нейтральным, но самого текста уже достаточно, чтобы эта проблема сохранялась. Поэтому кажется, что предпочтительнее делать ленту сообщений сверху вниз. В общем-то идея не новая, но иногда надо сделать большой круг, чтобы прийти к чему-то простому и обычному.
Во-вторых, сворачивание сообщений, которые возникают из-за необходимости поддерживать прозрачность рассуждений и тянуть время, кажется хорошим решением. Из плюсов, можно сохранять сценарий на одном экране долгое время. Из минусов, очевидное прыгание высоты при сворачивании, но, когда постинг идет сверху вниз, это уже не так бросается в глаза.
В-третьих, в ленте не надо оставлять сообщения, которые были вопросами или требовали пользовательского выбора. У меня первоначально кнопки оставались как часть истории, но очевидно, что глаз за них цепляется, если просматривать историю повторно, и это мешает.
В-четвертых, после использования перекрывающих чат сообщений, в этом сценарии это bottom sheet, при возвращении к ленте чата теряется внимание. Фактически невозможно сразу попасть в то место, где ты был до перекрывающего сообщения. Надо искать глазами, что явно повышает когнитивную нагрузку. Это маленькая, но важная задача, и я бы потратил время на поиск хорошего решения.
Из того, что мне кажется можно попробовать: добавлять текущему активному пункту больше яркости, чтобы он условно переливался, или поднимать контент выше, чтобы после возвращения последний пункт стоял посередине экрана. Второй вариант кажется мне более рабочим, потому что там внимание будет фокусироваться на нужном месте и за счет позиции на устройстве, и за счет отступа от нижней части, и за счет того, что это последний пункт в списке.
Ну и в-пятых, первоначально я задумал верхний блок как навигатор для сценария, чтобы вверху экрана фиксировать текущую задачу и отмечать этапы ее выполнения. Но сценарий получился коротким, все сообщения помещаются на экран без прокрутки, и, казалось бы, можно обойтись без верхнего блока. Но, на мой взгляд, он хорошо работает как отдельный акцент на сообщении об успешном завершении выполнения задачи. Моя идея в том, что, когда вы отдельно от чата выделяете ключевое событие, это дает дополнительный буст к привлечению внимания к этому сообщению.
Правда, с этим верхним сообщением не все еще гладко. Там куча кейсов, как оно должно себя вести, ответы на которые я пока не знаю. Но было бы желание, а решения найдутся.
В планах — продолжать играться со сценариями для голосовых интерфейсов. Хочу посмотреть, рабочая ли это вообще вещь, а для этого надо попробовать сделать еще парочку сценариев.
У меня в очереди стоит что-то типа: «Посмотри, какие ОФЗ сейчас дают выше 14% — хочу взять тысяч на 300, желательно с погашением не раньше 2027», «Уточни у банка, можно ли изменить время инкассации с 18:00 на 20:00 — магазины закрываются поздно, кассиры ждут». Полагаю, они будут длиннее, и возникнет необходимость в новых вариантах сообщений и типах данных. Если руки дойдут, потом расскажу, что получилось.
И немного деталей реализации. Сборка всего и отдельных элементов — это Figma. Для сценария чата я использовал HTML с библиотекой GSAP, которая отвечает за анимацию. Весь код собран в Claude.
Для чата использованы четыре типа сообщений. В текущем примере видны, правда, только три из них. Для одного из типов сделан свободный настраиваемый шаблон, чтобы можно было использовать произвольные элементы, такие как bottom sheet или модальное сообщение.
Текст можно публиковать в новый бабл, добавлять в текущий или заменять последнее сообщение, можно сворачивать бабл. Такого набора операций хватает, чтобы сделать поток сообщений управляемым и с возможностью компактного отображения.
С позиции построения диалога я сейчас учитываю несколько шагов: определение намерения (что пользователь хочет сделать), определение сущностей (кто, что, где и т.д.), восстановление контекста (достроить пользовательскую фразу, чтобы был полный смысл без сокращений), использование прописанных навыков (то есть в итоге нужен набор правил, который бы задавал логику и определения для базовых операций: «перевод денег», «лимиты» и т.д.), оценка уверенности и неопределенности (возможность остановить сценарий или запросить дополнительную информацию, когда невозможно уверенно выполнить действие), работа с памятью и ее обновление (типичные операции, формулировки запросов с результатами — все это надо сохранять в памяти, чтобы облегчить повторное выполнение), подтверждение результата (тут двоякая ситуация, надо либо акцентированно подтверждать, что все сделано, либо объяснять, что не сделано и почему).
Честно говоря, было интересно готовить этот маленький экспериментальный прототип, потому что под поверхностной простотой оказывается прорва деталей и нюансов. И хоть для меня это привычная ситуация, но, вглядываясь в глубину вариантов решений и нерешенных задач, я начинаю сомневаться, лезть ли во все это просто ради интереса.