Modèles de navigation iOS modernes

 (frankrausch.com)
6 points par GN⁺ 2023-12-13 | 3 commentaires | Partager sur WhatsApp
  • La navigation dans les apps iOS doit clairement distinguer la hiérarchie, les overlays et les flux internes aux vues afin que l’utilisateur comprenne sa position actuelle et le chemin de retour
  • Les modèles structurels se divisent en Drill-Down, Flat, Pyramid et Hub-and-Spoke, avec des significations différentes selon la transition d’écran : exploration d’arborescence, séparation par onglets, déplacement entre écrans frères ou retour à un hub
  • Les overlays servent à attirer l’attention, mais selon leur caractère modal et leur niveau de friction, ils bloquent plus ou moins l’écran arrière et impliquent des actions différentes pour l’utilisateur
  • La navigation intégrée doit rester dans une vue spécifique ou dans un modal, et être conçue pour que les changements d’état ou les flux Step-by-Step ne ressemblent pas à des déplacements hiérarchiques
  • Les onglets doivent être prévisibles, Cancel ne doit pas supprimer immédiatement les données, et dans les apps iOS il vaut mieux préserver des frontières claires entre hiérarchie, état et modalité plutôt que permettre des déplacements arbitraires

Les trois axes de la navigation iOS

  • Une app iOS est généralement composée de plusieurs niveaux d’une arborescence hiérarchique fixe
  • La navigation structurelle aide l’utilisateur à comprendre d’où il vient, où il se trouve dans la hiérarchie et comment revenir à sa position d’origine
  • Les overlays peuvent apparaître par-dessus n’importe quel contexte et même se superposer à d’autres overlays
    • Un overlay modal ne disparaît pas tant que l’utilisateur n’a pas agi et bloque l’interface en arrière-plan
    • Un overlay non modal ne bloque pas l’app
  • La navigation intégrée est mieux adaptée lorsqu’elle est contenue dans une vue spécifique ou dans un overlay modal, conformément au modèle structurel et spatial d’iOS

