1448 sujets

Web Mobile et responsive web design

Pages :
Bonjour à tou(te)s

Y'en a encore qui vont dire que je ferais mieux de me renseigner sur ce qui existe plutôt que réinventer l'eau chaude mais bon Smiley lol ...

Donc l'idée, suite à une discussion sur l'opportunité (ou l'inopportunité...) de maintenir deux sites, l'un "classique" et l'autre pour mobiles, est de chercher à raisonner la chose dans l'autre sens. On se dit que plusieurs cas de figures peuvent apparaitre, par exemple qu'un mobile ne reconnaisse pas handheld. Que se passe-t-il dans ce cas-là ? Hé bien il utilise screen et ça tourne vite au vinaigre question utilisabilité (ça j'ai pu le vérifier).

On part dans l'idée qu'en l'état normal des choses qu'un ordi utilisera la feuille screen et un mobile la handheld. On fabrique donc 2 feuilles, avec dans la handheld une gestion des contenus pour présentation spécifique aux mobiles. Le choix de l'une ou l'autre ne dépend pas de l'utilisateur mais de l'UA.

Dans le cas critique d'une feuille handheld non-reconnue (ou plus exactement d'utilisation de la première feuille rencontrée...), il convient d'envoyer au mobile une autre feuille CSS que la screen générique. L'idée est de commencer par détecter quelle feuille est utilisée par l'UA : screen ou handheld. Si handheld, pas de souci, le mobile réagit bien. Si screen, question : est-ce un ordi ou un mobile ? A ce moment-là JS intervient : si c'est une fenêtre supérieure à 450px de large rien ne se passe, si c'est moins il va proposer un lien (à placer par exemple en premier en haut de page avec les évitements et qui serait caché si y'en a pas besoin), genre Version pour mobiles. Ce lien ne concernera que les utilisateurs de mobiles non-handheld.
Quand l'utilisateur clique il ouvre une session PHP qui remplace dans l'entête les deux feuilles screen et handheld par une <link ref moobil.css media=screen>... A partir de là on peut développer une feuille suffisamment dégradée pour répondre aux différentes contraintes de consultation sur UA peu performants. On opère ainsi un système de filtrage plus ou moins temporaire puisque cette dégradation devrait concerner de moins en moins de mobiles.

Il reste aussi évidemment la possibilité de renvoyer par la session Php la même feuille handheld mais cette fois déclarée comme screen dans l'entête, mais il est dommage de se priver de cet outil de filtrage que représente une Css spécifique destinée aux "vieux" mobiles (enfin pas tant que ça.. le Viewty de LG, par ailleurs véritable bijou techno en mieux et moins cher que l'iPhone, s'affiche encore en screen).

Un petit test est en ligne ici. Ça marche aussi en réduisant les fenêtres d'écrans. Delete permet de réinitialiser le test en perdant la session Php.

Si votre mobile ne comprend ni Css ni JS il est temps d'en changer. Smiley biggol
J'ai un ipod touch et j'utilise les media queries :

<style type="text/css" media="screen and (min-device-width: 481px)">
@import '/dotclear2/themes/lombre/style.css';
</style>
<style type="text/css" media="handheld">
@import '/dotclear2/themes/lombre/handheld.css';
</style>
<style type="text/css" media="print">
@import '/dotclear2/themes/lombre/print.css';
</style>
<style type="text/css" media="only screen and (max-device-width: 480px)">
@import '/dotclear2/themes/lombre/handheld.css';
</style>


J'ai pas encore été voir si IE bloquait dessus. Je verrai demain. Smiley sweatdrop

Sinon ça fonctionne bien, mais je vais peut-être faire une css spécifique aux iBidules. De plus en plus de mobile vont utiliser webkit comme moteur et donc devraient être sensible aux media-queries, je verrai bien s'il y a des adaptations à faire…

P.S. : la feuille handheld.css est minimale, c'est juste pour faire des tests…
Modifié par Patidou (17 Dec 2007 - 21:28)
Pour ton test, c'est bizarre : il me dit que la session n'est pas active alors que je peux parfaitement utiliser les sessions php (par ex. sur mon blog avec DC2).

Tout le reste est OK.
Bonsoir,

