it-swarm.com.de

Soll ich in meinem Meldungsfeld Ja / Nein oder OK / Abbrechen verwenden?

Semantisch entsprechen die Ja/Nein-Schaltflächen in etwa den OK/Abbrechen-Schaltflächen. Was würden Sie jedoch generell empfehlen? Sollte ich immer Ja/Nein oder immer Ok/Abbrechen verwenden? Oder kommt es auf den Fall an?

335
laurent

Verwenden Sie niemals 'Ja' oder 'OK', wenn Sie stattdessen ein Verb verwenden könnten.

Und Sie können fast immer ein Verb anstelle von 'Ja' oder 'OK' verwenden.

Ich stimme der Postulation von Lukas Mathis zu, dass niemand liest Ihre Dialogfelder . Verwenden Sie nach Möglichkeit ein Verb anstelle von "Ja" oder "OK", da Ihre Schaltflächen außerhalb des Kontexts mit dem erläuternden Text oder Titel sinnvoll sind. Dies ist eine Ansicht, die in Richtlinien für die Benutzeroberfläche von Microsoft :

Wenn Sie sicherstellen möchten, dass Benutzer bestimmten Text zu einer Aktion lesen, platzieren Sie ihn auf einem interaktiven Steuerelement.

Akzeptabel:

In diesem Beispiel besteht die Möglichkeit, dass Benutzer den Text nicht lesen, in dem erklärt wird, was sie bestätigen.

Besser:

enter image description here

In diesem Beispiel können Sie sicher sein, dass zumindest Benutzer verstehen, dass sie eine Festplatte formatieren werden.

Apples Human Interface Guidelines erweitern dies noch weiter, indem sie Mehrwortverben anstelle der Schaltflächen "OK" oder "Ja" empfehlen und die vorgeschlagenen Regionen für ein Warnfeld klar definieren:

Apple's human interface guidelines on alert boxes

Sie empfehlen, erst dann eine Warnbox zu verwenden, wenn die Aktion nicht rückgängig gemacht werden kann. Zum Thema Tastenbeschriftungen bieten sie Folgendes:

Stellen Sie sicher, dass der Name der Standardschaltfläche der von Ihnen beschriebenen Aktion entspricht. Insbesondere ist es eine gute Idee, die Verwendung von OK für die Standardschaltfläche zu vermeiden. Die Bedeutung von OK kann selbst in Warnungen unklar sein, in denen gefragt wird, ob der Benutzer sicher ist, dass er etwas tun möchte. Bedeutet OK beispielsweise "OK, ich möchte die Aktion abschließen" oder "OK, ich verstehe jetzt die negativen Ergebnisse, die meine Aktion verursacht hätte"?

Durch die Verwendung eines fokussierteren Schaltflächennamens wie Löschen, Konvertieren, Löschen oder Löschen können Sie sicherstellen, dass Benutzer die von ihnen ausgeführten Aktionen verstehen.

Kurz gesagt, auch wenn es als die einzige oder logischste Option erscheint, dem Benutzer eine Schaltfläche "Ja" oder "Nein" anzubieten (z. B. "Möchten Sie sich wirklich abmelden?"), Können Sie fast immer a verwenden Verb oder Phrase stattdessen.

"Möchten Sie sich abmelden?"
[Abmelden] -oder- [Abbrechen]

Auf diese Weise muss ein Benutzer weder den Titel noch den erläuternden Text lesen, um zu verstehen, wie vorzugehen ist, und die Bedeutung des Klickens auf eine der beiden Schaltflächen kann nicht falsch interpretiert werden.

Beachten Sie auch, dass bei Auswahl zwischen "Nein" und "Abbrechen" "Abbrechen" aus genau den gleichen Gründen wie oben fast immer besser ist: Die Bedeutung von "Abbrechen" ist klar, auch wenn der Benutzer den Rest von nicht gelesen hat das Dialogfeld. Die Bedeutung von 'Nein' ist wahrscheinlich klar, macht aber weniger Sinn, wenn es mit einem Verb gepaart wird (z. B. 'Abmelden' und 'Abbrechen' sind allein sinnvoller als 'Abmelden' und ' Nein').

