Wenn man ein Button ist, hat man nur eine Aufgabe

• Selbst ein so einfacher Button wie zum Drehen von Fotos kann die User Experience stark verändern – je nachdem, wie er mit schnellen wiederholten Eingaben umgeht
• Das iPhone merkt sich mehrfach gedrückte Eingaben für eine 90-Grad-Drehung und führt die nächste Drehung aus, sobald die Animation beendet ist
• Nothing Phone/Android bestätigen den Tap zwar mit Haptik und Ton, ignorieren aber nachfolgende Taps, die während der Dreh-Animation eingehen
• Wenn mehrere Dokumentfotos gedreht werden müssen, wird auch von einer beiläufigen Foto-Editing-UI eine schnellere und besser vorhersehbare Bedienung erwartet
• Buttons sollten Nutzer nicht zwingen, bis zum Ende einer Animation zu warten, sondern Eingaben per Tap-Buffering oder durch Abbrechen bzw. Beschleunigen der Animation annehmen

---

Wie der Button zum Drehen von Fotos wiederholte Eingaben verarbeitet

• Ein Button zum Drehen von Fotos ist ein standardmäßiges Steuerelement: Einmal gedrückt, dreht er ein Bild normalerweise um 90 Grad gegen den Uhrzeigersinn; bei erneutem Drücken wiederholt er dieselbe Aktion
• Die Dreh-Animation zeigt, wie sich die Ausrichtung des Fotos ändert, und hilft Nutzern, die Orientierung nicht zu verlieren
• Drückt man schnell 8-mal auf die 90-Grad-Drehung, sollte sich das Bild – wie Ingenieure sagen würden – als „no op“ zweimal im Kreis drehen und wieder in der ursprünglichen Ausrichtung landen
• Auf dem iPhone entspricht das tatsächlich dieser Erwartung
  • Schnelle Tap-Eingaben werden gespeichert
  • Wenn die vorherige Drehung beendet ist, wird die nächste wartende Drehung ausgeführt
• Auf dem Nothing Phone/Android ergibt sich ein anderes Verhalten
  • Der Button bestätigt den Tap per Haptik und Ton
  • Ist die vorherige Dreh-Animation noch nicht beendet, wird der neue Tap ignoriert

Auch beiläufige UIs brauchen bei wiederholten Aufgaben eine robustere Eingabeverarbeitung

• Situative Behinderung ist das Konzept, dass Behinderung nicht nur einige Menschen betrifft, sondern dass jeder in bestimmten Situationen effektiv behindert sein kann
• Fotografieren ist meist eher eine beiläufige Nutzung, doch Smartphone-Kameras können die Fotoausrichtung verwechseln, wenn man nach unten gerichtet fotografiert
• Wenn man mehrere querformatige Dokumentfotos aufgenommen hat und jedes davon drehen muss, kann es passieren, dass man Dutzende Fotos einzeln drehen muss
• In einer solchen Situation ist es angenehmer und weniger umständlich, wenn der Button auch dann vorhersehbar funktioniert, wenn man ihn dreimal im gewünschten Tempo drückt
• Betrachtet man ausreichend lange Zeiträume oder große Nutzergruppen, kommen auch beiläufige Interfaces an Momente, in denen sie ernster genommen werden müssen
  • Diese Art von „situativer Power-User-Eigenschaft“ zeigt sich auch bei Beispielen wie der Foto-Editing-Funktion von Smartphones oder GarageBand
• Die Lösung muss nicht zwingend Tap-Buffering sein
  • Bei einem unterbrechenden Tap könnte die Animation auch gestoppt oder beschleunigt werden
  • Entscheidend ist, Nutzer nicht dazu zu zwingen, auf das Ende der Animation zu warten

[GN⁺]

Meinungen auf Hacker News

