Toast-Benachrichtigungen sind schlechte UX

• Die zentrale Schwäche von Toast-Benachrichtigungen liegt darin, dass der aktuelle Aufmerksamkeitspunkt der Nutzer vom Ort des Feedbacks getrennt ist, wodurch sich das Ergebnis der gerade ausgeführten Aktion nur schwer direkt zuordnen lässt
• Beim Speicher-Flow von YouTube wandert der Blick vom Save-Button rechts über ein zentrales Modal zu einem Toast unten links; dadurch wird die Interaktion unterbrochen, und während der Verzögerung gibt es auch keine Ladeanzeige
• Nach dem Ändern einer Checkbox muss man warten, bis der vorherige Toast verschwunden ist, um die neueste Bestätigung zu sehen; der Undo-Button im Toast ist zudem unnötig, wenn man einfach die Checkbox erneut anklicken kann
• Besser ist es, Feedback direkt am Ort der Aktion zu platzieren: Playlists können unterhalb des Buttons angezeigt werden, und während einer Checkbox-Änderung kann eine Ladeanzeige den Fortschritt zeigen
• Schlimmer als Toasts ist gar kein Feedback; wenn keine Zeit bleibt, besseres Feedback zu entwerfen oder umzusetzen, sind Toasts besser als gar nichts

---

Das Grundproblem von Toasts

• Toast-Benachrichtigungen erscheinen meist weit entfernt von der Stelle, auf die die Aufmerksamkeit der Nutzer gerichtet ist
• Wenn Feedback an einer anderen Stelle erscheint als der Button, der gerade gedrückt wurde, oder der Bereich, der bearbeitet wird, fällt es Nutzern schwer, Aktion und Ergebnis miteinander zu verbinden

Probleme im Speicher-Flow von YouTube

• Im YouTube-Beispiel klickt der Nutzer zunächst auf den Save-Button rechts auf dem Bildschirm und sieht danach nacheinander ein Modal in der Bildschirmmitte und einen Toast unten links
• Dieser Ablauf zwingt den Blick an mehrere Stellen und macht auch das Feedback schwer unmittelbar verständlich
  • Der Toast erscheint verzögert und ohne Ladeanzeige
  • Wenn man im Modal eine Checkbox ein- oder ausschaltet, muss man mehrere Sekunden warten, bis der vorherige Toast verschwunden ist, bevor der aktuelle Bestätigungs-Toast sichtbar wird
  • Der Undo-Button im Toast ist unnötig, weil der Nutzer einfach erneut auf die Checkbox klicken kann

Lösung ohne Toasts

• Schon ein einfaches Redesign kann dasselbe Feedback ohne Toasts abbilden
  • Playlists werden nicht in einem Modal, sondern direkt unter dem Button angezeigt
  • Beim Ein- oder Ausschalten einer Checkbox wird eine Ladeanzeige gezeigt
  • Wenn die Ladeanzeige verschwindet, ist auf natürliche Weise erkennbar, dass die Aktion abgeschlossen ist
• Da das Feedback an der Stelle bleibt, an der der Nutzer interagiert hat, ist kein separater Toast nötig

Gmail und Kopier-Feedback als Beispiele

• Wenn man in Gmail eine E-Mail archiviert, erscheint ein Bestätigungs-Toast
  • Dass die E-Mail aus der Liste verschwindet, signalisiert jedoch bereits, dass das Archivieren erfolgreich war
  • Allerdings kann Toast-Feedback bei einer Rückgängig-Funktion und bei der Nutzung von Tastenkürzeln nützlich sein
• Es gibt auch Fälle, in denen nach dem Kopieren von etwas in die Zwischenablage ein Toast angezeigt wird
  • Im Beispiel enthält der Button selbst bereits den Bestätigungszustand, sodass der Toast vollständig unnötig ist

Feedback bleibt trotzdem nötig

• Schlimmer als Toasts ist gar kein Feedback
• Wenn keine Zeit bleibt, einen besseren Feedback-Mechanismus zu entwerfen oder umzusetzen, sind Toasts besser als gar nichts

Wie Cakedesk Toasts vermeidet