477
Nick

Die Verwendung kurzer Wörter wie Ja/Nein auf Schaltflächen kann verwirrend sein, wenn der Benutzer die Nachricht im Dialogfeld falsch liest, insbesondere wenn die Nachrichten schlecht geschrieben sind. (Halten Sie also Nachrichten in erster Linie kurz und eindeutig)

Wenn yes/nook/cancel tatsächlich ist, mussder Benutzer die Nachricht lesen und verstehen bevor Sie wissen, wofür die Optionen gelten. Benutzer, die mit einem Produkt vertraut sind, scannen lieber die Schaltflächen selbst, als die Nachricht zu lesen.

Der Ansatz, den ich bevorzuge, besteht darin, die Bestätigung der Aktion etwas ausführlicher als OK zu machen (z. B. Save changes, Add user, Update password), So dass es sehr klarwas du gerade machst. Und dann behalten Sie Cancel bei - einen kurzen und vertrauten Fluchtweg, zumal dann klar sein sollte, dass es sich um die Option "Keine Aktion ausführen" handelt .

Selbst eine einfache Frage wie ist sicher, dass Sie sich abmelden möchten, (falls dies tatsächlich erforderlich ist) sollte die Schaltflächen Log out Und Cancel statt Yes/Cancel oder Yes/No.

Auf diese Weise kann der Benutzer die Schaltflächen schnell scannen und den Überblick darüber erhalten, auf was er klicken muss, auch ohne die Nachricht zu lesen.


Bearbeiten - Unter Bezugnahme auf die obigen Kommentare zur Antwort von greengit finden Sie hier ein Beispiel aus Skype, was nicht zu tun ist:

enter image description here

83
Roger Attrill

Ein Bestätigungsdialog (einer, der eine Frage stellt und keine Eingabe beinhaltet) sollte Ja/Nein haben. Zum Beispiel...

  • Möchten Sie Ihr Konto kündigen - yesno

  • Möchten Sie sich abmelden - yesno

Andererseits sollte ein Dialogfeld, das eine "Aktion" darstellt und eine Benutzereingabe erwartet, ok/cancel oder <action>/cancel haben. Zum Beispiel...

  • Datum und Uhrzeit des Ereignisses einstellen ... okcancel

  • Neuen Kontakt hinzufügen ... addcancel

  • Aktualisieren Sie Ihr Passwort ... updatecancel

  • Ändern Sie Ihre Zeitzone ... donecancel

47
treecoder

Die Schaltfläche Ok/Abbrechen und Ja/Nein ist nur zulässig, wenn Sie zu faul sind, um sich ein besseres Label für die Aktion auszudenken.

Ein Beispiel für einen guten Bestätigungsdialog:

  1. Dies ist LibreOffice/OpenOffice, als Sie versucht haben, ein nicht gespeichertes Dokument zu schließen:

enter image description here

die Beschriftung der Schaltfläche sollte widerspiegeln, welche Aktion ausgeführt wird.

Rufen Sie außerdem niemals Aktionen wie "Abmelden"/"Schließen eines Kontos" als "Abbrechen" auf, um Mehrdeutigkeiten mit der Schaltfläche "Abbrechen" zu vermeiden. Das heißt, die Schaltfläche "Abbrechen" ist ein sicherer Hafen, für den der Benutzer auf "Reflex" klicken kann, ohne dass etwas Schlimmes passiert. Machen Sie dem Benutzer keine Angst, auf die Schaltfläche "Abbrechen" zu klicken.

Anhand der Beispiele von greengit würde ich jedem von ihnen Folgendes vorschlagen:

Do you want to delete your account -- "Delete account" "Cancel"

Do you want to sign out -- don't even ask this since signing out 
                           is a non-destructive action, if the user 
                           has an unsaved work and signing out could 
                           lead to loss of unsaved work, then you have 
                           two options: ask whether they want to discard 
                           the unsaved work, or automatically save the 
                           work as a draft.

