Wahre Lügen optimistischer Benutzeroberflächen

Drei Benutzeroberflächen (UIs) gehen zu einer Kneipe. Der erste bestellt ein Getränk, dann mehrere weitere. Ein paar Stunden später fragt es nach der Rechnung und verlässt betrunken die Kneipe. Die zweite UI bestellt ein Getränk, bezahlt es im Voraus, bestellt ein weiteres Getränk, bezahlt es und so weiter und verlässt nach ein paar Stunden betrunken die Kneipe. Das dritte UI verlässt die Kneipe bereits betrunken sofort nach dem Betreten – es weiß, wie die Kneipen funktionieren und ist effizient genug, um keine Zeit zu verlieren. Hast du schon von diesem Dritten gehört? Es wird als „optimistische Benutzeroberfläche“ bezeichnet.

Nachdem ich kürzlich auf einer Reihe von Konferenzen, die sich sowohl der Front-End-Entwicklung als auch der UX widmeten, über psychologische Leistungsoptimierung diskutiert hatte, war ich überrascht zu sehen, wie wenig das Thema optimistisches UI-Design in der Community angesprochen wird. Ehrlich gesagt ist der Begriff selbst nicht einmal gut definiert. In diesem Artikel werden wir herausfinden, auf welchen Konzepten es basiert, und wir werden einige Beispiele betrachten sowie seinen psychologischen Hintergrund besprechen. Danach werden wir die Bedenken und Hauptpunkte in Bezug auf die Aufrechterhaltung der Kontrolle über diese UX-Technik besprechen.

Weiterführende Literatur zu SmashingMag:

• Der Benutzer ist der anonyme Webdesigner
• Entwerfen von kartenbasierten Benutzeroberflächen
• Conversational Interfaces: Wo stehen wir heute?
  

Aber bevor wir beginnen, um ehrlich zu sein, nichts kann als „optimistische UI“ bezeichnet werden. Vielmehr ist es das mentale Modell hinter der Implementierung einer Schnittstelle. Optimistisches UI-Design hat seine eigene Geschichte und Begründung.

Es war einmal

Vor langer Zeit – als das Wort „Tweet“ hauptsächlich für Vögel galt, Apple kurz vor dem Bankrott stand und die Leute noch Faxnummern auf ihre Visitenkarten schrieben – waren Weboberflächen ziemlich asketisch. Und die überwiegende Mehrheit von ihnen hatte nicht einmal einen Hauch von Optimismus. Eine Interaktion mit einer Schaltfläche könnte beispielsweise einem Szenario ähnlich dem folgenden folgen:

1. Der Benutzer klickt auf eine Schaltfläche.
2. Die Schaltfläche wird in einen deaktivierten Zustand getriggert.
3. Ein Anruf wird an einen Server gesendet.
4. Eine Antwort vom Server wird an die Seite zurückgesendet.
5. Die Seite wird neu geladen, um den Status der Antwort widerzuspiegeln.

Das mag 2016 ziemlich ineffizient aussehen; Überraschenderweise wird das gleiche Szenario jedoch immer noch in vielen Webseiten und Anwendungen verwendet und ist immer noch Teil des Interaktionsprozesses für viele Produkte. Der Grund dafür ist, dass es vorhersehbar und mehr oder weniger fehlersicher ist: Der Benutzer weiß, dass die Aktion vom Server angefordert wurde (der deaktivierte Zustand der Schaltfläche weist darauf hin), und sobald der Server antwortet, zeigt die aktualisierte Seite dies deutlich an das Ende dieser Client-Server-Client-Interaktion. Die Probleme bei dieser Art der Interaktion liegen auf der Hand:

• Der Benutzer muss warten. Inzwischen wissen wir, dass sich schon die kleinste Verzögerung in der Antwortzeit des Servers negativ auf die Wahrnehmung der gesamten Marke durch den User auswirkt, nicht nur auf dieser speziellen Seite.
• Jedes Mal, wenn der Benutzer eine Antwort auf seine Aktion erhält, wird diese auf ziemlich destruktive Weise präsentiert (eine neue Seite wird geladen, anstatt dass die vorhandene aktualisiert wird), was den Kontext der Benutzeraufgabe unterbricht und seinen Gedankengang beeinträchtigen kann. Auch wenn wir hier nicht unbedingt von Multitasking sprechen, ist jeder Wechsel des gedanklichen Kontextes unangenehm. Wenn also eine Aktion nicht inhärent dazu bestimmt ist, den Kontext zu wechseln (Online-Zahlung ist ein gutes Beispiel dafür, wann ein Wechsel natürlich ist), würde der Wechsel einen unfreundlichen Ton des Dialogs zwischen Benutzer und System erzeugen.

Gute, nicht so alte Tage

Dann kam das sogenannte Web 2.0 und bot neue Möglichkeiten der Interaktion mit Webseiten. Deren Kern waren XMLHttpRequest und AJAX. Diese neuen Interaktionsmodi wurden durch „Spinner“ ergänzt: die einfachste Form der Fortschrittsanzeige, deren einziger Zweck darin bestand, dem Benutzer mitzuteilen, dass das System mit der Durchführung einer Operation beschäftigt ist. Jetzt mussten wir die Seite nicht neu laden, nachdem wir eine Antwort vom Server erhalten hatten; Wir könnten stattdessen einfach einen Teil der bereits gerenderten Seite aktualisieren. Dies machte das Web viel dynamischer und ermöglichte gleichzeitig reibungslosere und ansprechendere Erfahrungen für die Benutzer. Die typische Interaktion mit einem Button könnte nun so aussehen:

1. Der Benutzer klickt auf eine Schaltfläche.
2. Die Schaltfläche wird in einen deaktivierten Zustand versetzt, und eine Art Spinner wird auf der Schaltfläche angezeigt, um anzuzeigen, dass das System funktioniert.
3. Ein Anruf wird an den Server gesendet.
4. Eine Antwort vom Server wird an die Seite zurückgesendet.
5. Der visuelle Zustand der Schaltfläche und der Seite werden entsprechend dem Antwortstatus aktualisiert.

Dieses neue Interaktionsmodell adressiert eines der oben genannten Probleme der alten Interaktionsmethode: Die Aktualisierung der Seite erfolgt ohne destruktive Aktion, wodurch der Kontext für den Benutzer erhalten bleibt und er viel besser als zuvor in die Interaktion eingebunden wird.

Diese Art von Interaktionsmustern ist überall in digitalen Medien weit verbreitet. Aber ein Problem bleibt: Benutzer müssen immer noch auf eine Antwort vom Server warten. Ja, wir können unsere Server schneller reagieren lassen, aber egal wie sehr wir uns bemühen, die Infrastruktur zu beschleunigen, die Benutzer müssen immer noch warten. Auch hier warten die Benutzer nicht gerne, um es milde auszudrücken. Untersuchungen zeigen beispielsweise, dass 78 % der Verbraucher aufgrund langsamer oder unzuverlässiger Websites negative Emotionen empfinden. Darüber hinaus geben laut einer von Harris Interactive für Tealeaf durchgeführten Umfrage 23 % der Benutzer zu, dass sie ihre Telefone beschimpfen, 11 % haben sie angeschrien und ganze 4 % haben ihr Telefon tatsächlich geworfen, wenn ein Problem mit einer Online-Transaktion auftritt. Verzögerungen gehören zu diesen Problemen.

Selbst wenn Sie eine Art Fortschrittsanzeige anzeigen, während der Benutzer wartet, reicht das heutzutage einfach nicht mehr aus, es sei denn, Sie sind sehr kreativ mit der Anzeige. Die Leute haben sich größtenteils daran gewöhnt, dass Spinner die Langsamkeit eines Systems anzeigen. Spinner werden jetzt eher mit rein passivem Warten in Verbindung gebracht, wenn der Benutzer keine andere Wahl hat, als entweder auf die Antwort des Servers zu warten oder den Tab oder die Anwendung vollständig zu schließen. Lassen Sie uns also einen Schritt überdenken, um diese Art der Interaktion zu verbessern. Schauen wir uns dieses Konzept einer optimistischen Benutzeroberfläche an.