• Cakedesk ist eine Offline-first-Rechnungs-App ohne Abo-Gebühren, mit der sich E-Mails direkt in der App versenden lassen
• Statt nach dem Klick auf den Send-Button einer E-Mail Feedback per Toast zu geben, ist der Zustandswechsel so gestaltet, dass er im selben Ablauf bleibt
  • Nicht gesendete Rechnungen haben in der Liste einen Send-Button
  • Während des E-Mail-Versands bleibt das Modal geöffnet, und der Submit-Button zeigt den Versandzustand an
  • Bei erfolgreichem Versand animiert die E-Mail aus dem Bildschirm heraus und zeigt so an, dass der Versand abgeschlossen ist
  • Der Send-Button in der Liste wird zu einer Paid-Checkbox, sodass bestätigt wird, dass die E-Mail gesendet wurde, und der Nutzer zur nächsten sinnvollen Aktion weitergeführt wird
• Nutzer können auch über den Kontext-Button prüfen, ob die E-Mail gesendet wurde

[wkang586]

Also heißt das, dass schlechte Toasts schlecht sind??

[GN⁺]

Hacker-News-Kommentare

• https://en.wikipedia.org/w/index.php?title=Toast_(computing)

• Ich bin nicht überzeugt. Der Großteil des Arguments wirkt so, als sei redundante UX schlechte UX
  Es fällt mir schwer, Beispielen wie dem zuzustimmen, dass beim Archivieren einer E-Mail ihr Verschwinden aus der Liste bereits Erfolg signalisiere oder dass ein Häkchen auf einem Button den Toast überflüssig mache. Dieselbe Information gleichzeitig auf verschiedene Weise zu vermitteln, ist kein Bug, sondern ein Feature, und das gibt es auch in der menschlichen Sprache allgemein. Denn so kommt die Nachricht auch unter nicht idealen Bedingungen an
  Toasts teilen den Status aller Aktionen auf eine standardisierte Weise mit und bieten wenn möglich sogar Rückgängig an, sodass Nutzer das Muster schnell erlernen können. Zusätzliche Hinweise in der Nähe der Aktion sind ebenfalls wertvoll, aber oft wird ihre Bedeutung erst zusammen mit einem Toast klar. Wenn man Toasts entfernt und durch mehrere spezifische Anzeigen ersetzt, müssen Nutzer allein aus dem Kontext verschiedene Ausdrücke dafür lernen, dass „es jetzt erledigt ist“. Für ältere Menschen, Sehbehinderte und Kinder könnte das besonders schlecht sein
  Solange sie nicht tatsächlich stören, sind Toasts keine schlechte UX, sondern redundante UX, und UX-Designer sollten nicht darauf fixiert sein, Redundanz zu beseitigen

  • Leider vermitteln die beiden nicht dieselbe Information
    Im YouTube-Beispiel ist das Kontrollkästchen zu 100 % ein optimistisches Update, und die Toast-Benachrichtigung bedeutet, dass die asynchron an das Backend gesendete Anfrage erfolgreich war. Beim Archivieren von E-Mails ist es genauso: Die Nachricht wird optimistisch aus der Liste entfernt, und der Toast zeigt an, dass sie tatsächlich archiviert wurde
    Ich würde lieber nur dann einen Toast erhalten, wenn das Commit der Änderung fehlschlägt. Normalerweise lenkt mich ein aufblinkender Toast von dem ab, was ich gerade tun will, und wenn er auf dem Bildschirm weit von der Stelle entfernt ist, an der die Aktion stattfand, ist er noch ablenkender
  • Nein, Toasts sind schlecht. Nachrichten am Rand meines Sichtfelds oder meiner Aufmerksamkeit, zum Beispiel auf einer Seite eines breiten Monitors, stiften aktiv Verwirrung. Ich bearbeite hier gerade dieses Problem, und dort drüben blinkt etwas auf. Während ich den Fokus verlagere, um es zu lesen, ist die Hälfte schon wieder verschwunden
    Man sollte Nachrichten dort platzieren, wohin die Aufmerksamkeit des Nutzers bereits gerichtet ist. Die UI hat meinen Blick bereits dorthin gelenkt, also sollte auch dort die Anzeige erscheinen
  • Ich nutze Computer hauptsächlich mit einer Vergrößerungshilfe, die Text und den Bereich um Maus- bzw. Fingerzeiger vergrößert. Toasts und die meisten Benachrichtigungen befinden sich nicht dort, wo ich gerade arbeite, deshalb verpasse ich sie fast immer. Bei meiner Nutzungsweise ist nur Feedback in der Nähe des Elements wertvoll, mit dem ich interagiere
  • Es heißt zwar, „Redundanz in der Kommunikation ist ein Feature, kein Bug“, aber wenn es zu viele Störinformationen gibt, lernen Nutzer, sie zu ignorieren, und dann wird es zum Problem, wenn sich gelegentlich wirklich wichtige Informationen darunter mischen
    Die Lehre daraus ist, den Nutzern keine Informationen zu senden, die nicht unbedingt nötig sind
    Weiterführende Lektüre:
    https://en.wikipedia.org/wiki/Banner_blindness
    https://en.wikipedia.org/wiki/Alarm_fatigue
    https://en.wikipedia.org/wiki/Inattentional_blindness
    https://en.wikipedia.org/wiki/Habituation
  • Ich denke, die vorgeschlagene Verbesserung bedeutet Folgendes: Wenn man befürchtet, dass das UI-Element, mit dem der Nutzer interagiert, die aktuelle Situation nicht ausreichend vermittelt, sollte man nicht ein zweites Element hinzufügen, das die Aufmerksamkeit des Nutzers aufteilt und verlangt, schnell zu lesen und selbst die Verbindung herzustellen, sondern dieses Element selbst verbessern. Fehler sollten im Kontext des Elements vermittelt werden, mit dem der Nutzer interagiert hat, damit der Zusammenhang klar ist
    Toasts sind im schlimmsten Fall als letztes Mittel sinnvoll, wenn man dem Nutzer etwas ohne Kontext mitteilen muss. Wenn der Nutzer zum Beispiel ein Häkchen bei einer Playlist entfernt, die Playlist-Liste während des Speicherns schließt und das Speichern dann fehlschlägt, ist der Handlungskontext verschwunden; dann ist auch ein Toast verständlich, der die Information irgendwo beliebig auf dem Bildschirm einblendet
    Trotzdem ist ein Toast wahrscheinlich nicht die beste Lösung, wenn man will, dass der Nutzer den Fehler wirklich versteht. In werbefinanzierten Apps wie YouTube, bei denen die Nutzer selbst das Produkt sind, ist es einem womöglich egal oder sogar recht, wenn Nutzer solche Fehler übersehen; bei einer Business-App würde man aber wohl nicht darauf setzen wollen, dass Nutzer einen Toast verpassen oder mit einem anderen Fehler verwechseln. Meist hilft es dem Nutzer mehr, das betreffende Element erneut zu öffnen und den Fehler im Kontext zu zeigen. Man könnte die Playlist-Liste öffnen und mit einer Animation die Aufmerksamkeit darauf lenken, dass die Änderungen nicht gespeichert wurden. Das mag als systematisch umzusetzendes Ideal unrealistisch sein, aber idealerweise sollte man immer Fehler im Kontext sehen

