Isolamento per categoria

Comunità
,
1

Vorrei eseguire una singola istanza di Discourse per un programma universitario, dove diverse categorie di primo livello corrispondono a diversi corsi e dove l’accesso è gestito dai gruppi. Affinché gli istruttori e gli studenti del corso possano avere un’impressione coesa di un corso, vorrei fornire una sensazione di isolamento dei diversi corsi. Pertanto, vorrei che la mia istanza offrisse un’esperienza di navigazione simile a Teams/Slack/Mattermost, dove ci sono team relativamente isolati e gli utenti devono passare da uno all’altro. Per la mia istanza, ciò significherebbe che l’interfaccia utente enfatizza i dati relativi al corso attualmente selezionato. Ad esempio, gli utenti trascorrono la maggior parte del tempo in una delle categorie di primo livello e la selezione di una di esse filtra le sottocategorie e i canali di chat che possono facilmente vedere.

Un’esigenza simile si presenta su un’istanza in cui diverse categorie corrispondono a diversi gruppi di ricerca (vorrei eseguirne una anche in quel caso).

Quali sono gli strumenti esistenti che possono aiutare a raggiungere questo obiettivo?

4 Mi Piace
2

Caso d’uso interessante! Una possibile soluzione è semplicemente disattivare le categorie non correlate, in modo che non vengano visualizzate negli elenchi degli argomenti.

3

In realtà non voglio che vengano silenziati: uno studente seguirà probabilmente più corsi contemporaneamente e le notifiche da tutti vanno bene. Piuttosto, voglio dare un’impressione più chiara di “ora sto guardando il corso X”.

1 Mi Piace
4

In realtà, mi sembra che avrei bisogno di qualcosa di simile

Ma con una “home” selezionabile.

5

Sembra che il gruppo primario = home selezionata, no? Devi abilitare user_selected_primary_groups in modo che gli utenti possano cambiare il loro gruppo primario nella pagina delle preferenze del loro account.

2 Mi Piace
6

Idealmente, vorrei qualcosa di più effimero e meno visibile pubblicamente. Tuttavia, immagino che se non uso il titolo e il flair, allora un componente dell’interfaccia utente che cambia il gruppo primario funzionerebbe come un selettore di squadra.

Qualcosa come il selettore della barra laterale aggiuntivo che è stato in esecuzione qui come esperimento qualche giorno fa sarebbe fantastico per questo.

7

Potresti farlo. Potresti anche cambiare il logo del sito a seconda del loro gruppo primario; l’ho fatto per un sito che ha più università che condividono un’istanza. Forse avresti un componente a tema con un menu a discesa nella barra superiore che permetterebbe loro di selezionare il loro gruppo primario (e magari dire “classe” invece di “gruppo”).

8

@Anton_Akhmerov speri di farlo da solo o saresti disposto a pagare qualcuno per farlo al posto tuo? Fammi sapere!

Se vuoi farlo da solo, vorrei spostare questo in Dev in modo che tu possa lavorarci lì e riferire alla community e ricevere input dai colleghi membri. Spostiamo questo in Dev.

Se vuoi pagare qualcuno, lo sposterò in Marketplace.

9

Dev per favore :folded_hands: :smiling_face_with_sunglasses:

Inoltre, se qualcuno in Dev ha dei suggerimenti, sarebbe assolutamente meraviglioso :heart_eyes:

13

Penso che potrebbe essere meglio spostare questo in Community e discutere ulteriormente del tuo caso d’uso, di come soddisfare al meglio le tue esigenze oggi e di fare spazio ad altri che potrebbero aver avuto esigenze simili e le hanno risolte.

Quindi, se vengono identificate lacune specifiche nel prodotto che ritieni abbastanza importanti da costruire tu stesso o da sostenere, possiamo creare argomenti separati in Feature e/o Dev per queste idee.

Ti sembra in linea con il tuo pensiero? O sei già nella fase “Sono pronto a costruire i pezzi mancanti”?

1 Mi Piace
14

Community ha anche senso :grin:. La funzionalità sembra complicata e sembra essere in qualche modo allineata con le esigenze della community, considerando la popolarità di richieste come questa

Ho intenzione di lavorarci, ma finora il mio piano è piuttosto vago.

2 Mi Piace
15

In seguito, ecco come immagino di soddisfare al meglio le vostre esigenze con le funzionalità standard di Discourse. Potrebbe non essere esattamente ciò che avete in mente, ma penso che valga la pena considerarlo come punto di partenza per la discussione.

