В Telegram-боте кнопки могут выполнять разные функции. Обычная клавиатура предлагает варианты пользовательского ответа, а inline-кнопки располагаются у конкретного сообщения и работают по выбранному типу действия. Внешне оба варианта выглядят просто, но их поведение влияет на сценарий, историю разговора и обработку старых нажатий.
Выбор начинают с задачи: человек вводит ответ, открывает ссылку или меняет состояние определённой заявки? Если эти действия смешать, бот будет принимать название кнопки за свободный текст либо сохранять старые элементы управления там, где они уже не подходят. Ниже разобраны критерии выбора без привязки к библиотеке разработки.
Обычная клавиатура: подсказка для ответа
Reply-клавиатура полезна, когда человеку нужно выбрать один из допустимых ответов и этот выбор естественно выглядит как сообщение. Например, бот спрашивает предпочитаемый способ связи. Кнопки сокращают набор текста и показывают варианты, но сервер всё равно должен проверять пришедшее значение.
Пользователь может отправить другой текст, скрыть клавиатуру или вернуться к старому шагу разговора. Поэтому нельзя считать наличие кнопок доказательством корректного ввода. Если ожидается один из нескольких вариантов, обработчик сравнивает сообщение с допустимыми значениями текущего состояния и объясняет неподходящий ответ.
У обычной клавиатуры есть параметры поведения, которые следует проверять в используемых клиентах. Если после завершения шага она больше не нужна, приложение должно предусмотренным способом изменить или убрать её. Иначе человек увидит варианты прежнего вопроса рядом с новым полем и отправит ответ не по смыслу.
Inline-клавиатура: действие у конкретного сообщения
Inline-кнопки привязаны к сообщению, поэтому удобны для действий над показанным объектом: открыть подробности, перейти по ссылке или подтвердить выбранный вариант. Конкретное поведение зависит от типа кнопки. Не каждая inline-кнопка отправляет callback: у некоторых назначение — открытие адреса или иной документированный путь.
Для callback-действия сервер должен понимать, к какому объекту и состоянию относится нажатие. Название «подтвердить» без контекста недостаточно, если пользователь открыл несколько сообщений с разными заявками. Сохраните связь действия с экземпляром операции и проверьте её при выполнении.
Inline-интерфейс также нуждается в обратной связи. Пользователь должен видеть, что нажатие принято, операция выполняется или кнопка устарела. Не оставляйте бесконечное ожидание интерфейса только потому, что внешний сервис не ответил. Техническое подтверждение нажатия и окончательный результат операции — разные этапы.
Не выбирайте тип по внешнему виду
Одинаковый короткий текст можно оформить обоими способами, но результат для разговора будет разным. Если важно, чтобы выбор сохранился как пользовательский ответ в истории, reply-кнопка может быть естественнее. Если действие относится к конкретной карточке, inline-привязка часто понятнее.
Ссылку обычно стоит показывать как явный переход, а не маскировать под подтверждение заявки. Человек должен понимать, откроется ли внешний ресурс или данные будут отправлены. Название кнопки объясняет действие: «Открыть инструкцию» и «Отправить заявку» обещают разные результаты и не должны быть взаимозаменяемыми.
Не перегружайте одно сообщение множеством равнозначных вариантов. На телефоне длинные подписи могут плохо читаться, а большое число строк заставляет искать нужное действие. Если вариантов много, сначала уточните категорию или используйте подходящий интерфейс формы, вместо бесконечной сетки кнопок.
Условный пример: выбор услуги и подтверждение записи
Предположим, бот помогает записаться на консультацию. На первом шаге человеку предлагаются несколько направлений. Выбор сохраняется как ответ анкеты. После заполнения бот показывает сводку с inline-действиями: изменить сведения, подтвердить или отменить. Эти кнопки относятся именно к показанному экземпляру записи.
Пользователь замечает ошибку и выбирает изменение. Приложение переводит анкету на нужный шаг и объясняет, какие данные можно исправить. После возвращения появляется новая сводка. Нажатие старой кнопки подтверждения проверяется по актуальному состоянию и не отправляет предыдущий вариант незаметно для человека.
После подтверждения запись получает результат, а интерфейс показывает завершение. Старые действия либо обновляются, либо корректно отвечают, что операция уже выполнена. Пример описывает работу приложения; выбор типа клавиатуры лишь помогает выразить сценарий и не создаёт такую логику автоматически.
Свободный текст между кнопками
Пользователи часто отвечают на вопрос своими словами, даже если предусмотрена кнопка. Для некоторых шагов это допустимо и полезно. Например, тему обращения можно уточнить текстом. Для других требуется строгий выбор. Правило должно зависеть от смысла поля, а не от желания заставить человека пользоваться интерфейсом определённым способом.
Если свободный ответ не подходит, объясните ожидаемое действие и верните актуальные варианты. Не повторяйте всю анкету с начала. При возможности сохраните уже введённые сведения, чтобы ошибка одного шага не уничтожала работу пользователя. Это особенно важно после длинного описания или отправленного файла.
Сообщение «отмена» тоже нуждается в определённом смысле. Оно может относиться к текущему шагу, всей анкете или конкретной записи. Если команда использует одинаковое слово в разных местах, добавьте подтверждение либо ясный текст. Пользователь не должен случайно отменить готовую услугу, пытаясь только выйти из редактирования.
История и старые элементы управления
Telegram сохраняет сообщения, поэтому пользователь может вернуться к старому интерфейсу через поиск или другое устройство. Сервер должен проверять актуальность действия независимо от того, обновлены ли кнопки в последней версии экрана. Внешний вид старого сообщения не гарантирует, что операция ещё допустима.
При устаревшем действии покажите короткое объяснение и путь к текущему состоянию. Например, предложите открыть актуальную запись. Не сообщайте «ошибка запроса» без следующего шага, если ситуация ожидаемая. История разговора помогает пользователю ориентироваться, поэтому приложение должно учитывать её длительное существование.
Для необратимых действий добавляйте смысловое подтверждение. Текст должен назвать объект и последствие, а не просто спросить «уверены?». Но даже после подтверждения сервер повторно проверяет состояние и права. За время между показом сводки и нажатием условия могли измениться.
Проверка на телефоне и разных клиентах
Испытайте интерфейс на небольшом экране, в разных темах и с увеличенным текстом. Проверьте длинные подписи, возврат к предыдущему шагу и использование клавиатуры ввода. Не все проблемы видны в настольном клиенте, где широкая область скрывает неудобные переносы и перегруженные строки.
Затем пройдите сценарий без нажатия предложенных вариантов: отправьте текст, файл и повторный ответ. Приложение должно реагировать согласно правилам шага. Отдельно откройте старое сообщение после завершения анкеты и проверьте его кнопки. Такой тест выявляет зависимость от идеального поведения пользователя.
Хорошая клавиатура делает действие понятным, но не требует от человека знания внутренней логики бота. Ввод, переход и подтверждение различаются по смыслу, а сервер сохраняет контроль над состоянием. Выбранный тип кнопок должен помогать этой модели, а не заменять её визуальной условностью.
Временные ошибки без смены смысла кнопки
Если внешняя операция временно недоступна, сохраните понятный путь продолжения. Кнопка повторной попытки должна относиться к той же операции, если речь именно о повторе, а не создавать новую анкету с потерянными ответами. Перед исполнением сервер проверяет, не завершилась ли первая попытка с задержкой.
Не меняйте подпись той же кнопки на противоположное действие без ясного обновления контекста. Пользователь мог нажать её в момент смены состояния и ожидать прежний результат. Для важных изменений полезно показать актуальную сводку и получить новое подтверждение. При тестировании замедлите ответ сервиса и выполните несколько нажатий с разных устройств. Так обнаруживаются ошибки, которые не видны при быстром одиночном клике разработчика в настольном клиенте и обычной стабильной связи.
Источники
Обычная клавиатура описана в Bot API: ReplyKeyboardMarkup, встроенная — в InlineKeyboardMarkup. Разрешённые действия кнопок перечислены в InlineKeyboardButton.