Optimistische Benutzeroberfläche

Wie bereits erwähnt, ist eine optimistische Benutzeroberfläche nichts anderes als eine Möglichkeit, die Mensch-Computer-Interaktion zu handhaben. Um die Hauptideen dahinter zu verstehen, bleiben wir bei unserem „Benutzer klickt auf eine Schaltfläche“-Szenario. Aber das Prinzip wird für so ziemlich jede Art von Interaktion gleich sein, die Sie vielleicht optimistisch machen möchten. Laut dem Oxford English Dictionary:

op-ti-mis-tic , adj. hoffnungsvoll und zuversichtlich in die Zukunft.

Beginnen wir mit dem Teil „Zuversichtlich in die Zukunft“.

Was denken Sie: Wie oft gibt Ihr Server bei einer Benutzeraktion einen Fehler zurück? Fällt Ihre API beispielsweise häufig aus, wenn Benutzer auf eine Schaltfläche klicken? Oder schlägt es oft fehl, wenn Benutzer auf einen Link klicken? Ehrlich gesagt glaube ich das nicht. Dies kann natürlich je nach API, Serverlast, Fehlerbehandlung und anderen Faktoren variieren, an denen Sie als Frontend-Entwickler oder UX-Spezialist möglicherweise nicht beteiligt sein möchten. Aber solange die API stabil und vorhersehbar ist und das Front-End legitime Aktionen in der Benutzeroberfläche richtig kommuniziert, dann wird die Anzahl der Fehler als Reaktion auf vom Benutzer initiierte Aktionen ziemlich gering sein. Ich würde sogar sagen, dass sie niemals über 1 bis 3 % hinausgehen sollten. Das bedeutet, dass in 97 bis 99 % der Fälle, wenn der Benutzer auf eine Schaltfläche auf einer Website klickt, die Antwort des Servers erfolgreich und ohne Fehler sein sollte. Dies verdient eine bessere Perspektive:

Denken Sie einen Moment darüber nach: Wenn wir uns bei einer Erfolgsantwort zu 97 bis 99 % sicher wären, könnten wir hinsichtlich der Zukunft dieser Antworten zuversichtlich sein – nun, zumindest viel zuversichtlicher in Bezug auf die Zukunft als Schrödingers Katze. Wir könnten eine ganz neue Geschichte über die Schaltflächeninteraktion schreiben:

1. Der Benutzer klickt auf eine Schaltfläche.
2. Der visuelle Zustand der Schaltfläche wird sofort in den Erfolgsmodus versetzt.

Das ist es! Mehr gibt es zumindest aus Nutzersicht nicht zu sagen – kein Warten, kein Starren auf einen deaktivierten Button und nicht schon wieder ein nerviger Spinner. Die Interaktion ist nahtlos, ohne dass das System grob eingreift, um den Benutzer an sich selbst zu erinnern.

Aus Entwicklersicht sieht der komplette Zyklus so aus:

1. Der Benutzer klickt auf eine Schaltfläche.
2. Der visuelle Zustand der Schaltfläche wird sofort in den Erfolgsmodus versetzt.
3. Der Anruf wird an den Server gesendet.
4. Die Antwort vom Server wird an die Seite zurückgesendet.
5. In 97 bis 99 % der Fälle wissen wir, dass die Antwort erfolgreich sein wird, und müssen den Benutzer daher nicht belästigen.
6. Nur bei einer fehlgeschlagenen Anfrage meldet sich das System. Machen Sie sich vorerst keine Sorgen darüber – wir werden später in diesem Artikel zu diesem Punkt kommen.

Schauen wir uns einige Beispiele für optimistische Interaktionen an. Sie kennen wahrscheinlich die „Gefällt mir“-Schaltflächen, wie sie auf Facebook und Twitter zu finden sind. Werfen wir einen Blick auf Letzteres.

