Kategorien vs. Tags für „Inhaltstyp“ vs. „Thema“ – was sind die richtigen URL-Muster?

Gemeinschaft
1

Hallo zusammen – ich suche nach Anleitungen zur Strukturierung unseres Discourse, da wir bei Ansatz 1 1200 Kategorien haben, wenn wir 3 Kategorienebenen (L1-L2-L3) haben, und wenn wir L3 eliminieren, haben wir etwa 150 Kategorien mit L1 und L2.

Kontext
Wir veröffentlichen mehrere Inhaltstypen (Fragen, Diskussionen, Anleitungen/Artikel, Veranstaltungen, Stellenangebote, Mitteilungen) zu verschiedenen Themen. Denken Sie an Beispiele wie:

  • Themenbereiche (L1): Kochen, Fotografie
  • Unterthemen (L2): Italienisch (unter Kochen), Porträt (unter Fotografie)
  • Schwerpunkt (L3): Pasta, Sauerteig, Beleuchtung, Komposition

Ich bin hin- und hergerissen zwischen zwei Ansätzen und würde mich über Best-Practice-Ratschläge freuen.

Ansatz A (Themenbereich = Kategorien, Inhaltstyp = Tags)

  • Kategorien

    • L1 (Themenbereich): kochen, fotografie
    • L2 (Unterthema): italienisch, porträt
    • (Frage) Sollten wir eine 3. Kategorieebene für „Schwerpunkt“ hinzufügen (z. B. kochen → italienisch → pasta) oder den Baum flach halten und den Schwerpunkt als Tags modellieren?

  • Tags

    • Erforderlicher Inhaltstyp-Tag (genau einer): frage, diskussion, anleitung, veranstaltung, stelle, mitteilung
    • Optionaler/erforderlicher Schwerpunkt-Tag: pasta, sauerteig, beleuchtung, komposition, …

URL-Muster (Ansatz A)

  • Vorausgefüllter Composer (L2 + Typ + optionaler Schwerpunkt):
    /new-topic?category=kochen/italienisch&tags=frage,pasta
  • Kategorie gefiltert nach einem Tag (z. B. „Fragen auf Italienisch“):
    /c/kochen/italienisch?tags=frage
  • Tag-Schnittmengen (UND) (seitenweit, z. B. „Pasta + Frage“):
    /tags/intersection/pasta/frage
  • Kategorie + Multi-Tag (Erweiterte Suche verwenden):
    /search?q=category:kochen/italienisch%20tags:pasta+frage

Fragen zu Ansatz A

  1. Ist die empfohlene Vorgehensweise, eine 3. Kategorieebene zu vermeiden und „Schwerpunkt“ als Tags zu belassen?
  2. Gibt es Fallstricke, da Kategorienseiten nur einen ?tags=-Filter unterstützen (erweiterte Suche für Multi-Tag in einer einzelnen Kategorie erforderlich)?

Ansatz B (Inhaltstyp = Kategorien, Themenbereich = Tags)

  • Kategorien: Oberste Ebene (oder wenige) für Fragen, Diskussionen, Anleitungen, Veranstaltungen, Stellenangebote, Mitteilungen.

  • Tags (drei Gruppen für Themen):

    • Themenbereich (z. B. kochen, fotografie) — Limit eins
    • Unterthema (z. B. italienisch, porträt) — Limit eins
    • Schwerpunkt (z. B. pasta, beleuchtung) — 1 erforderlich (oder optional)

URL-Muster (Ansatz B)

  • Vorausgefüllter Composer (Kategorie + Themen-Tags):
    /new-topic?category=fragen&tags=kochen,italienisch,pasta
  • Typ nach Thema durchsuchen (z. B. Fragen zu Italienisch):
    /c/fragen?tags=italienisch (Multi-Tag + Kategorie → Erweiterte Suche)
  • Seitenweite Themen-Schnittmengen (unabhängig vom Typ):
    /tags/intersection/italienisch/pasta

Fragen zu Ansatz B

  1. Erschwert die Aufteilung von Inhalten auf „Typ“-Kategorien das Durchsuchen nach Themen?
  2. Gibt es Fallstricke bei der Anforderung mehrerer Tag-Gruppen (Themenbereich + Unterthema + Schwerpunkt) pro Thema?

Übergreifende Fragen

  • Best Practices heute: Einen flachen Kategorienbaum (1–2 Ebenen) beibehalten und Details in Tags verschieben?
  • Wann ist eine 3. Kategorieebene gerechtfertigt? Nur für wirklich volumenstarke Schwerpunktbereiche, die separate Berechtigungen/Landingpages benötigen?
  • Feature-Umfang: Wenn wir Gelöst/Abstimmungen aktivieren, ist es besser, diese in Ansatz A auf Themenkategorien oder in Ansatz B auf „Fragen“-Kategorien zu beschränken?
  • Composer UX: Sind vorausgefüllte Composer-Links (/new-topic?category=...&tags=...) immer noch der bevorzugte Weg, um Autoren anzuleiten?
  • Search UX: Gibt es neuere Muster für die Filterung von Kategorien + Multi-Tags (über die erweiterte Suche hinaus), die wir kennen sollten?