• Das Schlimmste ist, dass Toasts zu schnell verschwinden und selbst bei Vorgängen, bei denen Erfolg selbstverständlich ist, unnötig Aufmerksamkeit auf sich ziehen. Zusammen ist das besonders nervig. Aufmerksamkeit wird unnötig gebunden, aber weil die Meldung so schnell wieder weg ist, weiß man nicht einmal, ob sie tatsächlich nichts Wichtiges enthielt. Es gibt auch die Variante, dass sie im Gegenteil zu lange stehen bleibt und dadurch Teile der UI verdeckt, die man sofort sehen und benutzen wollte
  Der traditionelle Desktop-Ansatz ist besser. Fehlermeldungen werden als Modal angezeigt, damit sie nicht übersehen werden, und Erfolgsmeldungen als unaufdringlicher Klartext in einer Statusleiste, die immer sichtbar ist und kein Zeitlimit hat. Ohne Fehler-Modal kann der Nutzer davon ausgehen, dass der Vorgang erfolgreich war, und wenn eine Bestätigung nötig ist, kann er sie ohne Zeitdruck in der Statusleiste nachsehen. Dort können auch Zusatzinformationen stehen
  Manche Apps zeigen sogar ein Pop-up mit einem Verlauf der Statusleistenmeldungen. In diesem Modell ist die Statusleiste wie die letzte Ausgabzeile eines Kommandozeilen-Terminals, und frühere Ausgaben kann man ebenfalls wieder aufrufen

  • Zusätzlich kommt hinzu, dass manche Toasts wichtige Informationen zeigen, die der Nutzer braucht, aber zu schnell verschwinden und wegen der Größenbegrenzung des Toasts auch noch unvollständig sind
    Ich gehe oft in die Benachrichtigungen, um nachzusehen, was ich verpasst habe. Es wirkte wichtig, aber ich hatte nicht genug Zeit, alles zu lesen. Wenn ich dort auf einen Eintrag tippe, der wie eine abgeschnittene Meldung aussieht, erwarte ich, zum vollständigen Kontext zu gelangen, aber tatsächlich verschwindet nur die Benachrichtigung und die App öffnet sich, ohne per Deep Link zu genau diesem Problem zu führen. Dann muss ich in der normalen UI der App nach einem Problem suchen, das dort vielleicht sichtbar ist oder auch nicht
    So etwas ist mir unzählige Male passiert, und jedes Mal ärgere ich mich über die Leute, die solche Systeme entworfen haben
  • Toasts vermitteln das Gefühl, als müsste es irgendwo ein Event-Log geben, in dem man später nachsehen kann, was passiert ist. In der Realität gibt es kein zugängliches Event-Log, und wenn eine Toast-Meldung per Timeout verschwindet, ist sie für immer weg
  • Als Gedankenexperiment: Wie lange sollte ein Toast auf dem Bildschirm bleiben? Man muss dem Nutzer Zeit zum Lesen geben, aber man weiß weder, wann er hinschaut, noch wie schnell er liest, also gibt es keine sichere Obergrenze
    Ich hatte dieses Problem heute mit meinem Sohn. Wir haben zusammen eine neue App benutzt, während er noch seine Lesegeschwindigkeit übt, und ständig erschienen Toasts, mit denen er kaum mithalten konnte und die ihn abgelenkt haben. Am Ende musste ich sie ihm laut vorlesen. Wären es Meldungen gewesen, die länger sichtbar bleiben, hätte er es wahrscheinlich ohne zusätzliche Hilfe geschafft
  • Die bessere Lösung ist, von Erfolg auszugehen und solche Meldungen nur dann anzuzeigen, wenn ein Fehler auftritt
  • Die schlimmste Toast-Implementierung ist die, bei der UI-Elemente tatsächlich verdeckt werden, sodass man sie weder sehen noch anklicken kann, bis der Toast verschwindet