Je n'ai testé que rapidement avec mon navigateur, et ça a l'air de marcher pas mal. Surtout, cette solution me semble plutôt habile.
Salut Arsene,

Je ne sais pas ce que j'ai fait hier mais ce qui est sûr c'est que j'ai posté à côté de plaque... C'est bizarre mais ça ne marche pas avec l'ipod touch, que ce soit en mode portrait ou paysage ton programme indique 962px de large donc l'affichage se fait avec le media screen.

Encore désolé. Smiley confused
Oui, très étonnant qu'il détecte une fenêtre de 962px... il ne doit pas comprendre l'instruction JS ou alors l'interpréter bizarrement. En tout cas c'est pour ça qu'il n'active pas la session puisque tu n'as pas à passer par le lien "Version pour mobiles".... mais c'est jamais qu'un iPod. Des retours d'iPhone seraient donc aussi bienvenus.
Pour moi ça fonctionne avec le vieux S-E w900i (il a 2 ans mais reconnait handheld), sur Nokia N95 (reconnait aussi handheld) et le nouveau LG Viewty. Quelqu'un d'autre peut tester de son côté ?

Le cas critique apparait quand JS n'est pas implémenté. Je n'ai pas encore fait de recherche là-dessus, notamment dans wurfl, mais amha peu de mobiles 3G implémentent Css et pas Js... ??? Question ouverte.
Modifié par Arsene (18 Dec 2007 - 10:45)
En fait iPod Touch ou iPhone c'est pareil, l'iPod Touch est en fait un iPhone sans la partie téléphone, appareil photo et mail. C'est le même navigateur avec les mêmes possibilités. Il y a juste la signature qui varie.

iPod Touch

iPhone

Je me souviens avoir vu quelque chose dans la doc Apple sur la taille de l'écran, dès que je l'ai retrouvé, je poste le lien.

Smiley cligne
" En fait iPod Touch ou iPhone c'est pareil" Ah, j'ignorais.

En revanche le Viewty donne bien 240px en affichage vertical et 390px (+ à mon avis 10px de barre de scroll pour arriver à 400) en horizontal.
Modifié par Arsene (18 Dec 2007 - 11:14)
Apparemment c'est un problème de viewport qui par défaut est de 980 pixels. (doc)

Documentation générale

Dans les podcasts, je me souviens qu'il était possible d'utiliser Javascript avec le viewport.

Sinon la méthode des media queries ne fonctionne pas avec IE6, j'ai un site nu. Je vais devoir utiliser les commentaires conditionnels. Smiley murf
OK, j'ai placé un <meta name = "viewport" content = "width = 450"> dans les head pour essayer... Reste à savoir si ça va être considéré comme une largeur de fenêtrage ou comme une limite de rendu d'affichage ? Classiquement viewport est décrit sur IE par document.body.offsetWidth / document.body.offsetHeight et sur Gecko par window.innerWidth / window.innerHeight.
Ceci dit cette question est accessoire si iPhone/iPodTouch comprend handheld, mais le comprend-t-il ?

EDIT : j'ai aussi rajouté une évaluation de la valeur du viewport dans le fichier JS si jamais iPhone ne la considère pas comme une largeur. Est-ce utilie ou nécessaire je ne sais pas.

Un lien assez complet : Web Devel for iPhone (en anglais)
Modifié par Arsene (18 Dec 2007 - 14:50)
Donc on doit bien fixer le viewport à 450 pour contraindre iPhone à proposer le lien vers moobil.css en feuille screen. Est-ce que ça marche ?

EDIT : en tout cas sur LG à l'horizontale il donne bien 390 en fenêtre et 400 en viewport...
Modifié par Arsene (18 Dec 2007 - 14:59)
Je te dirai quoi ce soir, je n'ai pas de wifi disponible au boulot.

