Требования к элементам

По чему проверяют

Ниже — критерии, по которым команда проверки оценивает элементы, отправленные в маркетплейс FlutterFlow. По каждому: что требуется, зачем это нужно и что сделать.

1. Оригинальность и права

1.1 Права на проект

• Требование. Права на отправляемый проект должны принадлежать вам.
• Почему. Делиться работой и продавать её вправе только автор. Это защищает интеллектуальную собственность и держит площадку честной.
• Что делать.
  • Если автор один — отправляйте проект со своего аккаунта FlutterFlow.
  • Если работали вместе — заявку подаёт владелец проекта. Договоритесь об этом заранее.
  • Если проект вам передали — убедитесь, что права владельца переданы официально. Возможно, потребуются документы.

1.2 Существенная переработка

• Требование. В проекте должна быть заметная собственная работа.
• Почему. Косметические правки чужого проекта не добавляют площадке ничего нового.
• Что делать.
  • Покажите, какие компоненты, возможности и решения вы сделали сами.
  • Если правки только визуальные — поменяли цвета и логотип, — добавьте что-то по существу.

1.3 Не переделка чужого элемента маркетплейса

• Требование. Проект не должен быть производной от уже опубликованного элемента.
• Почему. Дубликаты обедняют каталог: покупателю нужен выбор, а не десять одинаковых шаблонов.
• Что делать. Вдохновляйтесь чужими работами, но делайте своё: собственный стиль, свои возможности, своя логика.

1.4 Не переделка учебного примера

• Требование. Слегка изменённые примеры приложений от FlutterFlow не подходят.
• Почему. Примеры — учебный материал; элемент маркетплейса должен быть сложнее и самостоятельнее.
• Что делать. Берите пример за отправную точку и развивайте: собственный код, сложные анимации, полезные вызовы API.

1.5 Оригинальное содержимое

• Требование. Тексты, изображения и оформление должны быть вашими или лицензированными для коммерческого использования. См. юридические правила и лицензии сторонних площадок.
• Почему. Чужой материал без разрешения — прямой путь к жалобе и снятию элемента.
• Что делать.
  • Делайте материалы сами — это надёжнее всего.
  • Берите свободные ресурсы и код с подходящей лицензией; см. открытые лицензии.
  • Если покупаете платные материалы, проверьте, разрешает ли лицензия коммерческое распространение. Здесь легко ошибиться — см. лицензии сторонних площадок.

1.6 Библиотека без зависимостей от других библиотек

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

2. Карточка элемента

По карточке покупатель решает, подходит ему элемент или нет.

2.1 Всё на английском

• Требование. Название, описание, метки и остальные сведения — на английском.
• Почему. Площадка международная, и понимать карточку должны все.
• Что делать. Пишите просто и коротко. Если английский неродной, помогает встроенный перевод FlutterFlow.

2.2 Внятное название

• Требование. Название короткое, понятное, без грамматических ошибок.
• Почему. Это первое, что видит покупатель.
• Что делать. Держите его кратким, вставьте слова, по которым элемент будут искать, и вычитайте текст.

2.3 Уникальное название

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

2.4 Внятное описание

• Требование. Описание написано грамотно и по делу.
• Почему. Из него покупатель понимает возможности элемента и то, для чего он.
• Что делать.
  • Начните с сути: что элемент делает.
  • Ключевые возможности — списком, чтобы текст читался по диагонали.
  • Пишите о пользе: какую задачу элемент решает.
  • Вычитайте текст.

2.5 Достоверное описание

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

2.6 Сторонние сервисы

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

2.7 Понятная инструкция

• Требование. Инструкция и документация написаны так, чтобы им можно было следовать.
• Почему. От этого зависит, соберёт ли покупатель проект без обращений в поддержку.
• Что делать.
  • Пишите для человека, который видит и ваш элемент, и FlutterFlow впервые.
  • Разбивайте сложное на нумерованные шаги.
  • Добавьте ссылку на видеоразбор или на письменную документацию.
  • Дайте кому-нибудь пройти инструкцию — станет видно, где непонятно.