Modèles de navigation structurelle

  • Drill-Down

    • Le Drill-Down est un modèle de navigation par étapes dans une structure arborescente, généralement via des listes successives
    • Les transitions animées suggèrent un déplacement horizontal entre colonnes
      • Un déplacement vers la droite signifie qu’on descend plus profondément dans l’arborescence
      • Un déplacement vers la gauche signifie qu’on remonte vers un niveau supérieur
    • La navigation Drill-Down est de type modeless, donc une question comme l’enregistrement des modifications n’interrompt pas l’exploration hiérarchique
    • La Navigation Bar affiche le titre de l’écran courant, et le Disclosure indicator d’une ligne de liste indique qu’il est possible d’aller plus loin dans la hiérarchie
    • Le bouton Back fournit un chemin clair vers le niveau supérieur et, quand l’espace le permet, il vaut mieux utiliser le titre de l’écran parent comme libellé plutôt qu’un simple « Back »
    • Un geste de balayage depuis le bord gauche de l’écran vers la droite remplit le même rôle que le bouton Back
    • Une implémentation personnalisée doit proposer des transitions interactives et annulables, pilotées par un screen-edge pan gesture, comme dans iOS standard
    • Dans les langues qui se lisent de droite à gauche, la direction de navigation et la disposition des contrôles sont miroir selon le sens de lecture
    • L’arborescence peut être générée dynamiquement pour filtrer une base de données
      • Dans une app de musique, on peut atteindre le même album en Drill-Down depuis différents points de départ comme Artist, Album ou Genre, tout en combinant cela avec une interface de recherche
    • Le Drill-Down est une variante une colonne par écran des Miller columns du Finder de macOS

  • Flat

    • Le modèle Flat divise la hiérarchie au niveau racine et l’affiche via une tab bar
      • Sur iPad, cela peut être présenté dans une sidebar
    • Les éléments de la tab bar sont choisis autour des fonctions principales de l’app et structurent les attentes de l’utilisateur ainsi que son modèle mental de l’application
    • Un élément de la tab bar est toujours sélectionné, et ce choix actif détermine le contenu affiché dans la zone principale de l’app
    • L’élément actuellement sélectionné ne doit pas changer de manière programmatique sans interaction utilisateur, ni indirectement via un bouton situé ailleurs dans l’interface
    • La tab bar reste visible sur l’ensemble de l’app, sauf lorsqu’elle est temporairement masquée par une feuille modale
    • Les onglets peuvent servir de filtres ou de points d’entrée différents vers de grandes collections de contenu, comme des bibliothèques de musique, de vidéos ou de photos
    • Chaque section conserve son propre état de navigation dans sa sous-hiérarchie
    • Les éléments de la tab bar doivent avoir un comportement prévisible et ne doivent ni ouvrir une feuille ni déclencher une action
    • Le menu hamburger est une forme de navigation cachée, à l’opposé de la tab bar
      • Quand toute l’interface de navigation est dissimulée derrière une petite icône, sa découvrabilité baisse
      • Populaire sur iOS autour de 2015, il a ensuite été abandonné par de nombreux éditeurs après des études montrant que la tab bar était bien plus facile à repérer

  • Pyramid

    • Le modèle Pyramid permet de passer rapidement entre des vues sœurs au même niveau hiérarchique, sans revenir à l’écran parent
    • Dans les apps média, un geste de balayage horizontal est souvent utilisé pour naviguer entre ces vues sœurs
    • Des boutons peuvent aussi être utilisés, comme les chevrons Next Message et Previous Message dans l’app Mail d’iOS
    • L’app Photos d’iOS illustre ce modèle
      • On ouvre une photo en plein écran puis on balaie à gauche ou à droite pour parcourir les images adjacentes
    • Dans les petites collections, un page control permet de visualiser le nombre total d’éléments et la position de l’élément courant parmi ses pairs
    • Le sélecteur d’apps iOS implémente un modèle Pyramid pour passer rapidement d’une app à l’autre, plus vite qu’en repassant par l’écran d’accueil

  • Hub-and-Spoke

    • Le modèle Hub-and-Spoke convient quand le niveau supérieur de la hiérarchie contient de grandes collections sans lien direct entre elles
    • Pour passer d’une vue enfant en plein écran à une autre, il faut toujours revenir d’abord au hub
    • L’écran d’accueil d’iOS est une collection de toutes les applications installées et joue le rôle d’état neutre fiable du système d’exploitation
    • Le Home indicator, en bas de l’écran, constitue une issue de secours facile à apprendre et toujours disponible, qui ramène vers l’interface familière de l’écran d’accueil
    • Ce modèle est rarement utilisé à l’intérieur des apps
      • Il est rare qu’une app ait besoin en interne d’une séparation aussi forte que celle qui existe entre applications au niveau du système d’exploitation

Navigation par overlays

  • High-Friction Modal

    • Un overlay High-Friction Modal, comme une feuille ou une boîte de dialogue d’alerte avec plusieurs actions, bloque l’écran en arrière-plan jusqu’à ce que l’utilisateur prenne une décision
    • Lors de la rédaction d’un e-mail ou de la création d’un événement de calendrier, l’utilisateur doit pouvoir continuer avec Done ou Send, ou changer d’avis avec Cancel
    • Le bouton Cancel ne doit jamais supprimer directement un état ou des données
      • Dans une feuille modale, toucher Cancel doit toujours faire apparaître une boîte de dialogue de confirmation comme garde-fou
      • Dans une boîte de dialogue d’alerte, Cancel ne doit jamais être une action destructive
    • Les modaux se concentrent sur l’accomplissement d’une tâche spécifique et autonome, comme la rédaction d’un e-mail ou l’ajout d’un événement au calendrier

  • Low-Friction Modal

    • Un Low-Friction Modal, comme une feuille, un menu ou un popover, bloque le reste de l’app sans pour autant imposer une décision binaire
    • Il doit pouvoir être fermé facilement, par exemple via un bouton de fermeture ou en balayant la feuille vers le bas
    • Un context menu ou un popover disparaît quand on touche à l’extérieur
    • Une boîte d’alerte avec un seul bouton OK est facile à fermer, mais une faible friction n’est pas synonyme d’absence de friction
    • Les alertes à action unique sont à éviter autant que possible
      • Elles interrompent le flux utilisateur et peuvent souvent être remplacées par du texte inline ou une notification non modale

  • Non-Modal

    • Un overlay Non-Modal recouvre une partie de l’écran sans bloquer l’interface en arrière-plan
    • Comme il n’est pas bloquant, sa friction est faible voire nulle
    • Il peut apparaître en réponse à un déclencheur externe à l’app, comme une notification du système d’exploitation
    • Lorsqu’il disparaît automatiquement, il doit fournir des informations contextuelles visibles en un coup d’œil avec un minimum de perturbation
    • Les overlays non modaux temporaires peuvent offrir des interactions facultatives
      • On peut toucher une notification, ou balayer l’indicateur de volume avant sa disparition pour ajuster le volume
    • Un overlay qui n’apparaît ni ne disparaît automatiquement et ne bloque pas le reste de l’application peut être appelé une palette

