Писать энциклопедическую статью с картинками и кодом, честно говоря, лень. Возможно, буду делиться наработками по мере обсуждения. Получилась статья на минималках, исключительно ради обратной связи от таких же начинающих внедренцев ТГ-бота, как и я.
1. Преимущества ТГ Бота (в сравнении с мобильным приложением):
-
Не надо создавать приложения для нескольких ОС. Не надо тестировать на разных устройствах (на самом деле надо, но это связано с разной геометрией экранов). Не надо размещать релизы на разных площадках. Не надо следить за стандартами Google, Apple, Microsoft.
-
Мгновенное развертывание для всех пользователей. Не надо придумывать дополнительные механизмы для принудительного обновления.
-
Широкая совместимость с разнообразными устройствами и ОС.
-
Уже встроенная поддержка популярных media-функций, типа обмен файлами, фото, видео, голос, геопозиция, онлайн-оплата
-
Диалоговый интерфейс интуитивно понятный и естественный для большинства неискушенных пользователей, против оконного интерфейса.
-
ТГ быстрый и не занимает много места. Например, 1С-приложение весит от 150Мб, т.к. несет в себе компилятор всего фреймворка.
-
Готовая альтернатива электронной почте.
-
Можно работать с конфиденциальной информацией. Благодаря авторизации по телефону имеем почти стопроцентную уверенность, что адресат - наш человек.
-
Можно встраивать свои приложения на JavaScript
2. Недостатки:
-
Telegram Messenger попадает под политику импортозамещения. По слухам в госучреждениях и госкорпорациях формально уже запрещен. Если конечно ТГ вдруг не разместит серверы на территории РФ. Так что работаем здесь и сейчас, не строя особо далеко идущих планов. Хотя есть надежда, что физическую блокировку вообще делать не будут, ограничатся штрафами. Да и включать репрессии начнут разумно, при наличии достойной альтернативы.
-
Диалоговый интерфейс - это одновременно и минус. Есть ограничения (о них ниже). Не всё можно показать так просто, как в оконном интерфейсе, приходится придумывать нестандартные ходы.
-
ТГ любит постоянный Интернет, а мобильное приложение некоторое время может поработать в оффлайне. Но тут зависит от того, какие требования по оперативности предъявляет конкретный бизнес. Никто не мешает пользователю лазить под землей, что-то там писать и фоткать. А при первом выходе на поверхность отложенные сообщения улетят на сервер автоматом.
-
В отличие от электронной почты ТГ Бот довольно строго соблюдает правила проникновения в частную жизнь. Бот не может делать рассылки незнакомым пользователям, даже если известен их id. Знакомство происходит по инициативе пользователя - он хотя бы раз должен отправить сообщение в чат-бот. Этого ограничения нет в API клиента, там ты выступаешь от лица пользователя, хотя можно отхватить бан за подозрение в спаме. В среде 1С был один энтузиаст 5 лет назад (Telegram Native API), который упаковал TDLib во внешнюю компоненту 1С, но его никто не поддержал, и он соскочил с темы. Ведь компоненту надо регулярно пересобирать под новые релизы ТГ, чтобы она оставалась жизнеспособной.
3. Что интересного удалось раскопать:
-
ТГ по сути является файловым хранилищем - один раз принятый или отправленный файл не обязательно хранить у себя, достаточно запомнить его id и дальше на него ссылаться. ТГ хранит файлы почти без ограничений по времени и объему.
-
Отображать файлы лучше всего компактными пачками максимум по 10 штук (sendMediaGroup) - это выглядит стильно!
-
Работа с ТГ-сервером методом long polling имеет ряд преимуществ перед web hook. С точки зрения безопасности: не надо открывать свой сервер всему миру. С точки зрения быстродействия: висящий в режиме ожидания http-запрос к ТГ-серверу сработает быстрее, чем запуск http-сервиса в 1С-базе по внешнему обращению. Кто-то спросит, а как же асинхронная обработка? Отвечу - а кто мешает обрабатывать каждое сообщение в отдельном ФЗ. И еще спрошу: а когда пользователь отправляет одновременно пачку фоток, как вы их объединяете в одно сообщение, когда они приходят разными запросами в случае с web hook? (PS. Реакция зрачка евангелистов вебхуков показала их категорическое несогласие с моими доводами (см обсуждение). Ну что ж, хорошо когда есть выбор!)
-
ТГ бот помимо обычных кнопок (ReplyKeyboard), которые прикрепляются внизу экрана и не проматываются, может обрабатывать нажатие inline-кнопок, которые прикрепляются непосредственно к сообщению. При этом можно перерисовывать сообщение, из которого пришло нажатие - внешне это выглядит достаточно гладко, чтобы создалось впечатление открытия нового окна на том же месте.
-
Но у inline-кнопки есть недостаток - ограниченное место для текста: в лучшем случае не более ширины экрана. Это если размещать кнопки в один ряд. И нельзя переносить текст на следующую строку. Например, для каталога товаров это не подходит, часть описания будет обрезана. Но есть выход: размещать список в обычном тексте, а для открытия карточки товара в качестве ссылки использовать конструкцию типа /U1234 или даже просто числа /123123. ТГ-клиент обрабатывает тап на команду в тексте так, как если бы пользователь сам набрал ее с клавиатуры и отправил. Дальше нужно просто обработать текст полученного сообщения как уникальный идентификатор и вернуть карточку справочника или документа. Такой метод также можно рекомендовать для выдачи списка команд, если он должен подстраиваться под быстро меняющиеся обстоятельства, взамен стандартного меню.
-
Тап на команду в тексте смещает фокус экрана в самый низ - что, как по мне, тоже преимущество перед inline-кнопкой. Конечно же только в случае, если нажатие inline-кнопки должно вызывать новое сообщение, а не перерисовку существующего. Ведь пользователю никто не мешает прокрутиться далеко вверх, найти там старое сообщение с кнопками, и начать их тыкать. Вы ему в ответ шлете сообщения вниз, но он их не видит, разве что неприметное оконце с количеством новых сообщений.
-
Запрашивать у пользователя ввод текста или файлов можно через команду принудительной цитаты (ForceReply), полученный результат будет содержать ссылку на цитируемое сообщение. Но это смотрится громоздко. Более естественно выглядит сопоставление входящего текста с последним отправленным сообщением. Но для этого надо сохранять в БД историю всех исходящих сообщений. Бот не может повторно прочитать содержимое экрана, он обрабатывает только входящие события. Поэтому интерпретация полученного сообщения отдана на откуп программисту, сам ТГ-бот никаких методов на этот счет не предлагает.
-
В одном проекте была задача распознавать голосовые сообщения в текст. Как-то глупо было требовать от сантехника натыкивать “когтистой лапой” отчет о проделанной работе. Я не стал дожидаться выхода стабильной версии платформы 1С 8.3.23, где это уже есть. И не стал тратить время на обучение пользователей Android, как установить себе что-то типа Яндекс-клавиатуры. Сантехников с iPhone, где эта функция уже штатная, я не смог нарисовать в своем воображении. Поэтому воспользовался платным сервисом SaluteSpeech от Сбербанка. Не сочтите за рекламу, но объективно у них хорошая среда для разработчика, куча примеров на Postman, достаточно большой лимит бесплатного времени для тестирования распознавания, и само распознавание идет неплохо, даже пунктуацию расставляет.
-
В одном проекте заметили, что система время от времени перестает отвечать, как будто пропускает команды. Выяснилось, что сам провайдер по неведомой причине режет 5% запросов к https://api.telegram.org/. Причем ошибка прилетает стабильно на 22 секунде http-запроса по таймауту. Команда pathping сразу показала, на каком узле это происходит. Но для убедительности сделали тестовый стенд на 1С, отправляющий каждые 0,1 сек запросы, и уже готовы были сделать его аналог на Postman. Как вдруг ошибка из тестового стенда ушла, хотя pathping показывал те же 5% потерь. Думаю, провайдер тянул время, пока разбирался. Бывает.
-
Когда пользователей много, остро встает вопрос обучения. Начитавшись статей про UX/UI, понял только что интерфейс должен быть интуитивно понятным, и что никто не читает мануалы и не смотрит обучающие видео. Даже простейшая инфографика откладывается напотом, и когда надо не находится. Ну и прежний опыт доказал, что всё это баловство руководству лишь для галочки. Знающие люди посоветовали подпушивание - периодически слать пользователю ободряющие сообщения в зависимости от того, где он застрял. Например, пользователь самостоятельно нашел в поиске ваш бот и даже догадался нажать кнопку Запустить. Система выдала ему предложение отправить свой телефон для авторизации. Прошло пять минут бездействия - отправляем ему что-то типа “Спасибо что зашли! Теперь система должна Вас узнать, для этого нажмите кнопку “Отправить свой номер телефона” и подтвердите кнопкой “Поделиться”. Можно даже скриншот приложить для убедительности. Такие контекстные подсказки смотрятся как диалог с живым человеком, будто кто-то следит за твоими действиями и помогает советом по существу. Поверьте, это то единственное, что пользователь прочтёт и вникнет. Проверено - работает!
-
Для выбора значений из списка неограниченной длины можно использовать механизм inline-запросов. Я подсмотрел это у ВкусВилла: @VkusVillBot. В нём, если нажать кнопку “Искать по названию” (Главное меню - Каталог), в строке пользовательского сообщения появляется команда “@VkusVillBot Товар: “ и выпадает список с картинками и названиями товаров. В строке сообщения можно дописывать уточняющие слова для сужения круга поиска. При выборе позиции появляется сначала сообщение с названием товара как бы от вашего имени с заголовком “через @VkusVillBot”. А затем бот высылает карточку товара с кнопками. Я начал активно использовать inline-запросы в своих проектах, и выяснил, что список может содержать не только картинки, но и обычный текст. И что самое замечательное, такой список может поддерживать пагинацию - выдавать страницы по 50 позиций, а при пролистывании ближе к концу последней страницы подгружать следующую. Единственное ограничение: клиентские приложения в зависимости от геометрии устройства сами решают сколько символов выводить в каждой позиции списка, так что текст позиции должен быть максимально сжатым и информативным. И тем не менее такой механизм существенно расширяет спектр решаемых задач в ТГ боте. Например, можно заполнять поля нового документа (см скриншоты).