• Was ist mit Fällen, in denen Nutzer versehentlich zu oft klicken oder glauben, der erste Klick sei nicht registriert worden?
  Ich erinnere mich noch an eine Keynote, bei der Steve Jobs demonstrierte, wie viel schneller das Anzeigen von PDF-Dokumenten im neuen macOS geworden war. Die Engineers hatten einen Button gebaut, der ein PDF auf dem Bildschirm scrollte, aber Jobs drückte ihn versehentlich mehr als einmal und sagte sinngemäß: „Scrollt es jetzt zweimal bis zum Ende?“ — und tatsächlich wurde die Aktion gepuffert. Am Ende musste er wieder nach oben gehen und warten, bis der zweite Scrollvorgang abgeschlossen war.
  Jobs fing es damit auf, dass er sagte, es sei selbst dann schneller als PDFs im vorherigen OS, wenn man die Zeit für das zweite Durchblättern des Dokuments mitzähle.

  • Debouncing gibt es aus gutem Grund. Manchmal soll ein Button bei zweimaligem Drücken zweimal ausgeführt werden, manchmal eben nicht. Zu unterscheiden, welche Variante in welcher Situation besser ist, ist nicht trivial.
    Zumindest sollte man darüber nachdenken, welche Behandlung in welcher Situation richtig ist. In einer UI ist bei manchen Buttons die eine Seite offensichtlich, bei anderen Buttons klar die andere; einige sind aber uneindeutig, und wenn sich beide Verhaltensweisen verteidigen lassen, bekommt man am Ende eine inkonsistente UI.
    Eine gute Lösung kenne ich nicht.

  • Laut Artikel:

    The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap if a previous rotation is still animating.

    Genau das ist das Problem. Die Anzahl der Male, bei denen die App dem Nutzer signalisiert, dass die Button-Eingabe registriert wurde, sollte der Anzahl der tatsächlich ausgeführten Aktionen entsprechen. Debouncing ist eine gute Praxis, aber wenn man es einsetzt, darf man für debouncte Taps kein Feedback geben.

  • Bei der Stelle „Was ist mit Fällen, in denen Nutzer versehentlich zu oft klicken oder glauben, der erste Klick sei nicht registriert worden?“ war ich ziemlich verwirrt, weil sie für mich sofort nach Barrierefreiheit klang. Mir fiel direkt jemand mit zitternden Händen ein, der nur einmal drücken will, aber zweimal drückt.
    Und es gibt auch Leute, die jeden Button doppelklicken. Um solche Fälle abzufangen, ist es sehr üblich, den Submit-Button in onclick zu deaktivieren.

  • Ich bin nicht mehr wie früher ein Apple-/Mac-/Jobs-Fanboy, aber ich vermisse Apple-Präsentationen, die sich so anfühlten, als würden sie von jemandem gehalten, der einem etwas Cooles zeigen will.
    Neuere Apple-Präsentationen wirken so steif und unmenschlich und so, als würden sie von Anzugträgern betrieben, dass ich sie nicht einmal bis zum Ende ansehen konnte. Alle wirken wie Roboter, die Emotion und Menschlichkeit verstecken, aus Angst, gefeuert zu werden, wenn sie vom heiligen Skript abweichen.
    Vielleicht ist das off-topic, aber es erinnert daran, wie unterhaltsam selbst Jobs’ etwas chaotische improvisierte Präsentationen waren.

  • Für ein „Und was ist mit diesem Fall?“ ist diese Situation eindeutig nicht geeignet. Aus zwei Gründen:

    1. „The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap […]“
    2. Es gibt einen guten Grund, diesen Button dreimal hintereinander zu drücken.

• Ich möchte das anderswo vorgebrachte Argument „Was ist mit Debouncing?“ unterstützen; der Autor sollte es nicht einfach abtun.
  Gleichzeitig mag ich das you had one job-Meme nicht und möchte mich gegen dessen gedankenlosen Einsatz aussprechen. Meistens ist dieses Meme falsch, und bei Buttons ist es im Allgemeinen genauso. In einem üblichen User Interface hat ein bestimmter Button gleichzeitig mehrere der folgenden Aufgaben:

  • vermitteln, welche Aktion beim Drücken des Buttons passiert
  • manchmal den aktuellen Zustand eines Teils des Systems vermitteln, etwa wenn ein Button zum Ein- und Ausschalten eines Modus visuell zeigt, welcher Modus gerade aktiv ist
  • beim Klick die beabsichtigte Aktion ausführen
  • manchmal vermitteln, dass ein Befehl entgegengenommen wurde und gerade ausgeführt wird, etwa indem der Button während einer Rotationsanimation deaktiviert wird, um Verwirrung zu vermeiden, wie im Ausgangsbeispiel
  • Hinter dem you had one job-Meme könnte fast immer stehen: „weil ich mich geweigert habe, die tatsächliche Komplexität deiner Arbeit zu berücksichtigen“.
  • Guter Punkt, besonders weil er hervorhebt, dass Menschen unterschiedliche Erwartungen daran haben, was ein Button ist und was nicht. Die einzelnen Punkte beschreiben einen Button mit Label, einen Button mit Toggle, einen echten Button und eine Fortschrittsanzeige. Je nach Nutzer kann all das ein „Button“ sein.
  • Wenn es um „Was ist mit Debouncing?“ geht: Könnte man die Button-Funktion nicht beim Loslassen der Berührung statt beim Beginn der Berührung ausführen?

