1485 sujets

Web Mobile et responsive web design

Modérateur
Bonjour,

Testez-vous vos sites en fenêtre étroite, et si oui, en général jusqu'à quelle taille allez-vous dans vos tests ?

Votre avis m'intéresse !

Accessoirement, vous prévoyez quoi en pratique pour les fenêtres très étroites ?
- rien (au risque d'un design qui explose en dessous d'une certain taille),
- un min-width sur le body et/ou des overflow:auto (au risque de devoir scroller horizontalement un peu trop souvent),
- des hyphens et des word-breaks (au risque que cela devienne difficilement utilisable),
- autre chose

Amicalement,
salut
- mes grandes images sont en 3 tailles selon l'écran
- je modifie aussi la taille des marges, plus aéré pour les grands écrans
- je vérifie jusqu'a mini 320 x 560 v
- je met en display:none des éléments pas indispensable sur smartphone
- j'avais aussi parfois carrément bloqué tout l'affichage si vertical avec un picto invitant a tourner le smartphone en horizontal ou tout apparait
- j'aggrandi le font-size de 120% pour les grands écrans
- overflow-x:hidden sur tout parce que certaines images sont affichées plus grandes sur les smartphone

a+
Administrateur
Bonjour,

d´un point de vue accessibilité, il est demandé à ce qu´il n´y ait pas d´ascenseur horizontal avec une largeur de 320px (donc je teste en 320×480px), au niveau de la page.
Que l´on puisse consulter le site dans les 2 orientations (un device vissé à un fauteuil, ça ne se tourne pas aisément...). Test : dans Firefox en vue adaptative 320×480, il y a un bouton pour tourner de 90°

Une fois que c´est bon, comme mes interlocuteurs touchent un minimum en CSS, s´arranger pour que les titres et autres mots longs s´affichent dans le viewport (mieux vaut un mot coupé en 2 un peu nimp´ que coupé à droite et illisible !).

Niveau design, ça a intérêt à être parfait en 360, 375 et 414px de large : Android, iPhone...
Mon vieux smartphone en 360px de large (vieille version d´Android aussi) se fait passer pour 320px parce que j´ai agrandi la taille de texte d´un seul cran, enfin c´est ce que https://www.mydevice.io me dit. Ce doit pas être le seul je suppose...
Salut,

je "descend" jusqu'à l'iPhone 5-SE 320x568. C'est ok. En dessous, qui a un appareil, surtout connecté au net ?
Moins efficaces sur un petit écran, je supprime les fontes spéciales en mode mobile, pour alléger le chargement. Je le fais avec les @media pour isoler @font-face et le rendre opérant seulement sur grand écran.
Je ne fais rien que tu ne connaisses pas et je laisse flexbox ou grid se débrouiller avec les dimensions d'écran et toutes les valeurs en em, rem ou vw. Mais un @media landscape peut arranger des situations délicates.
Je dirai de nouveau que mis à part pour regarder des vidéos ou jouer, la majorité des personnes que je vois dans les Métros ou trains ne retourne pas son mobile. Alors, je ne vais pas m'acharner sur le mode paysage d'un iPhone 5-SE. Un mobile en mode paysage, c'est un faux desktop, ridicule.

Avis personnel pouvant être contredit.
Modérateur
Bonjour,

Merci à tous pour vos réponses. J'en retiens que dans le monde de 2024, tester jusqu'à une largeur de 320px semble faire consensus. Par contre, la taille de la police de caractères utilisée n'a pas l'air de vous préoccuper.

drphilgood a écrit :
overflow-x:hidden sur tout parce que certaines images sont affichées plus grandes sur les smartphone
Ça me parait risqué. Il faut être sacrément sûr qu'il n'y aura pas de dépassement quoi que configure l'utilisateur sur sa machine, sinon ce qui dépasse sera tout simplement inaccessible.

