it-swarm.com.de

UI Design / Flow - Was sollen "Speichern" und "Abbrechen" tun?

Ich hatte heute früher eine Diskussion mit einem Kollegen über einen meiner Design-Pet-Peeve, und nach einigem Suchen nach UI-Design-Prinzipien kann ich in Bezug auf dieses spezielle Szenario nichts wirklich finden.

In vielen Anwendungen (hauptsächlich im Web, aber auch in Windows) wird ein Formular angezeigt, mit dem der Benutzer Datenzeilen hinzufügen/bearbeiten/löschen kann. Dieses Formular enthält die Schaltflächen "Speichern" und "Abbrechen", die sich nur auf die bearbeitbaren Felder auswirken. Das Hinzufügen/Löschen von Datensätzen erfolgt in dem Moment, in dem ein Benutzer auf "Hinzufügen" oder "Löschen" klickt.

Beispiel: Sorry, I'm not an artist

Was sollten in diesem Fall die Schaltflächen "Speichern" und "Abbrechen" tun?

  • Mein Standpunkt ist, dass die Schaltflächen "Speichern" und "Abbrechen" alles (jedes bearbeitbare Feld und jede Aktion zum Hinzufügen/Bearbeiten/Löschen) im Formular beeinflussen sollten, da kontextuell nichts darauf hinweist, dass sie nur einen bestimmten Satz von Aktionen und/oder betreffen oder Felder.

  • Die Position meines Kollegen ist, dass es völlig verständlich ist, dass die Schaltflächen "Speichern" und "Abbrechen" nur die Felder betreffen und dass Benutzer nicht wirklich bemerken, dass Hinzufügungen/Löschungen beibehalten werden, ohne auf "Speichern" zu klicken.

Mir ist klar, dass einige davon "was die Benutzer wollen/brauchen" sind, aber ich bin gespannt, was andere Entwickler denken.

2
Paul K

Ich halte ein mehrdeutiges Design für ein schlechtes Design.

Machen Sie dem Benutzer klar, was passieren wird. Möglicherweise ein 'Hinzufügen'-Link in der Zeile, die Sie ändern. Oder verwenden Sie Ajax-ähnliche Funktionen, um sie im laufenden Betrieb hinzuzufügen (dies wird schwieriger, wenn Sie Daten für bestimmte Felder benötigen).

Oder färben Sie die Zeile in einer anderen Farbe, wenn sie nicht gespeichert ist. Oder verblassen Sie nach dem Hinzufügen von Grün zur normalen Farbe. Wenn Sie auf die Schaltfläche Abbrechen klicken, wird der Benutzer darauf hingewiesen, dass nicht gespeicherte Daten verloren gehen (was auch immer dies in diesem Szenario tatsächlich bedeutet). Es könnte heißen "die folgenden Datensätze werden nicht gespeichert ..."

Die Tatsache, dass Sie beide nicht einverstanden sind, bedeutet, dass Benutzer dies auch tun werden. Und ein überraschter Benutzer ist ein unglücklicher Benutzer.

7
Mike

Ihr Mitarbeiter hat recht; Speichern und Abbrechen sollten sich nur auf Feldbearbeitungen auswirken, nicht auf Hinzufügungen oder Löschungen. Hinzufügungen und Löschungen werden vom Benutzer als separate Operationen wahrgenommen (und im Allgemeinen implementiert).

Konzeptionell muss der Datenbank ein Datensatz hinzugefügt werden, bevor Sie eine Bearbeitung daran durchführen können. Um eine Speicherung in der von Ihnen vorgeschlagenen Weise zu implementieren, müssen Sie das gesamte Objekt in eine Transaktion einschließen.

Denken Sie daran, dass der Benutzer einen Datensatzzusatz jederzeit durch Löschen rückgängig machen kann. Konzeptionell ist "Abbrechen" das Rückgängigmachen der Bearbeitung, während "Löschen" das Rückgängigmachen des Hinzufügens ist.

3
Robert Harvey

Meiner Meinung nach sollten Tabellen überhaupt nicht zum Bearbeiten von Daten verwendet werden. Sie sollten für Anzeigen Daten und Auswählen von Datensätzen verwendet werden. Formulare sollte zum Bearbeiten von Daten verwendet werden. Wenn Sie wirklich ernsthafte Datenmanipulationen in Tabellenform durchführen müssen, benötigen Sie eine voll funktionsfähige Tabellenkalkulationsanwendung wie Excel, mit der Sie Datenspalten schnell bearbeiten können. Für jede typische Benutzeroberfläche werden Tabellen jedoch nicht zum Bearbeiten von Daten verwendet. Denken Sie an die Web-Apps, die Sie jeden Tag verwenden, sei es soziale Netzwerke, E-Mail, Q/A-Sites, Bankgeschäfte usw. Ich kann mir keine Beispiele vorstellen, bei denen ein Benutzer aufgefordert wird, Daten in einer Tabelle zu bearbeiten. Und außer Excel oder Apps, die von Programmierern verwendet werden, fallen mir auch keine Desktop-Anwendungen ein.

