Каталог, объявления или мессенджер на Bubble: как спроектировать данные и экраны

← Все подборки материалов

No-code · 3 материала

Начните проект на Bubble с главного действия пользователя. Для каталога это выбор предложения, для доски объявлений — публикация и поиск, для мессенджера — обмен сообщениями. От этого действия зависят структура данных, страницы и проверки доступа. Ниже — три модели, по которым можно набросать схему приложения до сборки интерфейса.

3 материала по задачеПерейти к инструкциям ↓
В этой подборке

Материалы подборки

Выберите инструкцию под свою задачу. Ниже — подробный разбор выбора и проверки результата.

Перед сборкой подпишите связи словами: клиент оформляет заказ, заказ относится к туру, сообщение входит в чат. Затем проверьте, что у каждой связи есть понятное направление. Если две разные сущности объединены в одну таблицу только ради удобства первого экрана, попробуйте описать их жизненный цикл отдельно: кто создаёт запись, кто меняет и когда она перестаёт быть актуальной.

Сначала определите, что хранит приложение

Нарисуйте не экраны, а связи между объектами. В каталоге турагентства пользователь выбирает тур и создаёт заказ; отзыв относится к конкретному туру. На доске объявлений автор публикует предложение, а другой пользователь находит его и связывается с автором. В мессенджере сообщение должно относиться к определённому чату. Похожая кнопка «Отправить» в этих приложениях создаёт разные записи.

Модель Основные сущности Первый рабочий маршрут
Каталог туров Тур, клиент, заказ, отзыв Поиск → карточка тура → заказ
Объявления Пользователь, объявление, сообщение Публикация → выдача → связь с автором
Мессенджер Пользователь, чат, сообщение, контакт Выбор собеседника → чат → сообщение

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

Превратите схему в набор экранов

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

Например, у объявления есть автор, заголовок и описание. На публичной карточке посетитель читает предложение, а в кабинете автор редактирует его. В учебной схеме запишите, какая запись изменяется после нажатия каждой кнопки. Это позволяет заметить ошибки до настройки workflow: кнопка сохранения объявления не должна создавать новый профиль пользователя.

Как проверить прототип

  • Создайте два тестовых пользователя и несколько различающихся записей.
  • Пройдите основной маршрут от входа до видимого результата.
  • Проверьте пустой поиск, незаполненную форму и повторное нажатие кнопки.
  • Убедитесь, что заказ ссылается на выбранный тур, а сообщение — на нужный чат.
  • Отдельно проверьте, может ли второй пользователь изменять чужую запись.

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