• Der Ausdruck „eine Aufgabe“ passt bei Buttons nicht besonders gut. Ein Button muss nämlich mehr tun, als nur anklickbar zu sein.
  Es gibt Feedback beim Klicken, Feedback beim Mouseover, Ladezustand, deaktivierten Zustand und Kombinationen aus all dem. Das kann sich sehr frustrierend anfühlen. Wenn man zum Beispiel einen Button drückt, der mit einem Backend-Service verbunden ist, und es keinerlei visuelles Feedback gibt, weiß man nicht, ob der Button gedrückt wurde. Gibt es auch keinen Ladezustand, weiß man nicht, ob im Hintergrund etwas verarbeitet wird, und drückt ihn deshalb immer wieder.

• Der Autor möchte, dass bei drei Klicks mit beliebiger Geschwindigkeit immer dieselbe Funktion ausgeführt wird. Er will Fotos schnell durchgehen und jedes davon vorhersagbar drehen können; das ist legitim.

  And it would be so much more predictable and pleasant if you could just tap the button three times at any pace you wanted without thinking, without paying attention, without getting your UI blocked by an animation that no longer helps you.

Der Autor führt Barrierefreiheit als Begründung an.
Allerdings kann man sich auch das genau gegenteilige Argument vorstellen. Zum Beispiel könnten Menschen mit motorischen Einschränkungen oder Parkinson ein Verhalten bevorzugen, bei dem überzählige Klicks ignoriert werden, wenn die Absicht bereits feststeht.
So etwas richtig umzusetzen ist knifflig.

• iOS hat eine Bedienungshilfe namens Ignore Repeats, die als systemweite Einstellung wie der bessere Ansatz wirkt. Wer eine solche Korrektur braucht, bekommt sie dann auch etwa bei der Bildschirmtastatur, und alle anderen müssen nicht langsamer tippen.

• Ich glaube nicht, dass jedes UI-Widget solche Dinge berücksichtigen muss.
  Das ließe sich vermutlich als geräteweite Einstellung behandeln, zum Beispiel indem wiederholte Taps ignoriert werden, wenn sie innerhalb von 100 ms und in einem Abstand von höchstens 50 px zueinander erfolgen.

• Stimme völlig zu. Man muss gar nicht bis zu Parkinson gehen: Wenn man Menschen beobachtet, die nicht uralt, aber älter sind und Smartphones und Touchscreens nutzen, sieht man oft, wie schwer es ist, kleine Buttons an der richtigen Stelle zu treffen und das Gefühl zu bekommen: „Ich habe gedrückt.“
  Aus Sicht der Barrierefreiheit passt daher das Verhalten des Nothing Phone vermutlich deutlich besser. Solche Nutzer klicken nicht sechsmal und zählen dabei mit, um ein Bild an eine bestimmte Position zu bringen. Außerdem ergibt es wenig Sinn, vorsorglich achtmal zu klicken, um exakt zur aktuellen Position zurückzukehren.
  Die Denkweise in diesem Fall ist eher: „Klicken, warten, prüfen, ob es die gewünschte Position ist, dann erneut klicken.“ Ein empfindlicher Button, der Eingaben puffert, kann dagegen leicht zu Overshooting führen: zu weit gehen und dann wieder zu weit zurück. Ähnlich wie wenn man in einer Liste zu einer gewünschten Stelle scrollen will und immer wieder daran vorbeischießt.
  Die iPhone-Variante eignet sich eher für junge Menschen oder Technikbegeisterte, die ohne Warten schnell arbeiten wollen. So wie man auf einer Computertastatur wegen der Verzögerung schon mehrere Buchstaben vorab eingeben kann, bevor der erste Buchstabe auf dem Bildschirm erscheint.

