Categorie vs. tag per "tipo di contenuto" vs. "argomento" — quali sono i pattern URL corretti?

Comunità
1

Ciao a tutti — cerco indicazioni su come strutturare il nostro Discourse, poiché se adottiamo l’approccio - Opzione 1, avremo 1200 categorie con 3 livelli di categorie (L1-L2-L3) e se eliminiamo L3, avremo circa 150 categorie con L1 e L2

Contesto
Pubblichiamo diversi tipi di contenuto (domande, discussioni, guide/articoli, eventi, offerte di lavoro, bollettini) su diversi argomenti. Pensate a esempi come:

  • Aree tematiche (L1): Cucina, Fotografia
  • Sottoargomenti (L2): Italiana (sotto Cucina), Ritratto (sotto Fotografia)
  • Focus (L3): pasta, lievito madre, illuminazione, composizione

Sono indeciso tra due approcci e gradirei consigli sulle best practice.

Approccio A (argomento = categorie, tipo di contenuto = tag)

  • Categorie

    • L1 (Area tematica): cucina, fotografia
    • L2 (Sottoargomento): italiana, ritratto
    • (Domanda) Dovremmo aggiungere un 3° livello di categoria per il “Focus” (es. cucina → italiana → pasta) o mantenere l’albero superficiale e modellare il Focus come tag?

  • Tag

    • Tag tipo-di-contenuto obbligatorio (esattamente uno): domanda, discussione, guida, evento, offerta di lavoro, bollettino
    • Tag focus opzionale/obbligatorio: pasta, lievito madre, illuminazione, composizione, …

Pattern URL (Approccio A)

  • Compositore precompilato (L2 + tipo + focus opzionale):
    /new-topic?category=cucina/italiana&tags=domanda,pasta
  • Categoria filtrata per un tag (es. “Domande in italiano”):
    /c/cucina/italiana?tags=domanda
  • Intersezioni di tag (AND) (su tutto il sito, es. “pasta + domanda”):
    /tags/intersection/pasta/domanda
  • Categoria + multi-tag (usa Ricerca Avanzata):
    /search?q=category:cucina/italiana%20tags:pasta+domanda

Domande per l’Approccio A

  1. La pratica consigliata è evitare un 3° livello di categoria e mantenere il “Focus” come tag?
  2. Ci sono insidie con le pagine di categoria che supportano solo un filtro ?tags= (richiedendo la Ricerca Avanzata per multi-tag all’interno di una singola categoria)?

Approccio B (tipo di contenuto = categorie, argomento = tag)

  • Categorie: di primo livello (o poche) per Domande, Discussioni, Guide, Eventi, Offerte di lavoro, Bollettini.

  • Tag (tre gruppi per argomento):

    • Area tematica (es. cucina, fotografia) — limite uno
    • Sottoargomento (es. italiana, ritratto) — limite uno
    • Focus (es. pasta, illuminazione) — 1 obbligatorio (o opzionale)

Pattern URL (Approccio B)

  • Compositore precompilato (categoria tipo + tag argomento):
    /new-topic?category=domande&tags=cucina,italiana,pasta
  • Naviga un tipo per argomento (es. Domande sulla cucina italiana):
    /c/domande?tags=italiana (multi-tag + categoria → Ricerca Avanzata)
  • Intersezioni di argomenti su tutto il sito (indipendenti dal tipo):
    /tags/intersection/italiana/pasta

Domande per l’Approccio B

  1. Dividere il contenuto tra categorie di “tipo” rende più difficile la navigazione per argomento?
  2. Ci sono insidie nel richiedere più gruppi di tag (Area tematica + Sottoargomento + Focus) per argomento?

