it-swarm-eu.dev

JavaScript Aufforderung, Bestätigung und Warnung als "altmodisch"

In letzter Zeit habe ich ein webbasiertes Managementsystem für ein Fitnessstudio entwickelt. Ihre vorherige App wurde in Visual Basic entwickelt. Für die neue App verwendet das gesamte Front-End-Scripting jQuery, auf dem Server läuft PHP & MySQL ... Sie wissen, der typische el-cheapo Linux-basierte Stack.

Wie auch immer, ich habe mich gefragt, warum die Dialogfelder für Eingabeaufforderungen, Bestätigungen und Warnmeldungen von JavaScript heutzutage so wenig genutzt werden. Es gibt viele jQuery-Plugins für modale Fenster und Warnmeldungen, die versuchen, etwas nachzuahmen, das die Sprache bereits bietet, und jeder Browser muss dies ordnungsgemäß unterstützen.

Die Verwendung handgefertigter oder Plugin-basierter Lösungen ist für komplexe Formulare und spezielle Anforderungen in Ordnung. Wenn Sie jedoch nur nach einem einzelnen Wert fragen oder das Löschen eines Datensatzes bestätigen müssen, warum sollten Sie Ihrer Web-App einen solchen Overhead hinzufügen? Darüber hinaus bieten iOS und Android) gut angepasste Nachrichtendialoge, wenn Sie Eingabeaufforderung, Bestätigung und Benachrichtigung verwenden.

21

1. UX: Nachrichtenfelder sind meistens böse

Warnfelder sind aus UX-Sicht in allen Fällen schlecht. In Desktop-Apps. In Web-Apps als Warnungen oder Inline-JavaScript-Nachrichten. Überall.

Sie können About Face 3 von Alan Cooper¹ lesen, wenn Sie wissen möchten, warum; es erklärt sehr gut, wie dies den Workflow unterbricht und den Benutzer nervt und wie fast jede Warnbox, die in der aktuellen Software vorhanden ist, ist zutiefst falsch. Auf Seite 542 erklärt "Der Dialog, in dem" Wolf! "Geschrien wurde", dass Warnfelder routinemäßig geschlossen werden, sodass ihr Modell vollständig beschädigt ist. Auf Seite 543 des Buches sind drei wichtige Gestaltungsprinzipien aufgeführt:

  • Frag nicht.
  • Machen Sie alle Aktionen umkehrbar.
  • Geben Sie modellloses Feedback, um Benutzern zu helfen, Fehler zu vermeiden.

Anschließend erklären uns die Autoren, wie die Warnboxen durch den richtigen Entwurfsansatz ersetzt werden können.

Eingabeaufforderungsnachrichten unterscheiden sich geringfügig. Und dennoch beeinträchtigen sie die Benutzererfahrung Ihrer App. Wenn Sie möchten, dass der Benutzer etwas eingibt, sollten Sie ein Textfeld oder einen Textbereich verwenden und es bei Bedarf mit JavaScript dekorieren. Seien Sie nicht faul, bieten Sie eine reichhaltige Oberfläche in Zeiten von RIA- und AJAX-fähigen Apps; In allen Fällen wird Ihre Eingabeaufforderung nicht angezeigt, wenn JavaScript deaktiviert ist.

Auf Webseiten sind sowohl Warnfelder als auch Eingabeaufforderungen meistens ärgerlich. Einige Beispiele:

  1. In einigen Foren können Sie Listen erstellen, indem Sie unendlich nach den Listenelementen fragen. Dies bedeutet, dass Sie beim Erstellen der Liste die Seite selbst, einschließlich Kopieren und Einfügen, nicht verwenden können. Sie haben auch ein einzelnes kleines Feld. Was ist mit Langtext? Was ist mit Fett und Kursiv?

  2. "Wenn Sie fortfahren, wird das Foto endgültig aus Ihrem Profil entfernt. Sind Sie sicher?" . Natürlich bin ich mir sicher! Würde ich sonst auf "Foto aus meinem Profil entfernen" klicken? Warum nimmt deine Web-App an, dass ich so dumm bin? Tatsächlich zeigen Google-Anwendungen als GMail den richtigen Ansatz. Sie können alles entfernen, löschen, zerstören, was Sie möchten. Wenn Sie dies tun, zeigt die App einen kleinen Link "Rückgängig" an.

  3. "Möchten Sie an unserer größten Umfrage teilnehmen?" . Eigentlich war ich dort, um Ihre Website zu besuchen, aber da Sie mich mit Ihren nervigen Nachrichten belästigen, würde ich lieber woanders hingehen.

  4. "Der Rechtsklick auf dieser Website ist deaktiviert, um urheberrechtlich geschützte Fotos zu schützen" . Eigentlich habe ich mit der rechten Maustaste geklickt, um die Sprache der Rechtschreibprüfung zu ändern, bevor ich meinen Kommentar gesendet habe. Klar, ich werde es senden, ohne die Rechtschreibung zu überprüfen.