Set event date and time -- "Set time" "Cancel". Although since this is a 
                           non-destructive action, you should probably not 
                           need to ask confirmation and just apply the 
                           action immediately with a "Revert" button.

Add a new contact -- Don't ask for confirmation to "Add", when the user 
                     entered the "Add contact" form and doesn't quit 
                     immediately, they already confirmed that they wanted 
                     to add a contact; automatically save the contact's 
                     information when the user finish entering the 
                     contact's information. Also you might want to have a 
                     "Revert" or "Discard" button.

Update your password -- "Update Password" "Cancel"

Change your timezone -- "Set Timezone" "Cancel". The same with setting 
                        time, if this is non-destructive then don't ask for 
                        confirmation.
20
Lie Ryan

In einigen UI-Richtlinien wird empfohlen, immer OK/Abbrechen-Dialoge anstelle von Ja/Nein zu verwenden.

Ich glaube jedoch, dass dies ein großer Fehler ist. Zum Beispiel habe ich kürzlich einen Dialog mit der Frage "Möchten Sie Ihr Konto wirklich kündigen?" Gesehen. und Schaltflächen mit den Bezeichnungen "Ok" und "Abbrechen". In diesem Fall bedeutete "Ok" "Abbrechen" und "Abbrechen" "Nicht abbrechen".

Zumindest meiner Meinung nach ist dies fast völlig verrückt. Natürlich wäre es möglich, die Frage als "Konto schließen" umzuformulieren. Trotzdem denken manche Leute wahrscheinlich, dass sie das Konto kündigen, selbst wenn Sie Word nicht verwenden/vorschlagen. Unter diesen Umständen ist eine Schaltfläche mit der Bezeichnung "Abbrechen" eine schlechte Idee. Einige Leute werden unweigerlich daran denken, dass das Schließen des Kontos abgebrochen wird, andere jedoch, dass sie das Konto selbst kündigen.

Ich muss zugeben, dass die Voreingenommenheit gegen "Ja"/"Nein" auch einen gewissen Wert hat. In diesem Fall halte ich es für besser, "Lager" -Labels zu vermeiden und so etwas wie "Konto schließen" und "Konto offen halten" zu verwenden.

18
Jerry Coffin

Weder sind sehr gute Lösungen, wenn Sie Ihren Benutzern eine Frage stellen und ihnen Optionen geben möchten, mit denen sie antworten können. Ja/Nein funktioniert, wenn Sie an einer Umfrage teilnehmen, aber für einen modalen Dialog ist dies sehr minimal. OK/Abbrechen ist wie ein Überbleibsel der alten Zeiten, als Bildschirme niedrige Auflösungen hatten und die Tasten knapp sein mussten, um zu passen.

Der Punkt ist, dass Tastenbeschriftungen als Mikrokopie gelten und als solche die Aufmerksamkeit erhalten sollten, die anderen Elementen der Benutzeroberfläche geschenkt wird. Wem stimme ich zu oder nicht? Was bin ich in Ordnung oder storniere ich? Warum sind diese Informationen nicht auf der Schaltfläche?

Gehen Sie also zurück und überlegen Sie, wie Sie das Etikett klarer gestalten können. "Diese Zeile löschen? Ja/Nein" wäre viel einfacher zu scannen (insbesondere, da es sich um eine destruktive Aktion handelt), wenn auf den Schaltflächen nur "Diese Zeile löschen"/"Nichts löschen" steht. Das Gestalten der Aktion, die der Benutzer als größeren Aufruf zum Handeln ausführen soll, und das Verkleinern der Abbrechen-Schaltfläche (und möglicherweise nicht einmal einer Schaltfläche) können ebenfalls sehr hilfreich sein.