Domande trasversali

  • Best practice attuali: Mantenere un albero di categorie superficiale (1-2 livelli) e spostare i dettagli nei tag?
  • Quando è giustificato un 3° livello di categoria? Solo per aree di Focus veramente ad alto volume che necessitano di permessi/pagine di destinazione separate?
  • Ambito delle funzionalità: Se abilitiamo Risolto/Votazione, è meglio limitarne l’ambito alle categorie di argomento nell’Approccio A, o alle categorie di “Domande” nell’Approccio B?
  • UX del compositore: I link al compositore precompilato (/new-topic?category=...&tags=...) sono ancora il modo preferito per guidare gli autori?
  • UX della ricerca: Ci sono pattern più recenti per il filtraggio categoria + multi-tag (oltre la Ricerca Avanzata) che dovremmo conoscere?

Grazie in anticipo per suggerimenti, esempi e “cosa ha funzionato per voi”!

1 Mi Piace
2

Penso che la risposta dipenda un po’ dalle tue aspettative su quanto i diversi argomenti all’interno della tua community attraggano un dato membro.

Ti aspetti molta sovrapposizione tra i gruppi che discutono di fotografia e cucina? Se sì, i tag per questi diversi argomenti probabilmente funzionano bene.

Oppure stai cercando di servire più sottocommunity – una per la cucina e una per la fotografia – all’interno dello stesso sito? Se sì, potresti preferire categorie per ciascuna.

Farò un’ipotesi che tu stia parlando prima di una singola community, dove le persone possono discutere insieme molti argomenti.

Il mio suggerimento sarebbe di iniziare con qualcosa di più simile all’Approccio B.

Avere diverse categorie per i diversi tipi di contenuto ti permetterà di segnalare più chiaramente che tipo di discussione è e quale sia il comportamento atteso dei partecipanti. Puoi approfondire ulteriormente in alcuni casi configurando le categorie per tali scopi (ad esempio, utilizzando il plugin solved per una categoria di domande e risposte).

Quindi, fai affidamento prima sui tag per l’argomento. Questo ti dà la libertà di applicare più tag alle discussioni quando c’è sovrapposizione (foto di cucina!).

Se, a un certo punto, osservi che è utile dividere più chiaramente alcuni argomenti da altri, puoi usare i tag per aiutarti a ricategorizzare le cose.

In generale, raccomandiamo meno categorie, piuttosto che più, specialmente all’inizio, e una gerarchia più superficiale piuttosto che una profonda. Per impostazione predefinita supportiamo solo due livelli di profondità. Devi fare uno sforzo per abilitare il supporto per un terzo.

Non so se le persone utilizzino molto gli URL per precompilare il composer. Posso immaginare che sia utile in alcuni scenari, ma ti suggerirei di accantonare quell’idea finché non ne troverai la necessità.

Per la scoperta, qualcos’altro da controllare è la pagina /filter, che ti permette di costruire elenchi di argomenti più personalizzati, che potresti configurare nella barra laterale del tuo sito: Filtering topic lists in Discourse

2 Mi Piace
3

Grazie, Mcwumbly. Mi rendo conto che la mia domanda precedente non ha fornito il contesto completo: è stato un po’ complicato da articolare. Ecco uno sfondo aggiuntivo per inquadrare il nostro caso d’uso e le aspettative degli utenti: stiamo costruendo un forum nel seguente contesto:

(Forum di nicchia solo sul cibo per illustrare la struttura)

1) Argomento (tre livelli; possono essere categorie o tag)

  • L1 = Cucina — Italiana, Caraibica, Indiana, Messicana
  • L2 = Focus — esempi: pasta (sotto Italiana), tacos (sotto Messicana), chaat / tandoori (sotto Indiana)
  • L3 = Micro-focus — tecniche/piatti/ingredienti, ad es. pasta estrusa, naan, guajillo, sous-vide

Realtà d’uso: Circa il 70% dei post avviene a L2 (Focus) combinato con un L3 (Micro-focus).
• Se L3 è una categoria, l’argomento viene pubblicato in L3. (nota importante qui avremo categorie L3 con nomi considerevolmente più alti rispetto a L2 e L1)
• Se L3 è un tag, l’argomento viene pubblicato in L2 con il tag L3 allegato.

2) Tipi di Contenuto (trasversali; possono essere categorie o tag)

