Перейти к основному содержимому

Критерии подачи элементов

Стандарты подачи элементов​

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

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

1.1 Права собственности на проект​

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

1.2 Значительные правки​

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

1.3 Не основано на существующем элементе маркетплейса​

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

1.4 Не основано на примера приложения​

  • Критерии: Подачи не должны быть минимально измененными версиями примеров приложений, предоставленных FlutterFlow.
  • Почему это важно: Примеры приложений — отличный инструмент для обучения, но элементы маркетплейса должны демонстрировать более высокий уровень сложности и оригинальной мысли.
  • Что делать:
    • Используйте примеры как основу: Рассматривайте их как отправную точку. Экспериментируйте, расширяйте и превращайте в нечто новое.
    • Покажите продвинутые навыки: Преодолейте базовые макеты и функции; интегрируйте пользовательский код, сложные анимации или полезные вызовы API.

1.5 Оригинальный контент проекта​

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

1.6 Отсутствие зависимостей от библиотек (только для библиотек)​

  • Критерии: Библиотеки не могут зависеть от других библиотек.
  • Почему это важно: Зависимости между библиотеками усложняют управление разрешениями и версиями, что может привести к проблемам совместимости или сбоям в работе.
  • Что делать:
    • Создайте самодостаточную библиотеку: Убедитесь, что ваша библиотека содержит всю необходимую функциональность без требования других библиотек (из маркетплейса или личных).
к сведению

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

Хотя создатели могут удалить свои элементы из маркетплейса в любое время, это не влияет на права пользователей, получивших элемент во время публикации — они сохраняют свои лицензионные права в соответствии с условиями, действовавшими на момент приобретения.

Подробнее о лицензировании и правах интеллектуальной собственности см. в наших Юридических рекомендациях для создателей.

2. Метаданные​

Четкие, привлекательные и точные метаданные помогают пользователям обнаруживать и понимать ценность вашего проекта.

2.1 Подача на английском языке​

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

2.2 Профессиональный заголовок​

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

2.3 Уникальный заголовок​

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

2.4 Профессиональное описание​

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

Хотя инструменты вроде ChatGPT могут помочь в создании контента, они часто генерируют общий текст, который может не полностью передать уникальные аспекты вашего проекта или звучать чрезмерно рекламно и неискренне. Всегда персонализируйте и проверяйте сгенерированный ИИ-контент, чтобы он соответствовал функциям и возможностям вашего элемента.

2.5 Точное описание​

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

2.6 Информация о сторонних сервисах​

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

2.7 Профессиональные инструкции​

  • Критерии: Инструкции и документация должны быть четкими, легкими для следования и написанными в профессиональном тоне.
  • Почему это важно: Хорошо написанные инструкции обеспечивают плавный опыт настройки и реализации для пользователей, повышая удовлетворенность клиентов.
  • Что делать:
    • Предполагайте отсутствие предварительных знаний: Пишите для человека, полностью незнакомого с вашим проектом и FlutterFlow.
    • Используйте нумерованные шаги: Разбивайте сложные процессы на управляемые, actionable шаги.
    • Включайте ссылки на видео: Используйте URL документации, чтобы направить пользователей на визуальный видео-руководство. Альтернативно, укажите на Google Doc или аналогичную письменную документацию для вашего элемента.
    • Протестируйте инструкции: Пусть кто-то другой следует им, чтобы выявить возможные точки путаницы.

2.8 Точные теги​

  • Критерии: Используйте релевантные теги, точно описывающие категорию, функции и возможности вашего проекта.
  • Почему это важно: Теги играют ключевую роль в помощи пользователям находить ваш проект через поиск в маркетплейсе.
  • Что делать:
    • Думайте как пользователь: Какие ключевые слова кто-то использовал бы для поиска проекта вроде вашего?
    • Сочетайте общие и конкретные теги: Например, используйте общие теги вроде "e-commerce" или "social media" вместе с более конкретными, такими как "shopping cart" или "user authentication".
    • Не используйте нерелевантные теги: Это только усложняет поиск нужного для пользователей.

2.9 Изображения высокого качества​

  • Критерии: Изображения должны быть визуально привлекательными, высокого разрешения и отражать дизайн и функциональность проекта. Обложки должны быть не менее 1200 x 800 пикселей и в соотношении 1.5.
  • Почему это важно: Изображения — первое, что видят пользователи, — создайте отличное визуальное впечатление!
  • Что делать:
    • Покажите ключевые экраны и функции: Выберите изображения, подчеркивающие наиболее впечатляющие и важные аспекты проекта.
    • Используйте изображения высокого разрешения: Избегайте размытых или пикселизованных изображений.
    • Соблюдайте единый стиль: Используйте похожие размеры изображений и визуальную обработку для создания цельного вида.