2.8 Точные метки

• Требование. Метки отражают категорию, возможности и назначение элемента.
• Почему. По ним элемент находят через поиск маркетплейса.
• Что делать. Думайте словами покупателя. Сочетайте общие метки («e-commerce», «social media») с точными («shopping cart», «user authentication») и не ставьте лишних.

2.9 Качественные изображения

• Требование. Изображения чёткие и показывают оформление и работу элемента. Обложка — не меньше 1200 × 800 пикселей с соотношением сторон 1,5.
• Почему. Это первое впечатление.
• Что делать. Покажите главные экраны и возможности, не берите размытые кадры, держите единый стиль и одинаковые размеры.

2.10 Изображения соответствуют элементу

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

2.11 Без логотипа FlutterFlow

• Требование. Логотипа FlutterFlow на обложке быть не должно.
• Почему. Он создаёт впечатление официального шаблона, а кроме того, попросту избыточен: все элементы и так продаются только в маркетплейсе FlutterFlow.
• Что делать. Уберите логотип из изображений.

3. Оформление

3.1 Уровень дизайна

• Требование. Оформление сделано по правилам: удобство, доступность, аккуратный вид.
• Почему. Хороший интерфейс не только приятно выглядит — по нему понятно, куда нажимать.
• Что делать.
  • Ставьте удобство выше украшений.
  • Стройте зрительную иерархию размером, цветом, контрастом и отступами.
  • Держите единообразие: цвета и шрифты темы, одинаковые отступы, интервалы в списках, скругления и элементы навигации.
  • Дайте кому-нибудь попробовать — станет видно, где интерфейс сбивает с толку.

3.2 Работа на разных экранах

• Требование. Раскладка приспосабливается к разным размерам экрана.
• Почему. Приложение на Flutter ожидаемо должно работать и на маленьком телефоне, и на большом мониторе.
• Что делать.
  • Используйте Wrap, Responsive Visibility и Flex — см. адаптивную раскладку.
  • Проверяйте на виртуальных устройствах в Test и Run Mode и меняйте размер холста прямо в редакторе.

4. Возможность попробовать

Прежде чем купить, покупатель хочет посмотреть, как элемент работает.

4.1 Рабочая ссылка на Run Mode

• Требование. Ссылка на Run Mode работает и открывает действующую демонстрацию. Если возможности элемента доступны только на мобильных устройствах или их вообще нельзя показать в вебе, нужен другой способ демонстрации.
• Почему. Это единственный способ пощупать элемент до покупки.
• Что делать.
  • Обычный элемент, работающий в вебе: проверьте ссылку перед отправкой и откройте её несколько раз — она должна работать стабильно.
  • Возможности только для мобильных: сделайте в проекте отдельную страницу-демонстрацию с описанием, снимками экрана или видео и прямо укажите, что именно работает только на устройстве и почему. Можно приложить ссылку на опубликованную веб-версию вместо Run Mode.
  • Служебные библиотеки (аналитика, фоновые задачи): сделайте страницу с объяснением работы библиотеки, покажите настройки и ожидаемый результат, добавьте схемы, примеры кода и отладочный вывод, по которому видно, что она работает.
  • Документация: в любом случае объясните, как подключить и проверить элемент на настоящем устройстве, и опишите типовые проблемы.

4.2 Вход без регистрации

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

4.3 Доступная навигация

• Требование. До всех страниц и разделов проекта можно дойти.
• Почему. Сломанная навигация раздражает и мешает оценить элемент.
• Что делать.
  • Задайте правильную стартовую страницу: Settings → App Details → Entry Page определяет, куда попадает пользователь по ссылке Run Mode.
  • Посмотрите Storyboard — там видны переходы между страницами. Недостижимые страницы в нём не отображаются.
  • Пройдите в Run Mode по каждой кнопке, ссылке и пункту меню.