Manchmal führt OK/Abbrechen zwei Schaltflächen ein, da es sich um einen modalen Dialog handelt. Fragen Sie sich, ob Sie einen modalen Dialog benötigen oder ob Sie ihn herausnehmen und die Erfahrung vereinfachen könnten. Wenn Sie beispielsweise das Abmeldedialogfeld eines Benutzers haben, fragen Sie ihn nicht in einem modalen Dialogfeld "Möchten Sie sich abmelden? OK/Abbrechen", sondern haben Sie nur eine Schaltfläche mit der Aufschrift "Abmelden", und der Benutzer kann sich dafür entscheiden Klicken Sie darauf oder nicht.

Relevante Fragen, die Ihnen bei Ihrer Entscheidung helfen:

11
Rahul

Im Allgemeinen stimme ich @Nick zu, aber es gibt noch eine weitere erwähnenswerte Sache:

Vermeiden Sie Dialoge, wenn Sie können - Dialoge sind die meiste Zeit nur ärgerlich - Sie fragen den Benutzer, ob er sicher ist. Ich weiß nicht, wie es mit dir ist, aber ich mag diese Art von Protest wirklich nicht - der Computer ist hier, um mir zu dienen, nicht anders herum!

Also - was ist mit der Schaltfläche "Löschen"? Es ist sinnvoll, vor dieser Art von Aktion zu fragen, oder? Nun, das tut es sicherlich, aber es gibt auch eine viel bessere Lösung - bietet Rückgängig-Funktionalität

Papierkorb, Link in Tray-Benachrichtigungen rückgängig machen, "E-Mail retten", die nach dem Kündigen des Kontos gesendet wird, mehrere Versionen desselben Dokuments usw. Seien Sie nicht faul - investieren Sie etwas Zeit in die Vereinfachung Ihrer Benutzeroberfläche, um sie übersichtlicher zu gestalten. Benutzer verdienen die Fähigkeit, schnell zu arbeiten, und wenn sie Fehler machen, sollten Sie nur ein Sicherheitsseil bereitstellen - das war's. Stören Sie sie nicht, es sei denn, es ist absolut notwendig.

Wenn Sie das Löschen getrennt von anderen Schaltflächen platzieren und es etwas kleiner machen, können Sie diese Fehler minimieren. iPhone-Apps haben normalerweise das Speichern/Abbrechen (beide potenziell gefährlich) oben auf dem Bildschirm - da es schwieriger ist, dort zu tippen.

EDIT: Es gibt auch Artikel über "Rückgängigmachen über Bestätigungen" von Aza Raskin

5
Kamil Tomšík

Die meisten Benutzer suchen nur 3 m.

  • Ein positives - Yes, OK, Add, Retry, Wait ..etc.

  • Ein Negativ - No, Abort, Quit, Exit

und der dritte ist:

  • "Escape from this Message Box" - Cancel

Wenn Sie also Yes, NO und Cancel verwenden, wird drei verschiedene Arten von Gedanken.

Das heißt, ihre Verwendung hängt vom Fall ab.

5
Vishnu Haridas

Das hängt von der Formulierung ab. Ich möchte nichts anderes als Ja/Nein für eine Frage, die eine Ja/Nein-Antwort erwartet. Ich möchte nicht Ja/Nein für etwas, das keine Frage ist (oder eine Frage, die so formuliert ist, dass Ja/Nein keine gültige Antwort ist).

4
AProgrammer

Ich habe keine Statistiken, um die folgende Behauptung zu belegen, aber für mich persönlich ist es nicht immer besser, einen benutzerdefinierten Text auf Schaltflächen zu haben.

Ok/Abbrechen/Ja/Nein sind so häufig, dass unser Gehirn bereits darauf trainiert ist, sie in Sekundenbruchteilen zu erkennen und darauf zu reagieren, während benutzerdefinierte Etiketten von einem Benutzer verlangen, die Informationen anzuhalten und aktiv zu verarbeiten, was bei Verwendung ärgerlich sein kann auf gemeinsame Aktionen.