Vielen Dank im Voraus für Hinweise, Beispiele und „was für euch funktioniert hat“!

1 „Gefällt mir“
2

Ich denke, die Antwort hängt ein wenig von Ihren Erwartungen ab, wie sehr die verschiedenen Themen in Ihrer Community für ein bestimmtes Mitglied attraktiv sind.

Erwarten Sie eine große Überschneidung zwischen den Gruppen, die Fotografie und Kochen diskutieren? Wenn ja, funktionieren Tags für diese verschiedenen Themen wahrscheinlich gut.

Oder möchten Sie mehrere Untergemeinschaften bedienen – eine für Kochen und eine für Fotografie – innerhalb derselben Website? Wenn ja, bevorzugen Sie vielleicht Kategorien für jede.

Ich gehe davon aus, dass Sie sich zuerst mit einer einzigen Community befassen, in der Menschen gemeinsam viele Themen diskutieren können.

Mein Vorschlag wäre, mit etwas zu beginnen, das eher dem Ansatz B ähnelt.

Unterschiedliche Kategorien für die verschiedenen Arten von Inhalten ermöglichen es Ihnen, klarer zu signalisieren, um welche Art von Diskussion es sich handelt und welches Verhalten von den Teilnehmern erwartet wird. Sie können dies in einigen Fällen weiter ausbauen, indem Sie die Kategorien für diese Zwecke konfigurieren (z. B. das „solved“-Plugin für eine Q&A-Kategorie verwenden).

Verlassen Sie sich dann zuerst auf Tags für das Thema. Das gibt Ihnen die Freiheit, Diskussionen mit mehreren Tags zu versehen, wenn es Überschneidungen gibt (Fotos vom Kochen!).

Wenn Sie zu einem bestimmten Zeitpunkt feststellen, dass es hilfreich ist, einige Themen klarer von anderen zu trennen, können Sie die Tags verwenden, um Dinge neu zu kategorisieren.

Im Allgemeinen empfehlen wir weniger Kategorien als mehr, insbesondere zu Beginn, und eine flachere Hierarchie als eine tiefe. Standardmäßig unterstützen wir nur zwei Ebenen der Tiefe. Sie müssen sich schon Mühe geben, um die Unterstützung für eine dritte zu aktivieren.

Ich weiß nicht, ob Leute URLs stark zum Vorabfüllen des Komponisten verwenden. Ich kann mir vorstellen, dass es in einigen Szenarien nützlich ist, aber ich würde vorschlagen, diese Idee beiseite zu legen, bis Sie einen Bedarf dafür finden.

Zur Entdeckung gibt es noch etwas anderes zu beachten: die Seite /filter, auf der Sie benutzerdefinierte Themenlisten erstellen können, die Sie in Ihrer Seitenleiste konfigurieren können: Filtering topic lists in Discourse

2 „Gefällt mir“
3

Vielen Dank, Mcwumbly. Mir ist bewusst, dass meine frühere Frage nicht den vollen Kontext enthielt – es war etwas schwierig zu formulieren. Hier sind zusätzliche Hintergründe, um unseren Anwendungsfall und die Erwartungen der Benutzer zu umreißen: Wir bauen ein Forum im folgenden Kontext auf:

(Nur auf Essen ausgerichtetes Nischenforum zur Veranschaulichung der Struktur)

1) Thema (drei Ebenen; können Kategorien oder Tags sein)

  • L1 = Küche — Italienisch, Karibisch, Indisch, Mexikanisch
  • L2 = Fokus — Beispiele: Pasta (unter Italienisch), Tacos (unter Mexikanisch), Chaat / Tandoori (unter Indisch)
  • L3 = Mikro-Fokus — Techniken/Gerichte/Zutaten, z. B. Extrudierte Pasta, Naan, Guajillo, Sous-Vide

Realität der Nutzung: Etwa 70 % der Beiträge erfolgen auf L2 (Fokus) in Kombination mit einem L3 (Mikro-Fokus).
• Wenn L3 eine Kategorie ist, wird das Thema in L3 gepostet. (Wichtiger Hinweis: Hier werden L3-Kategorien einen deutlich höheren Namen haben im Vergleich zu L2 und L1)
• Wenn L3 ein Tag ist, wird das Thema in L2 mit dem L3-Tag versehen.

2) Inhaltstypen (übergreifend; können Kategorien oder Tags sein)