подсказка

Используйте генератор скриншотов FlutterFlow screenshot generator вместе с сервисами вроде Shots.so, чтобы создать красивые обложки.

2.10 Соответствие изображений​

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

2.11 Отсутствие логотипа FlutterFlow на изображениях​

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

3. Эстетика и дизайн​

Первое впечатление имеет значение! Мы ищем проекты, которые выходят за рамки базовой функциональности и демонстрируют глубокое понимание принципов визуального дизайна.

3.1 Стандарт дизайна​

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

3.2 Совместимость с размерами экранов (адаптивность)​

  • Критерии: Проекты должны быть спроектированы для seamless адаптации к различным размерам экранов.
  • Почему это важно: Пользователи ожидают, что приложения Flutter будут масштабироваться на широком спектре устройств — от маленьких смартфонов до больших мониторов. Адаптивный дизайн обеспечивает положительный опыт на всех устройствах.
  • Что делать:
    • Следуйте лучшим практикам адаптивного дизайна: Используйте Wrap, Responsive Visibility и функции Flex, чтобы обеспечить масштабируемость приложения на устройствах. Подробнее об адаптивных макетах см. в Responsive Layouts: 101.
    • Тестируйте на разных устройствах: Используйте различные виртуальные устройства в режимах Test и Run в FlutterFlow, чтобы проверить проект на разных размерах экранов. Экспериментируйте с размером холста в конструкторе, чтобы увидеть, как масштабируется дизайн.

4. Опыт тестирования​

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

4.1 Рабочая ссылка на режим Run​

  • Критерии: Предоставленная ссылка на режим Run должна быть активной и корректно загружать рабочую демо-версию вашего проекта. Для функций, доступных только на мобильных устройствах, или утилитарных библиотек, которые нельзя продемонстрировать в веб-среде режима Run, вы должны предоставить альтернативные методы демонстрации.
  • Почему это важно: Ссылка на режим Run — основной способ взаимодействия пользователей с проектом перед покупкой. Неисправная, недоступная или недемонстративная ссылка создает значительный барьер для понимания ценности элемента.
  • Что делать:
    • Для стандартных элементов, совместимых с веб:
      • Дважды проверьте ссылку перед подачей, чтобы убедиться, что она показывает опыт, который вы хотите продемонстрировать потенциальным покупателям.
      • Протестируйте ссылку несколько раз, чтобы обеспечить стабильную функциональность.
    • Для функций, доступных только на мобильных:
      • Создайте专用 страницу демонстрации в проекте, объясняющую функциональность для мобильных.
      • Включите скриншоты, видео или мокапы, показывающие, как работает функция на мобильных устройствах.
      • Четко укажите, какие функции доступны только на мобильных и почему их нельзя продемонстрировать в режиме Run.
      • Опционально предоставьте опубликованную ссылку на веб-развертывание FlutterFlow вместо URL режима Run.
    • Для утилитарных библиотек (например, аналитика, фоновые сервисы):
      • Создайте страницу демонстрации, объясняющую функциональность библиотеки.
      • Покажите опции конфигурации и ожидаемые результаты.
      • Включите визуальные пособия, такие как блок-схемы или диаграммы, для объяснения работы библиотеки.
      • Предоставьте примеры кода или фрагменты конфигурации.
      • Рассмотрите добавление отладочных/тестовых выводов, демонстрирующих работу библиотеки.
    • Документация:
      • Независимо от типа элемента, убедитесь, что документация четко объясняет, как реализовать и протестировать функциональность в реальной мобильной среде.
      • Включите руководства по устранению неисправностей и распространенные сценарии реализации.
подсказка

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