• Bei YouTube gibt es ein noch besseres Beispiel
  Wenn man auf https://www.youtube.com/feed/history geht, rechts auf „Comments“ klickt und dann einen Kommentar löscht, erscheint erst ein Toast, dass die Löschung geplant ist, und 1–2 Sekunden später noch ein weiterer, dass sie erfolgt ist
  Löscht man mehrere Kommentare schnell hintereinander, erscheinen zuerst mehrere Toasts für die geplante Löschung, und nach 1–2 Sekunden Verzögerung kommen die jeweiligen Bestätigungs-Toasts der Reihe nach. Die eigentliche Löschung läuft ebenfalls sequenziell ab, also muss man auf alle Bestätigungs-Toasts warten. Selbst wenn man 10 Kommentare in 2–3 Sekunden anklickt, dauert die Bestätigung mehr als 10 Sekunden
  Bei Live-Chat-Kommentaren ist es genauso:
  https://myactivity.google.com/page?page=youtube_live_chat&co...

• Dem Punkt „Der Undo-Button im Toast ist unnötig, weil der Nutzer einfach das Kontrollkästchen noch einmal anklicken kann“ stimme ich im Allgemeinen nicht zu. Wenn man aus Versehen irgendwo geklickt hat, aber nicht genau weiß, wo, und die App nicht gut genug kennt, um den Vorgang allein anhand der Meldung leicht rückgängig zu machen, ist Rückgängig sehr nützlich

  • In diesem konkreten Beispiel gibt es den Rückgängig-Button bereits: das Kontrollkästchen selbst. Das Problem ist, dass es nicht dem exakten Zustand entspricht, den es anzeigen sollte. Wenn man es aktiviert, bleibt es für ein paar Sekunden aktiviert, obwohl das Video noch nicht gespeichert ist, und wenn man es deaktiviert, ist die Speicherung noch nicht aufgehoben, bis der Toast erscheint. Wenn man wiederholt an- und abwählt, weiß man am Ende nicht mehr, was der Endzustand ist
  • So etwas habe ich in einigen Systemen erlebt. Man weiß, dass man gerade den falschen Eintrag geändert hat, aber nicht welchen, und es gibt keinerlei Hinweis. Besonders problematisch ist es, wenn vielleicht auch gar nichts geändert wurde, man sich dessen aber nicht sicher sein kann
    Als extremes Beispiel: Stell dir vor, während du dich umdrehst, rollt ein Ball vom Regal und drückt auf der Tastatur herum. Hat sich etwas geändert? Was hat sich geändert? Wie behebt man es?