Felipe a écrit :
D´un point de vue accessibilité, il est demandé à ce qu´il n´y ait pas d´ascenseur horizontal avec une largeur de 320px (donc je teste en 320×480px), au niveau de la page.
J'imagine que ça vient de https://www.w3.org/WAI/WCAG21/Understanding/reflow.html ou d'un équivalent.

Excellente règle, mais il semble qu'il faille aussi tester le fait que l'utilisateur puisse changer la taille par défaut de la police de caractères (zoom texte seul sur firefox, ou changement de la taille de la police dans les paramètres du navigateur) jusqu'à 200%. Voir https://www.w3.org/WAI/WCAG21/Understanding/resize-text

Si on utilise beaucoup de rem ou em, il me semble que les contraintes seront (plus ou moins) les mêmes qu'en 160px de large avec une taille de police "normale".

Je n'ai jamais su trop me positionner par rapport à ça.

Felipe a écrit :
Mon vieux smartphone en 360px de large (vieille version d´Android aussi) se fait passer pour 320px parce que j´ai agrandi la taille de texte d´un seul cran, enfin c´est ce que https://www.mydevice.io me dit. Ce doit pas être le seul je suppose...
C'est en fait "un peu pareil partout" dès qu'on utilise le zoom (pas le zoom texte seul, mais le zoom qui grossit tous les éléments) sur n'importe quel navigateur. Si par exemple on essaie de récupérer la largeur des éléments via js, ça donnera la taille qu'on voit à l'écran divisée par le zoom. Plus généralement, le zoom change la taille physique du pixel "css", ce qui j'en conviens ne devrait pas être le cas quand on change la taille par défaut de la police , qui elle ne devrait changer que la valeur du rem, et alors que c'est ce qui semble se passer sur ta machine. À éclaircir !

Bongota a écrit :
Je "descend" jusqu'à l'iPhone 5-SE 320x568. C'est ok. En dessous, qui a un appareil, surtout connecté au net ?
Je suis d'accord avec toi sur le fait qu'en pratique, y en a plus beaucoup en 2024 qui ont des écrans de moins de 320px de large. Mais le problème, c'est si l'utilisateur a besoin d'utiliser une police par défaut plus grande que les 16px habituels (ou éventuellement une autre valeur selon la configuration par défaut sortie usine des outils qu'on utilise). Si tu testes ton design pour que rien ne dépasse en 320px de large et que tu as utilisé des rem ou des em comme unités de longueur, et si l'utilisateur passe sa police par défaut à ne serait-ce que 24px, et jusqu'à au moins 32px selon certains standards d'accessibilité (voir les liens plus haut dans cette page), bah, ça peut être panique à bord selon ce que tu as bricolé ici et là, non ?

Amicalement,
Modérateur
Bonjour,
Olivier C a écrit :
Si j'ai bien compris l'idée de Parsimonhi, l'idée est de savoir comment l'on gère en cas de dépassement quand-même.

Par exemple, toujours selon son idée, si l'on réduit une fenêtre à 500px de large tout en mettant le zoom à 500%.
J'espère que je ne t'ai pas trop traumatisé quand même ! Smiley biggol Smiley biggol Smiley biggol