EDIT : pas mal le lien qui résume toutes les infos
Modifié par Patidou (18 Dec 2007 - 15:39)
J'ai intégré le media-query détectant l'iPhone mais laissé quand même la définition du viewport à 450 pour le cas où d'autres mobiles non-Apple se mettraient à faire pareil (viewport fixe) mais ne reconnaitraient pas les media-queries...
La suite (le but est toujours d'arriver à un document unique) consiste à utiliser php et la session ouverte pour trier dans le flux ce qui va être distribué ou pas, tenant compte des spécificités techniques des mobiles et des coûts liés au volume loadé. Charger un élément de contenu pour ne pas l'afficher (display:none) coûte de l'énergie, du temps et des sous... c'est donc le serveur qui prendra ça en charge.
Bonne nouvelle Smiley smile

Donc on pourrait s'orienter vers un site unique avec un procédé de filtrage au niveau du serveur capable d'envoyer des contenus distincts selon l'UA. En gros, lors de la requête on détecte la Css utilisée : si c'est screen un script détecte la largeur/viewport et sert le contenu intégral avec lien immédiatement accessible pour passer en contenu restreint, si c'est handheld on sert par défaut le contenu intégral (...ce qui n'empêche pas la possibilité de proposer également un lien vers le contenu restreint)
Après reste plus qu'à émailler le contenu de (par exemple) <span class="no-moobil">...</span> qu'une regex supprimera :

<h1>Titre <span class="no-moobil">vraiment très long et, en terme d'affichage, pas du tout</span> adapté aux mobiles</h1>

ou encore, en complétant le dispositif :

<div class="moobil">
<ul>
<li>Menu spécifique aux mobiles...</li>
<li>...permettant d'accéder directement à des sections</li>
</ul>
</div>

... mais là pas besoin de regex, une ligne Css .moobil { display:none } placée dans la feuille screen suffira largement puisque le mobile non-handheld utilisera la feuille moobil.css. Il y a même plus fin : en affectant à .moobil les attributs ad hoc on peut gérer son apparition ou pas dans Jaws ou ailleurs.

Tout ça est très théorique et y'aurait pas mal de tests à faire. Est-ce que ça vaut le coup ou serait-ce une usine à gaz de plus qui se prépare ???

En tout cas Patidou merci de ton aide Smiley cligne
Modifié par Arsene (19 Dec 2007 - 10:02)
Modérateur
Salut,

On connait les problèmes d'une détection de résolution par l'intermédiaire de Javascript: on ne peut compter dessus, ne serait-ce que parce que ce langage n'est pas forcément disponible. (Perso, j'ai dû l'activer sur mon portable; ce n'était pas le cas par défaut) Et puis reconnaitre un quelconque support par l'intermédiaire de JS ou PHP, ce n'est pas fiable... dans l'absolu...

Donc pourquoi ne pas proposer une feuille css adaptée via un styleswitcher ? Ca permettrait de s'affranchir de la détection. (qu'on peut malgré tout ajouter... mais à titre optionnel)
C'est moins fun, certes, mais au moins, on a plus de chance de répondre au besoin.
Modifié par koala64 (31 Dec 2007 - 09:00)
si je ne me trompe pas... la seule façon de détecter exactement un mobile est par le user agent, qui est propre à chaque mobile, ou à chaque browser ( pour IE mobile par exemple) et là ça devient très difficile d'être à jour

je me demandais:

pourquoi ne pas simplement utiliser le fait qu'il existe maintenant une extension .mobi, fournir un adresse .com ou .fr pour le pc et le .mobi pour les mobile et essayer de travailler pour que nos pages soient compatible avec toutes les résolutions mobile.
Modérateur
Le problème, c'est que le user agent est souvent modifiable par le navigateur donc on ne peut vraiment compter dessus là encore. Smiley rolleyes
Administrateur
Pendant Paris Web, il a été question d'utiliser le sous-domaine m.domain.tld, à la manière de wap.domain.tld avec m pour mobile bien entendu. Il me semble que c'était Dom qui en parlait (donc le W3C), après à voir dans quels cas c'est une bonne chose ou pas de séparer les sous-domaines m et www, s'il y a intérêt à payer le .mobi, etc

EDIT: sur les sites web 2.0 hype (pléonasme Smiley rolleyes ), il existe un bouton qui réunit 20 boutons avec toutes les manières de promouvoir un article dans Digg, Fuzz, etc, etc, etc
A quand 2 boutons avec dans l'un le choix de la langue tellement il y en a et dans l'autre le choix de son type de navigateur (j'ai un mobile, le haut débit ou j'arrive à me connecter par satellite depuis un endroit perdu pour 10€/H merci de faire très simple) ?
Modifié par Felipe (31 Dec 2007 - 11:14)
Pages :