Navigation intégrée

  • State Change

    • Une même vue peut avoir plusieurs états
    • Une vue liste peut, sans donner l’impression d’avoir changé de place dans la hiérarchie, passer par des états empty, loading ou populated
    • Il faut vérifier qu’un changement d’état n’est en réalité ni hiérarchique ni modal
    • Les changements d’état sur place doivent éviter les transitions plein écran
    • Les exemples incluent le mode d’édition d’une liste, l’interface d’un navigateur web, une carte pouvant être déplacée, ou une image zoomable
    • Les options d’affichage modifient seulement la manière de présenter le contenu, sans changer la position de l’utilisateur
      • Le passage entre list view et thumbnail view consiste à basculer entre deux visualisations d’une même information dans un même contexte

  • Step-by-Step

    • Le modèle Step-by-Step relie une série d’écrans dans un flux linéaire, comme une visite guidée, un parcours de configuration ou un tutoriel d’onboarding
    • Les processus qui demandent beaucoup de saisie, comme le paiement dans une boutique en ligne, nécessitent également souvent plusieurs étapes
    • Avancer ou reculer dans cette séquence ne change pas de niveau hiérarchique, ce qui distingue ce modèle du Drill-Down
    • Il est préférable de présenter une séquence Step-by-Step dans un overlay modal
      • Dans ce contexte, le bouton Back n’a pas le même rôle que dans un Drill-Down hiérarchique
    • Le processus se termine généralement par un bouton Done ou Close, qui ferme aussi le modal qui le contient
    • Le nombre d’étapes et le parcours peuvent varier selon les options choisies
    • Wizard et assistant sont d’autres noms de ce modèle
    • Un processus Step-by-Step peut sembler fastidieux
      • Si l’on s’attend à ce que les utilisateurs l’effectuent souvent, on peut envisager de fusionner plusieurs étapes en différents états d’une seule vue afin d’augmenter la densité d’information et de réduire les changements de contexte

  • Content-Driven

    • La navigation Content-Driven fait passer instantanément l’utilisateur vers une autre page ou vue via des hyperliens ou des boutons
    • La navigation web dans un navigateur fonctionne de cette manière
    • Dans les apps iOS, il vaut mieux éviter ce modèle sauf pour les apps qui affichent de l’hypertexte, les jeux immersifs ou des contenus non linéaires similaires
    • Si une app doit afficher du contenu hypertexte, on peut envisager de l’intégrer dans une interface de navigateur avec des contrôles précédent/suivant
    • Les changements d’état d’une interface de navigateur indépendante sont plus faciles à comprendre qu’un déplacement inattendu dans la hiérarchie générale de l’application
    • Les liens peuvent être utilisés pour passer d’une app à l’autre
    • Les Deep Links utilisent un URL scheme ou des Universal Links associés à un domaine pour amener l’utilisateur depuis une app ou un site web vers un niveau profond d’une autre app

Références

À lire aussi

