Miglioramento della pagina "Aggiorna Discourse"

Contribuisci UX
1

Abbiamo discusso internamente alcune idee su come migliorare la pagina “aggiornamenti di Discourse”.

Una delle idee è mostrare la cronologia degli aggiornamenti, con collegamenti ai changelog per le differenze tra le versioni (il che potrebbe essere utile per comprendere le modifiche che si osservano dopo aver eseguito un aggiornamento).

Ecco altre due idee/lamentele emerse recentemente:

Quali altre idee avete?

1 Mi Piace
2

Ciao,

Ecco l’idea a cui continuo a tornare: la maggior parte della frustrazione dovuta al “nuova versione disponibile ad ogni commit” deriva dal fatto che il canale latest si aggiorna continuamente, quindi essere in ritardo di qualche commit è in realtà lo stato di riposo normale, ma la pagina lo tratta come se ci fosse un problema. Quindi, invece di ridisegnare tutto, mi concentrerei sul distinguere il segnale dal rumore.

Come lo immagino io, la pagina ha un’unica barra di stato che cambia significato in base alla tua posizione effettiva:

  • Aggiornato → silenzioso, positivo, senza call to action.
  • Qualche commit indietro rispetto a latest → grigio/informativo, e dice esplicitamente nessuna azione richiesta. Questo è lo stato che attualmente “urla” e non dovrebbe farlo.
  • In arrivo un nuovo rilascio mensile (es. v2026.8.0) → prominente, con un link alle note di rilascio.
  • Aggiornamento di sicurezza → rosso/urgente, evidenziato a parte.

Solo gli ultimi due dovrebbero sembrare qualcosa su cui devi agire.

Alcune altre cose che vorrei ci fossero:

  • Il numero di versione, di nuovo in primo piano. Basta una piccola card con la versione installata, l’hash del commit e il canale (es. v2026.8.0-latest.1 · dfe770d · latest). È la lamentela più comune che ho visto ed è facile da ripristinare.
  • Sfruttare il controllo in cache che già abbiamo. Il controllo della versione viene già eseguito come un lavoro Sidekiq periodico piuttosto che in tempo reale per ogni richiesta, quindi la pagina non dovrebbe sembrare lenta: può rendere il risultato in cache immediatamente con una riga “ultimo controllo X min fa” e un pulsante “controlla ora” manuale, invece di sembrare che stia ricalcolando al caricamento.
  • Una cronologia degli aggiornamenti con link al changelog fondamentalmente l’idea originale in questo argomento. Una breve timeline dei rilasci (mensili + ESR) con link al relativo changelog o diff.

Sui componenti e rebuild: la cosa che vorrei vedere resa più esplicita è la distinzione tra gli aggiornamenti che l’aggiornatore web può applicare da solo (core + plugin, via git pull) e quelli che cambiano il container e quindi richiedono ./launcher rebuild app dalla riga di comando. Un elenco per componente in cui ogni riga mostra a quale categoria appartiene aiuterebbe molto, e per il caso rebuild potrebbe mostrare il comando esatto con un pulsante di copia invece di lasciarti indovinare.

Sulla compatibilità dei plugin: il meccanismo .discourse-compatibility gestisce già il caso in cui il tuo core è più vecchio di quello che un plugin ora richiede, controllando silenziosamente l’ultimo commit compatibile di quel plugin durante un rebuild. Questo riguarda principalmente le installazioni stable/ESR, e oggi avviene in silenzio. Sarebbe bello renderlo visibile come una riga informativa “mantenuto a una versione compatibile” così gli amministratori di rilasci più vecchi possono vedere perché un plugin non è sul suo commit più recente. (Il caso opposto, un plugin che non supporta ancora un core più nuovo, non è gestito oggi; c’è una richiesta di funzionalità aperta su versioni min/max compatibili che lo coprirebbe.)

Ho creato rapidamente un mockup interattivo per vedere come si presentano gli stati diversi affiancati: onestamente, il vantaggio maggiore è semplicemente lo stato “sei indietro ma va bene così”. Una volta che smette di essere un allarme, la pagina diventa nuovamente utile. Sono felice di condividere il mockup se qualcuno vuole esaminarlo.

https://dynamic-changi-gne2.pagedrop.io/

1 Mi Piace
3

Ottimo materiale.

Solo un chiarimento su questa parte:

Sto pensando che si tratti degli aggiornamenti che hai effettuato tu, non necessariamente delle “versioni” che rilasciamo noi.

Quindi, ogni volta che esegui un aggiornamento, appare una nuova riga. Potrebbe riguardare 5 commit all’interno di una versione. Oppure potrebbe essere da 2026.1.6 a 2026.7.1, se hai aspettato il primo rilascio di patch dopo la prossima ESR per aggiornare.

In ogni caso, dovrebbe mostrarti la cronologia degli aggiornamenti che tu hai effettuato sul tuo sito in precedenza e le modifiche apportate tra di essi.

4

Aggiungi un avviso ben visibile sull’importanza di effettuare un backup prima di procedere!

Aggiungi una nota su come, in caso di fallimento dell’aggiornamento, il passaggio successivo sia una ricostruzione del launcher tramite CLI. Almeno una precisazione che gli aggiornamenti possono talvolta fallire, causando la messa offline del forum.

Idealmente, un modo per segnalare che le modifiche in sospeso includono qualcosa di significativo, come l’aggiornamento della versione del database avvenuto recentemente, che l’ultima volta si è rivelato un evento piuttosto importante, considerando il numero di discussioni aperte qui per il supporto. Se non ricordo male.