Es beginnt, offensichtlich genug, mit dem Klicken auf die Schaltfläche. Beachten Sie jedoch den visuellen Zustand der Schaltfläche, wenn der Benutzer nicht mehr auf die Schaltfläche drückt oder mit der Maus darüber fährt. Es wechselt sofort in den Erfolgszustand!

Mal sehen, was in diesem Moment auf der Registerkarte „Netzwerk“ der Entwicklertools unseres Browsers passiert.

Die Registerkarte „Netzwerk“ zeigt, dass die Serveranfrage gesendet wurde, aber noch in Bearbeitung ist. Der „Gefällt mir“-Zähler wurde noch nicht erhöht, aber mit der Farbänderung kommuniziert die Oberfläche dem Benutzer eindeutig den Erfolg, noch bevor er eine Antwort vom Server erhalten hat.

Nachdem eine erfolgreiche Antwort vom Server empfangen wurde, wird der Zähler aktualisiert, aber der Übergang ist viel subtiler als die sofortige Farbänderung. Dies bietet dem Benutzer ein reibungsloses, ununterbrochenes Erlebnis ohne wahrgenommenes Warten.

Ein weiteres Beispiel für optimistische Interaktion ist Facebook mit einem eigenen „Gefällt mir“-Button. Das Szenario ist ziemlich ähnlich, außer dass Facebook den Zähler zusammen mit der Erfolgsfarbe der Schaltfläche sofort aktualisiert, ohne auf die Antwort des Servers zu warten.

Eines ist hier jedoch zu beachten. Wenn wir uns die Antwortzeit des Servers ansehen, sehen wir, dass sie etwas mehr als 1 Sekunde beträgt. Wenn man bedenkt, dass das RAIL-Modell 100 Millisekunden als optimale Reaktionszeit für eine einfache Interaktion empfiehlt, wäre dies normalerweise viel zu lang. Aufgrund der optimistischen Natur dieser Interaktion nimmt der Benutzer in diesem Fall jedoch keine Wartezeit wahr. Hübsch! Dies ist ein weiteres Beispiel für psychologische Leistungsoptimierung.

Aber seien wir ehrlich: Es besteht immer noch eine Wahrscheinlichkeit von 1 bis 3 %, dass der Server einen Fehler zurückgibt. Oder vielleicht ist der Benutzer einfach offline. Oder, was wahrscheinlicher ist, vielleicht gibt der Server eine technisch gesehen erfolgreiche Antwort zurück, aber die Antwort enthält Informationen, die vom Client weiter verarbeitet werden müssen. Infolgedessen erhält der Benutzer keine Fehleranzeige, aber wir können die Antwort auch nicht als Erfolg betrachten. Um zu verstehen, wie man mit solchen Fällen umgeht, sollten wir verstehen, warum und wie optimistische UIs überhaupt psychologisch funktionieren.

Die Psychologie hinter optimistischen Benutzeroberflächen

Bisher habe ich noch niemanden über die oben erwähnten optimistischen Interaktionen in den großen sozialen Netzwerken klagen hören. Nehmen wir also an, diese Beispiele haben uns davon überzeugt, dass optimistische UIs funktionieren. Aber warum arbeiten sie für Benutzer? Sie funktionieren einfach, weil die Leute das Warten hassen. Das ist es, Leute! Sie können zum nächsten Teil des Artikels springen.

Aber wenn Sie immer noch lesen, dann interessiert Sie wahrscheinlich, warum das so ist. Lassen Sie uns also etwas tiefer in die psychologische Grundlage dieses Ansatzes eintauchen.

Eine optimistische Benutzeroberfläche hat zwei grundlegende Bestandteile, die eine psychologische Analyse wert sind:

• die schnelle Reaktion auf die Aktion des Benutzers;
• den Umgang mit potenziellen Fehlern auf dem Server, im Netzwerk und anderswo.

Schnelle Reaktion auf Benutzeraktion