Schlussfolgerung: Aus Sicht der Benutzererfahrung verwenden die Anwendungen die meisten Meldungsfelder falsch.

Aber warte! Viele Websites mit geringer Qualität ersetzen störende Warnmeldungen durch störende JQuery-Nachrichten mit einem halbtransparenten Hintergrund, der die gesamte Seite abdeckt. Die Nachteile bleiben also bestehen.

Es gibt noch weitere Gründe, Nachrichtenfelder in Webanwendungen nicht zu verwenden:

2. Design: Alarmboxen haben ein eigenes Design

Sie können überhaupt keine Warnbox entwerfen. Sie können ihre Farbe, ihre Größe und ihre Schriftart nicht ändern. Dies macht es für den Benutzer noch ärgerlicher: Sie haben mit einer Web-App gearbeitet, und Ihr Workflow wird durch eine Nachricht unterbrochen, die aus dem Nichts zu kommen scheint und nicht einmal dem visuellen Aspekt der App entspricht. Ohne zu berücksichtigen, dass die Sprache der Schaltflächen auch mit der Sprache des Betriebssystems/Browsers übereinstimmt, nicht mit der der Webanwendung.

Für Designer sind JavaScript-Nachrichten viel leistungsfähiger als die Warnfelder.

Sie sind auch viel umfangreicher. Sie können Fett und Kursiv hinzufügen, Sie können Ihre eigenen Schaltflächen auswählen (was ist mit: "Wir entschuldigen uns, aber das eingegebene Passwort ist ungültig. [Passwort zurücksetzen] [Anderes zurücksetzen] [Abbrechen]"?) ².

3. JavaScript: Der Anwendungsfluss wird gestoppt

Wenn ein Warnfeld angezeigt wird, wird JavaScript erst ausgeführt, wenn der Benutzer auf klickt. Auf einer Website könnte es in Ordnung sein. Mit einer Web-App wird es oft zu einem Problem.

4. Sandbox: Zwingen Sie den Benutzer nicht, seinen Computer neu zu starten

Erinnern Sie sich an die beschissenen Websites, die Ihnen eine unendlich viele Nachrichtenboxen zeigen? Die einzige Möglichkeit für Benutzer ohne ausreichenden technischen Hintergrund, um weiterarbeiten zu können, bestand darin, ihren Computer neu zu starten. Dies bringt uns zu einem Problem: Warnfelder liegen außerhalb des Bereichs der Website oder Webanwendung. Sie sind nicht berechtigt, den Benutzer daran zu hindern, auf andere Registerkarten des Browsers zuzugreifen³.

Das gleiche Problem zwang die Browser, es auf unterschiedliche Weise zu lösen. Firefox ermöglicht beispielsweise den Zugriff auf andere Registerkarten, wenn eine Warnung auf Ihrer Registerkarte angezeigt wird. Mit Chrome hingegen können Sie überprüfen, ob Sie keine Warnfelder mehr von einer Seite erhalten möchten, aber dennoch den Zugriff auf andere Registerkarten blockieren.

The screenshot shows an alert box with a checkbox "Prevent this page from creating additional dialogs"

Während der Firefox-Ansatz durchaus gültig ist, kann der Chrome-Ansatz kritisiert werden (da er immer noch jeden Tab blockiert) und ein Problem verursachen: Was ist, wenn der Benutzer durch mehrere von Ihrer App ausgegebene Meldungsfelder und die Überprüfung des Falls und dann Sie ernsthaft verärgert wurde? versucht etwas wirklich Wichtiges zu zeigen? Richtig, der Benutzer wird es nie sehen.