Dies ist der Grund, warum die Schaltflächen Speichern/Abbrechen in Ihrem Beispiel keine offensichtliche Funktion haben. Was wirklich los ist, ist, dass die Tabelle es dem Benutzer ermöglicht, Datensätze anzuzeigen/auszuwählen nd neue oder vorhandene Datensätze zu bearbeiten. Wenn Sie anstelle der Bearbeitung der Daten in der Tabelle durch Klicken auf die Schaltfläche Bearbeiten zu einer neuen Seite mit einem Formular zum Ausfüllen/Bearbeiten der Daten gelangen, sind die Schaltflächen Speichern/Abbrechen absolut sinnvoll (technisch würde ich "Speichern" empfehlen). zum Bearbeiten und "Senden" für einen neuen Datensatz, aber Sie bekommen die Idee).

Wenn Sie darauf bestehen möchten, eine Tabelle zum Bearbeiten von Daten zu verwenden, würde ich sagen, dass Ihr Mitarbeiter wahrscheinlich Recht hat: Speichern/Bearbeiten bezieht sich nur auf die Bearbeitung des Datensatzes. In beiden Fällen ist es jedoch wahrscheinlich klobig und verwirrend. Daher würde ich empfehlen, die bewährte Formularoberfläche zu verwenden, wenn Sie die Benutzerfreundlichkeit sicherstellen möchten.

2
devuxer

Ich bin mit @Robert Harvey nicht einverstanden, insbesondere mit der Aussage.

Denken Sie daran, dass der Benutzer einen Datensatzzusatz jederzeit durch Löschen rückgängig machen kann

Während neue Datensätze durch Löschen des Datensatzes rückgängig gemacht werden können, gibt es keine Möglichkeit, die Löschaktion zurückzusetzen. Sie können einen Standard "Möchten Sie diesen Datensatz wirklich löschen?" Einfügen, aber stellen Sie sich diese Benutzererfahrung vor.

  1. Der Benutzer löscht einen Datensatz und bestätigt das Löschen.
  2. Der Benutzer flippt aus, als er den "falschen" Datensatz bearbeitet und seine Aktion abbrechen möchte.

Im obigen Beispiel ist es zu spät und kann nicht rückgängig gemacht werden, da die Aktion zum Löschen (oder Hinzufügen) bereits in der Datenbank beibehalten wurde.

Ich stimme Ihrer Position aus Sicht der Transaktionsfähigkeit zu. Die Aufzeichnung ist erst dann vollständig, wenn alle Informationen erhalten bleiben.

1
Kane

Ich würde das folgende Schema vorschlagen:

  1. Schließen Sie alle Änderungen in einer Transaktion auf Schnittstellenebene ein. Speichern bedeutet also Speichern und Abbrechen bedeutet Abbrechen.
  2. Fügen Sie die Rückgängig-/Wiederherstellungsfunktion für alle Änderungen mit einer geeigneten Granularität hinzu (wahrscheinlich nicht einzelne Zeichen).
  3. Behalten Sie die Änderungen auf dem Server bei, auch wenn sie nicht gespeichert wurden. Wenn der Benutzer zur vorherigen Version zurückkehren möchte, kann er jederzeit auf Abbrechen klicken.

Dieses Schema würde sowohl mit der Tabellenbearbeitung als auch mit der von DanM vorgeschlagenen Einzelelementbearbeitung funktionieren.

Ich stütze mich dabei auf meine jüngsten Erfahrungen mit einer ähnlichen Benutzeroberfläche, bei der ich Noten und Feedback für Schüler eingeben sollte. Das System hat das Feedback auf dem Server während der Bearbeitung nicht beibehalten, was bedeutete, dass ich entweder unvollständiges Feedback veröffentlichen oder lokal speichern musste. Es scheint mir, dass es ähnliche Probleme für einen Benutzer geben würde, der viele Datenelemente eingibt und die Rückgängig-Funktionalität beibehalten möchte. Das Speichern/Veröffentlichen der Änderungen nach jedem Element macht den Zweck des Rückgängigmachens oder Abbrechens zunichte.

0
Jørgen Fogh