Jeder Thementyp benötigt ein eigenes Composer-Formular:

  • Frage → Problem • Was ich versucht habe • Umgebung • Erwartet vs. Tatsächlich
  • Anleitung / Artikel → Voraussetzungen • Schritte • Überprüfung • Stolpersteine
  • Veranstaltung → Start/Ende • Zeitzone • Ort/Link • RSVP
  • Stelle → Rolle • Ort/Remote • Anforderungen • Wie man sich bewirbt
  • (Plus) Diskussion

3) Offene Entscheidung (spiegelt den Enterprise-Fall wider)

  • Sollen Küche / Fokus / Mikro-Fokus Kategorien (mit Tag-Helfern) oder Tags (mit einer flachen Kategorienschicht) sein?
  • Sollen Thementypen Kategorien (einfache Vorlagen pro Typ) oder Tags (behält Küche/Fokus als primären „Ort“) sein?
  • Bei 70 % der Aktivität auf Fokus + Mikro-Fokus, welche Option bewahrt am besten starke Fokus-Landingpages und hält gleichzeitig die IA einfach?

Zusammenfassung unserer Einschränkungen & Ziele (gilt für beide Versionen)

  • Halten Sie die Navigation intuitiv dort, wo sich die Benutzer tatsächlich aufhalten (L2 + L3)… wie wir hier dennoch etwas Kontext geben müssen (Verweis auf L1, egal ob Italienisch oder Mexikanisch, von wo aus der Beitrag aus Sicht des Breadcrumbs oder der SEO erfolgt)
  • Vermeiden Sie unnötige Kategorie-Aufblähung, bieten Sie aber dennoch klare „Heimatbasen“ für stark frequentierte Themen.
  • Erzwingen Sie genau einen Inhaltstyp pro Thema und unterstützen Sie Themenüberschneidungen (z. B. Software + Technischer Bereich oder Küche + Fokus).
  • Stellen Sie sicher, dass das richtige Composer-Formular für jeden Inhaltstyp erscheint, unabhängig davon, ob die Typen als Kategorien oder Tags modelliert sind.

Wir suchen nach Anleitungen, welche Modellierungsentscheidung (Kategorien vs. Tags für Thema und Inhaltstypen) diese Einschränkungen am besten erfüllt, da das meiste Engagement bei L2 + L3 mit unterschiedlichen Inhaltstypen und unterschiedlichen Formularen für jeden Inhaltstyp stattfindet.

2 „Gefällt mir“
4

Um Ihnen hier die bestmögliche Antwort geben zu können, wäre es notwendig, noch tiefer in Ihren spezifischen Kontext einzudringen. Ich müsste Ihre spezifischen Themen, die verschiedenen Nutzer-Personas in Ihrer Community, wie sicher Sie sich bezüglich ihrer Bedürfnisse und Verhaltensweisen sind, ob Sie bereits eine aktive Community haben und wenn ja, wie groß und aktiv diese ist usw. genauer untersuchen.

In Ermangelung dessen verallgemeinern wir natürlich, und die Ratschläge, die Sie erhalten, passen möglicherweise besser oder auch nicht zu Ihnen.

Dennoch, basierend auf dem, was Sie bisher geteilt haben, würde ich die Dinge so angehen:

  1. Erstellen Sie zunächst nur Kategorien für die Anwendungsfälle (Fragen, Veranstaltungen usw.); verwenden Sie Tags für die Themen.
  2. Wenn sich Untergemeinschaften bilden, die ihren eigenen Raum benötigen, erstellen Sie eine oberste Kategorie für sie, erstellen Sie eine oberste Kategorie namens „Untergemeinschaften“ (Name Ihrer Wahl) und erstellen Sie Unterkategorien für jede von ihnen – innerhalb dieser gäbe es keine Kategorien basierend auf Anwendungsfällen. Die Annahme ist, dass dies eher freiformige Diskussionen innerhalb aufkommender eng verbundener Gruppen sind, die gemeinsam tiefer in ein Thema eintauchen und gleichzeitig weiterhin zu den anderen obersten Kategorien beitragen.
  3. Wenn diese Untergemeinschaften so weit wachsen, dass sie eigene Kategorien basierend auf Anwendungsfällen benötigen, befördern Sie sie zu obersten Kategorien und duplizieren Sie die Kategorien basierend auf Anwendungsfällen darin (Fragen, Veranstaltungen usw.); verschachteln Sie die anfängliche Reihe von Kategorien unter einer allgemeineren obersten Kategorie, um die „Haupt“-Community darzustellen.
  4. Verwenden Sie weiterhin Tags, um Inhalte über alle diese Kategorien hinweg nach Themen zu verbinden.
2 „Gefällt mir“
5

Vielen Dank, Mcwumbly, für deine Antwort. Es war sinnvoll, auch andere Faktoren zu berücksichtigen, um den Ansatz zu bestimmen. Wir haben den Ansatz quasi mit dem Mental-Model-Flow und der von Discourse vorgeschlagenen Arbeitsweise als Faktoren übernommen.

2 „Gefällt mir“