• Ich hatte früher einmal ein Gerät mit physischen Tasten: Beim Drücken piepte es, und eine Taste fügte der Zeit 30 Sekunden hinzu. Manchmal piepte es aber, ohne dass 30 Sekunden hinzugefügt wurden, und manchmal wurden ohne Ton 30 Sekunden hinzugefügt. Deshalb musste ich immer angestrengt auf das dunkle Display schauen, um zu prüfen, ob die Aktion tatsächlich passiert war.
  Ich hielt das für ein besonders schlechtes Design, habe aber seitdem unzählige reine Software-Buttons gesehen, die genau dieses kaputte Verhalten nachbilden. Ob sich die Button-Farbe auf dem Bildschirm ändert und ob die angeforderte Aktion tatsächlich ausgeführt wird, hängt nur lose zusammen. Warum ist das so? Wie muss man das überhaupt implementiert haben?

  • Das nennt man das Problem, zwei Dinge zu tun.
    Man schreibt imperativen Code und gibt zwei Befehle, die beide unabhängig voneinander fehlschlagen können.
    Es gibt viele Möglichkeiten, so zu tun, als hätte man das „behandelt“.
    Zunächst werden alle Tests bestehen, also können die meisten Entwickler sofort aufhören, darüber nachzudenken.
    Man könnte glauben, es reiche, Exceptions abzufangen und nur zu loggen, aber dadurch wird es nicht behoben.
    Man kann es eine Weile in Produktion laufen lassen und schauen, ob Probleme auftreten. Wenn irgendwann doch eines auftritt, wird der Entwickler es erneut versuchen, und beim zweiten Mal funktioniert es vermutlich, also kann er wieder aufhören nachzudenken.
    Vor ein paar Tagen gab es auch eine große Diskussion über das Outbox Pattern: Man teilt die erste Aufgabe in zwei Hälften und behandelt sie atomar, während man die zweite Aufgabe einem Leser überlässt.
    Ich glaube, der Grund, warum dieses Problem in der Praxis immer wieder auftaucht, ist, dass Entwickler sich in einer Quantenüberlagerung aus „So etwas passiert nicht“, „Ich habe es behoben“ und „Das lässt sich nicht beheben“ befinden.
  • Das ist wirklich häufig, weil die meisten UI-Frameworks zwei Design-Eigenschaften gemeinsam haben:
    Der Code, der die Button-Farbe ändert, ist internes Verhalten der „Button“-Komponente und muss nicht für jeden Button separat implementiert werden. Das bedeutet aber, dass er bis zu einem gewissen Grad vom Code getrennt ist, der die eigentliche Aktion ausführt. Wenn es im on click-Handler als letzte Prüfung so etwas gibt wie im Original, also „Bild nicht drehen, wenn gerade eine Rotationsanimation läuft“, gibt es oft keine Möglichkeit, dem Button mitzuteilen, dass er die Farbänderung zurücknehmen soll. Umgekehrt kann der on click-Handler ausgeführt werden, selbst wenn die Farbänderungsanimation nicht korrekt abgespielt wird.
    Buttons ändern normalerweise ihre Farbe, wenn die Maustaste gedrückt wird, führen die Aktion aber erst aus, wenn die Maustaste losgelassen wird. Das gibt absichtlich die Möglichkeit, gedrückt zu halten, aus dem Button herauszuziehen und im letzten Moment abzubrechen; auf Mobilgeräten kann die Interaktion auch als Scrollen statt als Klick neu interpretiert werden. In anderen Fällen erhöht es einfach nur die Zahl der Gelegenheiten, bei denen die Farbe bereits geändert wurde, die Aktion aber verhindert wird.
  • In Aufzügen sehe ich das ziemlich regelmäßig. Wenn man den Button nur sehr kurz drückt, leuchtet er während des Drückens auf, aber tatsächlich wird die Tasteneingabe nicht registriert.
  • Die Farbänderung eines Buttons zeigt an, dass das Drücken erfolgreich war. Wenn das nicht sofort passiert, sind die meisten Menschen darauf konditioniert, es erneut zu versuchen. Das ist besonders wichtig für Menschen mit schwacher motorischer Kontrolle.
    Das ist völlig unabhängig davon, ob dieser Druck im aktuellen Softwarezustand eine nützliche Eingabe ist. Gut geschriebene Software hätte wissen müssen, dass sie keine Eingabe annehmen kann, und den Button deaktiviert. Selbst halbwegs gut gemachte Software sollte nahezu sofortiges Feedback geben, dass eine Aktion verarbeitet wird oder abgebrochen wurde.
  • Vermutlich liegt es an mangelnden Tests und an der Annahme, dass Aktionsfehler so selten sind, dass sie keine Beachtung verdienen. Aber solche Muster machen es schwer, einer Oberfläche zu vertrauen und sie effizient zu nutzen.

