Die Seite /activity/pending listet aktuell alle ausstehenden Themen/Beiträge auf, aber nur Beiträge können gelöscht werden, wenn man das Thema aufruft und auf die „Löschen“-Schaltfläche unter dem „wartet auf Freigabe“-Kasten klickt, und Nutzer können ihre ausstehenden Themen nicht selbst löschen, ohne das Personal zu kontaktieren.
Dieser Commit fügt eine ähnliche „Löschen“-Schaltfläche direkt zur /activity/pending-Seite hinzu, sodass Nutzer ihre ausstehenden Themen selbst löschen können, wobei eine ähnliche Logik wie bei der Löschung ausstehender Beiträge zuvor angewendet wird.
warum bleibt das gelöschte Thema in der Warteschlange, wie auf deinem Screenshot zu sehen? Sollte es nicht einfach… abgebrochen werden?
Die Logik ist gleich wie bei einem Beitrag, d. h., wenn ein Beitrag von einem Benutzer gelöscht wird, bevor ein Mitarbeiter Maßnahmen ergreift, bleibt er ebenfalls in der Warteschlange wie oben (Der Status ist „Thema oder Beitrag gelöscht“, sodass der ausstehende Zustand nicht betroffen ist).
Außerdem finde ich, das ergibt Sinn: Wenn ein Benutzer versehentlich ein ausstehendes Thema löscht, kann er den Support um Wiederherstellung bitten.
Es würde für mich Sinn machen, einen Bestätigungsdialog zu haben, anstatt eine zerstörerische Aktion mit einem Klick auszuführen.
OK, ich füge ein Popup hinzu, damit Benutzer das bestätigen können.
In welchen ähnlichen Fällen zeigt Discourse eine Bestätigungsabfrage?
Wenn ich einen Beitrag oder ein Thema lösche, das ich selbst erstellt habe, gibt es ebenfalls keinen Bestätigungsschritt. In meinen Lesezeichenlisten löscht „Lesezeichen entfernen“ es ebenfalls, ohne erneut nachzufragen.
Ich verstehe, dass nachgefragt werden sollte, wenn Informationen dauerhaft verloren gehen, wie zum Beispiel beim Verwerfen eines Entwurfs, aber ich denke, es sollte nicht zu viele solcher Fälle geben, da sonst die wirklich wichtigen weniger wichtig erscheinen. (Die Diskussion hier könnte in diesem Zusammenhang auch interessant sein.)
Solange ein Teammitglied das Thema wiederherstellen kann, halte ich eine Bestätigung für dieses Szenario nicht für notwendig.
Wow, das ist seltsam. Ich habe gerade versucht, ein Thema zu löschen, und es hat mich überhaupt nicht gewarnt, auch nicht als normaler Benutzer. Jetzt, da ich es getan habe, ergibt das Sinn, aber vielleicht habe ich mich so an die Admin-Benutzeroberfläche gewöhnt, dass ich vergessen habe, dass es als Benutzer keine Aufforderung gibt, weil ich ehrlich gesagt dachte, dass es das tut. Allerdings passiert es auch im Antwort-Popup, was ich für ungefähr dasselbe wie dieses halte.
Am Ende des Tages finde ich, dass es eine Frage des persönlichen Vorliebens ist, und ich bevorzuge einfach eine schnelle Plausibilitätsprüfung, um versehentliche Klicks/Taps zu verhindern.
Aber das ist ein Fall, in dem der Inhalt des Beitrags sonst verloren geht, was bei den anderen Beispielen nicht der Fall ist. Ich habe das Gefühl, dass Discourse im Allgemeinen mit der Idee entwickelt wurde, dass der Benutzer weiß, was er tut, und nur warnt, wenn die Konsequenzen schwerwiegend sind.
Das ist genau richtig, und nicht unbedingt spezifisch für Discourse, sondern einfach allgemeine UX-Best Practices: Ein Modal/Dialog ist ein Element, das Reibung im Benutzerfluss verursacht, und sollte nur verwendet werden, wenn eine Aktion wirklich destruktiv ist. Alles, was leicht wiederhergestellt oder rückgängig gemacht werden kann, kann ohne es weitergehen.
Da stimme ich definitiv zu. Das Problem ist zumindest bei dieser Funktion, dass sie ohne das Eingreifen des Personals nicht rückgängig gemacht werden kann, so scheint es. Wenn ich ein Benutzer wäre und versehentlich auf den „Beitrag widerrufen“-Button tippe, würde ich es vorziehen, von einem Modal-Fenster gestoppt zu werden, als dass ich das Personal (das es vielleicht nicht sieht) bitten müsste, den Beitrag trotzdem zu genehmigen.
Die ursprüngliche Methode zum Löschen eines ausstehenden Beitrags bestand darin, zum Thema zu gehen, nach unten zu scrollen und dann auf die Schaltfläche „Löschen“ zu klicken. Dieser Vorgang ist komplex genug, um unbeabsichtigte Aktionen zu verhindern.
Doch „ausstehend“ ist eine Liste, jemand könnte versehentlich die Löschschaltfläche einer falschen Zeile angeklickt haben und müsste sich dann an das Personal wenden, um sie wiederherzustellen. Dies kann einige Zeit und Mühe kosten. Aus Sicht eines Nutzers halte ich das nicht für so „einfach“, daher ist hier vielleicht ein Bestätigungsdialog erforderlich.
P.S. Mein ursprünglicher Commit sollte die gleiche Logik wie beim Löschen eines ausstehenden Beitrags zuvor beibehalten, aber ich denke, es wäre hier notwendig, den Nutzer erneut zu warnen.
