Aufforderung, Bestätigung und Warnung von JavaScript als "altmodisch" eingestuft [geschlossen]

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 wird für alle Front-End-Skripte jQuery verwendet. Auf dem Server wird PHP und MySQL ausgeführt.

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

Die Verwendung von handgefertigten oder Plug-in-basierten Lösungen ist für komplexe Formulare und spezielle Anforderungen in Ordnung. Wenn Sie jedoch nur einen einzelnen Wert anfordern oder das Löschen eines Datensatzes bestätigen müssen, warum sollten Sie Ihrer Web-App einen solchen Mehraufwand hinzufügen? Darüber hinaus bieten iOS und Android gut angepasste Meldungsdialoge, wenn Sie Aufforderung, Bestätigung und Warnung verwenden.

1. UX: Message-Boxen sind meistens böse

Alarmboxen sind aus UX-Sicht in jedem Fall schlecht. In Desktop-Apps. In Web-Apps als Alerts oder Inline-JavaScript-Nachrichten. Überall.

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

• Fragen Sie nicht.
• Machen Sie alle Aktionen umkehrbar.
• Geben Sie Feedback ohne Modell, um Benutzern zu helfen, Fehler zu vermeiden.

Anschließend teilen uns die Autoren mit, wie die Warnungsfelder durch den richtigen Entwurfsansatz ersetzt werden.

Aufforderungsnachrichten unterscheiden sich geringfügig. Und dennoch beeinträchtigen sie die Benutzerfreundlichkeit Ihrer App. Wenn Sie möchten, dass der Benutzer etwas eingibt, sollten Sie ein Textfeld oder einen Textbereich verwenden und ihn bei Bedarf mit JavaScript dekorieren. Seien Sie nicht faul und bieten Sie eine umfangreiche Benutzeroberflä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 unbegrenzt 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 langem Text? 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 deine Web-App, wenn ich so dumm bin? Eigentlich zeigen Google-Anwendungen wie GMail den richtigen Ansatz. Sie können entfernen, löschen, zerstören, und wenn Sie dies tun, zeigt die App einen kleinen "Rückgängig" -Link 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. „Die rechte Maustaste wird auf dieser Website gesperrt , 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. Sicher, ich werde es senden, ohne die Rechtschreibung zu überprüfen.

Fazit: Aus Sicht der Benutzererfahrung verwenden die Anwendungen die meiste Zeit fälschlicherweise Meldungsfelder.

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

Nun, es gibt weitere Gründe, warum Nachrichtenfelder in Webanwendungen nicht verwendet werden:

2. Design: Alarmboxen haben ein eigenes Design

Sie können überhaupt keine Alarmbox entwerfen. Sie können die Farbe, die Größe und die 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 Meldung unterbrochen, die scheinbar aus dem Nichts stammt und nicht einmal dem visuellen Aspekt der App entspricht. Abgesehen davon, dass die Sprache der Schaltflächen auch mit der Sprache des Betriebssystems / Browsers und nicht mit der der Webanwendung übereinstimmt.

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 und Ihre eigenen Schaltflächen auswählen.

3. JavaScript: Anwendungsfluss stoppt

Wenn ein Warnungsfeld angezeigt wird, wird JavaScript so lange nicht ausgeführt, bis der Benutzer auf klickt. Auf einer Website könnte es in Ordnung sein. Bei einer Web-App wird dies häufig zu einem Problem.

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

Erinnern Sie sich an die beschissenen Websites, auf denen unendlich viele Nachrichtenfelder angezeigt werden ? Die einzige Möglichkeit für die Benutzer ohne ausreichenden technischen Hintergrund, ihre Arbeit fortzusetzen, bestand darin, ihren Computer neu zu starten. Dies bringt uns zu einem Problem: Warnmeldungsfelder sind außerhalb des Bereichs der Website oder Webanwendung. Sie sind nicht berechtigt, den Benutzer am Zugriff auf andere Registerkarten des Browsers zu hindern³.

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. Andererseits können Sie in Chrome überprüfen, ob Sie keine Warnungsfelder mehr von einer Seite erhalten möchten, aber dennoch den Zugriff auf andere Registerkarten blockieren.

Der Firefox-Ansatz ist zwar durchaus gültig, der Chrome-Ansatz kann jedoch kritisiert werden (da er nach wie vor alle Tabs blockiert) und ein Problem verursachen: Was passiert, wenn der Nutzer durch mehrere von Ihrer App ausgegebene Meldungsfelder stark verärgert wurde und den Fall überprüft hat, und dann Sie versucht, etwas wirklich Wichtiges zu zeigen? Richtig, der Benutzer wird es nie sehen.

Die Tatsache bleibt die gleiche, die meisten Benutzer werden von Warnmeldungsfeldern genervt, so dass sie immer noch nicht sehr benutzerfreundlich sind und möglicherweise einen Benutzer mit unzureichendem technischen Hintergrund schwer blockieren. Inline-JavaScript-Nachrichten blockieren möglicherweise die Seite, nicht jedoch den Browser. Da es sich bei dem Web-App-Modell um eine Art Sandbox handelt, bei der Sie beispielsweise nicht auf die Benutzertastatur zugreifen oder den Computer neu starten oder Dateien von der Festplatte lesen oder den Vollbildmodus aktivieren oder zwei Monitore verwenden können, wird dies durch Warnmeldungsfelder mit ihrer Sperrwirkung erheblich beeinträchtigt Sandbox-Modell .

Und was ist, wenn sich der Benutzer auf einer anderen Registerkarte befand, als Ihre Anwendung entschied, das Warnungsfeld anzuzeigen? Was ist, wenn der Benutzer etwas Wichtiges getan hat und jetzt nicht mit Ihrer App interagieren möchte?

^{¹ About Face 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. Tun Sie dies bitte nicht in Ihren Webanwendungen, da dies 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 Warnungsfeld in einem Browser ist dagegen wie ein Fenster, das aus dem Nichts als oberstes Fenster auf einem undurchsichtigen Vollbildhintergrund angezeigt wird und Sie daran hindert, auf eine andere Desktopanwendung zuzugreifen. Jede App, die dies einmal auf meinem Computer tun wird, wird sofort und für immer entfernt.}

Fazit: Die Standarddialogfelder für Eingabeaufforderung, Bestätigung und Warnung stimmen mit dem Stil Ihres Browsers überein, nicht mit dem Stil Ihrer Website. Die meisten Benutzeroberflächenbenutzer 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 Standard-Grau und Blau von MSIE oder FF.

Sie fügen nur Overhead hinzu, wenn Sie die ausgefallenen Dialoge an anderer Stelle nicht benötigen, was Sie wahrscheinlich auch tun. Zu diesem Zeitpunkt 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.

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

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

Bei Dialogen wie "Bestätigen" und "Ändern" sollte der Browser das Verhalten noch verstärken, und bei dem neuesten Firefox-Browser können Sie sehen, dass das oben erwähnte Problem behoben wurde. Sie werden in Seitenwarnungen verwendet, die auf die aktuelle Seite zugeschnitten sind.

Ich schlage daher vor, dass Sie das Warnverhalten außer Kraft setzen, damit alle Browser (zumindest Warnmeldungen) eleganter arbeiten können.

Einige zusammengefasste Gründe:

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