• Menschen vergessen oft, dass Animationen rein unterstützend sind und nicht selbst der Zweck.
  Animationen existieren, um Ladezeiten zu kaschieren und Übergänge von einem Zustand in einen anderen weich zu gestalten. Dafür verwendet man sie.
  Dieses Wissen ist irgendwann verloren gegangen, und jetzt gibt es Code, der warten muss, bis eine Animation beendet ist.
  Ein weiteres Beispiel für erstaunlichen Cargo-Kult.

  • Ich würde die Erklärung „Ladezeiten kaschieren und den Übergang von einem Zustand in einen anderen weich gestalten“ noch erweitern. Richtig eingesetzt zeigen sie, dass eine Zustandsänderung direkt durch eine bestimmte Handlung des Nutzers ausgelöst wurde, und deuten auch an, wie man sie rückgängig machen oder ändern kann.
    Mit dem Wort „kaschieren“ bin ich eigentlich nicht einverstanden. Dass etwas sofort erscheint, ohne einen Hinweis darauf, warum es erschienen ist, ist auf Touchscreens eindeutig ein Anti-Pattern.
  • Animationen dienen nicht ausschließlich diesem Zweck. Sie tragen auch kreativ zum Gefühl bei, das eine App bei der Nutzung vermittelt.
  • Apple wusste das früher. Nachdem ein Element verschwunden war, gab es Animationen, aber Animationen vor dem Anzeigen eines Elements wurden vermieden.
    Das alte Apple verstand, dass Design mehr ist, als etwas hübsch zu machen. Beim heutigen glasigen Apple zählt nur noch, wie es in Demos aussieht.
  • Animationen fühlen sich fast immer unnötig an. Ich schalte sie überall aus, wo eine App oder ein System es erlaubt.
  • Unter Android habe ich alle Animationen deaktiviert, und es fühlt sich viel besser an. Besonders hasse ich diese Overscroll-Animation, bei der sich der ganze Bildschirm dehnt, wenn man zu weit scrollen will.

• Als ich den ersten Vergleich sah, dachte ich ehrlich gesagt, dass das Problem beim iPhone-Beispiel liegt. Jedes Mal, wenn man auf den Drehen-Button tippt, verschwinden der Button und der Slider unter dem Bild und blenden sich dann wieder ein; das ist ein Verhalten, das ich in mehreren iOS-Apps gesehen habe und das endlos nervt. Besonders die Screenshot-App ist für mich persönlich ein großes Ärgernis.
  Wenn es sich um ein UX-Element handelt, das man sowohl vor als auch nach einer Interaktion bedienen kann, sollte es während der Transformation oder Verarbeitung durchgehend sichtbar bleiben. Welchen UX-Vorteil hat es, diese Buttons auf dem iPhone während der Drehung auszublenden? Es sieht nicht einmal besser aus. Natürlich hat Apples Software in letzter Zeit echte UX-Verbesserungen zugunsten des äußeren Erscheinungsbilds geopfert.
  Allerdings stimme ich der Aussage des Autors zu, dass solche Taps unabhängig von der Animation verarbeitet werden sollten.

  • Es wäre schön, wenn es für Software-Apps so etwas wie Tape-out-Regeln gäbe, wie bei Computerchips. Beim Chipdesign prüft ein Programm den Entwurf und vergleicht ihn mit einem 300-seitigen Regelwerk wie „Leitungen aus Metall X und Metall Y dürfen nicht innerhalb von Abstand Z liegen“.
    Für UX könnte man etwas Ähnliches schaffen: eine Sammlung von Design-Pattern-Beschränkungen, die warnen, wenn man mit bekannten UX-Mängeln veröffentlichen will.

