Moderne iOS-Navigationsmuster

 (frankrausch.com)
6 Punkte von GN⁺ 2023-12-13 | 3 Kommentare | Auf WhatsApp teilen
  • Die Navigation in iOS-Apps sollte Hierarchie, Overlays und view-interne Abläufe klar voneinander trennen, damit Nutzer ihre aktuelle Position und den Weg zurück verstehen können.
  • Strukturelle Muster lassen sich in Drill-Down, Flat, Pyramid und Hub-and-Spoke einteilen; ihre Übergänge zwischen Screens haben unterschiedliche Bedeutungen, etwa als Baum-Navigation, tab-basierte Aufteilung, Wechsel zwischen Geschwisteransichten oder Rückkehr zu einem Hub.
  • Overlays dienen dazu, Aufmerksamkeit zu erzeugen, aber je nach Modalität und Reibungsgrad unterscheiden sie sich darin, wie stark sie den dahinterliegenden Screen blockieren und welche Aktion vom Nutzer erwartet wird.
  • Eingebettete Navigation sollte innerhalb einer bestimmten View oder eines modalen Dialogs stattfinden, und Zustandsänderungen oder Step-by-Step-Abläufe sollten nicht so gestaltet sein, als wären sie hierarchische Navigation.
  • Tabs sollten vorhersehbar sein, Cancel sollte Daten nicht sofort verwerfen, und in iOS-Apps ist es meist sinnvoller, klare Grenzen zwischen Hierarchie, Zustand und Modalität beizubehalten als beliebige Sprünge zuzulassen.

Drei Achsen der iOS-Navigation

  • iOS-Apps bestehen meist aus einem mehrstufigen festen Hierarchiebaum.
  • Strukturelle Navigation hilft Nutzern zu verstehen, woher sie gekommen sind, wo sie sich innerhalb der Hierarchie befinden und wie sie zu ihrer ursprünglichen Position zurückkehren können.
  • Overlays können über jedem Kontext erscheinen und sich auch über andere Overlays legen.
    • Modale Overlays verschwinden nicht, bevor der Nutzer handelt, und blockieren die dahinterliegende Oberfläche.
    • Nicht-modale Overlays blockieren die App nicht.
  • Eingebettete Navigation sollte passend zum strukturellen und räumlichen Modell von iOS innerhalb einer bestimmten View oder eines modalen Overlays enthalten sein.

