Categorieën versus tags voor "content type" versus "onderwerp" — wat zijn de juiste URL-patronen?

Gemeenschap
1

Hallo allemaal — op zoek naar begeleiding bij het structureren van onze Discourse, want als we aanpak - Optie 1 volgen, hebben we 1200 categorieën met 3 niveaus van categorieën (L1-L2-L3) en als we L3 elimineren, hebben we ongeveer 150 categorieën met L1 & L2.

Context
We publiceren verschillende contenttypes (vragen, discussies, how-to’s/artikelen, evenementen, vacatures, bulletins) over verschillende onderwerpen. Denk aan voorbeelden zoals:

  • Onderwerpgebieden (L1): Koken, Fotografie
  • Subonderwerpen (L2): Italiaans (onder Koken), Portret (onder Fotografie)
  • Focus (L3): pasta, zuurdesem, belichting, compositie

Ik twijfel tussen twee benaderingen en zou graag advies over best practices willen.

Benadering A (onderwerp = categorieën, contenttype = tags)

  • Categorieën

    • L1 (Onderwerpgebied): koken, fotografie
    • L2 (Subonderwerp): italiaans, portret
    • (Vraag) Moeten we een 3e niveau categorie toevoegen voor “Focus” (bijv. koken → italiaans → pasta) of de boom ondiep houden en Focus als tags modelleren?

  • Tags

    • Vereiste content-type tag (exact één): vraag, discussie, how-to, evenement, vacature, bulletin
    • Optionele/vereiste focus tag: pasta, zuurdesem, belichting, compositie, …

URL-patronen (Benadering A)

  • Vooraf ingevuld composer (L2 + type + optionele focus):
    /new-topic?category=koken/italiaans&tags=vraag,pasta
  • Categorie gefilterd op één tag (bijv. “Vragen in het Italiaans”):
    /c/koken/italiaans?tags=vraag
  • Tag-intersecties (EN) (site-breed, bijv. “pasta + vraag”):
    /tags/intersection/pasta/vraag
  • Categorie + multi-tag (gebruik Geavanceerd Zoeken):
    /search?q=category:koken/italiaans%20tags:pasta+vraag

Vragen voor Benadering A

  1. Is de aanbevolen praktijk om een 3e categorieniveau te vermijden en “Focus” als tags te houden?
  2. Zijn er valkuilen met categoriewebpagina’s die slechts één ?tags= filter ondersteunen (waardoor Geavanceerd Zoeken nodig is voor multi-tag binnen één categorie)?

Benadering B (contenttype = categorieën, onderwerp = tags)

  • Categorieën: topniveau (of een paar) voor Vragen, Discussies, How-to’s, Evenementen, Vacatures, Bulletins.

  • Tags (drie groepen voor onderwerp):

    • Onderwerpgebied (bijv. koken, fotografie) — limiet één
    • Subonderwerp (bijv. italiaans, portret) — limiet één
    • Focus (bijv. pasta, belichting) — 1 vereist (of optioneel)

URL-patronen (Benadering B)

  • Vooraf ingevuld composer (type categorie + onderwerp tags):
    /new-topic?category=vragen&tags=koken,italiaans,pasta
  • Bladeren door een type op onderwerp (bijv. Vragen over Italiaans):
    /c/vragen?tags=italiaans (multi-tag + categorie → Geavanceerd Zoeken)
  • Site-brede onderwerp-intersecties (onafhankelijk van type):
    /tags/intersection/italiaans/pasta

Vragen voor Benadering B

  1. Maakt het splitsen van content over “type” categorieën het browsen op onderwerp moeilijker?
  2. Zijn er valkuilen bij het vereisen van meerdere taggroepen (Onderwerpgebied + Subonderwerp + Focus) per onderwerp?

Overkoepelende vragen

  • Best practices vandaag: Een ondiepe categorieweefsel (1-2 niveaus) aanhouden en details in tags pushen?
  • Wanneer is een 3e categorieniveau gerechtvaardigd? Alleen voor werkelijk hoog-volume Focus-gebieden die aparte permissies/landingspagina’s nodig hebben?
  • Feature-scoping: Als we Opgelost/Stemmen inschakelen, is het dan beter om ze te scopen op onderwerp-categorieën in Benadering A, of op “Vragen” categorieën in Benadering B?
  • Composer UX: Zijn vooraf ingevulde composerlinks (/new-topic?category=...&tags=...) nog steeds de voorkeursmanier om auteurs te begeleiden?
  • Zoek UX: Zijn er nieuwere patronen voor categorie + multi-tag filtering (voorbij Geavanceerd Zoeken) waar we van moeten weten?

Alvast bedankt voor aanwijzingen, voorbeelden en “wat voor jou werkte”!

1 like
2

I think the answer depends a bit upon your expectations for how much the different subject matters within your community appeal to a given member.

Do you expect a lot of overlap between the groups that discuss photography and cooking? If so, tags for these different subjects probably works well.

Or are you trying to serve multiple sub communities – one for cooking, and one for photography – within the same site? If so, you may prefer categories for each.

I’m going to make an assumption that you’re talking about a single community first, where people may together discuss many subjects.

My suggestion would be to start with something more like Approach B.

Having different categories for the different types of content will enable you to more clearly signal what kind of discussion it is, and what the expected behavior is of the participants. You can take that further in some cases by configuring the categories for those purposes (e.g. using the solved plugin for a Q&A category).