Die Tatsache bleibt die gleiche, die meisten Benutzer werden durch Warnfelder verärgert sein, so dass sie immer noch nicht sehr benutzerfreundlich sind und einen Benutzer ohne ausreichenden technischen Hintergrund ernsthaft blockieren können. Inline blockieren JavaScript-Nachrichten möglicherweise die Seite, nicht jedoch den Browser selbst. Da das Web-App-Modell eine Art Sandboxing ist, bei dem Sie beispielsweise nicht auf die Benutzertastatur zugreifen oder den Computer neu starten oder Dateien von der Festplatte lesen oder im Vollbildmodus arbeiten oder zwei Monitore verwenden können, Warnfelder mit deren Blockierung Effekt brechen stark dieses Sandbox-Modell.

Was ist, wenn sich der Benutzer auf einer anderen Registerkarte befand, als Ihre Anwendung beschlossen hat, das Warnfeld anzuzeigen? Was ist, wenn der Benutzer etwas Wichtiges getan hat und gerade nicht mit Ihrer App interagieren möchte?


¹ Über Gesicht 3, Die Grundlagen des Interaktionsdesigns , Alan Cooper, Robert Reimann und David Cronin, ISBN 978-0-470-08411-3; Kapitel 25: Fehler, Warnungen und Bestätigungen.

² Dies ist nur ein Beispiel. Bitte tun Sie dies nicht in Ihren Webanwendungen, da dies wirklich eine schlechte Wahl für das Design ist.

³ Wenn Sie einen Vergleich mit der Welt der Desktop-Apps wünschen, ähnelt eine Inline-JavaScript-Nachricht einem Meldungsfeld einer Desktop-Anwendung. Ein Warnfeld in einem Browser ist dagegen wie ein Fenster, das aus dem Nichts erscheint und als oberstes Fenster auf einem undurchsichtigen Vollbildhintergrund festgelegt ist, der den Zugriff auf andere Desktopanwendungen blockiert. Jede App, die sich dazu entscheidet, dies einmal auf meinem Computer zu tun, wird sofort und für immer entfernt.

56

Fazit: Die Standarddialogfelder für Eingabeaufforderung, Bestätigung und Warnung entsprechen dem Stil Ihres Browsers und nicht dem Stil Ihrer Website. Die meisten Benutzeroberflächen möchten, dass alle Dialogfelder mit der Benutzeroberfläche ihrer Site fließen. Sie verwenden modale Fenster, um Nachrichten zu präsentieren und Daten mit denselben Schriftarten und Farben wie die Benutzeroberfläche der Site zu sammeln, nicht mit dem Standardgrau und -blau von MSIE oder FF.

3

Sie fügen nur dann Overhead hinzu, wenn Sie die ausgefallenen Dialoge an anderer Stelle nicht benötigen, was Sie wahrscheinlich tun. An diesem Punkt macht es keinen großen Unterschied, ob die Funktionalität als Teil des Browsers oder als Teil des von Ihnen verwendeten Frameworks enthalten ist, und Sie können auch alle Ihre Popups konsistent aussehen lassen.

Obwohl Sie mit Javascript und ohne Frameworks viel anfangen können, erinnere ich mich, wie es war, in Javascript zu entwickeln, bevor die Frameworks verfügbar waren, und ich möchte nicht darauf zurückkommen.

2
Tom Clarkson

Weil Browser nicht sehr gut damit umgehen. Wie Sie vielleicht bemerkt haben, handelt es sich in der Regel um modale Dialoge, die nicht nur verhindern, dass Benutzer ihre Browser verschieben und ihre Größe ändern, sondern auch verhindern, dass auf andere Registerkarten zugegriffen wird, was sehr ärgerlich ist.

Für Dialoge wie Bestätigen und Ändern denke ich immer noch, dass der Browser das Verhalten erzwingen sollte, und für den neuesten Firefox-Browser können Sie sehen, dass sie das oben erwähnte Problem behoben haben. Sie werden in Seitenwarnungen verwendet, die sich auf die aktuelle Seite beziehen.

Daher schlage ich vor, dass Sie das Warnverhalten überschreiben, damit alle Browser (zumindest Warnungen) eleganter umgehen können.

Einige zusammengefasste Gründe:

  • Dies ist die Standard-API, und Entwickler können herausfinden, was Sie versuchen.
  • Es ist benutzerfreundlicher und sieht besser aus.
  • Für die Plattformunterstützung benötigen mobile Websites möglicherweise die native API.
1
Daniel Little