Strukturelle Navigationsmuster

  • Drill-Down

    • Drill-Down ist ein Muster zum schrittweisen Erkunden einer Baumstruktur von Informationen über Listen.
    • Die animierten Übergänge deuten eine horizontale Bewegung zwischen Spalten an.
      • Eine Bewegung nach rechts bedeutet, tiefer in die Baumhierarchie einzusteigen.
      • Eine Bewegung nach links bedeutet, zur übergeordneten Ebene zurückzukehren.
    • Drill-Down-Navigation ist modeless, daher unterbrechen Fragen wie das Speichern nicht die Hierarchienavigation.
    • Die Navigation Bar zeigt den Titel des aktuellen Screens an, und der Disclosure indicator in einer Listenzeile signalisiert, dass man zu einer tieferen Ebene wechseln kann.
    • Der Back-Button ist ein klarer Weg zurück zur übergeordneten Ebene; wenn genug Platz vorhanden ist, sollte sein Label besser den Titel des Eltern-Screens als das allgemeine „Back“ verwenden.
    • Eine Wischgeste vom linken Bildschirmrand nach rechts erfüllt dieselbe Funktion wie der Back-Button.
    • Eine Custom-Implementierung sollte wie der iOS-Standard interaktive und abbrechbare Übergänge bieten, die durch eine screen-edge pan gesture gesteuert werden.
    • In Sprachen mit Schreibrichtung von rechts nach links werden Navigationsrichtung und Anordnung der Controls entsprechend der Leserichtung gespiegelt.
    • Baumstrukturen können dynamisch für Datenbankfilterung erzeugt werden.
      • In einer Musik-App kann man über unterschiedliche Startpunkte wie Artist, Album oder Genre per Drill-Down zum selben Album gelangen; zusätzlich kann auch eine Suchoberfläche genutzt werden.
    • Drill-Down ist eine Variante von Miller columns im Stil des macOS Finders mit einer Spalte pro Screen.

  • Flat

    • Das Flat-Muster teilt die Hierarchie auf Root-Ebene auf und stellt sie über eine tab bar dar.
      • Auf dem iPad kann stattdessen eine sidebar verwendet werden.
    • Die Elemente der Tab Bar werden anhand der Hauptfunktionen der App ausgewählt und prägen die mentale Modellvorstellung der Nutzer von der App.
    • Eines der Elemente der Tab Bar ist immer ausgewählt, und die aktive Auswahl bestimmt, was im Hauptinhaltsbereich der App angezeigt wird.
    • Das aktuell ausgewählte Element der Tab Bar darf nicht ohne Nutzerinteraktion programmatisch geändert werden oder indirekt dadurch, dass ein anderer Button in der Oberfläche getippt wird.
    • Die Tab Bar bleibt über den gesamten App-Screen hinweg sichtbar, außer wenn sie vorübergehend von einem modalen Sheet verdeckt wird.
    • Tabs können als Filter dienen oder als unterschiedliche Einstiegspunkte in große Inhaltssammlungen wie Musik-, Video- oder Fotobibliotheken.
    • Jeder Bereich behält seinen eigenen Navigationszustand innerhalb seiner Unterhierarchie.
    • Elemente der Tab Bar sollten vorhersehbar funktionieren und weder Sheets öffnen noch Aktionen auslösen.
    • Das Hamburger-Menü ist eine versteckte Form der Navigation im Gegensatz zur Tab Bar.

  • Pyramid

    • Das Pyramid-Muster ermöglicht schnelle Wechsel zwischen Geschwister-Views auf derselben Hierarchieebene, ohne zum Eltern-Screen zurückzukehren.
    • In Media-Apps werden horizontale Swipe-Gesten oft für die Bewegung zwischen Geschwister-Views verwendet.
    • Auch Buttons können genutzt werden, etwa die Chevron-Buttons Next Message und Previous Message in der iOS-Mail-App.
    • Die iOS-Fotos-App ist ein Beispiel für das Pyramid-Muster.
      • Man tippt auf ein Foto, öffnet es im Vollbild und wechselt dann per Wisch nach links oder rechts durch benachbarte Bilder.
    • In kleinen Sammlungen visualisiert ein page control die Gesamtzahl der Elemente und die Position des aktuellen Elements unter seinen Geschwistern.
    • Der iOS App Switcher implementiert ein Pyramid-Muster für den schnellen Wechsel zwischen Apps und ermöglicht schnellere Navigation als der Umweg über den Home-Screen.

  • Hub-and-Spoke

    • Das Hub-and-Spoke-Muster eignet sich, wenn es auf der obersten Hierarchieebene große, nicht miteinander zusammenhängende Sammlungen gibt.
    • Um zwischen Child-Views im Vollbild zu wechseln, kehrt man immer zuerst zum Hub zurück.
    • Der iOS-Home-Screen ist eine Sammlung aller installierten Anwendungen und dient als verlässlicher neutraler Zustand des Betriebssystems.
    • Der Home indicator am unteren Bildschirmrand ist ein leicht erlernbares und jederzeit verfügbares Ausstiegselement, das zur vertrauten Home-Screen-Oberfläche zurückführt.
    • Innerhalb von Apps wird dieses Muster kaum verwendet.
      • Es kommt selten vor, dass innerhalb einer App eine so starke Trennung nötig ist wie die ausgeprägte Trennung zwischen Anwendungen auf Betriebssystemebene.