Reste que grâce au présent post, Felipe m'a mis sur la piste des standards d'accessibilité concernant la largeur minimal à tester (voir les liens que j'ai trouvé dans ma réponse plus haut et que je n'avais pas pensé à chercher avant aujourd'hui, mea culpa). Je n'avais qu'une vague idée de ce qu'ils étaient. Et si on combine la règle des 320px avec la règle des caractères à 2 fois la taille normale, on arrive en pratique à devoir tester jusqu'à 10rem de large (10 * 16px * 2 = 320px).

500px à zoom de 500% avec 1rem valant 16px, c'est 100px ou 6.25rem ! Ça semble extravagant, mais en fait, on n'est pas si loin des 10rem que suggèrent les normes une fois qu'on a fait tous les calculs de conversion appropriés (à confirmer, je peux me tromper dans les calculs ou avoir mal compris les standards).

Amicalement,
Alors, ok, tout ça c'est bien joli, mais on est bien d'accord qu'un Chrome ou un Firefox mobiles n'ont pas du tout le même comportement que sur desktop pour ce qui est du zoom : sur mobile, si l'on utilise les deux doigts pour agrandir, qu'un overflow soit hidden ou clip sur le document ça ne change rien au fait que l'on va pouvoir scroller la page dans tous les sens sans limitations.

Du coup il reste le cas de l'ordinateur de bureau effectivement... Mais pourquoi quelqu'un irait mettre 500% d'agrandissement pour une page, tout en ramenant sa fenêtre à 500 pixels ?

Il y a un choix technique à faire au départ qui influe sur l'expérience utilisateur. Pour moi, prendre comme point de départ une utilisation réaliste est un bon compromis.

Dans ton sens : Amazon, Google et Google Drive sont de bon exemples, avec pour tous - assez rapidement dans l'itération du zoom - une bonne barre de défilement horizontale. Mais il faut comprendre que chacun d'entre eux a une version spécifique pour mobiles (détection du useragent et autres paramètres hardwares et softwares), en plus de leurs applications mobiles. Si l'on fait ça à notre niveau, comme code, ça va commencer à devenir spaghetti...
Modifié par Olivier C (05 Mar 2024 - 22:41)
Modérateur
Bonjour,

Olivier C a écrit :
Sur mobile, si l'on utilise les deux doigts pour agrandir, qu'un overflow soit hidden ou clip sur le document ça ne change rien au fait que l'on va pouvoir scroller la page dans tous les sens sans limitations.
Je ne sais pas (ou plutôt je ne sais plus) ce que c'est qu'un "mobile". Smiley lol

Mais quoi qu'il en soit, raison de plus pour ne pas mettre d'overflow hidden ou clip sur le document puisque "ça sert à rien" (ou presque à rien) ! Smiley cligne

Olivier C a écrit :
Du coup il reste le cas de l'ordinateur de bureau effectivement... Mais pourquoi quelqu'un irait mettre 500% d'agrandissement pour une page, tout en ramenant sa fenêtre à 500 pixels ?
Oui, c'est un test un peu trop contraignant je l'admets, mais pas tant que ça comme je l'ai expliqué dans ma réponse précédente.

A priori, maintenant que j'ai un peu avancé sur la question, le test à faire a bien l'air d'être fenêtre de 320px, taille de la police 2 fois la normale, et pas de scroll ou de doigts qui trainent sur l'écran pour bouger le contenu horizontalement. Donc si ça dépasse en largeur lors du test, bah, on est recalé. Que ce soit avec un écran tactile ou pas, et si on utilise les doigts, ou une souris, ou un trackpad, c'est pareil.

On peut cependant, si j'ai bien compris, avoir des éléments internes à la page avec un scroll horizontal (par exemple, une "map", voire un tableau).

Olivier C a écrit :
Il y a un choix technique à faire au départ qui influe sur l'expérience utilisateur. Pour moi, prendre comme point de départ une utilisation réaliste est un bon compromis.
Oui, il faut bien sûr être réaliste. Cependant on n'est plus dans un choix technique là (comme je le pensais encore hier), mais dans le respect (ou pas) d'une norme. Smiley cligne .

Et quel serait techniquement ce choix ? On ne peut pas juste dire : "il faut que ça soit réaliste" car l'océan des possibles est trop vaste.

Et quelque soit la limite qu'on se fixe, il reste la question des contenus qui dépassent quand on est en dessous de cette limite (c'est surtout à ça que sert mon test de 500px zoomé à 500%, non pas à vérifier que le contenu tient dans cette largeur, mais plutôt que le design n'est pas cassé même à cette largeur). A priori, mieux vaut semble-t-il dans ce cas forcer le scroll horizontal avec une largeur suffisante pour ne pas trop couper les mots (on peut les couper "un peu" mais "pas trop" sinon c'est trop difficile à lire et au final cela nuit à l'accessibilité aussi), ne pas perdre une partie du contenu, et conserver un design en bon état, plutôt que réduire (ou laisser réduire sans le maitriser) la largeur du contenu à tout prix. Je ne retrouve plus où je l'ai lu aujourd'hui, mais ça semble être du bon sens de toute façon. Et techniquement, il me semble que c'est assez facile à réaliser : il suffit d'un min-width sur le body, sans avoir besoin de tenir compte du matériel des utilisateurs (et évidemment, pas d'overflow hidden ou clip).