4.4 Всё работает

• Требование. Основные возможности элемента должны работать.
• Почему. Сломанное производит впечатление недоделанного проекта.
• Что делать.
  • Проверьте всё: нажатия, отправку форм, вызовы API, анимации.
  • Не ограничивайтесь удачным сценарием — попробуйте неверные данные и крайние случаи.
  • Дайте посмотреть человеку со стороны.

5. Качество сборки

5.1 Без ошибок

• Требование. Ни ошибок во время работы, ни падений, ни странного поведения.
• Почему. Ошибки в демонстрации сразу закрывают вопрос о покупке.
• Что делать.
  • Не отправляйте проект с ошибками и разберите большую часть подсказок по оптимизации на верхней панели.
  • Пользуйтесь панелью отладки FlutterFlow.
  • Обрабатывайте null и сбои: задавайте значения по умолчанию и добавляйте в цепочки действий ветки на случай ошибки API.

5.2 Без выхода за границы

• Требование. Содержимое не должно вылезать за пределы контейнера.
• Почему. Обрезанные надписи и полосатые полосы переполнения — признак того, что раскладка собрана на жёстких размерах. Заметнее всего это на нестандартных экранах.
• Что делать.
  • Включите показ переполнения значком в правом верхнем углу холста.
  • Пользуйтесь Expanded и Flex, делайте Column и Row прокручиваемыми, включайте автоподбор размера текста или обрезку, убирайте жёстко заданные ширину и высоту там, где они не нужны.
  • Меняйте размер холста по ходу работы.

5.3 Собственный код без ошибок

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

5.4 Код по делу

• Требование. Собственный код должен решать конкретную задачу. Неиспользуемому и лишнему коду в проекте не место.
• Почему. Избыточный код тяжелее читать, поддерживать и обновлять.
• Что делать.
  • Сначала проверьте, нельзя ли обойтись встроенными возможностями FlutterFlow.
  • Комментируйте: зачем этот код и как он работает.
  • Разбивайте сложную логику на небольшие функции. Если функция короткая и нужна один раз, лучше использовать блок кода.

5.5 Код можно проверить в Run Mode

• Требование. То, что делает собственный код, должно быть видно в демонстрации.
• Почему. Иначе покупатель не поймёт, за что платит.
• Что делать. Сделайте страницу, где код применяется по назначению — в идеале с возможностью менять параметры прямо в Run Mode. Если для проверки нужны особые шаги, опишите их в описании или документации.

5.6 Правила Firestore

• Требование. Если проект работает с Firestore, правила безопасности должны быть настроены.
• Почему. Открытые правила выставляют наружу данные всех, кто возьмёт ваш шаблон.
• Что делать. Разберитесь, как FlutterFlow работает с правилами Firestore, и настройте их в базовом проекте. Проверьте: заведите тестовые аккаунты и попробуйте добавить, изменить и удалить данные в разных состояниях авторизации.

5.7 Орфография и грамматика

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

5.8 Шаблон удобно дорабатывать

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

5.9 Подходящая область состояния

• Требование. Состояние должно обновляться и отображаться правильно.
• Почему. От этого зависят и согласованность данных, и быстродействие.
• Что делать.
  • Выбирайте нужную область: App State, Page State или состояние компонента. Значение флажка внутри компонента не место в App State.
  • Следите, чтобы изменение состояния перестраивало только то, что нужно.

5.10 Аккуратное дерево виджетов

• Требование. Дерево виджетов должно быть структурированным.
• Почему. По понятному дереву проще ориентироваться и вносить правки, и в нём меньше ошибок.
• Что делать. Давайте узлам говорящие имена. Если вложенность перевалила за десяток уровней, выносите части в компоненты.

5.11 Общепринятые приёмы FlutterFlow

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

