[Web adaptatif] Quel type choisir ?

[@lucard]

Merci Globe pour ces précisions,
comme toi j'aime pas trop les nouvelles balises html5, sachant qu'on peu faire (presque) pareille avec le html4
je pense aussi que faire "à-la-main" ces css est une meilleur chose que d'utiliser des bibliothèques lourdes et complexes.

Dans tous les cas, quoi que je choisisse, il faudra que je "pense" à l'évolution possible responsive du site lors de la création de celui-ci.

On va décrier les sites qui proposent des sheets différentes en fonction des supports, mais c'est la solution assurée pour certaines interfaces qui doivent juste être totalement repensées pour l'expérience utilisateur plutôt que pour les chevilles du designer. Je pense que certains jeux entreront dans cette catégorie. Quand y'a des milliers de lignes responsive autant charger une sheet différente.

Effectivement, je n'avais même pas pensé à cela. le fait de changer de sheet en fonction du support... mais dans ce cas, n'y a-t il pas autant de lignes à faire ? (si ce n'est qu'elles sont réparties sur plusieurs sheets ?)

[Ter Rowan]

Effectivement, je n'avais même pas pensé à cela. le fait de changer de sheet en fonction du support... mais dans ce cas, n'y a-t il pas autant de lignes à faire ? (si ce n'est qu'elles sont réparties sur plusieurs sheets ?)

en source tu devrais te retrouver avec un css global qui a énormément de chose (tout ce qui est commun, couleur, background, bouton, ....) et un css dédié à chaque sheet

après pour optimiser le chargement du fichier css tu fais un css par sheet (global + dédié)


le seul point, c'est que, potentiellement, chaque média (smartphone, pc, ...) pourrait aussi voir son html spécifique (flux, contenu même pour avoir une réorganisation de la navigation, etc...)

personnellement, je ne crois pas qu'on puisse avoir la même ergonomie sur un écran de 20 pouces et sur un écran de 3 ( ? ) pouces. Je parle bien sûr dans le cas d application complexe

[Globe]

En fait c'est clairement pas une solution à appliquer tout le temps. Mais quand on prend certains exemples ça devient plus clair.

Exemple 1 : Un portfolio graphique. L'utilisateur pc et tablette va pouvoir profiter des créations graphiques dans une taille importante avec du texte en plus, du détail, des plugins jquery peut être pour la beauté du truc.

L'utilisateur cellulaire va devoir charger ces mêmes images énormes (adaptées par exemple à l'écran 23 pouces ou plus), ces même plugins lourds sur sa connexion 3g. Je me suis mal exprimé je ne parlais pas seulement de stylesheet différente mais également de redirection html comme on vous propose parfois "voulez vous accéder à la version mobile de ce site ?". Ce genre de message est très ringard en ce moment si on écoute la plupart des gens. Mais dans le cadre d'un portfolio on va vouloir charger des images plus petites puisque srcset n'est pas implémenté. Si on travaille en HTML / CSS natif sans utiliser de plugins on ne peut pas empêcher le chargement de données et même avec les solutions exotiques c'est un casse tête pas propre et pas ergonomique. Là il parait logique d'avoir une page différente bien qu'il soit tout à fait envisageable de faire le tout en responsive.

En webdesign comme dans tout c'est au cas par cas je trouve, je préfère bien évidemment le full responsive mais tant que des solutions comme srcset ne seront pas accessibles il faudra trouver des fallbacks pour privilégier l'expérience utilisateur plutôt qu'un "conscience rigoureuse de la pratique web" dans certains cas.

Cet exemple ne se marquait pas par la quantité de lignes mais plutôt par la nécessité de charger des fichiers différents.

Exemple 2 :

Un site qui à énormément recours à javascript et qui est en onepage avec parallax avec une grosse proportion d'éléments graphiques. Je l'ai rencontré irl et c'était très douloureux.

Hors de question de redimensionner en utilisant js, trop d'éléments, déjà trop de js sur la page, temps de chargement horrible. Une seule page contient toutes les données, c'est la requete du client, le tout défile en parallax donc chaque "page" doit faire 100% de largeur et 100% de hauteur, on voit déjà le problème se profiler, ce sont des images pas des textures, on DOIT les scale proportionnellement. Une image vaut mieux qu'un long discours :

Les images ne se scalent pas en fonction des résolutions, dans ce cas j'avais 16 pages différentes utilisant toutes au moins 15 images différentes qui devaient se repositionner. Dans ce cas là l'erreur de mon client à été de vouloir du responsive. J'ai fait ce qu'il m'a demandé mais je pense que c'est une erreur. Je m'explique :
1 - Page très lourde, mêmes images sur téléphone que sur grand écran.
2 - Code css très long et dégueulasse pour ne pas avoir trop de whitespace entre les images sur les dizaines de résolutions possibles
3 - Quel intérêt pour un utilisateur de mobile d'avoir autant d'images en tout petit ?
4 - Si jamais vous embauchez un designer demandez lui de créer le design mobile en même temps que le design full scale, là le client avait embauché un graphiste pour le design, une agence web pour le code (leur résultat mettait plus de 2 minutes à charger) et ensuite moi pour refaire le code et faire une version mobile

L'idée c'est que le contenu doit servir l'utilisateur et non pas "demeurer le même de manière figée". Mon client voulait le même rendu sur téléphone et tablette que sur PC. Quand je dis le même, je veux pas dire semblable mais il voulait exactement la même chose. Et ça c'est une erreur que beaucoup de gens ont en pensant au responsive.