Overlay-Navigation

  • High-Friction Modal

    • Ein High-Friction Modal-Overlay blockiert wie ein Sheet oder ein Alert-Dialog mit mehreren Aktionen den dahinterliegenden Screen, bis der Nutzer eine Entscheidung trifft.
    • Beim Verfassen einer E-Mail oder beim Erstellen eines Kalendereintrags braucht es eine Wahl zwischen Fortfahren mit Done oder Send und dem Umdenken per Cancel.
    • Der Cancel-Button darf keinen Zustand oder Daten direkt verwerfen.
      • Wenn in einem modalen Sheet auf Cancel getippt wird, sollte als Absicherung immer ein zusätzlicher Bestätigungsdialog angezeigt werden.
      • In einem Alert-Dialog darf Cancel niemals eine destruktive Aktion sein.
    • Modale Oberflächen konzentrieren sich auf das Abschließen einer bestimmten, in sich geschlossenen Aufgabe wie das Schreiben einer E-Mail oder das Hinzufügen eines Kalendereintrags.

  • Low-Friction Modal

    • Ein Low-Friction Modal blockiert wie ein Sheet, Menü oder Popover den Rest der App, verlangt aber keine Entweder-oder-Entscheidung.
    • Es sollte sich leicht schließen lassen, etwa durch einen Close-Button oder durch Herunterwischen eines Sheets.
    • Ein Tippen außerhalb eines context menu oder popover lässt dieses verschwinden.
    • Ein Alert-Dialog mit nur einem OK-Button lässt sich zwar leicht schließen, aber geringe Reibung ist nicht dasselbe wie keine Reibung.
    • Alerts mit nur einer Aktion sollten möglichst vermieden werden.
      • Sie unterbrechen den Nutzerfluss und lassen sich oft durch Inline-Text oder nicht-modale Hinweise ersetzen.

  • Non-Modal

    • Ein Non-Modal-Overlay überdeckt einen Teil des Screens, blockiert aber nicht die dahinterliegende Oberfläche.
    • Durch die nicht blockierende Form entsteht nur sehr wenig oder gar keine Reibung.
    • Es kann als Reaktion auf Trigger außerhalb der App erscheinen, etwa wie Betriebssystem-Benachrichtigungen.
    • Wenn es automatisch verschwindet, sollte es auf einen Blick erfassbare periphere Informationen mit minimaler Störung liefern.
    • Temporäre nicht-modale Overlays können optionale Interaktionen enthalten.
      • Man kann etwa auf eine Benachrichtigung tippen oder vor dem Verschwinden über die Lautstärkeanzeige wischen, um die Lautstärke zu ändern.
    • Ein Overlay, das den Rest der Anwendung nicht blockiert und weder automatisch erscheint noch verschwindet, kann als palette bezeichnet werden.

Eingebettete Navigation

  • State Change

    • Eine einzelne View kann mehrere Zustände haben.
    • Eine Listen-View kann etwa die Zustände empty, loading und populated haben, ohne dass es so aussieht, als hätte sich ihre Position in der Navigationshierarchie verändert.
    • Man sollte sicherstellen, dass Zustandsänderungen tatsächlich weder hierarchisch noch modal sind.
    • Bei Zustandsänderungen an Ort und Stelle sollten Vollbildübergänge vermieden werden.
    • Beispiele sind der Bearbeitungsmodus einer Liste, Webbrowser-Oberflächen, verschiebbare Straßenkarten und zoombare Bilder.
    • View-Optionen verändern nur die Darstellung von Inhalten, ohne die Position des Nutzers zu ändern.
      • Der Wechsel zwischen list view und thumbnail view ist ein Umschalten zwischen unterschiedlichen Visualisierungen derselben Informationen im selben Kontext.

  • Step-by-Step

    • Das Step-by-Step-Muster verbindet eine Reihe von Screens zu einem linearen Ablauf, etwa für geführte Touren, Setup-Flows oder Onboarding-Tutorials.
    • Auch Prozesse mit vielen Dateneingaben wie der Checkout in einem Online-Shop benötigen mehrere Schritte.
    • Vor- und Zurückwechseln innerhalb dieser Reihenfolge verändert nicht die Hierarchieebene; darin unterscheidet sich das Muster von Drill-Down.
    • Eine Step-by-Step-Sequenz sollte vorzugsweise innerhalb eines modalen Overlays dargestellt werden.
      • Der Back-Button in diesem Kontext hat einen anderen Zweck als der Back-Button in einer hierarchischen Drill-Down-Navigation.
    • Der Prozess wird meist mit einem Done- oder Close-Button abgeschlossen, der auch das enthaltene Modal schließt.
    • Je nach gewählter Option können sich Anzahl und Verlauf der Schritte ändern.
    • Wizard und assistant sind andere Bezeichnungen für dieses Muster.
    • Step-by-Step-Prozesse können sich mühsam anfühlen.
      • Wenn zu erwarten ist, dass Nutzer sie häufig durchführen, kann man erwägen, mehrere Schritte als unterschiedliche Zustände innerhalb einer einzigen View zu kombinieren, um die Informationsdichte zu erhöhen und Kontextwechsel zu reduzieren.

  • Content-Driven

    • Content-Driven-Navigation funktioniert so, dass Hyperlinks oder Buttons den Nutzer direkt auf eine andere Seite oder in eine andere View springen lassen.
    • Die Webnavigation im Browser funktioniert auf diese Weise.
    • In iOS-Apps sollte dieses Muster eher vermieden werden, außer in Apps, die Hypertext anzeigen, in immersiven Spielen oder bei ähnlichen nichtlinearen Inhalten.
    • Wenn eine App Hypertext-Inhalte anzeigen muss, kann man erwägen, sie innerhalb einer Browser-Oberfläche mit Back- und Forward-Controls einzubetten.
    • Zustandsänderungen in einer eigenständigen Browser-Oberfläche sind leichter zu verstehen als unerwartete Positionswechsel in der Anwendungshierarchie.
    • Für den Wechsel zwischen Apps können Links verwendet werden.
    • Deep Links verschieben Nutzer mithilfe von URL scheme oder domaingebundenen Universal Links von einer App oder Website in eine tiefere Hierarchieebene einer anderen App.

