Etant donné que le traffic mobile dépasse générallement la moitié des visites, c'est conseillé de dessiner les interfaces utilisateur avec l'usage mobile en première considération.

Moi ça me rend triste.

Déjà parce que cette pratique est loin d'être généralisée... Entre les projets qui ont un "MODE MOBILE" (Gmail il n'y a pas si longtemps, très glorieux sur mobile) et les autres qui sont tout foireux dans leur apparence responsive (en cela qu'il manque des trucs dans le menu et tout ce genre de choses), c'est pas la fête à la Knackwurst.

Qui n'a pas entendu ou ne s'est pas déjà dit "ah non, pour faire ça je dois être sur un ORDINATEUR". Parce que même si on est dans l'âge du mobile first depuis plusieurs années, la réalité c'est qu'on ne peut toujours pas tout faire sur mobile.

Ensuite viennent tous les autres détails qui rendent l'expérience mobile détestable, comme les popups "HEY TU VEUX PAS INSTALLER L'APPLI REDDIT ELLE EST BIEN".

Le site medium.com est tellement aggressif avec ces pratiques qu'il y a une tendance visible sur la Twittosphere tech de créer son propre blog perso sur un site à part entière (comme ici par exemple, bienvenue!).

Il y a toujours le bon vieux "Demander la version ORDINATEUR" qui offre toujours une impression de grande productivité (NOT).

Je pense qu'écrire ses CSS en Mobile First est une bonne pratique. Le problème c'est pour tester tout ça de manière réaliste parce qu'on ne développe pas (encore? BLEURPS) sur mobile.

Ma méthode de test primordiale consiste à réduire graduellement la largeur de la fenêtre et s'assurer que ça ressemble à quelque chose avec toutes les tailles horizontales jusqu'à quelque part autour de 600px.

Je serais particulièrement intéressé d'entendre comment les vrais développeurs font.

La vitesse supérieure consiste à enclencher le mode responsif des navigateurs. D'expérience, ce mode responsif ne se comporte pas exactement comme un vrai mobile. Déjà, la barre d'adresse fait normalement partie du viewport et sur le mode responsif, elle n'est soit pas présente du tout soit hors des calculs de viewport.

Bien entendu, tester les gestures est également plutôt compliqué dans ce mode.

Au final, je découvre toujours des problèmes liés à la saisie de données. En effet, l'écran de mobile c'est déjà pas grand mais si on occupe plus de la moitié avec un clavier c'est encore pire.

J'en arrive générallement à écrire des "hacks" sales pour essayer de vaguement centrer l'écran sur le contrôle de formulaire qui est sélectionné. Et ça, c'est pas aussi simple qu'on pourrait le croire.

Je serais également intéressé de savoir comment vous vous y prenez. Le plus simple pour moi consiste à bricoler quelque chose qui devrait vaguement ressembler à ça (je vous l'écris en live à l'arrache sans le tester, je préviens):

const inputElement = document.querySelector('#inputElement');
let scrolledTo = false;

inputElement.addEventListener('focus', () => {
  if (document.documentElement.clientWidth <= 600 && !scrolledTo && inputElement.scrollIntoView) {
    scrolledTo = true;
    inputElement.scrollIntoView();
  }
});

// Ajouter un évènement pour le submit du formulaire qui reset
// scrolledTo à true

La fonction scrollIntoView est "expérimentale", mais nous n'avons besoin que de ce que caniuse.com appelle "support partiel" donc on est quelque part autour de 97% de compatibilité ce qui est plutôt pas mal.

En plus compatible il y a location.hash mais ça change la barre d'adresse et retire le focus du contrôle de formulaire qui était actif. Ce qui demande encore plus de hacking pour que ça fonctionne correctement.

C'était particulièrement la galère avec ma fonction de recherche pour plusieurs détails auxquels je n'ai pas du tout pensé au moment de la conception.

Il était nécessaire d'essayer de vaguement centrer l'écran sur le contrôle d'entrée de la recherche, puis il est apparu que sans évènement "submit" (il n'y avait pas d'élément <form> du tout au départ, erreur de jugement de ma part) le clavier ne se ferme pas quand on clique sur "Enter" (ou le bonton CHECK, je sais pas trop comment qu'on dit) et ce serait franchement pas mal d'avoir un moyen de facilement virer le clavier parce que... Il cache tous les résultats en fait lel (voir image plus loin).

En fait le mieux serait de systématiquement tester avec un vrai mobile ou éventuellement un simulateur (comme celui qui est dans Android Studio).

En dépannage rapide j'ai également trouvé un moyen obscur d'activer le clavier mobile (ainsi que la barre inférieure du navigateur) - uniquement pour Chrome - qui consiste à choisir un téléphone "supporté" (Nexus 5 ou 5X) puis cliquer sur l'icône qui permet de basculer l'orientation: vous devriez y trouver une option pour afficher le clavier:

Ah bah oui ça prend la moitié de l'écran et c'est censé être un progrès par rapport aux téléphones rabattables...

Et vous, comment vous faites pour tester l'affichage sur mobile?