Solange die vom Benutzer gestartete erwartete Aktion und der Dialog der gleichen Logik folgen, ist einfaches Ja/Nein großartig. Ich weiß bereits, was ich tue, ich muss es nur bestätigen. Alle zusätzlichen Erklärungen sind nur eine Art Lärm.

Ein Beispiel ist die Aktion "Papierkorb leeren". Ich möchte jedes Mal aufgefordert werden, versehentliche Klicks zu vermeiden, aber wenn ich absichtlich darauf klicke, möchte ich so schnell wie möglich damit fertig sein. Klicken Sie einfach - klicken Sie, ich möchte den Text des Dialogfelds nicht lesen, ich erwarte bereits, was gefragt wird, und ich erwarte, mit Ja oder Nein (oder OK/Abbrechen) zu antworten, da dies die üblichen Antworten sind.

Eine gute Lösung für dieses IMHO ist die Verwendung der Schaltflächenbeschriftungen in der Form "Ja, etwas tun". Auf diese Weise ist es immer noch einfach, nur den Text zu scannen und die Bedeutung herauszufinden. Wenn Sie jedoch über den Dialog verwirrt sind, können Sie alles lesen und sicher sein, was die Schaltfläche bewirkt.

2
ivanhoe

Ich stimme den meisten anderen Antworten zu, dass es fast immer besser ist, bestimmte Antworten anzuzeigen, als Ja/Nein-Schaltflächen.

In den Dialogfeldern Microsoft Design Guidelines (vom Mai 2018) on werden jedoch einige Fälle erwähnt, in denen Ja/Nein angemessen sein kann:

  1. Um Bestätigungen zu machen, muss nachgedacht werden
  2. Um lange oder umständliche Phrasen zu vermeiden

(Ich bin mir nicht sicher, ob ich damit einverstanden bin, aber ich fand es interessant, dass die Verwendung von "Ja/Nein" in diesen Beispielen eine absichtliche Entwurfsentscheidung war.)


  1. Bestätigungen erfordern Nachdenken

Der Abschnitt zu Bestätigungen in den Microsoft Design Guidelines argumentiert, dass die Verwendung von Ja/Nein bei Bestätigungen mit erheblichen Konsequenzen angemessen sein kann.

Verwenden Sie keine Bestätigungen, nur weil die Möglichkeit besteht, dass Benutzer einen Fehler machen. Bestätigungen sind eher am effektivsten, wenn sie zur Bestätigung von Aktionen verwendet werden, die signifikante oder unbeabsichtigte Konsequenzen haben. [...]

Damit eine Bestätigung einen Wert hat, müssen Benutzer den Grund verstehen, nicht fortzufahren. Manchmal liegt der Grund auf der Hand, wenn Benutzer ein Dokument mit Änderungen schließen, die nicht gespeichert wurden:

(confirmation-obvious

In diesem Beispiel liegt der Grund für die Bestätigung auf der Hand.

In anderen Situationen ist der Grund möglicherweise nicht so offensichtlich.

Bei der Auswahl von Beschriftungen für Festschreibungsschaltflächen für Dialogfelder besteht die allgemeine Richtlinie darin, Beschriftungen auszuwählen, die spezifische Antworten auf die Hauptanweisung sind. Dies führt zu einer effizienten Entscheidungsfindung, da Benutzer eine Mindestmenge an Text lesen müssen, um fortzufahren. Dieses Effizienzziel kann jedoch für Bestätigungen kontraproduktiv sein. Betrachten Sie dieses Beispiel:

Falsch:

(confirmation-incorrect

In diesem Beispiel erfordert die richtige Antwort Nachdenken.

Wenn Sie diese Bestätigung unmittelbar nach dem Befehl des Benutzers zum Deinstallieren vorlegen, lautet die Antwort des Benutzers wahrscheinlich "Natürlich möchte ich deinstallieren!". Der Benutzer klickt auf Deinstallieren, ohne darüber nachzudenken.

Zur Bestätigung möchten wir nicht, dass Benutzer voreilige, emotionale Entscheidungen treffen. Um die Benutzer zu ermutigen, über ihre Reaktion nachzudenken, müssen wir einen kleinen Geschwindigkeitsschub für die Entscheidungsfindung bereitstellen. Wenn es praktisch ist, ist es normalerweise besser, dies zu tun, indem Sie die Commit-Schaltflächen sorgfältig formulieren. Zum Beispiel können wir eine zusätzliche Sprache verwenden, um anzuzeigen, dass es einen Grund gibt, nicht fortzufahren.

Besser:

(confirmation-better

In diesem Beispiel wird der Beschriftung der Festschreibungsschaltfläche "sowieso" hinzugefügt, um anzuzeigen, dass die Bestätigung einen Grund angibt, nicht fortzufahren.

Wenn dieser Ansatz nicht praktikabel ist, können wir Ja/Nein-Commit-Schaltflächen verwenden.

Auch besser:

(confirmation-also-better

In diesem Beispiel werden Benutzer durch die Verwendung von Ja/Nein-Festschreibungsschaltflächen gezwungen, mindestens die Hauptanweisung zu lesen.


  1. Um lange oder unangenehme Phrasen zu vermeiden

Betrachten Sie die Formulierung der Hauptanweisung als Ja- oder Nein-Frage, wenn sich Commit-Schaltflächen mit einer bestimmten Formulierung als lang oder umständlich herausstellen. Alternativ können Sie Befehlslinks für längere Antworten (fünf Wörter oder mehr) auf die Hauptanweisung verwenden.

Falsch:

(long-phrasing-incorrect

Richtig:

(avoid-long-phrasing-correct

Die spezifische Formulierung im falschen Beispiel ist zu lang, daher verwendet das richtige Beispiel Ja und Nein.

1
sonny

Ich würde Ja/Nein im Dialog verwenden, wenn der Workflow eine Abfrage benötigt, in welche Richtung er fortfahren soll. OK/Abbrechen sollte im Sinne von "Weiter?" Verwendet werden. mit der Verarbeitung/dem Workflow, da normalerweise Abbrechen impliziert, dass etwas gestoppt oder unterbrochen wird, wenn ich auf Abbrechen drücke. Ich würde kein OK/Abbrechen-Dialogfeld in Kombination mit einer Frage wie "Sollten wir hier aufhören?" Verwenden. Dies ist eine Ja/Nein-Abgabe (siehe Workflow und Abgabe). Die richtige Wahl hängt also auch immer von der Frage ab. Nun, es ist möglich, Fragen zu konstruieren, die den Benutzer irritieren ... aber warum sollten Sie dies tun?

1
Beachwalker

Ich bevorzuge es, Verb zu verwenden und abzubrechen, wie von @Nick beschrieben, es ist sinnvoller und benutzerfreundlicher. Zum Beispiel, wenn Sie ein Fenster schließen und den Benutzer fragen: "Möchten Sie das Fenster schließen?" Es gibt zwei Arten von Optionen: "Ja/Nein" und "Schließen/Bleiben". "Ok/Abbrechen" macht keinen Sinn.

Also geht zuerst das Verb dann ja/nein.

0
DevC

Die Zeiten der Schaltflächenbezeichnungen Ja/Nein und OK/Abbrechen sind vorbei. Es ist Zeit, aktionsspezifische Schaltflächenbeschriftungen in Ihren Dialogfeldern zu verwenden, wie in diesem Artikel vorgeschlagen.

Warum der 'Ok'-Button nicht mehr in Ordnung ist

Power-User, die den Text des Dialogfelds nicht lesen, können nicht auf die falsche Schaltfläche klicken. Sie bewegen sich in der Regel schnell durch die Benutzeroberfläche. Wenn Sie Ihre Schaltflächen mit einem aktionsspezifischen Wort kennzeichnen, müssen Sie lediglich die Schaltflächenbeschriftungen lesen, um zu wissen, auf welche Schaltfläche Sie klicken müssen. 'Ok' ist vage und beschreibt nicht, welche Aktion oder Aufgabe der Benutzer ausführt.

0
Fluke