3 commentaires

 
GN⁺ 2023-12-13
Avis sur Hacker News

  • Cela a déjà été beaucoup dit, mais c’était l’une des nombreuses raisons pour lesquelles Apollo était bien meilleur que l’app officielle de Reddit dans l’usage de ce genre de patterns
    La navigation, les gestes et les comportements étaient cohérents, et ce n’est pas non plus un concept difficile. Il suffit d’y prêter assez d’attention pour les respecter, mais il y a tellement d’apps qui ne le font pas que c’est décourageant

    • C’est la différence entre une app optimisée pour être une bonne app, et une app optimisée pour l’engagement et les ventes
      C’est un peu comme un supermarché qui change régulièrement l’emplacement de ses rayons. Si la navigation, les gestes et les comportements sont cohérents, l’utilisateur peut obtenir ce qu’il veut trop efficacement et repartir trop vite
    • Je n’ai jamais vu d’app aussi déroutante que l’app officielle de Reddit, et je pense avoir une intelligence moyenne
      Je gère un subreddit de 30 000 personnes, donc je dois pouvoir utiliser Reddit sur mon téléphone, mais c’est quasiment impossible. Trop d’actions sont nécessaires pour chaque tâche, et comme on ne sait jamais où on se trouve, c’est vraiment nul
    • La manière dont Steve Huffman a saboté Reddit en éliminant Apollo est vraiment honteuse
      J’avais déjà arrêté Reddit il y a quelques années, mais ça a été le coup de grâce
    • L’app officielle de Reddit est l’une des rares apps dans lesquelles je me perds régulièrement
      Revenir à l’écran principal demande tellement d’énergie mentale que je finis simplement par la forcer à quitter puis la rouvrir
    • Même dans Apollo, on pouvait ouvrir des couches comme des subreddits, des profils utilisateur ou des posts en les empilant à l’infini, ce qui pouvait devenir confus
      Après seulement quelques niveaux, revenir au premier écran devient assez pénible, car il faut continuer à balayer ou appuyer sur retour jusqu’à y revenir. Il existe peut-être un geste magique que je ne connais pas

  • L’expression « pattern de navigation iOS » me fait tiquer. Il n’y a pas vraiment de pattern, et c’est l’un des pires aspects d’iOS par rapport à Android
    Sur Android, revenir en arrière est simple et peut avoir plusieurs significations. Cela fait plus d’un an que j’utilise iOS, et je tente à l’aveugle l’un des deux « patterns » de retour avant de devoir chercher un bouton hors de portée. Et parfois, ça ne marche toujours pas
    Il ne faut pas laisser ce pattern aux développeurs, il faut le corriger au niveau du système d’exploitation. Les développeurs ne veulent pas que l’utilisateur quitte une partie de leur app. Il suffit d’essayer de revenir en arrière dans Instagram Reels

    • Le fait que « sur Android, revenir en arrière est simple et peut avoir plusieurs significations » est pour moi l’un des pires aspects d’Android
      Le bouton retour n’est absolument pas cohérent dans ce qu’il fait. Même en tant que développeur, je me demande parfois ce qu’il est censé faire dans une situation donnée. Doit-il revenir à l’écran précédent, ou remonter d’un niveau dans une navigation en profondeur ? Parfois les deux se confondent, mais pas toujours
      Tantôt il remonte d’un niveau dans la structure de navigation, tantôt il revient à l’écran précédent, tantôt il ferme une boîte de dialogue, et il peut même fermer l’app. Selon le contexte, n’importe laquelle de ces actions est possible, et si plusieurs s’appliquent, on ne sait pas laquelle sera choisie. Le seul moyen de le découvrir est d’appuyer dessus et de voir ce qui se passe
      Je déteste les éléments d’interface ambigus. Quand je clique sur quelque chose, je veux savoir quelle action va être exécutée
    • L’expérience de la pile d’activités d’Android est ce que je préfère dans la conception du système
      Elle crée une cohérence profonde qui fait que la navigation n’est pas pénible. J’aurais vraiment aimé qu’iOS ait la même chose en standard
      La pile d’activités fonctionne à travers les apps, donc même quand plusieurs apps coopèrent dans une même tâche, le geste retour ramène toujours à l’écran immédiatement précédent
    • Je ne comprends pas pourquoi le bouton retour d’iOS est autant dispersé
      Parfois il est en haut à gauche, parfois en bas à gauche, parfois en bas à droite, et certaines apps doivent sûrement le mettre ailleurs
      Sur Android, il y a un bouton retour du système d’exploitation qui reste toujours accessible, même à une main. Cette approche est largement supérieure
    • L’idée de « ne pas laisser ce pattern aux développeurs, mais le corriger au niveau du système d’exploitation » est probablement quelque chose qu’Apple n’a pas fait parce que c’est pratiquement impossible
      Par exemple, si l’on peut modifier le contenu d’une vue, on peut aussi tout effacer et le remplacer par un contenu entièrement nouveau. Si cela se produit à la suite d’une action de l’utilisateur, cela revient en pratique à « naviguer vers un nouvel écran ». Mais si le développeur ne fait que modifier le contenu de la vue actuelle au lieu d’utiliser l’appel API du système d’exploitation proposé, createNewView, alors un geste au niveau du système d’exploitation ne pourra pas fonctionner
      Cela dit, Apple pourrait imposer l’usage de cette API du système d’exploitation comme condition de validation. Mais même dans ce cas, ce qui constitue une « nouvelle vue sur laquelle on peut revenir » et ce qui n’est qu’une « vue existante dont le contenu a changé » reste à mon avis assez subjectif
    • Le menu de partage est horrible. Je ne vois pas comment quelqu’un est censé comprendre ça
      Il montre des contacts, des applications, des éléments verticaux, des éléments horizontaux, puis d’autres éléments en bas, et il faut en plus deviner qu’il faut tirer vers le haut pour tout voir. Son emplacement varie selon les apps, et son icône n’a rien à voir avec « partager » ou « copier/coller »
      Les gens qui ont grandi avec les smartphones finissent comme toujours par s’y adapter. Si l’on n’avait pas déjà plus de 40 ou 50 ans quand ça a été introduit, on peut généralement s’y habituer. La plupart des choses modernes sont terriblement conçues et souvent instables. AppleTV aussi, et on pourrait parler du changement de mot de passe Wi‑Fi. J’en ai besoin pour contourner des bugs, et je ne comprends pas pourquoi appuyer sur l’interrupteur marche/arrêt ne redémarre pas l’appareil

  • Je ne sais pas si c’est suffisamment lié, mais sur Mac et désormais sur iPadOS(https://useyourloaf.com/blog/ipad-customizable-toolbars/), les contrôles de barre d’outils intégrés prennent en charge un haut niveau de personnalisation
    On peut l’essayer dans Finder ainsi que dans plusieurs autres apps natives
    Les widgets intégrés puissants sont un élément sous-estimé du bureau Mac, et c’est aussi un point qui m’inquiète avec la domination de SwiftUI. C’est aussi un gros atout sur iOS, mais cela se voit relativement moins parce qu’il est trop courant que les apps veuillent imposer leur propre design
    Mais sauf erreur de mémoire, il me semble que les anciennes apps iOS prenaient en charge nativement la personnalisation de la barre d’onglets, non ? C’est évidemment différent d’une barre d’outils, mais permettre d’éditer l’ordre des onglets et les onglets réellement affichés donnait l’impression d’un équivalent conceptuel à la personnalisation intégrée de la barre d’outils. Cela dit, je n’ai plus vu ça depuis des années
    D’après la documentation, c’est toujours là. Je me demande si quelqu’un connaît encore des apps qui utilisent ce modèle : https://developer.apple.com/documentation/uikit/uitabbarcont...
    Quoi qu’il en soit, les barres d’onglets sont chouettes. C’est la manière dont fonctionnent la plupart des apps Apple TV que j’ai utilisées, et la cohérence de l’expérience est excellente

    • Au début, il était assez courant de réorganiser les onglets et de n’ajouter ou retirer que ceux qu’on voulait
      À l’époque où Facebook était encore bien, probablement vers iOS 7, je me souviens qu’on pouvait modifier ainsi des éléments comme le chat, le fil, les notifications et les groupes
    • Plusieurs apps Apple comme Apple Store et Music utilisent une barre d’onglets en bas, mais sans personnalisation
      En dehors d’Apple, les apps qui me viennent à l’esprit ont toutes basculé depuis longtemps vers des menus hamburger difficiles à découvrir
    • Sur Mac, j’aimerais que davantage d’apps utilisent la barre d’outils standard
      Les possibilités de personnalisation sont intéressantes, mais elles sont presque introuvables dans les implémentations maison
    • UITabBar a toujours été péniblement limité du point de vue du développeur en matière de personnalisation, et très peu de projets se sont souciés de laisser l’utilisateur le modifier lui-même
      J’ai l’impression qu’Apple a tellement verrouillé l’apparence que tout le monde a fini par le remplacer par autre chose
    • La possibilité de réorganiser la barre d’outils dans des apps iOS comme Music me manque encore
      Sur Apple Music, il y a deux onglets que je n’utilise littéralement jamais. J’aimerais pouvoir aller directement aux playlists et aux albums

  • Le premier point, « la navigation en drill-down n’a pas d’état », me paraît inversé
    L’écran N dépend de ce qui a été fait auparavant, et on peut même y revenir plus tard, donc c’est une structure avec énormément d’état. Pour être utile, il faut réellement suivre l’état interne. Par exemple, le contenu d’une liste dépend de l’état N-1, sinon ce serait affreux
    Une UI sans état, ce serait quelque chose comme une modale à une seule étape. Soit elle est là, soit elle ne l’est pas. On peut encore plus la considérer comme sans état si elle est transitoire et qu’il n’existe aucun moyen de la « reprendre »
    Depuis des années, j’ai vu pas mal de discussions utiliser « avec état » dans un sens complètement différent, et récemment en particulier cela a explosé. J’en arrive presque à la conclusion que presque personne ne s’accorde vraiment sur ce que cela veut dire, et que peu de gens en ont conscience
    Je suis curieux de savoir ce qu’est, pour vous, une UI avec état. Cette différence est intéressante

    • Je suis d’accord pour dire que l’expression « UI avec état » est généralement ambiguë, mais dans le contexte de la navigation, j’entends souvent qu’on appelle la hiérarchie sans état et la pile d’activités avec état
      Dans une hiérarchie comme sur iOS, chaque enfant doit avoir exactement un parent, donc si l’on connaît seulement la page actuelle, on sait ce que fera le bouton « retour » : il remontera au parent, un niveau au-dessus dans la hiérarchie, quelle que soit la manière dont on est arrivé sur cette page
      Dans une pile d’activités comme sur Android, connaître uniquement la page actuelle ne suffit pas : il faut savoir comment on y est arrivé. Le bouton « retour » signifie revenir en arrière dans l’historique
      Beaucoup de sites web prennent en charge les deux. Le bouton retour du navigateur a un état et parcourt l’historique personnel, mais la navigation dans la page, comme le fil d’Ariane, est généralement sans état et ne dépend pas du chemin précis emprunté pour atteindre cette page. Il y a bien sûr des exceptions. Beaucoup d’interfaces de recherche peuvent être considérées comme avec état, car si on entre dans un élément puis qu’on revient via la navigation interne de la page, on retourne non pas à la page parente mais à la requête précédente
    • Pour moi, une UI avec état, c’est quand le frontend utilise des variables pour gérer son propre comportement

  • Je vois ici une formulation inexacte. Le passage qui dit « balayer de la gauche de l’écran vers la droite équivaut à appuyer sur le bouton retour »
    Si on l’implémente soi-même, cela ne devrait pas être un geste de glissement mais un geste de pan depuis le bord. Cela doit être une interaction de pan qui suit le doigt et qu’on peut annuler, sinon la sensation n’est pas la bonne

    • Il me semble que les apps iOS de X/Twitter et Reddit ont ce problème
      Trop souvent, j’écris quelque chose avec application, je frôle à peine le bord du téléphone, et tout le commentaire disparaît
    • Glisser de gauche à droite pour revenir en arrière est une manière horrible d’implémenter un « bouton retour » et cela ne devrait jamais être fait. Il devrait toujours y avoir un vrai bouton retour
      La raison, c’est que les gauchers existent. Ce n’est ni un mouvement naturel ni un mouvement confortable avec le pouce gauche. On ne peut pas non plus inverser la direction pour les gauchers. Si l’on lit de gauche à droite, un glissement vers la droite donne l’impression d’aller vers l’avant, pas vers l’arrière
      De manière générale, je n’aime pas naviguer par gestes de glissement. Sur iOS, c’est particulièrement mauvais. Un glissement du bas vers le haut fait apparaître un menu qui contient des choses importantes, mais impossible de les trouver quand on en a besoin, alors qu’il se déclenche sans arrêt par erreur quand on fait défiler une page web
      Plus généralement, j’ai l’impression qu’iOS a régressé vers un système d’exploitation terriblement complexe, un cauchemar à naviguer, et qu’Apple devrait recommencer à prendre l’UI/UX au sérieux. Le problème principal semble être qu’on attend désormais des téléphones qu’ils gèrent une multitude de tâches pour lesquelles ils ne sont pas adaptés au départ
    • Sailfish OS gère cela correctement et de manière cohérente dans toutes les apps
      https://sailfishos.org/
      Globalement, je le trouve plus simple et meilleur qu’iOS et Android

  • C’est une très bonne ressource pour les personnes qui ont du mal avec l’aspect visuel du logiciel
    Les diagrammes et les explications claires sont excellents

  • Frank Rausch est la personne qui a créé « V for Wiki », la meilleure app Wikipedia
    Donc, quand il parle de design iOS et d’expérience utilisateur, ça vaut la peine d’écouter ce qu’il a à dire
    https://web.archive.org/web/20211223231349/https://v-for-wik...

    • À part ça, je ne sais vraiment pas ce qui est arrivé à V For Wiki
      Je l’utilisais tous les jours, puis un jour ça a soudainement cessé de fonctionner, et quand j’ai regardé sur l’App Store, l’app avait disparu. J’étais vraiment dégoûté

  • Ce serait bien de pouvoir désactiver le comportement « glisser de la gauche vers la droite depuis le bord gauche de l’écran équivaut à appuyer sur le bouton retour »
    Trop souvent, en faisant un défilement horizontal sur une page web mal adaptée à l’écran, ça déclenche un retour en arrière

  • iOS gère plutôt bien cet aspect
    Une application iOS typique a une architecture fixe, comparable à un arbre hiérarchique à plusieurs niveaux, et cette structure rigide rend les choix de navigation prévisibles. Les schémas de navigation structurelle donnent à l’utilisateur l’assurance de savoir d’où il vient, où il se situe dans la hiérarchie et comment revenir à l’endroit où il était au départ
    À l’inverse, sur Android, le geste de retour ramène parfois à la page précédente, et parfois ferme complètement l’application. C’est tellement incohérent que, après 12 ans sur Android, je suis passé à iOS

    • Ça a toujours été comme ça
      C’est étonnant d’avoir tenu pas moins de 12 ans avant de décider qu’on ne pouvait plus le supporter

  • Quand j’ai commencé à développer pour iPhone, au moment où le SDK officiel venait juste de sortir, Apple était très strict sur les Human Interface Guidelines, et la documentation sur ce qui faisait une bonne UI ainsi que sur les patterns standards à suivre était excellente
    Mais avec le passage au design « flat », tout cela semble avoir complètement disparu. À mon avis, la raison principale est que ces documents n’avaient tout simplement plus vraiment de sens
    Avant, c’était très clair, du genre « faites en sorte que les interactions utilisateur soient clairement visibles », alors que maintenant c’est devenu « ceci est peut-être cliquable, ou peut-être juste du texte, ou peut-être qu’il faut faire un appui long »
 
genkino 2023-12-13

Bonjour ! Je l’ai appris moi aussi en partageant cet article avec un collègue. Il paraît qu’en coréen, la forme standard conforme à l’orthographe est naebigeisyeon plutôt que nebigeisyeon. Comme il s’agit d’une transcription de l’anglais, il est vrai qu’il peut être un peu délicat d’affirmer catégoriquement laquelle est « correcte ». Mais comme c’est un endroit que beaucoup de gens consultent, je me suis dit qu’il serait préférable, tant qu’à faire, d’utiliser la forme standard, donc je me permets de laisser ce petit commentaire.
 
xguru 2023-12-14

Ce texte est un résumé réalisé par GPT-4. Il semble que GPT utilise correctement « navigation », mais emploie parfois aussi « naviagation » de manière interchangeable. Je l’ai corrigé haha.