Verbesserung der Seite „Discourse aktualisieren“

Beitragen UX
1

Wir haben intern ein paar Ideen ausdiskutiert, wie wir die Seite „Update-Diskurs“ verbessern könnten.

Eine Idee ist, den Verlauf der Updates anzuzeigen, mit Links zu den Changelogs für die Unterschiede zwischen ihnen (was hilfreich sein könnte, um Änderungen zu verstehen, die man nach einem Update bemerkt).

Hier sind ein paar weitere Ideen / Beschwerden, die gerade aufkamen:

Welche anderen Ideen haben die Leute?

1 „Gefällt mir“
2

Hallo,

Hier ist die Idee, die mir immer wieder durch den Kopf geht: Die meisten Frustrationen bezüglich der “neue Version bei jedem Commit verfügbar”-Meldung entstehen daraus, dass der latest-Kanal sich kontinuierlich aktualisiert. Daher ist es eigentlich der normale Ruhezustand, ein paar Commits hinterherzuhinken, aber die Seite behandelt dies so, als wäre etwas falsch. Anstatt das Ganze neu zu entwerfen, würde ich mich darauf konzentrieren, Signale von Rauschen zu unterscheiden.

So stelle ich mir das vor: Die Seite hat einen Statusbanner, dessen Bedeutung davon abhängt, wo man sich tatsächlich befindet:

  • Auf dem neuesten Stand → unauffällig, positiv, keine Aufforderung zum Handeln.
  • Ein paar Commits hinter latest → grau/informativ, und es steht explizit keine Aktion erforderlich. Dies ist der Zustand, der aktuell „schreit“ und das wirklich nicht sollte.
  • Eine neue monatliche Version ist unterwegs (z. B. v2026.8.0) → prominent, mit einem Link zu den Veröffentlichungshinweisen.
  • Sicherheitsupdate → rot/dringend, separat hervorgehoben.

Nur die letzten beiden sollten so wirken, als müsste man darauf reagieren.

Ein paar weitere Dinge, die ich dort gerne sehen würde:

  • Die Versionsnummer wieder prominent in der Mitte. Einfach eine kleine Karte mit der installierten Version, dem Commit-Hash und dem Kanal (z. B. v2026.8.0-latest.1 · dfe770d · latest). Das ist die häufigste Beschwerde, die ich gesehen habe, und sie ist einfach wiederherzustellen.
  • Nutzung des bereits vorhandenen zwischengespeicherten Checks. Der Versionscheck läuft bereits als periodischer Sidekiq-Job, nicht live pro Anfrage. Daher sollte die Seite nicht langsam wirken – sie kann das zwischengespeicherte Ergebnis sofort mit einer Zeile „zuletzt vor X Minuten geprüft“ und einem manuellen „Jetzt prüfen“-Button anzeigen, anstatt beim Laden neu zu berechnen.
  • Ein Update-Verlauf mit Links zu den Änderungsprotokollen – im Grunde die ursprüngliche Idee in diesem Thema. Eine kurze Zeitleiste der Releases (monatlich + ESR), wobei jedes auf sein Änderungsprotokoll oder Diff verweist.

Zu Komponenten und Neuaufbauten: Was ich am deutlichsten gemacht sehen möchte, ist die Unterscheidung zwischen Updates, die der Web-Updater selbst anwenden kann (Kern + Plugins, via git pull), und solchen, die den Container ändern und daher ./launcher rebuild app auf der Kommandozeile erfordern. Eine pro Komponente aufgelistete Übersicht, in der jede Zeile zeigt, zu welcher Kategorie sie gehört, wäre sehr hilfreich. Für den Neuaufbau-Fall könnte das exakte Kommando mit einer Kopier-Schaltfläche angezeigt werden, anstatt man raten zu lassen.

Zu Plugin-Kompatibilität: Der Mechanismus .discourse-compatibility behandelt bereits den Fall, in dem dein Kern älter ist als das, was ein Plugin jetzt anspricht – er checkt während eines Neuaufbaus stillschweigend den letzten kompatiblen Commit dieses Plugins aus. Das betrifft hauptsächlich Stable/ESR-Installationen, und heute geschieht es stillschweigend. Es wäre schön, dies als einfache informative Zeile „auf einer kompatiblen Version gehalten“ anzuzeigen, damit Admins älterer Releases sehen, warum ein Plugin nicht auf seinem neuesten Commit ist. (Der umgekehrte Fall, dass ein Plugin noch keine neuere Kernversion unterstützt, wird heute nicht wirklich behandelt; es gibt einen offenen Feature-Request bezüglich min/max kompatibler Versionen, der dies abdecken würde.)

Ich habe schnell einen interaktiven Mockup erstellt, um zu sehen, wie die verschiedenen Zustände nebeneinander wirken – ehrlich gesagt ist der größte Gewinn einfach der Zustand „du hinkst, aber das ist in Ordnung“. Sobald dieser kein Alarm mehr ist, wird die Seite wieder wirklich nützlich. Gerne teile ich den Mockup, wenn jemand ihn ausprobieren möchte.

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

1 „Gefällt mir“
3

Guter Inhalt.

Nur eine Klarstellung zu diesem Teil:

Ich denke, es geht dabei darum, welche Updates du durchgeführt hast, nicht unbedingt um die „Releases“, die wir veröffentlichen.

Jedes Mal, wenn du ein Update durchführst, erscheint eine neue Zeile. Sie könnte sich auf 5 Commits innerhalb eines Releases beziehen. Oder sie könnte den Sprung von 2026.1.6 zu 2026.7.1 abbilden, falls du auf das erste Patch-Release nach dem nächsten ESR gewartet hast, um zu aktualisieren.

Auf jeden Fall sollte es dir den Verlauf der Updates zeigen, die du zuvor an deiner Site vorgenommen hast, sowie die Änderungen zwischen diesen Versionen.

4

Füge einen prominenten Hinweis darauf hinzu, wie wichtig es ist, zunächst ein Backup zu erstellen!

Ergänze etwas darüber, dass im Falle eines fehlgeschlagenen Updates der nächste Schritt ein Wiederaufbau des Launchers über die CLI ist. Zumindest sollte ein Hinweis darauf stehen, dass Updates gelegentlich fehlschlagen und das Forum dadurch offline geht.

Idealerweise eine Möglichkeit, signalisieren zu können, dass die ausstehenden Änderungen etwas Grundsätzliches beinhalten, wie z. B. das kürzlich erfolgte Datenbankversions-Upgrade, das beim letzten Mal – wenn ich mich recht erinnere – ein wirklich großes Ereignis war, was die Anzahl der hier gestarteten Support-Themen betrifft.