Bref, en résumé, taille minimum de 10em (320px avec une police de 32px) de large et pas de scroll horizontal de l'ensemble du contenu au dessus de cette largeur, ça me parait pas mal et tenable.

Amicalement,
Du coup, tu peux faire comme Google et Amazon, mes trois exemples plus haut : pages web optimisées pour un affichage d'environ 1200px, pas de points de rupture (ou très peu). On agrémentera avec quelques éléments gérés de manière individuelle, par exemple avec des barres de scroll horizontales au niveau des composants (si si), typiquement une barre de navigation (ex : Google Drive). Comme ça pas de prise de tête pour la version desktop. Smiley cligne

Par contre, bien sûr, détection incontournable du matériel + système d'exploitation (au revoir user agent) pour proposer une alternative très spécifique aux mobiles.

parsimonhi a écrit :
Je ne sais pas (ou plutôt je ne sais plus) ce que c'est qu'un "mobile".

Blague mise à part, c'est le type de terminal qu'utilisent 65-75% des utilisateurs d'un site web de nos jours. Pour la nouvelle génération tu peux monter le chiffre à plus de 95%. Juste ça.
Modifié par Olivier C (06 Mar 2024 - 09:52)
Modérateur
Bonjour,

J'ai hésité à répondre ! Smiley cligne

Olivier C a écrit :
Du coup, tu peux faire comme Google et Amazon, mes trois exemples plus haut : pages web optimisées pour un affichage d'environ 1200px, pas de points de rupture (ou très peu). On agrémentera avec quelques éléments gérés de manière individuelle, par exemple avec des barres de scroll horizontales au niveau des composants (si si), typiquement une barre de navigation (ex : Google Drive). Comme ça pas de prise de tête pour la version desktop. Smiley cligne
Si tu veux. Mais bon, ça fait un moment que je ne me préoccupe plus des 1200px. Il faut que ça marche pour les petits écrans, les moyens et les grands.

Olivier C a écrit :
Par contre, bien sûr, détection incontournable du matériel + système d'exploitation (au revoir user agent) pour proposer une alternative très spécifique aux mobiles.
Règle de parsimonhi N°45 : ne cherche jamais à détecter avec quels matériels les utilisateurs viennent visiter ton site.

Je ne vois aucune bonne raison de proposer une version spécifique selon le type de matériels utilisés. Par contre, j'en vois des tas de mauvaises.

Dois-je détailler ? Smiley biggol Smiley biggol Smiley biggol

Olivier C a écrit :
Blague mise à part, c'est le type de terminal qu'utilisent 65-75% des utilisateurs d'un site web de nos jours. Pour la nouvelle génération tu peux monter le chiffre à plus de 95%. Juste ça.
C'est une règle fondamentale selon moi (et ce n'est pas une blague Smiley biggrin ) : y a pas de "mobiles". Ça ne veut rien dire. Il y a des tonnes de matériels connectés d'une variété "épouvantable" (et cette variété augmente tous les jours) qui vont de l'écran tactile géant pas mobile du tout, au petit ordinateur portable ayant un écran avec moins de pixels qu'un téléphone. Et il y a des utilisateurs qui iront ouvrir 10 ou 20 (petites) fenêtres en même temps sur un grand écran, des utilisateurs qui feront exactement la même chose avec une tablette ou un ordinateur portable, des utilisateurs qui navigueront au clavier quand bien même ils pourraient se servir d'une souris ou d'un écran tactile, des utilisateurs qui "parlent" avec leur machine (j'en vois de plus en plus), etc.