• Das erinnert mich daran, wie ich früher BabyButton implementiert habe, das für die Nutzung durch ein Baby gedacht war. Statt des üblichen Klickverhaltens habe ich das touchdown-Event verwendet; so konnte das Kind sofort sehen, dass etwas passiert, und es war kein Problem, wenn es den Button zu lange gedrückt hielt oder den Finger gedrückt bewegte.
  Ob man Systeme für diese Altersgruppe bauen sollte, ist ein ganz anderes Thema, aber ich empfand es als gute Herausforderung, etwas passend zu den Bedürfnissen der Nutzer zu entwerfen.

  • Interessant, wie sehr wir uns daran gewöhnt haben, dass GUI-Buttons erst beim Loslassen der Maustaste auslösen und bestimmte Verhaltensweisen haben, etwa wenn man den Buttonbereich gedrückt verlässt und wieder betritt.
    Reale Buttons tun in über 99 % der Fälle sofort etwas, wenn man sie drückt. Ein Button, der sich in einer GUI so verhält, würde sich aber seltsam anfühlen.

• Der eigentliche Artikel, der dem Kern dessen, was der Autor sagen will, näherkommt, ist dieser hier: https://aresluna.org/show-your-hands-honor/

• Kommt es vor, dass beim Drücken der Ein-/Aus-Taste des iPhone-Bildschirms während eines Telefonats manchmal das Gespräch beendet wird und manchmal einfach nur der Bildschirm ausgeht?
  Ich habe das Muster immer noch nicht verstanden, aber bevor ich das iPhone in die Tasche stecke, drücke ich manchmal diesen Button und habe dabei gelegentlich versehentlich aufgelegt.

  • Im Lautsprecher-/Freisprechmodus geht nur der Bildschirm aus. Wenn man es ans Ohr hält, geht der Bildschirm automatisch aus, daher scheint man anzunehmen, dass man die Sperrtaste nicht drücken wird. Das Problem ist, dass der Bildschirm wegen eines Bugs manchmal eingeschaltet bleibt oder dass man es in einem ruhigen Raum auch wie im Freisprechmodus benutzt.

[GN⁺]

Kommentare auf Lobste.rs

• Es ist zwar nur leichter Sarkasmus, aber wenn es um gute UI/UX geht, ist ein Video-Embed ohne Bedienelemente und ohne Anzeige das Schlimmste.
  Viele Leute haben Autoplay standardmäßig deaktiviert, und ich saß eine ganze Weile vor zwei fast identischen Bildern und dachte: „Und was ist jetzt anders?“

  • „Da war ein Video?“ dachte ich — ich habe es wohl auch übersehen.
  • Ich verstehe nicht, warum das „das Schlimmste“ sein soll. Hast du einfach nicht ein Stück nach unten gescrollt, um die Problembeschreibung zu lesen, und stattdessen nur weiter „Na und?“ gedacht?
  • Bei diesem Thema muss man GitHub zugutehalten, dass es bei animierten GIFs Wiedergabesteuerungen anzeigt. Das sieht man anderswo fast nie.
  • Könnte auch ein Browser-Unterschied sein. In Vivaldi auf Android sah ich einen großen Play-Button und eine Fortschrittsleiste.

• Ich stimme „Lass Nutzer niemals warten, bis eine Animation fertig ist“ voll und ganz zu.
  In einer App sollten Nutzerbefehle immer Vorrang vor hübscher Optik haben.

• Ich denke, dieses Prinzip gilt auch für Spiele. Manche Spiele haben nach dem Öffnen eines Menüs eine sehr kurze Verzögerung, bis Eingaben registriert werden.
  Das ist die Frage, ob in einem Spiel mit aufwendiger Menüanimation nach schnellem Drücken von Pause und Pfeil nach unten nach dem Erscheinen des Menüs der zweite Eintrag ausgewählt sein sollte.
  Input Buffering ist in Spielen ein heikles Thema, aber bei der Menübedienung fühlt es sich meistens selten schlecht an.