• Es gibt nur einen Fall, in dem Toasts sinnvoll sind: wenn es sich um eine Benachrichtigung handelt, die nichts mit der aktuellen Aktion des Nutzers zu tun hat. So etwas Ähnliches wie die OS-artigen Benachrichtigungen, die das inzwischen verschwundene Growl umgesetzt hat
  Feedback zu einer Nutzeraktion sollte im Kontext dieser Aktion erfolgen. Wenn es sich um eine asynchrone Aktion handelt, sollte das klar ersichtlich sein, und das Feedback sollte sofort zeigen, dass die betreffende Aufgabe in die Warteschlange aufgenommen wurde. In diesem Fall sollte das Feedback Optionen zum Abbrechen und zum Zugriff auf die Warteschlange bieten, besser noch zur Anzeige des Fortschritts

  • Ich würde noch ein weiteres Szenario hinzufügen: wenn das UI-Element, das normalerweise Feedback geben würde, bereits entfernt wurde, man aber trotzdem noch Feedback anzeigen möchte
    Wenn man eine Aufgabe aus einem Board entfernt hat, kann man darüber keine Möglichkeit zum Rückgängigmachen mehr anzeigen. Man kann das zwar per Tastenkürzel rückgängig machen, aber woher soll der Nutzer das visuell wissen?
    In einer Aufgabenliste sollten nur Aufgaben stehen, daher würde man nicht statt einer Aufgabe eine Notiz einfügen. Man würde auch keine Art abgeleitete Aufgabe erzeugen, die nur eine Nachricht anzeigt. Das würde bedeuten, der Aufgabenkomponente eine funktionslose Absicht zu injizieren. Den Nutzer gar nicht zu informieren, gefällt mir ebenfalls nicht. Dass die Aufgabe entfernt wurde, ist offensichtlich, aber wie man eine so beunruhigende Aktion, die mit einem einzigen Klick ausgelöst wurde, rückgängig macht, ist nicht offensichtlich. Vor dem Löschen einer Aufgabe würde ich aber auch nicht jedes Mal lästig um Bestätigung bitten. Es ist eine Kernfunktion der Aufgabenliste und sollte sofort ausgeführt und sofort rückgängig gemacht werden können
    Solche kleinen Sonderfälle dürfte es viele geben. Toasts wurden aus einem Grund erfunden. Nur weil Leute sie auf niedliche Weise überstrapaziert haben, heißt das nicht, dass sie in bestimmten Szenarien nicht konkret nützlich sind
  • Bei modalen Aufgaben, die der Nutzer nach dem Starten in 99 % der Fälle in den Hintergrund schicken und etwas anderes tun möchte: Wo soll man dieses Feedback dann anzeigen?
  • Es gibt auch Beispiele, die mit der aktuellen Nutzeraktion zusammenhängen, aber außerhalb des aktuell sichtbaren Bildschirmbereichs liegen. Etwa wenn man einen USB-Stick einsteckt oder andere hardwarebezogene Funktionen ausführt
    Solche Aktionen haben keinen sichtbaren Kontext auf dem Bildschirm, und oft ist eine zusätzliche Handlung nötig. Selbst wenn keine weitere Handlung nötig ist, ist es eindeutig nützlich zu bestätigen, dass die Aktion des Nutzers erkannt wurde
  • Growl hat OS-artige Benachrichtigungen nicht erfunden. Growl erschien 2004, und Windows XP hatte bereits 2001 Benachrichtigungen. Wenn man Clippys Meldungen als Benachrichtigungen betrachtet, könnte man mindestens bis zu Microsoft Bob (1995) zurückgehen

