Non riesco a capire due cose:
Qualcuno ha già riscontrato questo problema?
È possibile, ma abbiamo un caso speciale che lo rende più complicato di un semplice inserimento. Il selettore di categoria consente solo l’aggiunta di categorie esistenti… ma attualmente consentiamo un’immissione personalizzata con @ per applicare il componente alla vista di primo livello “tutte le categorie”.
Dovremo separare questa funzionalità in un’impostazione separata e migrare le impostazioni esistenti per poter utilizzare il menu a discesa delle categorie.
Questa scheda?
Non riesco a riprodurre il problema, potrebbe essere già stato risolto — se lo incontri ancora, faccelo sapere.
Mi dispiace, da allora ho lasciato Discourse e ho riportato la mia community su Discord.
Questo è incredibilmente confuso. Potresti spiegare cosa significa “@” e come usarlo? L’ho visto nell’interfaccia utente delle Impostazioni Kanban e non sono riuscito a capire cosa fa.
Inoltre, perché avere un “@” personalizzato rende impossibile usare il menu a discesa? Non basterebbe aggiungere la voce “@” al menu a discesa? E ancora meglio, perché chiamarlo “@”? Dici “Tutte le categorie” in quel menu a discesa e fai in modo che utilizzi “@” dietro le quinte. Si è rivelato troppo criptico anche per me, uno sviluppatore software, che usa Discourse fin dalla sua nascita.
Questo è ovviamente fuori tema, ma vorrei aggiungere la mia opinione e dire che le frustrazioni persistenti con l’interfaccia utente di Discourse mi rendono completamente incapace di reclutare i miei partner e gli stakeholder del progetto per utilizzare Discourse. Tutti odiano l’interfaccia utente, semplicemente non riescono a usarla perché è confusa in ogni modo, e questa incapacità di impostare Kanban come strumento utile aggiunge solo frustrazione a quei partner che sto cercando di convincere ad adottare Discourse per la gestione del progetto. Per tornare alla questione effettivamente discussa in questo argomento, come diavolo dovrei spiegare il “@” a un manager che vuole solo aprire il pannello delle impostazioni e configurare le liste Kanban a suo piacimento? Sono tutte queste piccole cose che si sommano e disorientano completamente le persone quando entrano nello spazio Discourse, e cercano di andarsene immediatamente e mi chiedono di non interagire più con loro su questa piattaforma perché fa perdere loro tempo. Sono impotente nel far entusiasmare le persone per Discourse. E per peggiorare le cose, per qualche motivo il team di Discourse peggiora alcuni aspetti dell’interfaccia utente invece di migliorarli, vedi un recente aggiornamento qui e la mia critica: Now that the topic title is editable by click, I can't simply copy it without entering the edit mode
A proposito, se inserisco lì “@MyCategory” (cosa che ho fatto intuitivamente mentre cercavo di capire cosa fa il “@”), non mi dice alcun errore di validazione. Come si può considerare accettabile non dirmi che sto facendo qualcosa di sbagliato quando è ovvio dal punto di vista del programmatore, e può essere facilmente rilevato durante il “Salvataggio…” del valore dell’impostazione aggiornato?
Mi dispiace di aver dovuto dire tutto, soprattutto dopo aver visto che qualcuno ha lasciato Discourse ed è tornato su Discord, il che ha solo confermato le mie preoccupazioni e frustrazioni con l’interfaccia utente.
Mi stavo davvero sforzando, ma c’è troppa complessità. È come ai vecchi tempi: le guerre Android contro iPhone.
Android ti permetteva di personalizzare tutto ciò che volevi.
iPhone era super limitato, ma… funzionava e basta.
Questo è lo stesso caso con Discourse in questo momento. Credo che dobbiamo percorrere di più la strada di Antoine de Saint-Exupéry: “La perfezione si ottiene non quando non c’è più nulla da aggiungere, ma quando non c’è più nulla da togliere”.
C’è così tanta confusione (come i DM rispetto alle chat private, per citare la prima cosa che viene in mente) che è davvero difficile convincere le persone a usarlo liberamente. Su Discord, c’è meno attrito. Lo stesso vale per Skool. Penso che questo sia ciò a cui dovremmo mirare, non aggiungere altre funzionalità.
Recentemente un cliente ha lasciato Discourse proprio per la ragione che hai citato: troppa complessità.
Ma a dire il vero, guardando alcuni server Discord, non direi affatto che siano semplici? Ora puoi aggiungere molte cose a un server Discord (inclusi i bot).
Un enorme svantaggio dello spostarsi su Discord o su qualsiasi app personalizzata è che si perde SEO, giusto? Forse questo non ti interessa.
Chiunque lo abbia implementato ha scelto “@” come simbolo univoco per rappresentare gli elenchi di argomenti di primo livello quando non sono filtrati per categoria o tag. È come forum.example.com/latest o forum.example.com/top. Quindi inserisci “@” separatamente come voce a sé stante per applicarlo lì.
Concordo sul fatto che sia confuso, ma è qualcosa che può essere ignorato a meno che tu non voglia bacheche kanban globali.
Non lo fa, complica solo il passaggio al menu a discesa delle categorie perché dobbiamo anche creare una migrazione in modo da non ripristinare le impostazioni sui siti che lo stanno già utilizzando in questo modo.
Le impostazioni del tema sono dettate dalle API principali, quindi quando utilizziamo il tipo di elenco di categorie, non possiamo estenderlo con opzioni aggiuntive dal tema stesso.
Discourse non è un’azienda enorme, abbiamo vincoli di tempo per concentrarci sulle funzionalità più utilizzate e la refattorizzazione dei componenti (che sono offerti gratuitamente tra l’altro) può essere difficile da prioritizzare. Se qualcuno vuole sponsorizzare miglioramenti alle impostazioni kanban, possiamo certamente renderlo una priorità più alta.
Discord ha una funzionalità di bacheca kanban disponibile? Ho cercato ma non sono riuscito a trovare molto a parte un bot che si integra con un servizio kanban esterno.
Perdi anche un po’ di controllo, i tuoi utenti sono utenti Discord, il contenuto che pubblicano è anche contenuto di Discord. Quando qualcuno paga per Discord, il profitto è di Discord. Ci sono compromessi e costi per ogni piattaforma.
Sì, non è chiaro quando saremo in grado di dedicare attenzione alla funzionalità Kanban in questo momento.
È qualcosa che mi piacerebbe rivisitare a un certo punto. Penso che l’adozione del componente tema abbia fornito alcune prove che c’è un desiderio per più cose di questo tipo là fuori.
Implementarlo come componente tema ha avuto dei vantaggi: è relativamente facile per qualsiasi amministratore trovarlo e installarlo, ma presenta anche alcuni vincoli significativi che rendono difficile progettarlo nel modo in cui ci si potrebbe aspettare.
Se e quando lo rivisiteremo, penso che ci siano due possibili percorsi che potremmo intraprendere: potremmo utilizzare il set di funzionalità desiderato per una lavagna Kanban come motivo per migliorare le API disponibili per i componenti tema, oppure potremmo trasformarlo in una funzionalità principale o in un plugin e avere un maggiore accesso per aggiungere API server adatte allo scopo di cui abbiamo bisogno.
Fino ad allora, penso che riceverà solo piccole modifiche per problemi specifici.
È vero, ma questo onere ricade su di noi - proprietari - non sugli utenti. Gli utenti lo vedono nel modo più semplice possibile:
scegli il canale → invia il messaggio e basta!
Non c’è Kanban. Non c’è bisogno di comprendere la differenza tra Guardando e Seguendo. Non c’è una marea di ehi-quanto-sarebbe-bello-se-discourse-potesse-FARE-ANCHE-xyz funzionalità.
Tutte queste funzionalità sono super fantastiche, per noi - persone tecniche/proprietari/amministratori.
Ma per la gente comune, vogliono un senso di comunità. Vogliono sentirsi liberi di esprimersi e non dover capire tutte quelle centinaia (credo siano così tante) di opzioni, termini e altre cose diverse.
Questo è esattamente il feedback che ho dai portatori di interesse. Si perdono tra chat e argomenti privati.
Nel mio attuale progetto, il proprietario del progetto sta esplorando Basecamp perché dice di non poter semplicemente usare Discourse dopo averlo provato. Sto sostenendo Discourse perché ne conosco le eccezionali caratteristiche e capacità, ma non posso fare molto perché la scarsa usabilità e un disordine sia nell’interfaccia utente che nella terminologia superano sempre la funzionalità. Per non parlare del Markdown che ogni persona normale e non tecnica odia e non riesco a spiegare loro perché non sia wysiwyg in primo luogo. Grazie a Dio il team di Discourse sta finalmente lavorando sull’editor appropriato. La maggior parte delle persone vuole un semplice editor di testo simile a Word con solo poche capacità: formattazione, tabelle, colori, immagini, snippet di codice. Non c’è motivo per cui una qualsiasi di queste cose debba essere ottenuta sotto forma di markdown da un utente normale. Funzionalità più sofisticate come l’IA sembrano inutili quando l’utente finale non riesce a capire perché il suo editor di testo per i post è diviso verticalmente in due colonne, è a questo che pensano, non all’IA.
Hanno tutti i dati. Questo è il compromesso, e capisco la frustrazione iniziale, ma vedo molti miglioramenti negli ultimi mesi su Discourse.
Gli amministratori possono scegliere di smettere di usare chat e/o messaggi privati e semplificare. Ci vuole tempo e c’è una curva di apprendimento che tutti sicuramente capiscono. Pro e contro come in ogni cosa.
Auguro il meglio al team e penso che dobbiamo davvero contribuire e dare tempo al processo di evoluzione naturale.
Questo va bene nel breve termine, ma non è una dinamica molto buona per organizzare le informazioni?
Utenti che sparano a caso < un sito web ben organizzato.
Quindi l’attenzione di Discourse sulla moderazione e sugli strumenti per organizzare le cose?
Questo è esattamente il caso in cui non stiamo tenendo il passo con il panorama in evoluzione di come i membri delle nostre community consumano i contenuti.
Ho affrontato esattamente la stessa decisione. Avere qualcosa di robusto, ben organizzato, con un’ottima SEO, qualcosa che ci permetta di creare un patrimonio data la natura dei contenuti che stiamo creando.
Ma le persone oggi (e questa è ovviamente una generalizzazione) non sentono che, ad esempio, Slack stia portando via qualcosa limitando la cronologia agli ultimi 90 giorni.
Uno dei miei membri mi ha detto (ed è un’imprenditrice di estremo successo appena trentenne) che oggi, se le informazioni hanno più di 3 mesi, non le legge, poiché tutto cambia così velocemente, scavare nel vecchio materiale è solo una perdita di tempo. Indipendentemente dal fatto che si tratti di affari, scienza o… beh, vita.
E naturalmente, avere thread come quelli che abbiamo qui riguardo a plugin che potrebbero essere aggiornati molti mesi in futuro - è un caso valido. ma al di fuori di questo - nel senso di “costruire la community” si tratta più del “senso di appartenenza” e di poter interagire con questa community con poco o nessun attrito, invece di capire tutte le opzioni che ci sopraffanno.
Ne ho parlato in thread precedenti, dove chiedevo del successo di Skool, rispetto a Discourse.
Capisco perfettamente, grazie per la tua prospettiva.
Per essere perfettamente chiari - vedo un potenziale straordinario in Discourse, e se potessi mai essere utile per aiutare il team con la mia esperienza nella creazione di comunità - sono felice di aiutare.