• Das Video hat die Information nicht besonders gut vermittelt. Man musste konzentriert hinschauen, um den Moment zu bemerken, in dem die Taste mehrfach hintereinander gedrückt wird.
  Zur eigentlichen Sache: Es ist auch unklar, ob das Android-Phone wirklich etwas falsch macht. Ich verstehe die Frustration, schnell achtmal zu drücken, um das gewünschte Ergebnis zu bekommen, aber es erinnert mich an die Erkennung versehentlicher Doppelklicks in Desktop-Betriebssystemen.
  Letztlich wirkt es eher wie ein Unterschied zwischen der Usability, die der Hersteller im Kopf hat, und dem Komfort, den Nutzer empfinden. Wenn man es genau nimmt, finde ich es sogar ablenkender, dass das iPhone den „Done“-Button auch während der Animation anzeigt.

• Schwer zu sagen, dass Android völlig falsch liegt. Wegen träge reagierender UIs habe ich schon Aktionen versehentlich zweimal ausgeführt.
  Die beste Lösung könnte sein, den Button zu deaktivieren, bis die Animation beendet ist.

  • Dann entsteht genau das Problem, das der Artikel zeigt. Eine 90-Grad-Drehung gegen den Uhrzeigersinn ohne auf den Bildschirm zu schauen wird nahezu unmöglich.
    „Dreimal klicken“ funktioniert nicht, und zusätzliche Klicks während der Animation werden ignoriert. Klicken, auf den Bildschirm schauen und warten, bis die Animation fertig ist, dann erneut klicken und wieder warten — das ist langsam und verlangt viel Aufmerksamkeit vom Nutzer.
    Eine bessere Lösung scheint zu sein, in der UI sofortiges Feedback zu geben. Man könnte den Button-Zustand, der zeigt, dass der Klick verarbeitet wurde, sofort rendern oder den Bildschirm vor der langsamen Gesamtanimation vorübergehend schnell neu zeichnen, um den aktuellen Fortschritt zu zeigen.

• Ich stimme dem ganzen Artikel stark zu. Ich würde sagen, hier hat Animation den hippokratischen Eid gebrochen.
  Das erste Prinzip von Animation sollte „Zuerst keinen Schaden anrichten“ sein, also „Zuerst keine Nutzereingaben behindern“.

• Hattest du schon einmal einen Rotary Encoder, der nicht hinterherkommt? Der Lautstärkeregler meines Kopfhörerverstärkers tut gar nichts, wenn man ihn zu schnell dreht.
  Wenn ich nur für einen Tag Präsident wäre …