Then, lean first on tags for the subject matter. That gives you the freedom to apply multiple tags to discussions when there is overlap (photos of cooking!).

If, at some point, you observe it’s helpful to more clearly divide some subject matter from others, you can use the tags to help recategorize things.

I’m general, we recommend fewer categories, rather than more, especially when starting out, and a shallower hierarchy rather than a deep one. By default we only support two levels of depth. You have to go out of your way to turn on support for a third.

I don’t know that people heavily use URLs to prefill the composer. I can imagine it being useful in some scenarios but I would suggest leaving that idea aside until you find a need for it.

For discovery, something else to check out is the /filter page, which lets you construct more custom topic lists, which you could configure in your sites sidebar: Filtering topic lists in Discourse

2 likes
3

Thank you, Mcwumbly. I realize my earlier question didn’t set the full context—it was a bit tricky to articulate. Here’s additional background to frame our use case and user expectations: we’re building a forum in the following context:

(Food-only niche forum to illustrate the structure)

1) Subject Matter (three levels; can be categories or tags)

  • L1 = Cuisine — Italian, Caribbean, Indian, Mexican
  • L2 = Focus — examples: pasta (under Italian), tacos (under Mexican), chaat / tandoori (under Indian)
  • L3 = Micro-focus — techniques/dishes/ingredients, e.g., extruded-pasta, naan, guajillo, sous-vide

Reality of use: About 70% of posts happen at L2 (Focus) combined with an L3 (Micro-focus).
• If L3 is a category, the topic is posted in L3.(important note here we will have L3 categories considerable higher name when compared to L2 and L1)
• If L3 is a tag, the topic is posted in L2 with the L3 tag attached.

2) Content Types (cross-cutting; can be categories or tags)

Each topic type needs a distinct composer form:

  • Question → Problem • What I tried • Environment • Expected vs. Actual
  • How-to / Article → Prereqs • Steps • Verification • Gotchas
  • Event → Start/End • Timezone • Location/Link • RSVP
  • Job → Role • Location/Remote • Requirements • How to apply
  • (Plus) Discussion

3) Open decision (mirrors the enterprise case)

  • Should Cuisine / Focus / Micro-focus be categories (with tag helpers) or tags (with a shallow category layer)?
  • Should topic types be categories (easy per-type templates) or tags (keeps Cuisine/Focus as the primary “place”)?
  • With 70% of activity at Focus + Micro-focus, which option best preserves strong Focus landing pages while keeping the IA simple?

Summary of our constraints & goals (applies to both versions)

  • Keep navigation intuitive where users actually spend time (L2 + L3)…how we still need to give some context here (reference of L1 whether it is italian or mexican-where post is done from breadcrumb stand point or SEO stand point )
  • Avoid unnecessary category bloat, but still provide clear “home bases” for heavy-traffic subjects.
  • Enforce exactly one Content Type per topic and support subject intersections (e.g., Software + Technical Area, or Cuisine + Focus).
  • Ensure the right composer form appears for each Content Type, regardless of whether types are modeled as categories or tags.

We’re looking for guidance on which modeling choice (categories vs. tags for Subject Matter and Content Types) best fits these constraints, given that most engagement happens at L2 + L3 with different content type with different forms for each content type.

2 likes
4

Om u hier het best mogelijke antwoord te geven, zou het noodzakelijk zijn om nog dieper in uw specifieke context te duiken. Ik zou verder willen ingaan op uw specifieke onderwerpsgebied, de verschillende gebruikerspersona’s in uw community, hoe zeker u bent van hun behoeften en gedrag, of u al een actieve community heeft, en zo ja, hoe groot en actief deze is, enzovoort.

Bij gebrek daaraan generaliseren we natuurlijk, en het advies dat u krijgt, past mogelijk wel of niet het beste bij u.

Dat gezegd hebbende, gezien wat u tot nu toe heeft gedeeld, denk ik dat ik de zaken als volgt zou aanpakken:

  1. Maak in eerste instantie alleen categorieën voor de use-cases (vragen, evenementen, enz.); gebruik tags voor het onderwerpsgebied.
  2. Wanneer subcommunities ontstaan die hun eigen ruimte nodig hebben, maak dan een hoofdcategorie voor hen, maak een hoofdcategorie “subcommunities” (naam naar keuze) en maak daarbinnen subcategorieën voor elk van hen – hierin zouden géén use-case categorieën zijn. De aanname is dat dit meer vrije discussies zijn onder opkomende hechte groepen, die dieper op een onderwerp ingaan terwijl ze blijven bijdragen in de andere hoofdcategorieën.
  3. Als die subcommunities groeien tot het punt waarop ze hun eigen use-case-gebaseerde categorieën nodig hebben, promoot ze dan naar hoofdcategorieën en dupliceer de use-case-gebaseerde subcategorieën daarbinnen (vragen, evenementen, enz.); nestel de initiële set categorieën onder een algemenere hoofdcategorie om de “hoofd” community weer te geven.
  4. Blijf tags gebruiken om inhoud te verbinden over al deze categorieën op basis van het onderwerpsgebied.
2 likes
5

Bedankt Mcwumbly voor je reactie en het was logisch om ook anderen mee te nemen om de aanpak te bepalen. We hebben de aanpak min of meer bepaald door het mentale model, de flow en de voorgestelde manier van werken in de discussie.

2 likes