Innanzitutto, faccio alcune supposizioni, che potrebbero essere valide o meno. Vi prego di farmi sapere dove sbaglio:

  1. Ci saranno molti corsi (decine, forse centinaia)
  2. La configurazione dei corsi avverrà periodicamente, in batch consistenti, all’inizio di ogni semestre (2-4 volte all’anno)
  3. I corsi avranno una data di fine vita
  4. Le persone che gestiscono i corsi devono avere una certa capacità di configurarli autonomamente
  5. Le persone che gestiscono i corsi avranno un’esperienza limitata o nulla nella gestione di un sito Discourse.
  6. Le persone che gestiscono i corsi hanno solo bisogno di vedere i propri. Potrebbero voler vedere occasionalmente quelli degli altri come esempi, ma non hanno bisogno di una partecipazione continua ad essi.
  7. ^ idem per le persone che seguono i corsi
  8. C’è un team molto piccolo che gestisce il sistema nel suo complesso
  9. I corsi non necessitano realmente di sottocategorie; l’uso di tag per organizzare i contenuti all’interno dei corsi sarebbe sufficiente

Dato che queste sono vicine, ecco cosa suggerirei, prima a grandi linee:

  1. Creare un piccolo numero di categorie di primo livello: una per “Corsi Attuali”, una per “Corsi Passati”, una per “Corsi Futuri” e una o più per cose più generali sul sistema stesso (ad esempio, come usare il sito)
  2. Impostare lo stile della home page su “box con categorie” in modo che siano ben visibili
  3. Usare sottocategorie per ogni corso
  4. Crearle in “Corsi Futuri”
  5. Spostarle in “Corsi Attuali” all’inizio del semestre
  6. Al termine di un corso, spostarlo da “Corsi Attuali” a “Corsi Passati”
  7. Controllare l’accesso ai Corsi utilizzando i Gruppi (maggiori dettagli di seguito)

Controllo dell’accesso:

  1. Per ogni corso, creare un set di gruppi come segue, ad esempio: foo_interessati, foo_iscritti, foo_admin
  2. Creare due gruppi aggiuntivi: “sfoglia_corsi” e “sfoglia_corsi_passati”
  3. Impostare le categorie in “Corsi Futuri” e “Corsi Attuali” in modo che siano accessibili solo alle persone nei gruppi per il corso specifico e alle persone nel gruppo “sfoglia_corsi”.
  4. Impostare le categorie in “Corsi Passati” in modo che siano accessibili solo alle persone nei gruppi per il corso specifico e alle persone nel gruppo “sfoglia_corsi_passati”.

Esperienza utente per gruppi e corsi

  1. Avere un argomento fissato nella categoria di primo livello per “Corsi Futuri” che spieghi come sfogliare i corsi, con un’agevole opzione per le persone di unirsi al gruppo “sfoglia_corsi”.
  2. ^ idem per “Corsi Attuali”
  3. ^ idem per “Corsi Passati”

Per i singoli corsi, avere un argomento fissato nella categoria che spieghi come iscriversi al Corso:

  1. Unirsi al gruppo “foo_interessati” e/o “foo_iscritti”
  2. Aggiungere il corso alla propria barra laterale

L’amministrazione sarà un po’ laboriosa all’inizio, poiché per ogni nuovo corso qualcuno con i privilegi appropriati dovrà:

  1. Creare la categoria
  2. Creare i gruppi
  3. Creare l’argomento fissato
  4. Aggiungere le persone al gruppo _admin
  5. Fornire loro la documentazione necessaria per gestire il proprio corso

Parte di ciò potrebbe essere automatizzata con alcuni strumenti leggeri. A seconda di chi sia il team di amministrazione principale, potrebbe avere senso iniziare con qualcosa di esterno che utilizzi semplicemente l’API. Oppure, potrebbe essere necessario qualcosa di più basato sull’interfaccia utente, integrato in Discourse come componente tematico o plugin. Ma suggerirei di iniziare in modo snello qui, e concentrarsi prima sulla definizione di un processo che funzioni, quindi progettare gli strumenti attorno ad esso.

La scalabilità delle categorie è una possibile preoccupazione qui. Discourse presenta alcuni problemi di prestazioni e usabilità quando il numero di categorie diventa troppo elevato (centinaia o migliaia). Gli utenti con accesso a più categorie ne risentiranno, mentre quelli con accesso limitato no. Questa è parte della motivazione per limitare l’accesso alle categorie come ho delineato.

Sono molto interessato a ricevere qualsiasi feedback o domanda in merito a quanto sopra.

1 Mi Piace
16

Ciao @mcwumbly, grazie per una descrizione dettagliata e ponderata.

Ciò che descrivi è effettivamente vicino a ciò che ho in mente, con alcune differenze.

Dall’esecuzione di un’unica istanza per un corso per circa 5 anni, ho capito che è molto meno faticoso nascondere o spostare discussioni obsolete piuttosto che ricreare un’istanza di corso da zero. Quindi, in pratica, lo spazio di discussione per un corso è fisso, ma la maggior parte degli argomenti ha una fine vita.