4.2 Вход пользователя (анонимная аутентификация)​

  • Критерии: Пользователи должны иметь возможность исследовать основную функциональность вашего элемента без необходимости создания аккаунта или входа.
  • Почему это важно: Требование предварительной аутентификации создает барьеры для пользователей, желающих просто попробовать перед покупкой. Кроме того, принуждение к предоставлению личной информации может вызвать проблемы с конфиденциальностью. Анонимная аутентификация позволяет немедленное исследование.
  • Что делать:
    • Предоставьте предзаполненные демо-учетные данные: Если демо сильно зависит от пользовательских данных, создайте демо-аккаунт с предзаполненными примерами данных, доступными гостям. Предзаполните имя пользователя и пароль на экране входа, чтобы пользователи могли легко начать исследование.
    • Реализуйте анонимную аутентификацию: FlutterFlow поддерживает простую интеграцию с Firebase для анонимного входа. Это позволяет пользователям получить доступ к демо-режиму проекта без создания аккаунта.
    • Удалите аутентификацию: Другой вариант — полностью убрать необходимость аутентификации. Это позволит пользователям сразу начать исследование без барьеров.

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

  • Критерии: Все страницы и разделы в вашем проекте должны быть легко навигируемыми и доступными.
  • Почему это важно: Запутанный или сломанный поток навигации создает раздражающий опыт. Пользователи должны интуитивно исследовать все аспекты проекта.
  • Что делать:
    • Настройте начальную страницу правильно: В Settings > App Details параметр 'Entry Page' определяет точку входа для ссылок режима Run и начальную страницу, которую увидят пользователи при входе в приложение. Убедитесь, что это установлено на наиболее логичную и приветливую страницу для плавного опыта входа и навигации.
    • Просмотрите вид Storyboard вашего проекта: Этот вид отображает навигацию по различным страницам и помогает выявить пробелы. Обратите внимание, что недоступные страницы не отображаются.
    • Тщательно протестируйте навигацию: Кликните по каждой кнопке, ссылке и пункту меню в режиме Run, чтобы убедиться, что они ведут в правильные места.

4.4 Функциональный шаблон​

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

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

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

5.1 Отсутствие ошибок в функциональности​

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

5.2 Отсутствие переполнения пикселей​

  • Критерии: Убедитесь, что элементы UI правильно позиционированы и sized, чтобы избежать переполнения контента контейнером, приводящего к визуальным глюкам / обрезанному контенту.
  • Почему это важно: Переполнение пикселей — признак несоответствий UI, которые могут негативно повлиять на опыт, особенно на разных размерах экранов. Проблемы переполнения могут возникать в режиме Test, когда есть жестко заданное значение пикселей и недостаточно места на экране для его рендеринга.
  • Что делать:
    • Предварительный просмотр переполнения пикселей: Включите иконку переполнения пикселей в правом верхнем углу холста, чтобы увидеть возможные проблемы.
    • Воспользуйтесь инструментами макета FlutterFlow: Используйте Expanded и значения Flex, чтобы предотвратить проблемы макета. Делайте Columns или Rows прокручиваемыми, чтобы избежать переполнений. Используйте авторазмер текста или обрезку текста, где это имеет смысл. Удалите жестко заданные ширину и высоту, где это уместно.
    • Тестируйте на разных размерах экранов: Изменяйте размер холста во время сборки, чтобы предварительно просмотреть потенциальные проблемы.

5.3 Отсутствие ошибок в пользовательском коде​

  • Критерии: Любой пользовательский код, интегрированный в проект (с помощью Custom Functions, Actions и Widgets), должен быть свободен от синтаксических ошибок, логических ошибок и потенциальных уязвимостей безопасности.
  • Почему это важно: Ошибки в пользовательском коде могут привести к нестабильности приложения, сбоям или даже рискам безопасности.
  • Что делать:
    • Пишите чистый, хорошо задокументированный код: Это упрощает отладку и поддержку проекта.
    • Тщательно тестируйте пользовательский код: Изолируйте и тестируйте единицы пользовательского кода (функции, действия), чтобы убедиться в их корректной работе.
    • Используйте валидацию кода FlutterFlow: Обратите внимание на любые предупреждения или ошибки, выделенные встроенной валидацией кода FlutterFlow.

5.4 Соответствующий и релевантный пользовательский код​

  • Критерии: Пользовательский код должен быть целенаправленно интегрирован и улучшать функциональность проекта значимым образом. Избегайте ненужного или избыточного кода. Не включайте неиспользуемый или нерелевантный пользовательский код.
  • Почему это важно: Хотя пользовательский код обеспечивает гибкость, чрезмерный или плохо интегрированный код может усложнить понимание, поддержку и обновление проекта в будущем.
  • Что делать:
    • Планируйте пользовательский код стратегически: Определите, могут ли встроенные функции FlutterFlow реализовать желаемую функциональность, прежде чем прибегать к пользовательскому коду.
    • Эффективно комментируйте код: Объясняйте цель и логику пользовательского кода для улучшения читаемости и поддерживаемости.
    • Делайте модульным: Разбивайте сложную логику на меньшие, переиспользуемые функции или действия. Предпочитайте блоки кода, когда Custom Function относительно короткая и используется только один раз.