• Jedes Mal, wenn ich so etwas sehe, überlege ich, wie sich mein GUI-Toolkit verhalten würde. Mein Toolkit behandelt zwei schnelle Klicks als Doppelklick, ähnlich wie ein von der Windows-Plattform übernommenes Verhalten, und das macht mich manchmal wahnsinnig.
  Doppelklicks selbst sind eine gängige Konvention und haben einen Wert, der sich von einem Klick unterscheidet. Idealerweise macht man Klick-Events idempotent, sodass es kein Problem ist, wenn sie zweimal ausgelöst werden. Wenn ein Klick zum Beispiel ein Element auswählt und ein Doppelklick die Standardaktion ausführt, ist es harmlos, dasselbe Element zweimal auszuwählen. In der Realität ist das aber nicht immer so.
  Das Problem ist: Wenn man einen Button sehr schnell anklickt, wird der Button möglicherweise nur einmal ausgelöst, und der nächste Klick geht als Doppelklick-Event durch und tut gar nichts. Dadurch entsteht das Verhalten, dass bei schnellem Drücken die Hälfte der Klicks ignoriert wird.
  Wegen dieses Problems habe ich ein Boolean namens triggersOnMultiClick eingeführt; wenn es auf true gesetzt ist, werden Trigger-Events auch bei schnellen Mehrfachklicks wie Doppelklicks ausgegeben. Aus Gründen der Abwärtskompatibilität habe ich den Standardwert allerdings auf false gesetzt. Da es nun Zeit für ein neues Major Release ist und das Argument des Artikels stichhaltig wirkt, will ich den Standardwert jetzt auf true ändern.
  Man könnte etwa festhalten: „Hinzugefügt am 2. Juli 2021, Standardwert false. Am 5. Juli 2026 (v13.0) wurde der Standardwert auf true geändert, sodass alle Klicks auf Buttons standardmäßig Trigger auslösen. Wer das alte Verhalten möchte, kann das Doppelklick-Event überschreiben oder nach dem Aufruf des Super-Konstruktors triggersOnMultiClick = false setzen.“
  Auch bei der Implementierung von Animationen kann zufällig ein ähnliches Verhalten entstehen. Wenn man in einem Objekt eine Variable für die Animationsposition hält und sie beim Klick setzt, hat man bei zwei Klicks grob zwei Optionen: die restliche Animation überspringen und direkt in den nächsten internen Zustand wechseln, oder aus Gründen der visuellen Geschmeidigkeit Events ignorieren, etwa mit if(animationCounter) return;. Der Android-Entwickler aus dem Artikel scheint Letzteres gewählt zu haben.
  Apple nutzt vermutlich einen dritten Ansatz, nämlich eine Queue für ausstehende Animationen, in die Events eingereiht werden. Mich interessiert, ob sich der interne Zustand beim Einreihen in die Queue ändert, beim Abschluss oder ob tatsächlich das Bild animiert gedreht wird. Wenn man die Animation mittendrin abbricht und speichert, könnte dann ein um 45 Grad gedrehtes Bild herauskommen? Wenn ich es machen würde, würde ich EXIF atomar um 90 Grad aktualisieren und die Übergangsanimation separat laufen lassen.
  Zwischen einfacher Implementierung, visueller Treue und UI-Verhalten kann es mehrere vernünftige Entscheidungen geben. Persönlich gefällt mir auch die Variante, bei der der zweite Tastendruck nicht auf die Animation wartet, sondern sofort in den neuen Zustand springt. Eine Animations-Queue würde ich wohl nicht bauen.
  Es ist lustig, dass ich den Code ungefähr zur gleichen Zeit ändere. Die letzte Änderung war auch am 2. Juli, und diesmal ist es zufällig der 5. Juli. Ich mag es, solche Historie direkt in Dokumentationskommentare zu schreiben. Später kann man sie beim Ändern aus Nostalgie noch einmal lesen.
  Apple stellt wahrscheinlich eine Standard-Animations-Queue bereit, aber der Zeitpunkt der Zustandsänderung bleibt trotzdem ein separates Problem. Im Web würde ich den Zustand atomar aktualisieren und eine rein visuelle Animation wie eine CSS-transform-Transition separat halten. Das dürfte einfach und effizient zu implementieren sein, weil man auch Layout-Neuberechnungen vermeiden kann. Ob es springt oder gequeued wird, wenn man Klassennamen schneller ändert als die Animation läuft, möchte ich später einmal ausprobieren.

• Vielleicht liegt es am Alter, aber ich habe mich schon ein paarmal über solches Verhalten geärgert, wenn ich versehentlich doppelt getippt habe.
  Einen Button an derselben Position oder einen Doppeltipp als Bestätigung zu verwenden, ist furchtbar. Wenn wirklich eine Bestätigung nötig ist, sollte man es nicht leicht machen, sie versehentlich auszulösen.
  In diesem Beispiel scheint es allerdings eine gute Idee zu sein, schnelle Eingaben hintereinander anzunehmen. In anderen Fällen kann das anders sein. Bei manchen physischen Buttons wird absichtlich verhindert, dass man sie zweimal drückt, bis etwas „fertig“ ist; auch wenn das nicht immer bewusst gestaltet ist, kann es manchmal die richtige Entscheidung sein.
  Viele Menschen müssen ruckelige oder defekte Geräte verwenden, und bei gesundheitlichen Problemen wie Zittern der Hände oder Finger kann es Vorteile haben, Eingaben zu begrenzen.
  Dieses Beispiel wirkt wie ein Fall, in dem beide Seiten vertretbar sind. Es gibt Beispiele, die noch frustrierender sind, weil man warten muss, und es gibt definitiv auch Beispiele, bei denen man sich Eingabebegrenzung wünschen würde, sei es wegen einer Animation oder anderer Bedingungen.

• Es ist wirklich endlos nervig, wenn Suchergebnisse im mobilen Browser unter dem Finger aktualisiert werden und die Option, die ich antippen wollte, an eine andere Stelle geschoben wird.
  Ich habe mich zwar darauf trainiert, länger zu warten, aber es ergibt keinen Sinn, dass UI-Interaktionen empfindlich auf asynchrone Hintergrundaufgaben reagieren müssen, deren Abschlusszeit vom Empfangszustand abhängt.