Ionic et développement mobile : bonnes pratiques tests/ux/performances

icon Tags de l'article : , , , ,

Aout 28, 2019
Hello,

Quelques petites astuces / bonnes pratiques en vrac pour celles et ceux qui se mettent à Ionic ou au développement mobile en général.

Déjà, voici comment je teste ce que je développe pour mobile (Ionic) :
  • Je teste avec Firefox en général, car c'est le navigateur le plus rigoureux (si ça marche sur Firefox, y'a 99,9% de chances que tout fonctionne nickel sur Chrome et Safari)
  • Je teste avec 3 largeurs d'écran : 360, 375 et 415. (360 = Galaxy S, 375 = iPhone 6+, 415 = grands smartphones 6")
  • Je teste avec 320px de large. Ca ne doit pas être parfait, mais ça doit être utilisable (pour les utilisateurs de vieux smartphones)
  • Je teste avec 600/700px de large. L'idée est que ce soit exploitable sur tablette / PC.
  • Je teste ensuite sur Chrome et Safari, pour être sûr
  • Je teste, enfin, sur iOS puis Android

Avec ce process de test, j'ai rarement de mauvaises surprises. En développant via Chrome j'ai eu plusieurs soucis sur iPhone. En développant sur Safari j'ai eu des soucis sur Android. En commençant par Firefox, j'ai un truc ultra stable.

Et pourquoi ces tests de tailles ? Ben déjà ça apprend à maitriser le flex et les alignements.
Ensuite ça permet d'avoir un truc qui pourrait, sur un coup de tête, être sorti sur tablette ou en build web.
Enfin, du CSS bien conçu fonctionnera dans toutes ces configurations... et du CSS bien conçu diminue les risques que notre application soit inexploitable sur un vieux smartphone ou un smartphone pourri.