5.12 Поменьше статичных картинок

• Требование. Не заменяйте интерфейс большими неоптимизированными картинками.
• Почему. Они утяжеляют приложение и тормозят загрузку на медленной сети. Хуже того, они вводят в заблуждение: картинка карты или формы оплаты выглядит как готовая возможность, а на деле по ней нельзя нажать.
• Что делать.
  • Собирайте работающие элементы вместо картинок — так интерфейс останется живым на любом экране.
  • Сжимайте изображения без потери качества.
  • Включайте кэширование для изображений из сети.

5.13 Поменьше собственного кода

• Требование. Делайте максимум встроенными средствами редактора.
• Почему. Чем больше собственного кода, тем труднее шаблон поддерживать и дорабатывать.
• Что делать. Прежде чем писать код, посмотрите, нет ли готового виджета, действия или интеграции.

5.14 Компоненты вместо копирования

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

5.15 Library Values в библиотеках

• Требование. Ключи и настраиваемые значения в библиотеке должны быть вынесены в Library Values.
• Почему. Так пользователь подставит свои ключи API и настройки, не трогая саму библиотеку. Это и безопаснее, и удобнее.
• Что делать.
  • Найдите в библиотеке всё, что пользователю нужно менять: ключи, адреса, параметры.
  • Заведите для них Library Values в Settings → App Settings → Publish as Library.
  • Напишите в описании, какие значения обязательны для работы.
  • Проверьте, что библиотека работает и после того, как значения изменили.

5.16 Автоматические тесты (желательно)

• Требование. Тесты, проверяющие основные сценарии. Для одобрения не обязательны, но для библиотек их настоятельно рекомендуют, и на видимость элемента они влияют положительно.
• Почему. Тесты ловят поломки при доработках и показывают, что автор относится к качеству серьёзно.
• Что делать.
  • Добавьте интеграционные тесты через автоматическое тестирование.
  • Покройте ключевые сценарии, ради которых элемент и берут.
  • Для библиотек это особенно важно: они становятся частью чужих приложений. Тесты подтвердят, что Library Values работают, что библиотека ведёт себя одинаково при разных настройках, и покажут покупателю ожидаемое поведение.

6. Ценность (для платных элементов)

6.1 За что берут деньги

• Требование. Цена должна быть обоснована.
• Почему. Покупатель платит за сэкономленное время и за то, чего не найдёт в другом месте.
• Что делать.
  • Сформулируйте, чем ваш элемент отличается от остальных и какую задачу решает.
  • Правильно укажите тип: приложение, UI-kit или библиотека — от этого зависят ожидания.
  • Сопоставьте цену с похожими предложениями: она должна соответствовать содержанию.
  • Платная библиотека должна выигрывать хотя бы в одном:
    • 🧘 упрощать сложное;
    • ⚡️ ускорять подключение;
    • 🎛️ давать много переиспользуемых компонентов;
    • 🛠️ работать надёжно;
    • 🙋 закрывать конкретную востребованную задачу.

7. Право и безопасность

7.1 Без неприемлемого содержимого

• Требование. В проекте не должно быть оскорбительного, дискриминирующего и противозаконного: разжигания ненависти, порнографии, призывов к насилию и противоправным действиям.
• Почему. Это нарушает условия использования FlutterFlow и может иметь юридические последствия.
• Что делать. Проверьте тексты, изображения и остальные материалы. В спорных случаях лучше отказаться.

7.2 Без чужих объектов авторского права

• Требование. Никаких чужих изображений, иллюстраций, музыки, звуков и кода без разрешения — про код см. открытые лицензии.
• Почему. Это нарушение закона, которое заканчивается запросом на удаление по DMCA.
• Что делать. Прочитайте юридические правила и разбор лицензий сторонних площадок.

7.3 Без чужих товарных знаков

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

7.4 Без секретов в проекте

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

За что чаще всего отклоняют

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