Ogni tipo di argomento necessita di un modulo di composizione distinto:

  • Domanda → Problema • Cosa ho provato • Ambiente • Atteso vs. Effettivo
  • Come fare / Articolo → Prerequisiti • Passaggi • Verifica • Insidie
  • Evento → Inizio/Fine • Fuso orario • Luogo/Link • RSVP
  • Lavoro → Ruolo • Luogo/Remoto • Requisiti • Come candidarsi
  • (Più) Discussione

3) Decisione aperta (rispecchia il caso aziendale)

  • Dovrebbero Cucina / Focus / Micro-focus essere categorie (con aiuti per i tag) o tag (con un livello di categoria superficiale)?
  • Dovrebbero i tipi di argomento essere categorie (modelli facili per tipo) o tag (mantenendo Cucina/Focus come “luogo” primario)?
  • Con il 70% di attività a Focus + Micro-focus, quale opzione preserva meglio le pagine di atterraggio Focus robuste mantenendo semplice l’IA?

Riepilogo dei nostri vincoli e obiettivi (si applicano a entrambe le versioni)

  • Mantenere la navigazione intuitiva dove gli utenti trascorrono effettivamente del tempo (L2 + L3)… come possiamo comunque fornire un certo contesto qui (riferimento a L1, sia esso italiano o messicano, da dove viene effettuato il post dal punto di vista del breadcrumb o dal punto di vista SEO).
  • Evitare un gonfiore non necessario delle categorie, pur fornendo “basi” chiare per argomenti ad alto traffico.
  • Imporre esattamente un Tipo di Contenuto per argomento e supportare intersezioni di argomenti (ad es. Software + Area Tecnica, o Cucina + Focus).
  • Garantire che appaia il modulo di composizione corretto per ciascun Tipo di Contenuto, indipendentemente dal fatto che i tipi siano modellati come categorie o tag.

Stiamo cercando una guida su quale scelta di modellazione (categorie vs. tag per Argomento e Tipi di Contenuto) si adatti meglio a questi vincoli, dato che la maggior parte del coinvolgimento avviene a L2 + L3 con diversi tipi di contenuto con moduli diversi per ciascun tipo di contenuto.

2 Mi Piace
4

Per poterti dare la migliore risposta possibile, sarebbe necessario approfondire il tuo contesto specifico. Vorrei indagare ulteriormente sul tuo particolare argomento, sulle diverse persone utente nella tua community, quanto sei sicuro delle loro esigenze e del loro comportamento, se hai già una community attiva e, in tal caso, quanto è grande e attiva, ecc.

In mancanza di ciò, stiamo generalizzando, ovviamente, e i consigli che ricevi potrebbero adattarsi meglio a te o meno.

Detto questo, date le informazioni che hai condiviso finora, penso che procederei in questo modo:

  1. Crea categorie solo per i casi d’uso iniziali (domande, eventi, ecc.); usa i tag per l’argomento.
  2. Man mano che emergono sottocommunity che necessitano di uno spazio proprio, crea una categoria di primo livello per esse, crea una categoria di primo livello “sottocommunity” (nome a tua scelta) e crea sottocategorie per ciascuna di esse – all’interno di queste, non ci sarebbero categorie basate sui casi d’uso. L’ipotesi è che si tratti di discussioni più libere tra gruppi emergenti strettamente connessi, che potrebbero approfondire un argomento insieme continuando a contribuire nelle altre categorie di primo livello.
  3. Se queste sottocommunity crescono al punto da necessitare delle proprie categorie basate sui casi d’uso, promuovile a categorie di primo livello e duplica le categorie basate sui casi d’uso al loro interno (domande, eventi, ecc.); annida il set iniziale di categorie sotto una categoria di primo livello più generale per rappresentare la community “principale”.
  4. Continua a usare i tag per collegare i contenuti attraverso tutte queste categorie per argomento.
2 Mi Piace
5

Grazie Mcwumbly per la tua risposta, è stato sensato considerare anche gli altri per decidere l’approccio. Abbiamo definito un approccio che tiene conto del modello mentale, del flusso e del modo di lavorare suggerito dal discorso.

2 Mi Piace