Quelques astuces CSS/UX :
  • Toujours les tailles en REM, on évite les pixels.
  • Eviter les éléments clickables de moins de 40px de haut
  • Un article ultra clair sur comment bien créer un formulaire pour application mobile
  • Chaque élément avec lequel on peut interagir doit le montrer via son style (encadré, souligné, bordure, ombre, ...)
  • Pensez à checker d'autres applications et regardez comment elles font les choses.
  • Jamais de listes déroulantes, on est sur mobile !
  • Privilégiez une UI simple réutilisant les composants tout faits d'Ionic (qui sont pensés pour iPhone et Android) plutôt que de faire du maison qui va déstabiliser et gêner ... tout le monde.
  • Pas de couches de popups ! Si vous avez besoin de faire ça, privilégiez plutôt un formulaire en étapes.
  • Pensez navigation de gauche à droite (j'avance vers la droite, je reviens en arrière vers la gauche). Surtout avec les derniers iphones qui permettent le retour via un scroll à gauche.
  • Si vous avez un doute sur une façon originale de faire quelque chose (par exemple le bouton retour en haut à droite), essayez de trouver une application utilisée en masse qui fait ça. Si vous n'en trouvez pas, c'est que c'est probablement une mauvaise idée.
  • Pensez mobile et utilisation du pouce ! On ne met pas d'onglets en haut. On ne met pas de burger menu en bas à gauche. On évite d'avoir 6+ onglets. Scroller est naturel sur mobile, mais évitez les scroll verticaux/horizontaux mélangés. etc.
  • Réfléchissez aux cas d'utilisations critiques de votre application. Designez votre application autour d'eux. Ajoutez ensuite les options pour les scénarios moins critiques, sans rendre l'application trop compliquée.
  • Si vous avez des doutes, checkez les composants ionic et autres projets de démo Ionic. Vous tomberez probablement sur un exemple pertinent pour votre besoin.
  • Attention au routing en Ionic 4. Pensez le comme un routing Web. Exemple : j'ai un onglet Settings, dedans j'ai une option mon profil. Le lien de la page profil doit être tabs/tab-settings/my-profile et pas /my-profile.
  • Privilégiez les modales quand vous êtes sur une action où le routing n'aurait aucun sens (exemple : la modification de votre nom/prénom dans l'application, vous ne feriez pas un routing pour ça, si la personne refresh, elle est censée retomber sur son profil, pas sur une "page" de modification de son profil)
  • Chaque composant doit gérer ce à quoi il ressemblera. Le parent ne doit gérer que le positionnement. Si le parent veut donner un rendu différent (exceptionnellement), on ajoute une classe sur le composant et dans ce composant, on exploite cette classe pour appliquer un CSS différent.
  • Pensez à tester votre application avec les polices augmentées sur un smartphone (par défaut c'est 16px, mais si la personne règle 20px dans son Android, votre application sera-t-elle toujours utilisable ?)

Enfin niveau perfs :
  • Evitez les trucs "réutilisables/bidouilles" pour "gagner du temps". Genre les composants transverses qui gèrent le ion-header et ion-content avec le titre et des booléens pour les boutons à afficher. Ca ruine les perfs en ionic 4.
  • ChangeDetection: Onpush sur TOUS vos composants. Si vous avez besoin de dynamisme : Observables et | Async.
  • Pendant vos tests n'hésitez pas à mettre un console log sur vos actions de services et composants en bas des grappes. Si vous voyez que les appels se font par 2, 5, 10 ou 100, vous avez un souci de perfs potentiel.
  • N'oubliez pas qu'Ionic c'est du HTML/JS embarqué et affiché via une webview. Evitez tout ce qui peut être facultatif mais qui boufferait les performances (par exemple charger une carte par défaut alors que 90% de vos utilisateurs se fichent de la carte)
  • On évite les calculs de tailles / rendu / affichage en typescript, il faut essayer de tout faire en CSS
  • takeUntil($onDestroy) pattern sur les souscriptions, on ne doit pas avoir d'accumulation de souscriptions à l'infini.
  • Si vous voulez gérer l'accessibilité (couleurs, tailles, etc.) ajoutez une classe CSS à la racine de votre application, et dans vos composants (ou dans un CSS spécifique) overridez l'affichage de base en CSS si la classe CSS est présente à la racine (évitez d'appeler un service dans chaque composant).
  • Le pattern Smart vs Dumb reste une référence : https://medium.com/@jtomaszewski/how-to-write-good-composable-and-pure-components-in-angular-2-1756945c0f5b
  • Même dans une page qui ne contient presque rien, on met un container qui contiendra un composant. (réutilisabilité / performances / sécurité)
  • Attention à ngrx. C'est génial, mais il ne faut pas en abuser. C'est là pour gérer des états au niveau de l'application. Evitez de tout faire avec, sinon non seulement vous allez compliquer à mort la relecture du code, mais en plus vous perdrez un temps monstre à développer (car à chaque refresh vous perdez tout votre state).

Enfin je finirais cette note sur le point le plus important pour moi : Pensez votre code pour qu'il soit ultra simple à relire, reprendre et débugguer par un autre développeur.
Si c'est trop compliqué, y'a un souci.
Si vous êtes obligé de commenter le code, y'a un souci.
Si vous découpez des trucs en des tas de morceaux interdépendants, y'a un souci.
Si un dev qui doit reprendre votre code est obligé de venir vous voir pour comprendre le code, y'a un souci.

Egalement, n'oubliez pas une chose : vous n'aurez pas deux chances de faire une bonne première impression.
Si vous sortez une application à la va vite, sans faire de tests utilisateurs, avec une mauvaise UX, votre application va accumuler les notes négatives et ce sera la merde direct.

Privilégiez : Fluidité = UX > UI > masse fonctionnalités.
Les applications mobiles doivent surtout séduire et être agréables à utiliser. Mais si vous accumulez trop de fonctionnalités et que votre application devient lente/inutilisable/moche, vous perdrez bien plus d'utilisateurs que si vous aviez laissé moins de features mais plus d'UX/fluidité. Largement.

Un dernier ultime rappel : une bonne UX c'est comme une blague. Si vous devez l'expliquer, c'est qu'elle n'est pas bonne.
Donc si votre application a besoin d'un tutoriel de 20 pages pour être utilisée... posez vous des questions.

Bon dev à toutes/tous !