• Für alle, die verwirrt waren: Dieser Beitrag handelt nicht von geröstetem Brot [1], sondern von einer Art UI-Widget [2]
  [1] https://en.wikipedia.org/wiki/Toast_(food)
  [2] https://en.wikipedia.org/w/index.php?title=Toast_(computing)

  • Es ist ironisch, dass ein Beitrag über ein schlechtes Kommunikationsparadigma ausgerechnet hier nicht erklärt hat, was toast bedeutet
    Es ist das wichtigste Wort auf der Seite, und selbst unter technisch versierten Lesern gibt es offenbar Menschen, die diesen Fachbegriff nicht verstehen
    Andererseits könnte das Engagement dank Lesern, die sich für Backen und Frühstücksrezepte interessieren, sogar höher gewesen sein

• Was die Aussage „Der Undo-Button im Toast ist unnötig, weil der Nutzer die Checkbox einfach erneut anklicken kann“ angeht: Ich bin für diese Funktion besonders dankbar. Unzählige Male dachte ich, ich hätte eine E-Mail archiviert, und der Toast hat mich darauf hingewiesen, dass ich stattdessen den Spam-Button gedrückt hatte. Sonst hätte ich es überhaupt nicht bemerkt
  Ein weiteres grundlegendes Problem mit Toasts, das der Originaltext übersehen hat, ist, dass Web-Aktionen asynchron sind. Man weiß nicht, ob eine Aktion erfolgreich war, fehlgeschlagen ist oder überhaupt beim Server angekommen ist. Ein Toast liefert asynchrone Updates über den Serverstatus
  Natürlich stimme ich zu, dass manche Toasts lästig sind und in manchen Fällen wichtige UI-Inhalte verdecken, ohne dass man sie schließen kann

  • Der Originaltext hat den Kernpunkt von Toasts völlig verfehlt. Manche Nutzeraktionen können 1) versehentlich ausgeführt werden und 2) kommen oft wiederholt vor, weshalb sie schlecht zu Bestätigungsdialogen passen
    Wenn man also versehentlich auf etwas klickt und eine E-Mail plötzlich aus dem Posteingang verschwindet, braucht man einen Toast mit einem Undo-Button. Wenn man einfach still dasitzt und dann mit dem Körper gegen einen Button kommt und plötzlich ein Toast erscheint, ist man froh, dass es ihn gibt. Idealerweise sollte er die ausgeführte Aktion beschreiben und einen Undo-Button enthalten
    In Gimp wird beim Drücken von Tab die gesamte UI ausgeblendet, und wenn man die Tastenkombination nicht kennt, gibt es keinen Weg zurück. Für Künstler, die sich auf das Bild konzentrieren möchten, ist das eine wünschenswerte Funktion. Aber als ich versehentlich darauf gedrückt hatte und nach „gimp how to fix interface disappeared“ suchen musste, hätte ich mir nichts sehnlicher gewünscht als einen Toast mit Undo-Button. Ich kann mir gar nicht vorstellen, wie jemand reagieren würde, der sich mit Computern nicht auskennt