Immagino principalmente che i team dei corsi dovranno gestire un corso piuttosto che configurarlo.

I nostri corsi hanno circa 200 studenti e un team di circa 10 persone, inclusi i TA. Ciò giustifica almeno diverse categorie:

  • Domande e risposte sui contenuti (gli studenti pubblicano, il team del corso risponde)
  • Organizzazione del corso (come sopra, ma solo per questioni organizzative)
  • Annunci (il team del corso pubblica, gli studenti possono rispondere)
  • Domande sulla valutazione (gli studenti pubblicano, solo il team del corso può vedere e rispondere).
    Questo lo intendo affrontare utilizzando Private Topics Plugin e Assigning based on post content.
  • Discussione del team del corso (visibile solo al team del corso)

Credo che l’uso delle sottocategorie coprirà questa esigenza.

Mi rendo conto che si potrebbe creare un raggruppamento a livello di istanza di quanto sopra, simile a ciò che descrivi, ma sembra più ragionevole inserire tutto ciò in un’unica categoria.

Tutto sommato, penso che le attuali capacità di discourse si adattino bene a questo caso d’uso, ad eccezione della funzionalità puramente frontend di dover dare a un membro del team del corso o a uno studente la sensazione di guardare un singolo corso, piuttosto che tutti i corsi contemporaneamente.

Il componente tematico della documentazione è un po’ simile in quanto consente all’utente di “entrare” in una categoria, ma non consente di “rimanere” facilmente all’interno di una categoria.

1 Mi Piace
17

Sì, spostare argomenti in massa è un po’ complicato, ma riassegnare un’intera categoria da “corsi attuali” a “corsi passati” sarebbe piuttosto facile, penso.

I vantaggi di farlo sono che ogni semestre potrebbe iniziare da capo.

Questo potrebbe però essere uno svantaggio, a seconda che tu ritenga che il contenuto dei semestri precedenti sia prezioso o dannoso, e quanto sforzo richiede al tuo team per creare nuove categorie per ogni semestre.

Avere categorie che durano indefinitamente riduce certamente quello sforzo. Se è fattibile, sembra fantastico.

E se diventa un problema avere contenuti vecchi in giro per sempre, forse questo è “un buon problema da avere”, non dovrebbe essere troppo difficile passare al modello che ho suggerito in seguito.

Penso che la tua teoria qui sia valida.

Avere sottocategorie per ciascuna di queste attività all’interno di ogni categoria del corso sembra ragionevole.

Penso che dipenda ancora un po’ da quanto sei sicuro che la complessità aggiuntiva sia giustificata e, in tal caso, se quella sia la forma giusta.

Potresti usare un tag limitato per gli annunci invece, il che ha alcuni vantaggi.

Gli ultimi due potrebbero essere gestiti tramite messaggi privati di gruppo invece che tramite una categoria.

Penso che entrambe le opzioni valgano la pena di essere considerate. Ci sono alcuni compromessi tra di esse.

Man mano che approfondisci l’impostazione, continua a fare domande quando ti imbatti in esse.

E indipendentemente dalla direzione che sceglierai per iniziare, mi piacerebbe ricevere aggiornamenti occasionali su come vanno le cose!

2 Mi Piace
18

Un componente del tema potrebbe, ad esempio, cambiare l’icona e farla puntare alla home page del corso anziché a quella globale.

Ho iniziato a usare discourse per insegnare corsi di tecnologia didattica quando ero professore di educazione.

Ho usato una categoria per i materiali del corso e ho fatto in modo che gli studenti rispondessero come argomento collegato per consegnare il loro lavoro (in categorie pubbliche). In un argomento a livello di semestre, un programma di studi farebbe riferimento ai materiali didattici canonici indicando quando fare cosa. Ho poi usato un set di tag per indicare quali argomenti dovevano essere valutati e ho scritto uno script che verificava se mi piaceva un argomento per indicare se avevo approvato il lavoro.

Ho scritto uno script che aggiornava un csv dal lms dell’università per facilitare il caricamento dei voti lì.

La cosa che penso mi sia piaciuta di più, e di cui avrei potuto scrivere se fossi stato un accademico migliore (e non avessi lasciato quel lavoro), era che aggiornavo i compiti durante il corso per correggere cose poco chiare, piuttosto che aspettare l’anno successivo per apportare miglioramenti. E poiché tutte le modifiche erano disponibili nella cronologia, gli studenti erano liberi di fare qualsiasi versione del compito volessero (o avessero fatto prima che apportassi la modifica). Penso ancora che migliorare il corso al volo piuttosto che aspettare un anno sperando di ricordare quali fossero i problemi fosse un’ottima idea.

4 Mi Piace