Wenn wir von optimistischem UI-Design sprechen, sprechen wir von einer optimalen Reaktionszeit in der Mensch-Computer-Interaktion. Und Empfehlungen für diese Art der Kommunikation gibt es bereits seit 1968. Damals veröffentlichte Robert B. Miller sein wegweisendes Werk „Response Time in Man-Computer Conversational Transactions“ (PDF), in dem er bis zu 17 definiert verschiedene Arten von Antworten, die ein Benutzer von einem Computer erhalten kann. Eine dieser Arten nennt Miller eine „Reaktion auf die Aktivierung der Steuerung“ – die Verzögerung zwischen dem Drücken einer Taste und dem visuellen Feedback. Schon 1968 dürfte sie 0,1 bis 0,2 Sekunden nicht überschritten haben. Ja, das RAIL-Modell ist nicht das erste, das dies empfiehlt – die Empfehlung gibt es seit etwa 50 Jahren. Miller merkt jedoch an, dass selbst diese kurze Verzögerung des Feedbacks für erfahrene Benutzer viel zu langsam sein könnte. Das bedeutet, dass der Benutzer im Idealfall innerhalb von 100 Millisekunden eine Bestätigung seiner Aktion erhalten sollte . Dies kommt in den Bereich einer der schnellsten unbewussten Aktionen, die der menschliche Körper ausführen kann – ein Augenzwinkern. Aus diesem Grund wird das 100-Millisekunden-Intervall normalerweise als unmittelbar wahrgenommen. „Die meisten Menschen blinzeln ungefähr 15 Mal pro Minute, und ein Blinzeln dauert im Durchschnitt 100 bis 150 Millisekunden“, sagt Davina Bristow vom Institut für Neurologie des University College London und fügt hinzu, dass dies „bedeutet, dass wir insgesamt mindestens 9 Tage pro Jahr mit Blinzeln verbringen. ”

Aufgrund ihrer sofortigen visuellen Reaktion (noch bevor die eigentliche Anfrage abgeschlossen ist) ist eine optimistische Benutzeroberfläche eines der Beispiele für Techniken der frühen Fertigstellung, die bei der psychologischen Leistungsoptimierung verwendet werden. Aber die Tatsache, dass Menschen Oberflächen mögen, die im Handumdrehen reagieren, sollte die meisten von uns wirklich nicht überraschen. Und es ist auch nicht schwer zu erreichen. Auch früher haben wir Schaltflächen sofort nach dem Anklicken deaktiviert, was in der Regel ausreichte, um die Eingabe des Benutzers zu bestätigen. Aber ein deaktivierter Zustand in einem Oberflächenelement bedeutet passives Warten: Der Benutzer kann nichts dagegen tun und hat keine Kontrolle über den Prozess. Und das ist für den Benutzer sehr frustrierend. Aus diesem Grund überspringen wir den deaktivierten Zustand in einer optimistischen Benutzeroberfläche vollständig – wir kommunizieren ein positives Ergebnis, anstatt den Benutzer warten zu lassen.

Umgang mit potenziellen Fehlern

Kommen wir zum zweiten interessanten psychologischen Aspekt des optimistischen UI-Designs – dem Umgang mit potenziellen Fehlern. Generell gibt es viele Informationen und Artikel, wie man mit UI-Fehlern bestmöglich umgehen kann. Wir werden zwar später in diesem Artikel sehen, wie Fehler behandelt werden, aber was in einer optimistischen Benutzeroberfläche am wichtigsten ist, ist nicht, wie wir mit Fehlern umgehen, sondern wann wir es tun.

Menschen organisieren ihre Aktivitäten natürlicherweise in Klumpen, die durch die Erfüllung eines subjektiv definierten Zwecks oder Unterzwecks beendet werden. Manchmal bezeichnen wir diese Klumpen als „Gedankengang“, „Gedankenfluss“ (PDF) oder einfach als „Fluss“. Der Flow-Zustand ist geprägt von höchstem Genuss, energetischer Fokussierung und kreativer Konzentration. Während eines Flows ist der Benutzer vollständig in die Aktivität vertieft. Ein Tweet von Tammy Everts veranschaulicht dies sehr schön:

Im Internet ist die Dauer solcher Aktivitätshäufungen viel kürzer. Lassen Sie uns noch einmal kurz auf die Arbeit von Robert B. Miller zurückkommen. Zu den Antworttypen, die er nennt, gehören:

• eine Antwort auf eine einfache Abfrage von aufgelisteten Informationen;
• eine Antwort auf eine komplexe Anfrage in grafischer Form;
• eine Antwort auf „System, verstehst du mich?“

All dies verknüpft er mit demselben 2-Sekunden- Intervall, innerhalb dessen der Benutzer die relevante Art von Antwort erhalten sollte. Ohne weiter darauf einzugehen, sollten wir anmerken, dass dieses Intervall auch vom Arbeitsgedächtnis einer Person abhängt (bezieht sich auf die Zeitspanne, in der eine Person eine bestimmte Menge an Informationen im Kopf behalten und, was noch wichtiger ist, in der Lage ist, sie zu manipulieren). Für uns als Entwickler und UX-Spezialisten bedeutet dies, dass der Benutzer innerhalb von 2 Sekunden nach der Interaktion mit einem Element in einem Flow ist und sich auf die erwartete Antwort konzentriert. Liefert der Server in diesem Intervall einen Fehler zurück, befindet sich der Nutzer sozusagen noch im „Dialog“ mit der Oberfläche. Es ähnelt einem Dialog zwischen zwei Personen, bei dem Sie etwas sagen und die andere Person Ihnen leicht widerspricht. Stellen Sie sich vor, die andere Person hätte lange zustimmend genickt (das Äquivalent zu unserer Anzeige eines Erfolgszustands in der Benutzeroberfläche), aber dann schließlich „nein“ zu Ihnen gesagt. Umständlich, nicht wahr? Eine optimistische Benutzeroberfläche muss dem Benutzer also innerhalb von 2 Sekunden des Flows einen Fehler mitteilen.

Bewaffnet mit der Psychologie, wie man mit Fehlern in einer optimistischen Benutzeroberfläche umgeht, kommen wir endlich zu diesen 1 bis 3 % der fehlgeschlagenen Anfragen.

Die pessimistische Seite des optimistischen UI-Designs

Die mit Abstand häufigste Bemerkung, die ich höre, ist, dass optimistisches UI-Design eine Art schwarzes Muster ist – Betrug, wenn man so will. Das heißt, indem wir es verwenden, belügen wir unsere Benutzer über das Ergebnis ihrer Interaktion. Rechtlich würde wohl jedes Gericht diesen Punkt unterstützen. Dennoch betrachte ich die Technik als Vorhersage oder Hoffnung. (Erinnern Sie sich an die Definition von „optimistisch“? Hier lassen wir etwas Raum für den „hoffnungsvollen“ Teil davon.) Der Unterschied zwischen „lügen“ und „vorhersagen“ liegt darin, wie Sie mit diesen 1 bis 3 % der fehlgeschlagenen Anfragen umgehen. Schauen wir uns an, wie sich der optimistische „Gefällt mir“-Button von Twitter offline verhält.

Erstens wechselt die Schaltfläche gemäß dem optimistischen UI-Muster direkt nach dem Klicken in den Erfolgszustand – wiederum ohne dass der Benutzer die Schaltfläche länger drückt oder mit der Maus darüber fährt, genau so, wie sich die Schaltfläche verhält, wenn der Benutzer online ist.

Da der Benutzer jedoch offline ist, schlägt die Anforderung fehl.

Daher sollte der Fehler so schnell wie möglich im Flow des Benutzers mitgeteilt werden. Wiederum sind 2 Sekunden normalerweise die Dauer eines solchen Flusses. Twitter kommuniziert dies auf die subtilste Art und Weise, indem es einfach den Status der Schaltfläche zurücksetzt.

Der gewissenhafte Leser könnte hier sagen, dass diese Fehlerbehandlung noch einen Schritt weiter gehen könnte, indem der Benutzer tatsächlich benachrichtigt wird, dass die Anfrage nicht gesendet werden konnte oder dass ein Fehler aufgetreten ist. Dies würde das System so transparent wie möglich machen. Aber es gibt einen Haken – oder besser gesagt eine Reihe von Problemen:

• Jede Art von Benachrichtigung, die plötzlich auf dem Bildschirm erscheint, würde den Kontext des Benutzers ändern und ihn dazu auffordern, den Grund für den Fehler zu analysieren, ein Grund, der wahrscheinlich in der Fehlermeldung angezeigt würde.
• Wie bei jeder Fehlermeldung oder Benachrichtigung sollte diese den Benutzer in diesem neuen Kontext anleiten, indem sie umsetzbare Informationen bereitstellt.
• Diese verwertbaren Informationen würden einen weiteren Kontext setzen.

OK, inzwischen sind wir uns alle einig, dass dies etwas kompliziert wird. Während diese Fehlerbehandlung beispielsweise für ein großes Formular auf einer Website sinnvoll wäre, ist sie für eine so einfache Aktion wie das Klicken auf einen „Gefällt mir“-Button übertrieben – sowohl in Bezug auf die erforderliche technische Entwicklung als auch auf das Arbeitsgedächtnis der Benutzer.

Also, ja, wir sollten offen mit dem Scheitern einer optimistischen Benutzeroberfläche umgehen und es so schnell wie möglich kommunizieren, damit unser Optimismus nicht zur Lüge wird. Aber es sollte proportional zum Kontext sein. Für ein fehlgeschlagenes Like sollte es ausreichen, den Button subtil in seinen ursprünglichen Zustand zurückzusetzen – das heißt, es sei denn, der Benutzer mag den Status seines Lebensgefährten, in diesem Fall funktioniert das Ding besser die ganze Zeit.

Extremer Pessimismus

Eine weitere Frage könnte sich stellen: Was passiert, wenn der Benutzer den Browser-Tab schließt, nachdem er eine Erfolgsanzeige erhalten hat, aber bevor die Antwort vom Server zurückgegeben wird? Der unangenehmste Fall wäre, wenn der Benutzer den Tab schließt, bevor überhaupt eine Anfrage an den Server gesendet wurde. Aber wenn der Benutzer nicht extrem flink ist oder die Zeit verlangsamen kann, ist dies kaum möglich.

Wenn eine optimistische Benutzeroberfläche richtig implementiert ist und Interaktionen nur auf die Elemente angewendet werden, die nie länger als 2 Sekunden auf eine Serverantwort warten, müsste der Benutzer die Browserregisterkarte innerhalb dieses 2-Sekunden-Fensters schließen. Das ist mit einem Tastendruck nicht besonders schwierig; Wie wir jedoch gesehen haben, wird die Anfrage in 97 bis 99 % der Fälle erfolgreich sein, unabhängig davon, ob die Registerkarte aktiv ist oder nicht (es wird nur keine Antwort an den Client zurückgegeben).

Dieses Problem tritt also möglicherweise nur bei den 1 bis 3 % auf, die einen Serverfehler erhalten. Andererseits, wie viele von denen beeilen sich, den Tab innerhalb von 2 Sekunden zu schließen? Ich glaube nicht, dass die Zahl signifikant sein wird, es sei denn, sie befinden sich in einem Geschwindigkeitswettbewerb zum Schließen von Tabs. Wenn Sie jedoch der Meinung sind, dass dies für Ihr spezielles Projekt relevant ist und negative Folgen haben könnte, verwenden Sie einige Tools, um das Benutzerverhalten zu analysieren. Wenn die Wahrscheinlichkeit eines solchen Szenarios hoch genug ist, beschränken Sie die optimistische Interaktion auf unkritische Elemente.

Fälle, in denen eine Anfrage künstlich verzögert wird, habe ich bewusst nicht erwähnt; diese fallen im Allgemeinen nicht unter den Begriff des optimistischen UI-Designs. Darüber hinaus haben wir mehr als genug Zeit mit der pessimistischen Seite der Dinge verbracht, also fassen wir einige Hauptpunkte zur Implementierung einer guten optimistischen Benutzeroberfläche zusammen.

Faustregeln