• Toasts können schlechte UX sein. Meistens dann, wenn sie das einzige Feedback sind, aber zusammen mit anderen Elementen sind sie hervorragend
  Ein Bestätigungs-Toast, der zusammen mit einer Seitenweiterleitung erscheint, ist ein gutes zusätzliches Signal dafür, dass das Absenden erfolgreich war
  Warn- oder Fehler-Toasts zusammen mit standardmäßigen Formularvalidierungshinweisen sind ein hervorragendes zweites Signal dafür, dass der Nutzer etwas ändern muss
  Wenn man sie zur pauschalen Behandlung nicht spezifizierter Fehler implementiert, kann man den Seitenzustand des Nutzers erhalten, ohne ihn auf eine Fehlerseite zu schicken
  Sie sind eine gute Option, wenn man sie nicht als einziges Werkzeug, sondern als ein Werkzeug im Werkzeugkasten verwendet

• Es gibt noch etwas Schlimmeres als Toasts: versteckte Slide-Panels. Im Grunde sind das versteckte Toasts, die man für bestimmte Aktionen braucht, die aber überhaupt nicht intuitiv sind und sich weder finden noch entdecken lassen. Das schlimmste Erlebnis hatte ich, als ich auf dem Handy von jemand anderem Waze benutzt habe. Ich musste irgendetwas tun, weiß aber nicht mehr was, und habe nur leer auf den Bildschirm gestarrt und geraten, was ich tun sollte. Am Ende nahm die Person das Handy und zeigte mir, wie man von rechts ein verstecktes Panel hereinzieht
  Ich verstehe ja, dass man Platz sparen will, aber das ist wirklich absurd. Wie kann irgendein UX-Profi erwarten, dass Nutzer das erraten? Werden UIs heutzutage für Leute gebaut, die wie Kinder überall herumtippen, um Dinge zufällig zu entdecken?

  • Wenn die Nutzer es wissen und es nicht mehr als ein Hauptmenü und zwei Sidebars gibt, finde ich UX mit links/rechts wischen zum Öffnen von Sidebars in Ordnung
    Die mobile Discord-App nutzte früher diese Methode sowohl für die linke als auch für die rechte Sidebar, aber irgendwann hatte jemand die großartige Idee, dass die Geste „zum Antworten wischen“ wichtiger sei als die Navigation in der App, und jetzt muss man einen kleinen, unklaren Button drücken, um die rechte Sidebar zu sehen
  • Ich erinnere mich, dass ich sofort gemerkt habe, wie schrecklich Snapchat ist, sobald ich es installiert hatte. In verschiedenen Ecken waren verschiedene Funktionen. So etwas sollte illegal sein
  • Stimme voll zu. iOS ist natürlich voll von so etwas, und das gilt sogar auf Tablets mit reichlich Bildschirmfläche
  • Die meisten „Toasts“ kenne ich inzwischen zwar als Begriff, halte sie aber für redundant und nutzlos. Meistens verpasse ich sie komplett. Im Allgemeinen halte ich sie nicht für schädlich, aber man sollte sie nicht verwenden, um wichtige Informationen zu vermitteln
    Bei „versteckten Panels“ dachte ich immer, das sei ein Bug, aber vielleicht hielt es irgendjemand für eine gute Idee
    Ich benutze oft die Apple-Connect-App, mit der man Apps im App Store verwaltet. Wenn ich mein iPad Mini im Hochformat benutze und dann eine meiner Apps auswähle, verschwindet der Zurück-Button oft. Dann kann ich kein anderes Konto auswählen und auch keine andere App im aktuellen Konto
    Erst wenn ich das iPad physisch ins Querformat drehe, ändert sich das. Dann erscheint links der Navigator, und ich kann eine andere App auswählen oder das Konto wechseln
    Ehrlich gesagt bin ich von der gesamten UX des Apple-App-Store-Backends ziemlich enttäuscht. Das Frontend gefällt mir auch nicht besonders, aber im Backend bin ich ständig. Wenn man bedenkt, wie viel Aufmerksamkeit sie dem restlichen Nutzererlebnis der Plattform widmen, ist das ziemlich schockierend