Referenzen

Verwandte Beiträge

3 Kommentare

 
GN⁺ 2023-12-13
Hacker-News-Kommentare

  • Das wurde zwar schon oft gesagt, aber dass solche Patterns gut umgesetzt waren, war einer der vielen Gründe, warum Apollo der offiziellen Reddit-App weit überlegen war.
    Navigation, Gesten und Verhalten waren konsistent, und dieses Konzept ist auch nicht schwierig. Man muss nur genug darauf achten, es einzuhalten; es ist frustrierend, dass so viele Apps das nicht tun.

    • Das ist der Unterschied zwischen einer App, die darauf optimiert ist, eine gute App zu sein, und einer App, die auf Engagement und Verkäufe optimiert ist.
      Es ist ähnlich wie bei Supermärkten, die regelmäßig ihre Regale umstellen. Wenn Navigation, Gesten und Verhalten konsistent sind, können Nutzer zu effizient das bekommen, was sie wollen, und wieder verschwinden.
    • Ich habe noch keine App gesehen, die so verwirrend ist wie die offizielle Reddit-App, und ich halte meine Intelligenz für durchschnittlich.
      Ich moderiere ein Subreddit mit 30.000 Mitgliedern und muss Reddit daher auf dem Smartphone nutzen können, aber es ist nahezu unmöglich. Für jede Aktion sind viel zu viele Schritte nötig, und man weiß nie, wo man gerade ist; es ist einfach völliger Müll.
    • Es ist wirklich beschämend, wie Steve Huffman Reddit ruiniert hat, indem er Apollo abgeschafft hat.
      Ich hatte Reddit schon vor ein paar Jahren aufgegeben, aber das war der letzte Sargnagel.
    • Die offizielle Reddit-App ist eine der wenigen Apps, in denen ich regelmäßig die Orientierung verliere.
      Es kostet zu viel mentale Energie, zum Hauptbildschirm zurückzukommen, also beende ich sie einfach zwangsweise und öffne sie neu.
    • Auch in Apollo konnte man Ebenen wie Subreddits, Nutzerprofile und Beiträge endlos stapeln und öffnen, was verwirrend werden konnte.
      Nach ein paar Ebenen war es ziemlich umständlich, zum ersten Bildschirm zurückzukehren, weil man so lange wischen oder Zurück drücken musste, bis man dort ankam. Vielleicht gab es irgendeine magische Geste, die ich nicht kannte.

  • Bei dem Ausdruck „iOS-Navigationsmuster“ zucke ich zusammen. Es gibt keine Patterns, und im Vergleich zu Android ist das eines der schlimmsten Dinge an iOS.
    Unter Android ist Zurück einfach und kann mehrere Bedeutungen haben. Ich nutze iOS seit über einem Jahr, und ich probiere blind eines von zwei „Zurück“-Patterns aus und suche dann nach einem Button außerhalb meiner Reichweite. Manchmal funktioniert es trotzdem nicht.
    Man sollte Patterns nicht den Entwicklern überlassen, sondern das auf Betriebssystemebene beheben. Entwickler wollen nicht, dass Nutzer Teile ihrer App verlassen. Man kann es zum Beispiel mit Zurück in Instagram Reels versuchen.

    • Dass „Zurück unter Android einfach ist und mehrere Bedeutungen haben kann“, ist für mich eines der schlimmsten Dinge an Android.
      Es gibt keinerlei Konsistenz darin, was der Zurück-Button tut. Selbst ich als Entwickler komme in bestimmten Situationen ins Grübeln, was Zurück tun sollte. Soll es zum vorherigen Bildschirm gehen oder in einer Drilldown-Navigation eine Ebene nach oben? Das ist unklar; manchmal ist beides dasselbe, aber eben nicht immer.
      Manchmal geht es in der Navigationsstruktur eine Ebene nach oben, manchmal zum vorherigen Bildschirm, manchmal schließt es einen Dialog und manchmal sogar die App. Je nach Kontext ist jede Aktion möglich, und wenn mehrere zutreffen könnten, ist unklar, welche es ist. Die einzige Möglichkeit, es herauszufinden, ist, darauf zu drücken und zu schauen, was passiert.
      Ich hasse mehrdeutige Benutzeroberflächen-Elemente. Wenn ich auf etwas klicke, möchte ich wissen, welche Aktion ausgelöst wird.
    • Die Erfahrung mit dem Activity Stack von Android ist mein Lieblingsaspekt des Systemdesigns.
      Er erzeugt eine tiefe Konsistenz, sodass Navigation nicht mühsam wird. Ich hätte mir wirklich gewünscht, dass iOS das auf dieselbe Weise eingebaut hätte.
      Der Activity Stack funktioniert appübergreifend; selbst wenn mehrere Apps gemeinsam eine Aufgabe erledigen, bringt einen die Zurück-Geste immer zum unmittelbar vorherigen Bildschirm zurück.
    • Ich verstehe nicht, warum der Zurück-Button unter iOS so überall verstreut ist.
      Manchmal ist er oben links, manchmal unten links, manchmal unten rechts, und manche Apps platzieren ihn wahrscheinlich noch woanders.
      Android hat einen Zurück-Button auf Betriebssystemebene, der auch bei einhändiger Nutzung immer erreichbar ist. Dieser Ansatz ist deutlich überlegen.
    • Dass man „Patterns nicht den Entwicklern überlassen, sondern auf Betriebssystemebene beheben sollte“, hat Apple meiner Meinung nach nicht gemacht, weil es praktisch unmöglich ist.
      Wenn man zum Beispiel den Inhalt einer View ändern kann, kann man auch den gesamten Inhalt löschen und durch völlig neuen Inhalt ersetzen. Wenn das durch irgendeine Nutzeraktion passiert, ist es faktisch dasselbe wie „zu einem neuen Bildschirm wechseln“. Wenn der Entwickler aber nicht den vorgeschlagenen Betriebssystem-API-Aufruf createNewView verwendet, sondern nur den Inhalt der aktuellen View ändert, funktioniert eine Geste auf Betriebssystemebene nicht.
      Allerdings könnte Apple die Nutzung dieser Betriebssystem-API zur Pflicht machen, um die Review zu bestehen. Trotzdem ist es meiner Ansicht nach bis zu einem gewissen Grad subjektiv, was eine „neue View, zu der man zurückgehen kann“ ist und was eine „bestehende View, deren Inhalt nur geändert wurde“.
    • Das Share-Menü ist das Schlimmste. Ich weiß nicht, wie ein Mensch das herausfinden soll.
      Es zeigt Kontakte, Anwendungen, vertikale Elemente, horizontale Elemente und weitere Elemente unten an, die man außerdem erst sieht, nachdem man herausgefunden hat, dass man es nach oben ziehen muss. Die Position ist von App zu App unterschiedlich, und das Icon hat keinerlei Bezug zu „Teilen“ oder „Kopieren/Einfügen“.
      Menschen, die mit Smartphones aufgewachsen sind, können sich wie immer anpassen. Wenn man bei der Einführung nicht über 40 oder 50 war, kann man sich im Allgemeinen daran gewöhnen. Die meisten modernen Dinge sind schrecklich gestaltet und oft instabil. Apple TV ist auch so ein Fall; oder reden wir mal darüber, das WLAN-Passwort zu ändern. Ich brauche das, um Bugs zu umgehen, aber ich verstehe nicht, warum es nicht neu startet, wenn man den Ein-/Ausschalter drückt.

  • Ich weiß nicht, ob das ausreichend relevant ist, aber auf dem Mac und inzwischen auch in iPadOS (https://useyourloaf.com/blog/ipad-customizable-toolbars/) unterstützen die integrierten Toolbar-Controls ein hohes Maß an Anpassung
    Man kann das in mehreren nativen Apps ausprobieren, darunter Finder
    Leistungsfähige integrierte Widgets sind auf dem Mac-Desktop ein unterschätzter Faktor, und es ist auch etwas, das mir Sorgen macht, seit SwiftUI die Oberhand gewinnt. Auch für iOS ist das ein großer Vorteil, aber dort fällt es relativ weniger auf, weil Apps allzu oft ihr eigenes Design darüberlegen wollen
    Vielleicht erinnere ich mich falsch, aber ich meine, dass ältere iOS-Apps die Anpassung der Tab-Leiste standardmäßig unterstützt haben. Das ist natürlich etwas anderes als eine Toolbar, aber die Möglichkeit, die Reihenfolge der Tabs und die tatsächlich angezeigten Tabs zu bearbeiten, fühlte sich wie das geistige Äquivalent zur integrierten Toolbar-Anpassung an. Ich habe das allerdings seit Jahren nicht mehr gesehen
    Laut Dokumentation gibt es das noch. Ich frage mich, ob jemand eine App kennt, die dieses Pattern noch nutzt: https://developer.apple.com/documentation/uikit/uitabbarcont...
    Jedenfalls sind Tab-Leisten großartig. Die meisten Apple-TV-Apps, die ich genutzt habe, verwenden sie so, und die konsistente Experience ist hervorragend

    • In den frühen Tagen war es ziemlich üblich, Tabs zu mischen und nur die gewünschten ein- oder auszublenden
      Als Facebook noch in Ordnung war, vermutlich etwa zu iOS 7, konnte man meiner Erinnerung nach Elemente wie Chat, Feed, Benachrichtigungen und Gruppen auf diese Weise ändern
    • Mehrere Apple-Apps wie Apple Store und Music verwenden unten eine Tab-Leiste, lassen sich aber nicht anpassen
      Außerhalb von Apple sind die Apps, die mir einfallen, schon vor langer Zeit alle zu schwer auffindbaren Hamburger-Menüs gewechselt
    • Auf dem Mac würde ich mir wünschen, dass mehr Apps die Standard-Toolbar verwenden
      Die Anpassbarkeit ist gut, aber in Eigenimplementierungen findet man sie kaum
    • UITabBar war aus Programmierersicht schon immer schmerzhaft eingeschränkt anpassbar, und kaum ein Projekt hat sich um die vom Nutzer selbst veränderbare Seite gekümmert
      Ich denke, Apple hat das Erscheinungsbild so stark verriegelt, dass letztlich alle dazu gebracht wurden, es durch etwas anderes zu ersetzen
    • Ich vermisse immer noch die Funktion, mit der man in iOS-Apps wie der Music-App die Toolbar neu anordnen konnte
      Zwei der Tabs in Apple Music nutze ich buchstäblich nie. Ich würde gern direkt zu Playlists und Alben springen können

  • Die Aussage im ersten Punkt, „Drilldown-Navigation hat keinen Zustand“, wirkt auf mich genau umgekehrt
    Screen N hängt davon ab, was man zuvor getan hat, und man kann auch wieder dorthin zurückkehren, also ist das eine sehr zustandsreiche Struktur. Damit sie nützlich ist, muss ihr interner Zustand tatsächlich verfolgt werden. Beispielsweise hängt der Inhalt einer Liste vom Zustand N-1 ab; andernfalls wäre es schrecklich
    Eine zustandslose UI wäre eher so etwas wie ein einstufiges Modal. Entweder es ist da oder nicht. Besonders wenn es temporär ist und es keine Möglichkeit gibt, es „fortzusetzen“, kann man noch stärker von zustandslos sprechen
    Über die Jahre habe ich ziemlich viele Diskussionen gesehen, in denen „zustandsbehaftet“ in völlig unterschiedlichen Bedeutungen verwendet wurde, und in letzter Zeit hat das besonders stark zugenommen. Daher komme ich fast zu dem Schluss, dass sich kaum jemand auf die Bedeutung einigt und nur wenige sich dieser Tatsache bewusst sind
    Mich würde interessieren, was für euch eine zustandsbehaftete UI ist. Der Unterschied ist spannend

    • Ich stimme zu, dass der Ausdruck „zustandsbehaftete UI“ allgemein mehrdeutig ist, aber im Navigationskontext höre ich üblicherweise, dass eine Hierarchie als zustandslos und ein Activity-Stack als zustandsbehaftet bezeichnet wird
      In einer Hierarchie wie bei iOS muss jedes Kind genau einen Elternknoten haben; wenn man also nur die aktuelle Seite kennt, weiß man, was der „Zurück“-Button tun wird. Egal, wie man auf diese Seite gekommen ist, man geht in der Hierarchie eine Ebene nach oben zur Elternseite
      In einem Activity-Stack wie bei Android reicht die aktuelle Seite allein nicht aus; man muss wissen, wie man dorthin gekommen ist. Denn der „Zurück“-Button bedeutet, im Verlauf zurückzugehen
      Viele Websites unterstützen beides. Der Zurück-Button des Browsers ist zustandsbehaftet und navigiert durch den persönlichen Verlauf, während Navigation innerhalb der Seite, etwa Breadcrumbs, normalerweise zustandslos ist und nicht von dem konkreten Pfad abhängt, über den man zu dieser Seite gelangt ist. Ausnahmen gibt es natürlich. Viele Suchoberflächen können als zustandsbehaftet gelten, weil man beim Öffnen eines Eintrags und anschließender Rückkehr über die In-Page-Navigation nicht zur Elternseite, sondern zur vorherigen Suchanfrage zurückkehrt
    • Für mich bedeutet eine zustandsbehaftete UI, dass das Frontend Variablen verwendet, um sein eigenes Verhalten zu verwalten

  • Hier sehe ich eine ungenaue Formulierung. Gemeint ist der Teil: „Wenn man vom linken Bildschirmrand nach rechts wischt, entspricht das dem Drücken des Zurück-Buttons“
    Wenn man das selbst implementiert, sollte das keine Swipe-Geste sein, sondern eine Edge-Pan-Geste. Es muss ein interaktives Pan sein, das dem Finger folgt und abgebrochen werden kann; sonst fühlt es sich falsch an

    • Die iOS-App von X/Twitter und die Reddit-App scheinen dieses Problem zu haben
      Viel zu oft passiert es, dass ich gerade intensiv etwas eintippe, nur leicht den Rand des Telefons berühre und dann der ganze Kommentar weg ist
    • Von links nach rechts zu wischen, um zurückzugehen, ist eine schreckliche Art, einen „Zurück-Button“ zu implementieren, und sollte niemals gemacht werden. Es sollte immer einen echten Zurück-Button geben
      Der Grund ist, dass es Linkshänder gibt. Mit dem linken Daumen ist diese Bewegung weder natürlich noch bequem. Man kann die Richtung für Linkshänder auch nicht einfach umkehren. Wenn man von links nach rechts liest, wirkt ein Wischen nach rechts nämlich wie Vorwärtsgehen, nicht wie Zurückgehen
      Insgesamt mag ich Navigation per Wischgeste nicht. Auf iOS ist sie besonders schlecht. Wenn man von unten nach oben wischt, kommt irgendein Menü hoch, in dem zwar wirklich wichtige Dinge stecken, die man aber nicht findet, wenn man sie braucht, und das beim Scrollen auf Webseiten ständig versehentlich ausgelöst wird
      Allgemeiner gesagt ist iOS zu einem schrecklich komplizierten Betriebssystem verkommen, das ein Albtraum in der Navigation ist, und ich habe das Gefühl, Apple sollte UI/UX wieder ernst nehmen. Das Hauptproblem scheint die Erwartung zu sein, dass Telefone unzählige Aufgaben erledigen sollen, für die sie ursprünglich gar nicht geeignet sind
    • Sailfish OS handhabt das in allen Apps korrekt und konsistent
      https://sailfishos.org/
      Insgesamt fühlt es sich einfacher und besser an als iOS und Android

  • Wirklich gutes Material für jemanden, der mit visueller Software Schwierigkeiten hat
    Die Diagramme und die klaren Erklärungen sind hervorragend

  • Frank Rausch ist der Entwickler von „V for Wiki“, der besten Wikipedia-App.
    Wenn er also über iOS-Design und User Experience spricht, lohnt es sich zuzuhören.
    https://web.archive.org/web/20211223231349/https://v-for-wik...

    • Unabhängig davon weiß ich nicht, was mit V For Wiki eigentlich passiert ist.
      Ich habe es täglich genutzt, bis es eines Tages plötzlich nicht mehr funktionierte; als ich im App Store danach suchte, war es verschwunden. Das hat mich wirklich geärgert.

  • Es wäre schön, wenn man die Geste „vom linken Bildschirmrand nach rechts wischen entspricht dem Zurück-Button“ deaktivieren könnte.
    Beim horizontalen Scrollen, das auf Webseiten, die nicht auf den Bildschirm passen, häufig nötig ist, wird viel zu oft Zurück ausgelöst.

  • iOS macht das in dieser Hinsicht ziemlich gut.
    Eine typische iOS-Anwendung hat eine feste Architektur wie einen hierarchischen Baum mit mehreren Ebenen, und dank dieser strengen Struktur werden Navigationsoptionen vorhersehbar. Strukturelle Navigationsmuster geben Nutzern Sicherheit darüber, woher sie gekommen sind, wo sie sich in der Hierarchie befinden und wie sie zu ihrem ursprünglichen Ort zurückkehren.
    Unter Android führt die Zurück-Geste dagegen manchmal zur vorherigen Seite und schließt manchmal die App komplett. Das war so inkonsistent, dass ich nach 12 Jahren Android zu iOS gewechselt bin.

    • Das war von Anfang an so.
      Erstaunlich, dass ich ganze 12 Jahre durchgehalten habe, bevor ich beschloss, dass ich es nicht mehr ertrage.

  • Als ich zum ersten Mal mit der iPhone-Entwicklung begann, also etwa zu der Zeit, als das offizielle SDK gerade erschienen war, war Apple bei den Human Interface Guidelines sehr streng, und die Dokumentation dazu, was eine gute UI ausmacht und welche Standardmuster einzuhalten sind, war ebenfalls sehr gut.
    Mit dem Wechsel zu „Flat“ Design scheint das jedoch völlig verschwunden zu sein. Der Hauptgrund war meiner Ansicht nach, dass diese Dokumente schlicht nicht mehr sinnvoll waren.
    Früher war es sehr klar, etwa „mach Benutzerinteraktionen eindeutig sichtbar“; heute ist daraus geworden: „Das könnte anklickbar sein, einfach nur Text sein oder man muss vielleicht lange darauf drücken.“
 
genkino 2023-12-13

Hallo! Ich habe das auch erst erfahren, als ich diesen Artikel mit einem Kollegen geteilt habe: Nicht „Navigation“, sondern „Navi­gation“ gilt nach der koreanischen Rechtschreibung als Standardschreibweise. :) Da es sich um die Aussprache eines englischen Wortes handelt, ist es vielleicht etwas schwer zu sagen, was nun wirklich „richtig“ ist. Aber weil hier viele Leute mitlesen, dachte ich, ich hinterlasse vorsichtig einen Kommentar in der Hoffnung, dass es nach Möglichkeit in der Standardschreibweise geschrieben wird.
 
xguru 2023-12-14

Dieser Beitrag wurde von GPT-4 zusammengefasst. Mir ist aufgefallen, dass GPT „Navigation“ zwar meist korrekt verwendet, gelegentlich aber auch eine andere Schreibweise mischt. Ich habe das korrigiert, haha.