Alors OK, il y a comme en tout chose "le gros du peloton". Mais pourquoi ferait-on du spécifique pour un type de matériels ? Je ne vois vraiment pas ! Tout ça est tellement "mélangé".

Peut-être que parfois, on ira corriger un bug ou vérifier qu'une fonctionnalité est bien présente, mais c'est cosmétique, souvent transitoire, et uniquement quand on ne peut vraiment pas faire autrement. Et ça n'a rien à voir avec "mobile" ou pas "mobile".

Bref, faire des versions "mobiles" versus "pas mobiles", c'est trop "has been".

Amicalement,
Modérateur
Bonjour,

Finalement, le test fenêtre de 500px de large et zoom de 500%, c'est pour les mickeys.

Ce qu'il faut faire, c'est fenêtre de 500px de large, zoom de 500% et taille par défaut de la police du navigateur à 72px. Là, on voit vraiment si un code marche ou pas ! Smiley biggol

Plus sérieusement, jouer sur ces 3 paramètres est important (sans forcément aller dans les extrêmes bien sûr). Fenêtre à 640px de large, zoom de 200%, taille par défaut de la police du navigateur à 32px, ça reste dans le domaine du probable et c'est instructif, car ils ne font pas apparaitre les mêmes sortes de bugs.

Amicalement,
parsimonhi a écrit :
Ce qu'il faut faire, c'est fenêtre de 500px de large, zoom de 500% et taille par défaut de la police du navigateur à 72px. Là, on voit vraiment si un code marche ou pas !

Alors, je te concède un truc : je viens de m'apperçevoir, que dans une situation de ce type, mon menu en version mobile n'est plus accessible pour tous ses items car j'utilise `overflow: clip`, alors qu'il faudrait que je me contente de :
:where(html,body).active {
    overflow-x: clip;
}

Merci à toi, cher pointilliste Smiley cligne
Bonjour,
En général, il est recommandé de tester les sites web en fenêtre étroite jusqu'à une taille
minimale de 320 pixels de largeur, correspondant à la largeur minimale d'un iPhone 5 en mode
portrait. Cependant, il est essentiel de tester le site sur diverses tailles d'écran afin de s'assurer
qu'il est utilisable sur tous les types de dispositifs.
Pour optimiser les sites web pour les fenêtres étroites, plusieurs options sont disponibles :
- Utiliser un design responsive pour une adaptation automatique à la taille de l'écran.
- Utiliser des media queries pour des styles CSS spécifiques.
- Eviter les éléments trop complexes qui peuvent ralentir le chargement, privilégier les boutons et les liens tactiles facilement cliquables.
- Veiller à ce que le texte soit suffisamment grand pour être lisible sur un écran mobile, avec une taille de police recommandée d'au moins 16 pixels.
@Heloise12 : Bonjour,

Avez-vous un minimum parcouru le topic avant de répondre ?

En effet, ne le prenez pas mal mais... en l'état on a l'impression d'une réponse émanant de ChatGPT.

(ceci étant dit, vous ne seriez pas la seule du moment, j'ai en tête quelqu'un d'autre)
Oui, je teste les sites en fenêtre étroite pour assurer leur réactivité. Les tailles courantes incluent 320 px pour les smartphones en portrait, 480 px pour les smartphones en paysage, 768 px pour les tablettes en portrait, et 1024 px pour les tablettes en paysage ou petits ordinateurs portables. Ces tests garantissent que le site reste fonctionnel et bien présenté sur une gamme d'appareils et de résolutions.