5.5 Тестируемый пользовательский код в режиме Run​

  • Критерии: Убедитесь, что функциональность, реализованная с помощью пользовательского кода, доступна и проверяема в демо-режиме Run.
  • Почему это важно: Пользователи должны ощутить полный эффект вашего элемента с пользовательским кодом в среде режима Run.
  • Что делать:
    • Добавьте страницу, использующую ваш пользовательский код: Эта страница должна идеально демонстрировать типичный сценарий использования пользовательского кода или позволять пользователям устанавливать и контролировать значения параметров в режиме Run.
    • Предоставьте четкие инструкции: Если для тестирования определенных функций пользовательского кода в режиме Run требуются специальные шаги, четко объясните их в описании проекта или документации.

5.6 Правильные правила Firestore (если применимо)​

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

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

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

5.8 Удобный шаблон​

  • Критерии: Ваш шаблон должен позволять пользователям легко и интуитивно строить на его основе, независимо от их опыта в FlutterFlow.
  • Почему это важно: Удобный шаблон повышает его ценность и привлекательность. Когда пользователи могут быстро понять и настроить шаблон, они с большей вероятностью выберут его, что приведет к успеху вашего элемента в маркетплейсе.
  • Что делать:
    • Используйте переиспользуемые компоненты: Проектируйте шаблон с учетом модульности. Создавайте переиспользуемые компоненты, которые пользователи могут легко модифицировать под свои нужды.
    • Четкие и лаконичные соглашения об именовании: Используйте описательные имена для виджетов, переменных и функций, чтобы структура шаблона была понятна с первого взгляда.
    • Логическая организация: Структурируйте макет шаблона четко и логично, группируя связанные элементы и используя комментарии для руководства пользователей.
    • Документация — ключ: Предоставьте четкую и всестороннюю документацию, которая направляет пользователей по использованию и настройке шаблона. Включите объяснения ключевых функций, опций настройки и потенциальных сценариев использования.
    • Тестируйте с разными пользователями: Получите отзывы от пользователей с разным уровнем опыта в FlutterFlow. Это поможет выявить потенциальные проблемы или области, где шаблон можно сделать более удобным.

5.9 Соответствующее управление состоянием​

  • Критерии: Реализуйте управление состоянием эффективно, чтобы данные обновлялись и отражались корректно по всему приложению.
  • Почему это важно: Правильное управление состоянием критически важно для создания отзывчивых и динамичных приложений Flutter. Оно предотвращает несоответствия данных, улучшает производительность и упрощает поддержку кода.
  • Что делать:
    • Выберите правильный scope управления состоянием: FlutterFlow поддерживает (1) App State, (2) Page State и (3) Component State переменные. Ознакомьтесь с этими опциями и ограничивайте переменные состоянием там, где они нужны. Например, не используйте App State для управления значением чекбокса в компоненте.
    • Перестраивайте эффективно: Убедитесь, что изменения состояния перестраивают только необходимый scope для эффективности.

5.10 Организованное дерево виджетов​

  • Критерии: Сохраняйте хорошо структурированное и организованное дерево виджетов в проекте FlutterFlow.
  • Почему это важно: Чистое и организованное дерево виджетов делает проект более понятным, поддерживаемым и менее подверженным ошибкам. Оно также упрощает совместную работу над проектом.
  • Что делать:
    • Используйте описательные имена для виджетов и переменных: Делайте код самодокументирующимся с помощью четких и значимых имен для основных узлов.
    • Избегайте глубоко вложенных виджетов: Если дерево виджетов становится слишком глубоким (>10 уровней), рассмотрите разбиение на меньшие, переиспользуемые компоненты.

5.11 Следуйте лучшим практикам FlutterFlow​

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

Следите за предстоящим "руководством по стилю", которое мы опубликуем с более глубокими деталями о лучших практиках создания в FlutterFlow.

5.12 Ограничьте статические изображения​

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

5.13 Ограничьте пользовательский код (если возможно)​

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

