Quel contenu jugez-vous essentiel pour démarrer une nouvelle communauté ?
Dans Discourse, nous avons l’assistant d’installation qui pose quelques questions pour laisser des descriptions sur la page “À propos”, etc., mais c’est ensuite à vous de créer le contenu que vos utilisateurs découvriront en visitant votre site.
Pour moi, cette étape peut en fait freiner un projet, car personne ne veut lancer un site vide en ligne.
Pour surmonter cet obstacle dans le processus, je crée une liste de contenu pour pouvoir cocher des éléments lors de la configuration de nouveaux sites. Et c’est là qu’intervient votre sagesse !
Voici une courte liste de contenu pour m’aider à démarrer, veuillez répondre avec des idées (et des exemples liés) afin que je puisse développer une liste plus complète pour aider les visiteurs de mes communautés.
Remplir autant de descriptions que possible dans l’assistant d’installation
Modifier le message “Bienvenue sur Discourse” à l’échelle du site, inclure un lien vers Site feedback
Modifier la description de la catégorie pour Site feedback, encourager les utilisateurs à y créer de nouveaux sujets pour obtenir de l’aide, lier à d’autres catégories principales
Ce n’est pas vraiment du contenu, mais je dirais : quelques personnes. La première chose que j’ai remarquée en configurant une instance, c’est qu’il me manquait des modérateurs et même les premiers utilisateurs /wizard/steps/invites
C’est une bonne étape (ou deux) à avoir dans la liste de contrôle !
Je sais que l’assistant d’installation demande toujours d’inviter des modérateurs, mais je ne le fais pas à ce moment-là : je veux au moins leur fournir des conseils sur ce que nous faisons, sinon ils tombent aussi sur un site vierge.
Quant aux utilisateurs, j’invite normalement un groupe restreint, et je leur apprends à utiliser les fonctionnalités d’invitation, donc j’ajouterai cela à ma liste !
Quand invitez-vous les modérateurs dans votre communauté ? Dès le début ?
Potentiellement utile, mais cela pourrait rendre Discourse excessivement compliqué. S’il doit être copié sur un nouveau site, assurez-vous d’installer le composant de thème DiscoTOC - automatic table of contents et d’ajouter une table des matières au sujet.
Quand j’en ai besoin. Pas plus tôt. Mon forum n’est pas très fréquenté et je n’ai pas besoin de modérateurs. Idem pour le groupe Facebook connecté — 25 000 membres, très actif et je n’ai pas besoin d’aide supplémentaire.
Ce que j’ai toujours, c’est une catégorie Discourse. J’y stocke des guides pratiques, des liens vers des guides officiels, et je fournis un point où les utilisateurs peuvent donner leur avis sur le forum ou demander de l’aide, etc.
De plus, j’ai un sujet « Meilleures pratiques », qui comprend des éléments tels que la façon de poser une bonne question, basé sur les règles de Stack Overflow.
Oui, nous pourrions décomposer cela en documents plus petits, et que ce sujet serve d’index ; ensuite, chaque sous-sujet pourrait être copié et collé au besoin… ce n’est pas le processus le plus simple, mais ce serait utile pour permettre aux gens de générer leur propre(s) document(s) pour leur communauté.
Nous ne voulons absolument pas que chaque communauté Discourse paraisse aussi compliquée qu’elle en a la capacité.
Voici un très bon exemple d’une communauté Discourse utilisant le sujet FAQ pour expliquer son fonctionnement à ses utilisateurs :
Dans un monde idéal, ce type de documentation serait disponible directement dans l’instance Discourse dans une barre latérale « Aide ». Similaire à ce que fait Slack. Dans le monde réel, non idéal, copier la documentation dans un sujet sur le site a du sens.
C’est ce que j’ai fait pour ma communauté. Cela signifie que lorsque les gens recherchent « Comment intégrer une vidéo », par exemple, ils obtiennent un sujet qui couvre exactement cela, et rien de plus. Si vous n’autorisez pas les vidéos sur votre site, vous pouvez simplement omettre un tel sujet. De plus, ils peuvent simplement répondre à ce sujet spécifique s’ils ont un problème avec celui-ci, en documentant uniquement les problèmes liés à ce sujet, au lieu du mélange de sujets qu’un guide plus large contient.
Un deuxième avantage est que vous pouvez y faire référence dans plusieurs guides plus importants, en profitant de l’intégration d’autres sujets Discourse.
Voici un exemple de guide de voile que j’ai où les sujets sont divisés en sujets distincts mais unifiés sous un guide « principal ». Dans ce cas, SBF SEE est un sujet pour un type de licence. SBF Binnen est un autre sujet (non visible ici) qui a exactement les mêmes informations de navigation. Je maintiens donc un sujet de navigation et je le lie aux deux guides.
Malheureusement, tout ne s’affiche pas bien avec l’intégration, mais c’est néanmoins un excellent moyen de combiner des sujets et de créer un point d’édition unique, qui met à jour tous les sujets qui doivent faire référence aux mêmes informations.
Je suis tout à fait d’accord. Je trouve qu’une catégorie Discourse est meilleure qu’une barre latérale (bien qu’elle puisse être accessible avec une barre latérale) simplement parce qu’elle encourage les utilisateurs à soulever des problèmes avec la configuration de la communauté, et les administrateurs à modifier les sujets pour mieux correspondre à leur communauté. Par exemple, en remplaçant les images par défaut par des images qui se rapportent spécifiquement à leur plateforme.
Cela dépend certainement de la niche, mais en général, la plupart des utilisateurs ne voient jamais les barres latérales. Enfin, en Europe en tout cas. Ici, dans la partie nord, la plupart des gens ordinaires ne possèdent même plus de bureau/ordinateur portable, ils utilisent des téléphones.
Sujet totalement différent, mais la plupart des sites devraient concevoir la mise en page et l’expérience utilisateur pour les petits écrans, et ensuite, s’il reste du temps au concepteur/codeur, faire un effort pour les ordinateurs de bureau/tablettes.