Ich hoffe aufrichtig, dass dieser Artikel Ihnen geholfen hat, einige der Hauptkonzepte hinter dem optimistischen UI-Design zu verstehen. Vielleicht möchten Sie diesen Ansatz in Ihrem nächsten Projekt ausprobieren. Wenn ja, sollten Sie Folgendes beachten, bevor Sie beginnen:

• Eine Voraussetzung für alles, worüber wir bisher gesprochen haben: Stellen Sie sicher, dass die API, auf die Sie sich verlassen, stabil ist und vorhersehbare Ergebnisse liefert. Genug gesagt.
• Die Schnittstelle sollte potenzielle Fehler und Probleme abfangen, bevor eine Anfrage an den Server gesendet wird. Besser noch, eliminieren Sie vollständig alles, was zu einem Fehler in der API führen könnte. Je einfacher ein UI-Element ist, desto einfacher ist es, es optimistisch zu gestalten.
• Wenden Sie optimistische Muster auf einfache binäre Elemente an, für die nicht mehr als eine Erfolgs- oder Misserfolgsantwort erwartet wird. Wenn beispielsweise ein Klick auf eine Schaltfläche eine Serverantwort wie „Ja“, „Nein“ oder „Vielleicht“ voraussetzt (die alle in unterschiedlichem Maße Erfolg darstellen können), wäre eine solche Schaltfläche ohne ein optimistisches Muster besser dran.
• Kennen Sie die Antwortzeiten Ihrer API. Das ist entscheidend. Wenn Sie wissen, dass die Antwortzeit für eine bestimmte Anfrage nie unter 2 Sekunden sinkt, dann ist es wahrscheinlich am besten, zuerst etwas Optimismus über Ihre API zu streuen. Wie bereits erwähnt, funktioniert eine optimistische Benutzeroberfläche am besten für Serverantwortzeiten von weniger als 2 Sekunden. Wenn Sie darüber hinausgehen, könnte dies zu unerwarteten Ergebnissen und vielen frustrierten Benutzern führen. Betrachten Sie sich gewarnt.
• Bei einer optimistischen Benutzeroberfläche geht es nicht nur um Schaltflächenklicks. Der Ansatz könnte auf verschiedene Interaktionen und Ereignisse während des Lebenszyklus einer Seite angewendet werden, einschließlich des Ladens der Seite. Zum Beispiel folgen Skeleton-Bildschirme der gleichen Idee: Sie sagen voraus, dass der Server erfolgreich antworten wird, um Platzhalter auszufüllen, die dem Benutzer so schnell wie möglich angezeigt werden.

Optimistisches UI-Design ist weder wirklich neu im Web noch eine besonders fortschrittliche Technik, wie wir gesehen haben. Es ist nur ein weiterer Ansatz, ein weiteres mentales Modell, das Ihnen hilft, die wahrgenommene Leistung Ihres Produkts zu steuern. Optimistisches UI-Design basiert auf den psychologischen Aspekten der Mensch-Computer-Interaktion und kann Ihnen bei intelligenter Verwendung helfen, bessere, nahtlosere Erfahrungen im Web zu erstellen, während nur sehr wenig Implementierung erforderlich ist. Aber um das Muster wirklich effektiv zu machen und zu verhindern, dass unsere Produkte die Benutzer belügen, müssen wir die Mechanik des optimistischen UI-Designs verstehen.

Ressourcen

• „Reaktionszeit bei Mensch-Computer-Gesprächstransaktionen“ (PDF), Robert B. Miller, Fall Joint Computer Conference, 1968
• „Introducing RAIL: A User-Centric Model for Performance“, Paul Irish, Paul Lewis, Smashing Magazine, 2015
• „Mobile Web Stress: The Impact of Network Speed ​​on Emotional Engagement and Brand Perception“, Tammy Everts, Radware Blog, 2013
• Anwendungen von Flow in der menschlichen Entwicklung und Bildung , Mihaly Csikszentmihalyi, 2014
• „Mobile Designdetails: Vermeiden Sie den Spinner“, Luke Wroblewski, 2013
• „Warum Leistung wichtig ist, Teil 2: Wahrnehmungsmanagement“, Denys Mishunov, Smashing Magazine, 2015