5.14 Эффективное использование компонентов и избежание дублирования​

  • Критерии: Проекты должны демонстрировать эффективное использование компонентов FlutterFlow. Избегайте ненужного дублирования страниц, виджетов или действий. Стремитесь создавать переиспользуемые компоненты и реализовывать блоки действий масштабируемо и поддерживаемо.
  • Почему это важно: Дублирование больших секций кода или целых страниц с незначительными изменениями раздувает размер проекта, снижает поддерживаемость и может ввести пользователей в заблуждение относительно сложности и ценности проекта.
  • Что делать:
    • Воспользуйтесь компонентами: Создавайте переиспользуемые компоненты для элементов, повторяющихся в проекте (например, карточки товаров, элементы списков, заголовки, футеры).
    • Используйте параметры: Передавайте данные и настраивайте экземпляры компонентов с помощью параметров вместо дублирования и жесткого кодирования значений.
    • Проверьте на избыточности: Перед подачей тщательно осмотрите проект на наличие ненужных дублированных страниц, виджетов или цепочек действий, которые можно объединить или упростить.

5.15 Реализация значений библиотек (только для библиотек)​

  • Критерии: Библиотеки должны использовать Library Values для чувствительных ключей и настраиваемых элементов, которые пользователи должны конфигурировать.
  • Почему это важно: Library Values позволяют пользователям безопасно предоставлять свои API-ключи и настраивать критическую конфигурацию без модификации основной функциональности библиотеки. Это улучшает безопасность и делает библиотеки более гибкими и переиспользуемыми.
  • Что делать:
    • Выявите настраиваемые элементы: Проверьте библиотеку на наличие API-ключей, конечных точек или других значений, которые пользователи должны настраивать.
    • Создайте Library Values: Настройте Library Values для этих элементов в Settings > App Settings > Publish as Library.
    • Документируйте требования: Четко объясните в описании элемента, если для корректной работы библиотеки требуются Library Values.
    • Протестируйте конфигурацию: Убедитесь, что библиотека работает корректно при изменении Library Values пользователями.

5.16 Автоматизированные тесты (настоятельно рекомендуется)​

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

6. Ценность (платные элементы)​

Успешный элемент маркетплейса выходит за рамки просто функционального приложения — он предоставляет реальную ценность пользователям.

6.1 Высокая ценностная пропозиция​

  • Критерии: Элементы должны предлагать убедительную ценностную пропозицию, оправдывающую их цену.
  • Почему это важно: Пользователи ищут решения, которые экономят время, усилия или ресурсы, или предоставляют уникальный опыт, который трудно найти в другом месте.
  • Что делать:
    • Определите уникальную ценность: Выявите и сформулируйте, что отличает ваш проект от других. Убедитесь, что он решает конкретную проблему способом, недоступным в маркетплейсе.
    • Тегируйте правильно: Точно категоризируйте элемент — будь то полное приложение, UI-kit или библиотека, — чтобы установить правильные ожидания для потенциальных пользователей.
    • Обоснуйте цену: Убедитесь, что цена элемента отражает его истинную ценность и справедливо сравнима с аналогичными предложениями. Обеспечьте достаточную глубину и уникальность для оправдания минимальной цены.
    • Для платных библиотек: Библиотеки должны выделяться хотя бы в одной из этих областей:
      • 🧘 Упрощение технической сложности (простота)
      • ⚡️ Обеспечение быстрых и seamless интеграций (скорость)
      • 🎛️ Предложение разнообразных переиспользуемых компонентов и функций (количество)
      • 🛠️ Предоставление robust, надежной функциональности (качество)
      • 🙋‍♂️ Решение конкретных, востребованных сценариев с продуманными решениями (релевантность)

7. Юридические и безопасностные аспекты​

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

7.1 Отсутствие неподобающего контента​

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

7.2 Отсутствие материалов, защищенных авторским правом​

  • Критерии: Проекты не должны включать несанкционированное использование материалов, защищенных авторским правом, таких как:
    • Изображения, иллюстрации или графика
    • Музыка или звуковые эффекты
    • Фрагменты кода или библиотеки — см. документацию по Открытым лицензиям для деталей
  • Почему это важно: Использование материалов, защищенных авторским правом, без разрешения — юридическое нарушение, которое может привести к серьезным последствиям, включая DMCA-удаление.
  • Что делать: Подробнее см. наши Юридические рекомендации для создателей и Работу с внешними лицензиями.

7.3 Отсутствие материалов, защищенных товарными знаками​

7.4 Отсутствие конфиденциальных данных​

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

Распространенные причины отклонения​

Чтобы упростить процесс подачи, вот наиболее частые причины, по которым проекты отклоняются:

Мы с нетерпением ждем потрясающих проектов FlutterFlow, которые вы принесете в маркетплейс! Следуя этим рекомендациям, вы поможете нам поддерживать платформу высокого качества, полезную для всего сообщества FlutterFlow. Давайте создадим что-то невероятное вместе! 🚀