Aloha ;) Ich klinke mich mal an der Stelle ganz random ein, um vielleicht einen weiteren Aspekt in die Abwägung mit einzubringen, der bisher unter den Tisch gefallen ist. Als Vorwort: Ich bin nach der Lektüre vor allem von [diesem Artikel](https://www.smashingmagazine.com/2016/11/true-lies-of-optimistic-user-interfaces/) (ja, derselbe Autor wie der von Gunnar verlinkte Vortrag, aber die Erklärungen sind weit besser als auf den Folien) durchaus von der Sinnhaftigkeit von "optimistic UI" überzeugt. Wie immer nicht als Allheilmittel, aber in seinen Grenzen. > > Der Fall hier mit der Platzreservierung ist anders zu betrachten, da will man kein "optimistic UI". > > Warum nicht? Ganz konkret, bitte. Ich möchte mal von der anderen Seite argumentieren. Dass "optimistic ui" da sinnvoll ist, wo ein User eine Eingabe tätigt, die der Server nur entgegennehmen muss, ist wahrscheinlich unstrittig. Klassisches Beispiel für eine solche Eingabe sind die auch im Artikel mehrfach zitierten Like-Buttons der verschiedenen sozialen Netzwerke. Da kann etwas schiefgehen (zum Beispiel wenn der Client offline ist), aber es ist sehr unwahrscheinlich und handelt sich um den absoluten Fehlerfall. Die Funktion an sich ist so ausgelegt, dass sie selbst keinen Widerspruch erzeugt (Ich kann ein like abgeben wann und wo ich will, eine Plausibilitätsprüfung, die über das übliche wer-bist-du-und-darfst-du-das hinausgeht, findet nicht statt). Die zentrale Frage für mich ist hier, ob diese Voraussetzungen auch im Fall unseres kleinen Theaters gegeben sind - und falls nein ist die Verwendung von optimistic ui vielleicht doch nochmal mehr Überlegung wert als im Fall der Like-Buttons. Punkt 1: Wir haben hier an den Server die Anforderung, eine Vorreservierung vorzunehmen. Wir gehen davon aus, dass auch bei ordnungsgemäßem Funktionieren des Systems ein Fehlschlag auftreten kann - quasi by design dieses Features, da wir ja Kollisionen vermeiden müssen. Mir ist bewusst, dass der Fakt, dass es sich um ein kleines Theater handelt und nicht um Bruce Springsteen, dazu führt, dass dieses Argument in der Bedeutung schrumpft, weil die Größe des Systems nicht viele Kollisionen erwarten lässt. Aber dennoch sollten wir uns klarmachen, dass wir hier über ein im Vergleich zum Like-Button *relativ gesehen* deutlich erhöhtes *failure*-Risiko sprechen. Diesen Aspekt kann man abtun wenn man möchte. Es gibt sicher extremere Beispiele, aber ganz grundsätzlich muss man die Größe des *failure*-Risiko eben in die Abwägung mit einbeziehen. Das mag man mit dem Verweis auf das **kleine** Theater in diesem Fall auch erfüllt haben. Folgender wiegt meiner Meinung nach ein wenig schwerer: Punkt 2: Was der Server hier intern tut, ist, eine *Vorreservierung* vorzunehmen. Bei einem *optimistic ui* wird das nicht unbedingt klar. So kann der user wenn er auf einen Platz klickt, um diesen für sich auszuwählen, nicht unterscheiden, ob jetzt einfach nur der Platz im Formular angewählt wurde, das erst bei Abschicken auf Kollisionen überprüft wird, oder ob tatsächlich sofort eine Überprüfung auf Kollisionen stattfindet. Vielleicht ist das aber - als Designentscheidung - eine Information, die man dem user zukommen lassen möchte, damit er sich eben nicht extrem beeilen muss, weil seine Plätze noch frei sind. Wenn der User wegen *optimistic ui* denkt, dass keine Kollisionsprüfung stattfindet, kann es passieren, dass er in Stress gerät, weil er denkt, sich die guten Plätze, die er eben noch anwählen konnte, jetzt auch sichern zu müssen. Wenn man dem user visuell anzeigt, dass eine Interaktion mit dem Server stattfindet kann er sich daraus zusammenreimen, dass er diese eben angewählten Plätze eher nicht verlieren wird, wenn er das Formular nicht sofort nach Auswahl absendet. Mit *optimistic ui* kann man dem User nicht vermitteln, dass eine temporäre Vorreservierung stattfindet. Das kann durchaus an der Stelle - auch bei einem kleinen Theater - ein Grund sein, auf *optimistic ui* verzichten zu wollen. Ein paar weiter Gedanken: Auch im *optimistic ui* soll eine *failure*-Botschaft spätestens nach 2 Sekunden eintreffen. Das bedeutet im Umkehrschluss, dass im *not so optimistic ui* auch höchstens 2 Sekunden lang der Ladekringel auf dem eben angeklickten Platz zu sehen ist. Dadurch, dass man sich beim Plätze-Aussuchen die gesamte Zeit über auf diese Aufgabe fokussiert fällt das Warten wahrscheinlich weniger ins Gewicht. Aus meiner Warte stellt es sich so dar, dass das Warten auf die Serverantwort vor allem dann eine Belastung darstellt, wenn man sich direkt danach einem anderen Kontext zuwenden möchte - wie beim Like-Button, den man betätigt nachdem man ein Posting gelesen hat und nach dessen Betätigung man sich sofort ohne weiteres Ausharren dem nächsten Posting zuwenden möchte. Da stört ein Ladekringel und erzeugt Warten - wenn man sich sowieso noch ein paar Sekunden am selben Interaktionselement aufhält (z.B. um den Blick nochmal über die Sitzreihen schweifen zu lassen, um sich den ausgewählten Sitzplatz nochmal im Gesamtbild anzusehen) trifft dieser Effekt mMn lang nicht so stark zutage. Gesetzt den Fall man möchte mehr als einen Sitzplatz reservieren kann *optimistic ui* auch beim kleinen Theater einen weiteren Nachteil haben: Ich klicke nacheinander auf vier nebeneinanderliegende Sitzplätze, die schalten sofort auf "ausgewählt" um und ich drücke zuversichtlich auf "buchen" ohne die zwei Sekunden abzuwarten, die der Server benötigt um mir zu sagen, dass der dritte von den vier Plätzen eben schon gebucht wurde. Also werde ich (falls das System sich richtig verhält) eine Fehlermeldung bekommen und nochmal zur Auswahl von Plätzen aufgefordert werden. Zu dem Zeitpunkt hab ich aber dann schon (wie CK das ansprach) das Vertrauen ins System verloren, aber dadurch, dass es gar kein Feedback über ein letztliches Okay des Servers gibt, hab ich auch gar keine letztendliche Kontrolle. Das fühlt sich nicht cool an. Um das mit Twitter zu vergleichen: Da geht der Counter erst hoch, wenn der Server mein Like akzeptiert, das Herz wird sofort bei Klick rot. Ich habe also, wenn es mir nicht wichtig ist, den Vorteil von *optimistic ui* und werde nicht zum Warten verdonnert - und habe gleichzeitig, wenn ich mich, beispielsweise aus Skepsis, zum Warten entscheide, auch ein visuelles Feedback über den definitiven Erfolg. Wenn man also optimistic ui hier an den Sitzplätzen machen möchte, dann bietet es sich an, irgendwo noch eine Möglichkeit einzubauen, die ermöglicht, den definitiven Erfolg der Auswahl zu überwachen und gleichzeitig subtil genug ist, um den User nicht zum Warten zu nötigen. --- Konkreter Vorschlag: Bei fetten Ladekringeln je Sitzplatz kann es passieren, dass der User jeden einzelnen Vorreservierungsvorgang abwartet. Das ist nicht sinnvoll. Deshalb würde ich auf jeden Fall auf *optimistic ui* setzen wollen. Allerdings in Form eines Kompromisses, den ich mir konkret so vorstellen könnte: Der angewählte Sitzplatz soll sofort bei Klick auf "ausgewählt" umschalten (also sich *optimistic* verhalten). Vor dem Button "buchen" gibt es einen Info-Satz, der lautet > Sitzplätze, die schon jetzt für Sie vorreserviert sind: **3** <<buchen>> Dabei geht der Counter im Info-Satz erst bei tatsächlicher Bestätigung durch den Server nach oben. Der Client wird nicht eingeschränkt und der optische Änderungsvorgang ist so subtil, dass er nur dann zu einem Warten des users führt, wenn dieser spezifisch darauf achtet / Wert legt. Gleichzeitig werden die x möglichen Wartezeiten kumuliert und der user, dessen visueller Fokus während der Platzwahl eben nicht auf dem Info-Satz liegt, wird nicht dazu angehalten nach jeder Auswahl einzeln zu warten, sondern hält frühestens dann inne, wenn sich sein Fokus auf das "buchen" verschiebt und er auf eine Bestätigung aktiv Wert legt. ~~Ein ähnlicher Effekt würde auch zustande kommen, wenn man statt der Verwendung eines Info-Textes den Buchen-Button zwischen Platzwahl und Bestätigung sperrt (der ja auch nicht im visuellen Fokus ist und die Wartezeiten kumuliert).~~ Davon rate ich aber ab, da gesperrte Buttons auch kein Zeichen einer guten UX sind und mit dem Info-Satz eine sinnvollere Möglichkeit besteht, die die Seite nicht unresponsiv macht. Grüße, RIDER -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller # [Twitter](https://twitter.com/Camping_RIDER) # [Steam](http://steamcommunity.com/id/Camping_RIDER) # [YouTube](https://www.youtube.com/user/RidersFlame) # [Self-Wiki](http://wiki.selfhtml.org/wiki/Benutzer:Camping_RIDER) # [Selfcode](http://community.de.selfhtml.org/fanprojekte/selfcode.htm): sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[

Aloha ;) Ich klinke mich mal an der Stelle ganz random ein, um vielleicht einen weiteren Aspekt in die Abwägung mit einzubringen, der bisher unter den Tisch gefallen ist. Als Vorwort: Ich bin nach der Lektüre vor allem von [diesem Artikel](https://www.smashingmagazine.com/2016/11/true-lies-of-optimistic-user-interfaces/) (ja, derselbe Autor wie der von Gunnar verlinkte Vortrag, aber die Erklärungen sind weit besser als auf den Folien) durchaus von der Sinnhaftigkeit von "optimistic UI" überzeugt. Wie immer nicht als Allheilmittel, aber in seinen Grenzen. > > Der Fall hier mit der Platzreservierung ist anders zu betrachten, da will man kein "optimistic UI". > > Warum nicht? Ganz konkret, bitte. Ich möchte mal von der anderen Seite argumentieren. Dass "optimistic ui" da sinnvoll ist, wo ein User eine Eingabe tätigt, die der Server nur entgegennehmen muss, ist wahrscheinlich unstrittig. Klassisches Beispiel für eine solche Eingabe sind die auch im Artikel mehrfach zitierten Like-Buttons der verschiedenen sozialen Netzwerke. Da kann etwas schiefgehen (zum Beispiel wenn der Client offline ist), aber es ist sehr unwahrscheinlich und handelt sich um den absoluten Fehlerfall. Die Funktion an sich ist so ausgelegt, dass sie selbst keinen Widerspruch erzeugt (Ich kann ein like abgeben wann und wo ich will, eine Plausibilitätsprüfung, die über das übliche wer-bist-du-und-darfst-du-das hinausgeht, findet nicht statt). Die zentrale Frage für mich ist hier, ob diese Voraussetzungen auch im Fall unseres kleinen Theaters gegeben sind - und falls nein ist die Verwendung von optimistic ui vielleicht doch nochmal mehr Überlegung wert als im Fall der Like-Buttons. Punkt 1: Wir haben hier an den Server die Anforderung, eine Vorreservierung vorzunehmen. Wir gehen davon aus, dass auch bei ordnungsgemäßem Funktionieren des Systems ein Fehlschlag auftreten kann - quasi by design dieses Features, da wir ja Kollisionen vermeiden müssen. Mir ist bewusst, dass der Fakt, dass es sich um ein kleines Theater handelt und nicht um Bruce Springsteen, dazu führt, dass dieses Argument in der Bedeutung schrumpft, weil die Größe des Systems nicht viele Kollisionen erwarten lässt. Aber dennoch sollten wir uns klarmachen, dass wir hier über ein im Vergleich zum Like-Button *relativ gesehen* deutlich erhöhtes *failure*-Risiko sprechen. Diesen Aspekt kann man abtun wenn man möchte. Es gibt sicher extremere Beispiele, aber ganz grundsätzlich muss man die Größe des *failure*-Risiko eben in die Abwägung mit einbeziehen. Das mag man mit dem Verweis auf das **kleine** Theater in diesem Fall auch erfüllt haben. Folgender wiegt meiner Meinung nach ein wenig schwerer: Punkt 2: Was der Server hier intern tut, ist, eine *Vorreservierung* vorzunehmen. Bei einem *optimistic ui* wird das nicht unbedingt klar. So kann der user wenn er auf einen Platz klickt, um diesen für sich auszuwählen, nicht unterscheiden, ob jetzt einfach nur der Platz im Formular angewählt wurde, das erst bei Abschicken auf Kollisionen überprüft wird, oder ob tatsächlich sofort eine Überprüfung auf Kollisionen stattfindet. Vielleicht ist das aber - als Designentscheidung - eine Information, die man dem user zukommen lassen möchte, damit er sich eben nicht extrem beeilen muss, weil seine Plätze noch frei sind. Wenn der User wegen *optimistic ui* denkt, dass keine Kollisionsprüfung stattfindet, kann es passieren, dass er in Stress gerät, weil er denkt, sich die guten Plätze, die er eben noch anwählen konnte, jetzt auch sichern zu müssen. Wenn man dem user visuell anzeigt, dass eine Interaktion mit dem Server stattfindet kann er sich daraus zusammenreimen, dass er diese eben angewählten Plätze eher nicht verlieren wird, wenn er das Formular nicht sofort nach Auswahl absendet. Mit *optimistic ui* kann man dem User nicht vermitteln, dass eine temporäre Vorreservierung stattfindet. Das kann durchaus an der Stelle - auch bei einem kleinen Theater - ein Grund sein, auf *optimistic ui* verzichten zu wollen. Ein paar weiter Gedanken: Auch im *optimistic ui* soll eine *failure*-Botschaft spätestens nach 2 Sekunden eintreffen. Das bedeutet im Umkehrschluss, dass im *not so optimistic ui* auch höchstens 2 Sekunden lang der Ladekringel auf dem eben angeklickten Platz zu sehen ist. Dadurch, dass man sich beim Plätze-Aussuchen die gesamte Zeit über auf diese Aufgabe fokussiert fällt das Warten wahrscheinlich weniger ins Gewicht. Aus meiner Warte stellt es sich so dar, dass das Warten auf die Serverantwort vor allem dann eine Belastung darstellt, wenn man sich direkt danach einem anderen Kontext zuwenden möchte - wie beim Like-Button, den man betätigt nachdem man ein Posting gelesen hat und nach dessen Betätigung man sich sofort ohne weiteres Ausharren dem nächsten Posting zuwenden möchte. Da stört ein Ladekringel und erzeugt Warten - wenn man sich sowieso noch ein paar Sekunden am selben Interaktionselement aufhält (z.B. um den Blick nochmal über die Sitzreihen schweifen zu lassen, um sich den ausgewählten Sitzplatz nochmal im Gesamtbild anzusehen) trifft dieser Effekt mMn lang nicht so stark zutage. Gesetzt den Fall man möchte mehr als einen Sitzplatz reservieren kann *optimistic ui* auch beim kleinen Theater einen weiteren Nachteil haben: Ich klicke nacheinander auf vier nebeneinanderliegende Sitzplätze, die schalten sofort auf "ausgewählt" um und ich drücke zuversichtlich auf "buchen" ohne die zwei Sekunden abzuwarten, die der Server benötigt um mir zu sagen, dass der dritte von den vier Plätzen eben schon gebucht wurde. Also werde ich (falls das System sich richtig verhält) eine Fehlermeldung bekommen und nochmal zur Auswahl von Plätzen aufgefordert werden. Zu dem Zeitpunkt hab ich aber dann schon (wie CK das ansprach) das Vertrauen ins System verloren, aber dadurch, dass es gar kein Feedback über ein letztliches Okay des Servers gibt, hab ich auch gar keine letztendliche Kontrolle. Das fühlt sich nicht cool an. Um das mit Twitter zu vergleichen: Da geht der Counter erst hoch, wenn der Server mein Like akzeptiert, das Herz wird sofort bei Klick rot. Ich habe also, wenn es mir nicht wichtig ist, den Vorteil von *optimistic ui* und werde nicht zum Warten verdonnert - und habe gleichzeitig, wenn ich mich, beispielsweise aus Skepsis, zum Warten entscheide, auch ein visuelles Feedback über den definitiven Erfolg. Wenn man also optimistic ui hier an den Sitzplätzen machen möchte, dann bietet es sich an, irgendwo noch eine Möglichkeit einzubauen, die ermöglicht, den definitiven Erfolg der Auswahl zu überwachen und gleichzeitig subtil genug ist, um den User nicht zum Warten zu nötigen. --- Konkreter Vorschlag: Bei fetten Ladekringeln je Sitzplatz kann es passieren, dass der User jeden einzelnen Vorreservierungsvorgang abwartet. Das ist nicht sinnvoll. Deshalb würde ich auf jeden Fall auf *optimistic ui* setzen wollen. Allerdings in Form eines Kompromisses, den ich mir konkret so vorstellen könnte: Der angewählte Sitzplatz soll sofort bei Klick auf "ausgewählt" umschalten (also sich *optimistic* verhalten). Vor dem Button "buchen" gibt es einen Info-Satz, der lautet > Sitzplätze, die schon jetzt für sie vorreserviert sind: **3** <<buchen>> Dabei geht der Counter im Info-Satz erst bei tatsächlicher Bestätigung durch den Server nach oben. Der Client wird nicht eingeschränkt und der optische Änderungsvorgang ist so subtil, dass er nur dann zu einem Warten des users führt, wenn dieser spezifisch darauf achtet / Wert legt. Gleichzeitig werden die x möglichen Wartezeiten kumuliert und der user, dessen visueller Fokus während der Platzwahl eben nicht auf dem Info-Satz liegt, wird nicht dazu angehalten nach jeder Auswahl einzeln zu warten, sondern hält frühestens dann inne, wenn sich sein Fokus auf das "buchen" verschiebt und er auf eine Bestätigung aktiv Wert legt. ~~Ein ähnlicher Effekt würde auch zustande kommen, wenn man statt der Verwendung eines Info-Textes den Buchen-Button zwischen Platzwahl und Bestätigung sperrt (der ja auch nicht im visuellen Fokus ist und die Wartezeiten kumuliert).~~ Davon rate ich aber ab, da gesperrte Buttons auch kein Zeichen einer guten UX sind und mit dem Info-Satz eine sinnvollere Möglichkeit besteht, die die Seite nicht unresponsiv macht. Grüße, RIDER -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller # [Twitter](https://twitter.com/Camping_RIDER) # [Steam](http://steamcommunity.com/id/Camping_RIDER) # [YouTube](https://www.youtube.com/user/RidersFlame) # [Self-Wiki](http://wiki.selfhtml.org/wiki/Benutzer:Camping_RIDER) # [Selfcode](http://community.de.selfhtml.org/fanprojekte/selfcode.htm): sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[