Какой контент необходим для нового сообщества?

Какой контент вы считаете необходимым для запуска нового сообщества?

В Discourse есть мастер настройки, который предлагает ответить на несколько вопросов, чтобы заполнить описание на странице «О нас» и так далее. Однако создание контента, который пользователи увидят при посещении вашего сайта, остается на вашей совести.

Для меня этот этап может стать препятствием для проекта, так как никто не хочет запускать живой, но пустой сайт. :sweat_smile:

Чтобы преодолеть это препятствие, я составляю список контента, чтобы отмечать выполненные пункты при настройке новых сайтов. И здесь пригодится ваш опыт! :star_struck:

Вот краткий список контента, который поможет мне начать. Пожалуйста, поделитесь идеями (и ссылками на примеры), чтобы я мог составить более полный список для помощи посетителям моих сообществ. :slight_smile:


  • Заполнить как можно больше полей в мастере настройки
  • Изменить глобальное сообщение «Добро пожаловать в Discourse», добавив ссылку на Contribute > Site feedback
  • Скопировать Understanding Discourse for new users, отредактировать при необходимости
  • Изменить описание категории Contribute > Site feedback, поощряя пользователей создавать в ней новые темы для получения помощи, и добавить ссылки на другие основные категории
  • Скопировать Configuring how users can create and send invites for others to join your community, отредактировать при необходимости для модераторов/первых пользователей
  • Пригласить первых пользователей! :tada:
13 лайков

Это не совсем контент, но я бы сказал: некоторые люди. Первое, что я заметил при настройке экземпляра, — это отсутствие модераторов и даже первых пользователей :sweat_smile:
/wizard/steps/invites

4 лайка

Это отличный шаг (или два) для включения в чек-лист!

Я знаю, что мастер настройки всегда предлагает пригласить модераторов, но я этого пока не делаю: я хочу сначала дать им некоторое представление о том, что мы делаем, иначе они тоже столкнутся с пустым сайтом. :slight_smile:

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

Когда вы приглашаете модераторов в своё сообщество? Сразу же?

3 лайка

Интересная тема!

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

Мне также оказалась полезной эта статья в блоге при запуске:

6 лайков

Возможно, это полезно, но может создать впечатление, что Discourse излишне усложнён. Если нужно скопировать это на новый сайт, обязательно установите компонент темы DiscoTOC - automatic table of contents и добавьте оглавление в тему.

5 лайков

Когда они мне нужны. Не раньше. Мой форум не настолько активен, и мне не нужны модераторы. То же самое с подключённой группой в Facebook — 25 000 участников, очень активная, и мне не нужны лишние руки.

2 лайка

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

Кроме того, у меня есть тема «Лучшие практики», которая включает такие вещи, как, например, как задать хороший вопрос, основываясь на правилах Stack Overflow.

5 лайков

Да, мы, возможно, разобьём это на более мелкие документы, и эта тема будет служить индексом; тогда каждую подтему можно будет копировать и вставлять по мере необходимости… это не самый простой процесс, но это поможет пользователям создавать собственные документы для своего сообщества. :thinking:

Определённо не хотим, чтобы каждое сообщество Discourse выглядело таким сложным, каким оно может быть. :slight_smile:

Вот отличный пример сообщества Discourse, использующего тему FAQ для объяснения того, как оно работает для своих пользователей:

https://community.namati.org/t/faq-frequently-asked-questions/1467

Хорошая идея, я обновил информационный блок там:

2 лайка

В идеальном мире такая документация была бы доступна прямо в экземпляре Discourse в боковой панели «Справка». Подобно тому, как это делает Slack. В несовершенном реальном мире копирование документации в тему на сайте имеет смысл.

3 лайка

Вот что я сделал для своего сообщества. Это означает, что когда люди ищут, например, «Как вставить видео», они получают тему, которая посвящена именно этому и ничему другому. Если вы не разрешаете видео на своём сайте, вы можете просто исключить такую тему. Кроме того, они могут отвечать именно на эту тему, если у них возникнут проблемы с ней, документируя только вопросы, связанные с этой темой, вместо смеси тем, которую содержит более крупное руководство.

Второе преимущество этого подхода заключается в том, что вы можете ссылаться на него в нескольких крупных руководствах, используя функцию однооконного отображения (oneboxing) других тем Discourse.

Вот пример моего руководства по парусному спорту, где темы разбиты на отдельные разделы, но объединены под «основным» руководством. В данном случае SBF SEE — это тема для одного типа лицензии. SBF Binnen — это другая тема (не показанная здесь), которая содержит точно такую же информацию о навигации. Поэтому я поддерживаю одну тему навигации и ссылаюсь на неё в обоих руководствах.

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

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

2 лайка

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

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

2 лайка