Una conversazione significativa avviene quando tutti nella stanza hanno ascoltato i pensieri degli altri, e una timeline piatta e lineare è sempre stata il modo migliore per rendere ciò possibile su Discourse. Ma il formato piatto non si adatta a ogni comunità. Nei forum più grandi e dinamici, migliaia di risposte su un’unica timeline rendono impossibile per chiunque stare al passo. Ecco perché quest’anno abbiamo sperimentato con cautela una visualizzazione delle risposte completamente nidificata e riteniamo sia un’ottima soluzione per le comunità che hanno superato i limiti del formato piatto.
Ciò che è iniziato come un plugin sperimentale è diventato un progetto integrato direttamente in Discourse. Ecco un’anteprima di come appare un argomento nidificato al momento:
Le impostazioni del sito per attivare questa funzione sono disponibili nell’interfaccia di amministrazione. Vai alla sezione “Risposte nidificate” per controllare la funzione, le modalità di ordinamento predefinite, la profondità massima e altro ancora.
Roadmap
Al momento della stesura, siamo ancora agli inizi per quanto riguarda le risposte nidificate. La roadmap non è ancora completamente definita. Ecco alcune cose che sappiamo faremo:
Migliorare l’esperienza su dispositivi mobili
Ripensare la timeline degli argomenti per la vista nidificata. Al momento non c’è alcuna timeline negli argomenti mentre si è in modalità risposte nidificate
Aggiungere almeno una nuova modalità di ordinamento per i post con decadimento basato sull’età, simile alla nostra modalità “Caldo” per le liste di argomenti.
Limitazioni
Quando la nidificazione è abilitata per una categoria, gli argomenti esistenti rimangono in modalità piatta. Ogni argomento può essere singolarmente commutato dalla chiave inglese dell’amministratore, ma al momento non esiste un modo per convertire un’intera categoria esistente in modalità nidificata.
Vorremmo avere il tuo feedback
Abbiamo bisogno del tuo feedback e della tua esperienza nell’uso di questa funzione per orientarne lo sviluppo. Se questa soluzione ti sembra adatta alla tua comunità, provala e facci sapere cosa pensi tu e i tuoi utenti!
DIO SÌ. Ottimo tempismo. Sto migrando un forum su un nuovo server con 2 container stasera e non vedo l’ora di passare da questo al nuovo quando tra un paio di settimane inizierà la stagione regolare e le nostre pool sportive. Dovrebbe essere un ottimo caso di test.
Sarà così figo avere la possibilità di scegliere tra discussioni piatte e incorporate: grazie per questo @markvanlan e Team.
Solo per precisare: quando ci sono nuove risposte in più rami dell’albero, sembra che la visualizzazione a thread singolo ne mostri solo una alla volta. Ho dovuto tornare indietro più volte, con il conteggio dei non letti che diminuiva di uno ogni volta.
Ok, non sono sicuro di quanto sia praticabile l’attivazione/disattivazione in blocco per le categorie con decine di migliaia di argomenti. Potrebbero essere un’opzione i job di conversione in blocco/lotti di Rails?
E questo è reversibile? È possibile convertire un argomento threadato di nuovo in un argomento piatto?
Sì, sono d’accordo con te. Questa è una limitazione per ora, e qualcosa su cui continueremo assolutamente a riflettere.
Il motivo principale per cui ho scelto di non convertire gli argomenti storici in una categoria quando è abilitato è che gli utenti probabilmente interagiranno in modo diverso. In modalità piatta, i vari pulsanti Rispondi contano meno. Il post va in fondo all’argomento. Non sono sicuro che gli utenti premano sempre intenzionalmente quello “giusto” che corrisponderebbe alla vista nidificata.
In pratica, temo che gli amministratori lo abilitino per gli argomenti storici e poi improvvisamente la conversazione diventi illeggibile. Continueremo a pensarci. La modifica più semplice che riesco a immaginare è che quando si attiva l’impostazione della categoria, appaia un popup modale che chiede: “Vuoi applicare questa modifica agli argomenti esistenti?”
Ho sempre pensato che le etichette “Rispondi” potessero essere più specifiche – quindi qualche tempo fa ho utilizzato del CSS personalizzato per aggiungere contesto:
/* aggiungi testo al pulsante Rispondi per il messaggio originale (aka Argomento) */
#post_1 nav.post-controls {
.actions {
button.reply {
span.d-button-label:after {
// Aggiunge questo contenuto dopo Rispondi
content: " a questo Argomento";
}
}
}
}
/* aggiungi testo al pulsante Rispondi per tutti i messaggi successivi (li chiamo commenti) */
nav.post-controls {
.actions {
button.reply {
span.d-button-label:after {
// Aggiunge questo contenuto dopo Rispondi
content: " a questo commento";
}
}
}
}
/* aggiungi testo al pulsante blu Rispondi (all'Argomento) che appare alla fine della pagina */
#topic-footer-buttons {
.topic-footer-main-buttons {
button.btn-primary.create {
span.d-button-label:after {
// Aggiunge questo contenuto dopo Rispondi
content: " all'Argomento principale";
}
}
}
}
Il problema con questa soluzione è che non verrà tradotto nell’interfaccia utente per gli utenti che hanno un’impostazione linguistica diversa dall’inglese nelle loro preferenze
Questo suggerisce che dovrebbe essere testata prima nelle nostre comunità in isolamento, prima di procedere tutti alla conversione di ogni argomento esistente?
Funzionerebbe, a condizione che supporti decine di migliaia di argomenti.
Ma dovrebbe essere chiarito in modo molto netto che non c’è modo di tornare indietro da questo
Questa funzionalità verrà implementata prima qui su meta o su https://try.discourse.org, così da poterla testare al di fuori dei nostri ambienti di produzione?
Se fosse la mia community, la testerei prima in isolamento. D’altro canto, otterreste un feedback più prezioso più velocemente abilitandolo per tutta la vostra community . Scherzi a parte, penso che testare in isolamento sia probabilmente una buona idea, ma qui non ci sono migrazioni di dati distruttive. Può essere abilitato e disabilitato in sicurezza. Nessuna decisione che prenderete qui vi bloccherà in una direzione o nell’altra.
Immagino di aver risposto accidentalmente a questa parte! Abilitare l’annidamento crea semplicemente un record nested_topic per ogni argomento nel database e avvia un lavoro per calcolare i conteggi delle risposte lungo l’albero di discendenza. Disabilitare l’annidamento rimuove quel record nested_topic e si torna alla struttura piatta, nessun problema.
C’è un motivo per cui questa opzione può essere attivata solo dallo staff e non dagli utenti normali? Quando ho visto che sarebbe arrivata su Meta, pensavo che sarebbe stata aggiunta al menu dei tipi di post, ma l’interruttore è nascosto dietro l’icona della chiave inglese dello staff.
Non vogliamo che questa sia una decisione o una preferenza dell’utente. Spetta agli amministratori decidere come dovrebbe funzionare il loro sito. I due paradigmi sono molto diversi e gli utenti non dovrebbero interagire in modo così diverso sullo stesso contenuto. Questa è almeno la nostra attuale opinione.
I blocchi pubblicitari non funzionano bene in questa struttura e la conversione dei topic tende a generare un bug in cui gli elementi sullo schermo scompaiono e si può modificare solo il titolo.
Bellissima funzionalità! Tuttavia sono più curioso riguardo all’ordinamento Top / New / Old che non al layout nidificato in sé. Ho implementato controlli di ordinamento simili nella mia app mobile (un client Discourse) e mi piacerebbe supportarli nativamente invece di usare il mio metodo attuale, anche se funziona, come mostrerò di seguito.
Guardando il codice sorgente, vedo che GET /n/{slug}/{topic_id}.json?sort={top|new|old}&page={n} restituisce l’argomento in vista nidificata ordinato secondo la modalità scelta. La mia domanda: c’è interesse a esporre solo l’ordinamento tramite l’endpoint esistente /t/{slug}/{topic_id}.json (ad esempio ?sort=top) in modo che anche i client in vista piatta possano trarne beneficio?
Se l’ordinamento fosse disponibile nella vista piatta, i client di terze parti potrebbero optare per questa funzionalità senza adottare il modello di rendering in vista nidificata.
Sono consapevole che la struttura dei dati della vista nidificata (post radice + figli lazy) è ciò che rende fattibile l’ordinamento lato server, e che la vista piatta utilizza una paginazione diversa. Se un ordinamento completo in vista piatta non è realistico per motivi di prestazioni, anche un opzionale ?sort=top&limit=N sarebbe sufficiente per abilitare una vista “evidenziati”.
. Scherzi a parte, penso che testare in isolamento sia probabilmente una buona idea, ma qui non ci sono migrazioni di dati distruttive. Può essere abilitato e disabilitato in sicurezza. Nessuna decisione che prenderete qui vi bloccherà in una direzione o nell’altra.