Sur un autre site le point central est un champs de recherche. C'est le centre d'intérêt, sur la version mobile on à donc que ce champs de texte et un menu responsive plutôt que de retranscrire toutes les photos, décorations, images, commentaires... de la version pc. En gros ce que je disais ce n'est pas que c'est une bonne pratique de faire des versions différentes plutôt qu'une seule responsive mais seulement qu'il y à des cas de figures ou faire un fichier simplifié pour certaines résolutions est la bonne solution.

Ma conclusion : Responsive != retranscription exacte dans toutes les résolutions
et parfois il vaut mieux faire deux design qu'un seul responsive.

[stefde3]

Après rien ne t'empêche pour les dimensions d'image de les définir dans une div définie en % et tu donne à ton image un width de 95% centrée ou 100% de la div et ton height en auto ainsi selon la largeur affichée, la hauteur se réglera automatiquement au ratio de la largeur.

[Ter Rowan]

Après rien ne t'empêche pour les dimensions d'image de les définir dans une div définie en % et tu donne à ton image un width de 95% centrée ou 100% de la div et ton height en auto ainsi selon la largeur affichée, la hauteur se réglera automatiquement au ratio de la largeur.

pas forcément dans le sens ou fonction du média tu pourrais aussi vouloir utiliser des images de qualité différente (donc poids différent)

c'est là où on rentre avec des modèles où on na pas que du css mais aussi du html qui varie

enfin tout dépend du besoin , de la qualité du rendu , etc..

[stefde3]

En effet oui mais pour ça y a encore d'autres solution en JS par exemple ou on peut savoir quelle est la résolution et en fonction de celle-ci, si elle est < à 800px tu peux faire une condition en PHP pour afficher une image réduite en taille et en poids

[@lucard]

[...] solution en JS [...]et en fonction[...]faire une condition en PHP [...]

[joke mode=On]
Ouais sinon j'peux demander au client de choisir sa résolution d'écran, et en fonction lui envoyer un mail, qui l’enverra vers un serveur contenant le site à sa résolution d'écran, enfin s'il connait sa résolution exacte. x)
[joke mode=Off]
plus légèrement, et plus facilement,
je pense que, comme Globe, j'vais attendre l'adoption du srcset.

sinon ne pas mettre de balise image,
seulement des div (dans ce cas, images non-sélectionnables)

@media screen and (max-width: 640px)

{ div.img1

   {

   height:300px;

   width:200px;

   display:block;

   background: url(toto200x300.jpg) 0 0 no-repat;

   background-size:cover;

   }

}



@media screen and (min-width: 640px)

{ div.img1

   {

   height:600px;

   width:400px;

   display:block;

   background: url(toto400x600.jpg) 0 0 no-repat;

   background-size:cover;

   }

}

ça devrait fonctionner, non ?
dans tous les cas, j'suis pas fan de passé par du .js, et du .php, tout ça pour afficher une image à la bonne dimension, le jours où l'image, ou la mise en page, ou l'organisation globale du site doit changer, va surement avoir pas mal de cafouillages là-dedans.
[ moins y'en a, mieux c'est ? ]

[Ter Rowan]

je rejoins @lucard, à une nuance près : le background image est de la cosmétique

si tu veux une image qui a du sens et être jolie (c'est le but dans la discussion) tu ne peux pas t'arrêter à des div vides (enfin d'un point de vue sémantique)

dans ce cas je ferais plutôt

à la page d'accueil / via cookie / ... je détecte la résolution

ma vue générée côté serveur restitue l'image (et le reste) fonction de cette résolution

[stefde3]

Y a tellement de manières de faire qu'aucune n'est bonne ni mauvaise dans le sens ou rien n'a été prévu pour ces cas de figures de toute manière ^^

après peu importe la solution, ça reste du bidouillage de fortune pour que ça fonctionne.

[Globe]

La base de mon propos n'était justement pas de définir de solution absolue mais de défendre un peu l'underdog du moment : l'idée que le responsive n'a pas pour vocation de créer une réplique exacte du site full size mais plutôt d'en fournir une version adaptée et ergonomique.

@stefde3 > Comme tu dis on peut toujours trouver un fix, un htc, un plugin js... Le point de vue que je défendais était simplement que dans bien des cas il est plus responsable et ergonomique de ne pas faire ce que tu appelles un "bidouillage de fortune" comme mes clients m'ont souvent imposé. Ce n'est ni rapide, ni efficace, souvent l'intégrateur lui même doute de la fonctionnalité du truc sur la totalité des devices et c'est surtout extrêmement coûteux en temps et donc en argent.

A mon avis on reste à une période charnière du webdesign ou la mode à encore bien trop à dire et ou on ne donne pas trop la parole aux experts au niveau interface et ergonomie. Du coup on se retrouve avec beaucoup de clients qui demandent un webdesign avec des milliards d'images, du parallax et le tout qui se scale en responsive d'une manière "stylée" plutôt que d'une manière efficace. Sur mon téléphone ça m'emmerde d’accéder à des trucs esthétiques mais pas ergonomique j'ai pas 3 heures à perdre sur un écran de la taille de ma main. On voit d'ailleurs se multiplier lentement mais sûrement les postes d'intégrateurs full fledged (plutôt que comme précédemment des postes de dév web qui se chargeaient également d'intégration) et notamment les notions d'ergonomie et d'ux comme spécialités.