Un "style switcher" pour mobile

Bonjour,
sur le site de la BBC, (excellent au passage), on peut accéder directement à la version linéarisée pour mobile du site via un lien en haut de page.
Manifestement ce n'est pas un simple style switcher puisque la structure n'est pas identique mais l'idée d'un style switcher vers une CSS handheld me semble être intéressante sachant que le media handheld n'est pas encore totalement implémenté par les navigateurs de mobiles.
Bien évidement il faudra pouvoir s'assurer que l'accès au lien "mobile" se fait sans trop de difficulté sur un appareils portatif
mais le mieux est de mettre en place un URL différente pour un accès directe.
Modifié par Hermann (14 Oct 2008 - 12:06)

Ça n'inspire pas grand monde manifestement...

Ha! l'accès à la balise link (sous exploitée)

<link rel="alternate" href="http://www.bbc.co.uk/mobile/i/index.shtml"> 

Ou quelque chose dans le même esprit.

Enfin je dis ça mais je n'ai jamais surfer sur le net avec un portable et je ne sais pas si c'est susceptible d'être pris en compte par les navigateurs.

En tous cas sur les navigateurs desktop, les switchers ne serviraient plus à rien.
Modifié par knarf (17 Oct 2008 - 21:39)

Le mécanisme de changement des styles (via CSS handheld, media queries ou style switcher) a ses limites. Il est sans doute pertinent pour des petits sites, mais la surcharge d'informations et contenus guette l'utilisateur de périphérique mobile à qui on servirait strictement le même contenu. D'où l'intérêt des versions «mobiles» de grands sites, mettant en avant certains cervices et contenus, diminuant la charge d'informations ou la répartissant mieux.

Donc l'intérêt d'un style switcher me semble faible. Aujourd'hui, il me semble pertinent de développer des versions mobiles pour certains gros sites et services web. La simple adaptation des styles (CSS handheld ou media queries ou style switcher) est aujourd'hui:
- pas extrêment compliquée, mais ça demande un travail supplémentaire;
- pas super intéressante, vu l'utilisation relativement faible du web mobile pour du surf «classique», à pondérer encore par la part faible de navigateurs capables de gérer les mécanisme intelligents tels que les media queries.

D'ici deux ans sans doute, il sera beaucoup plus utile de faire des adaptations stylistiques en CSS, via les media queries. Le media handheld risque, pour sa part, de tomber en désuétude (car peu pertinent).

Pour info, Firefox 3.1 supporte les media queries. Il s'ajoute donc à la liste des navigateurs compatibles, avec Safari (depuis sa version 3) et Opera (depuis sa version 7!). À voir pour IE8, et bien sûr pour les différentes déclinaisons mobiles présentes et à venir.

a écrit :
D'où l'intérêt des versions «mobiles» de grands sites, mettant en avant certains cervices et contenus, diminuant la charge d'informations ou la répartissant mieux.

Mais cette page est elle automatiquement chargée comme ça ?

Est-ce que cela nécessite une action spécifique (aller chercher le lien "mobile" dans la page) ou alors il existe des moyens de reconnaitre l'UA et de servir directement la bonne page ?

Média queries est relatif au css non ? Donc pas d'action sur le contenu (j'entends par là suppression de certaines parties physiquement).

Désolé de poser des questions qui peuvent paraitre un peu bête mais comme je n'utilise pas (web portable) j'ai du mal à me rendre compte de la manière dont tout cela est géré.

En fait je crois bien que c'est une des premières fois (voire la première) que je mets les pieds dans ce salon
Modifié par knarf (18 Oct 2008 - 06:18)

Florent V. a écrit :
Le mécanisme de changement des styles (via CSS handheld, media queries ou style switcher) a ses limites. Il est sans doute pertinent pour des petits sites, mais la surcharge d'informations et contenus guette l'utilisateur de périphérique mobile à qui on servirait strictement le même contenu. D'où l'intérêt des versions «mobiles» de grands sites, mettant en avant certains cervices et contenus, diminuant la charge d'informations ou la répartissant mieux.

Et le display:none il sert à quoi? Mais je suis d'accord que ce n'est pas idéal si l'on veut minimiser les requêtes serveur et la bande passante.
Il doit aussi y avoir des cas ou le display:none n'est pas suffisant.

Florent V. a écrit :

- pas super intéressante, vu l'utilisation relativement faible du web mobile pour du surf «classique», à pondérer encore par la part faible de navigateurs capables de gérer les mécanisme intelligents tels que les media queries.

D'accord sur ce point. D'ou l'intérêt actuel du média handheld, faute de mieux.

Florent V. a écrit :

D'ici deux ans sans doute, il sera beaucoup plus utile de faire des adaptations stylistiques en CSS, via les media queries. Le media handheld risque, pour sa part, de tomber en désuétude (car peu pertinent).

Peu pertinent, peu pertinent... c'est quand même mieux que rien non?
Ce media est actuellement à ma connaissance plus largement implémenté par les navigateurs pour mobiles que les media queries.

Florent V. a écrit :

Pour info, Firefox 3.1 supporte les media queries. Il s'ajoute donc à la liste des navigateurs compatibles, avec Safari (depuis sa version 3) et Opera (depuis sa version 7!). À voir pour IE8, et bien sûr pour les différentes déclinaisons mobiles présentes et à venir.

Merci pour l'info
A ce propos, c'est bizarre le module media queries a retrogradé à l'état de Working Draft, soit c'est une erreur du CSS working group soit je comprends pas tout : http://www.w3.org/TR/css3-mediaqueries/

Knarf a écrit :

Mais cette page est elle automatiquement chargée comme ça ?
Est-ce que cela nécessite une action spécifique (aller chercher le lien "mobile" dans la page) ou alors il existe des moyens de reconnaitre l'UA et de servir directement la bonne page ?

Non, sauf erreur de ma part elle n'est pas chargée automatiquement d'ou la présence du lien mobile.
Il y a les vieilles techniques de redirection JavaScript, ceci dit il existe peut-être d'autres techniques que je ne connais pas.

Knarf a écrit :
Média queries est relatif au css non ? Donc pas d'action sur le contenu (j'entends par là suppression de certaines parties physiquement).

C'est un des nombreux module CSS3 qui vient de passer à l'état de Last Call (enfin je crois)


EDIT @Florent
Ma remarque sur le display:none n'est que partiellement pertinente, tu veux sais doute dire que la rédaction des contenues devra être reétudiée POUR une lecture sur mobile, là ok
Modifié par Hermann (18 Oct 2008 - 18:36)

Hermann a écrit :
Peu pertinent, peu pertinent... c'est quand même mieux que rien non?

Le média handheld est peu pertinent car il correspond à une vision que le marché a démonté. Pourquoi est-ce que l'iphone/itouch l'ignore, hum?

La vision en question était d'une séparation claire entre screen et handheld, comme il y a une séparation claire entre screen et print par exemple. Sauf qu'entre-temps:
- les écrans correspondant au média screen se sont «étalés» sur une gamme qui va de 10cm à 80cm de large (avec des résolutions du 800x600 au 3000px ou presque...);
- les périphériques mobiles se sont diversifiés, du téléphone classique à mini-écran au smartphone;
- il y a toute une catégorie de périphériques mobiles ou semi-mobiles tels que les netbooks et ultraportables.

Bref, il n'y a pas deux catégories d'écrans. Et les fabriquants de périphériques mobiles ne veulent pas que les navigateurs embarqués sur leurs appareils se voient servir des contenus ou une apparence destinés à des écrans en 180x120. Donc: échec cuisant du média handheld, on oublie et on passe au media queries (ou pas).

Edit: effectivement, les media queries sont passées de Candidate Recommendation (2007) à Working Draft (2008). Ça arrive parfois. Apparemment ils ont introduit deux nouveaux mécanismes qu'ils veulent valider avant de repasser en CR.
Modifié par Florent V. (18 Oct 2008 - 19:18)

Noooooooonnnn Hermann, pas de display:none qui charge tout sans rien afficher ! Du coup l'inconvénient est double : tu payes (en temps, en volume,...) le load et tu ne profites pas du contenu.
Y'a un double problème à résoudre : par quel biais accéder au contenu (mediaquery, handheld, screen qui s'affichera comme il pourra genre iPhone), et le contenu distribué.

Pour le moment les solutions que j'applique sont, concernant l'accès, d'envoyer un CSS handheld à qui en veut bien (d'acc avec Florent qu'il va devenir obsolète car la frontière entre ce qui relève de handheld et screen s'estompe de jour en jour) mais surtout de détecter (oui, je sais bien...) la taille du viewport et de proposer, dans les skiplinks, une version handheld à switcher, lien qui n'apparaît donc que dans les UA concernés. Après, l'utilisateur fait ce qu'il veut.
En attendant de voir où les mediaqueries nous mèneront, c'est la soluce la plus économique (temps, énergie, dév., ressources) que j'aie trouvée.

Pour les contenus, deux possibilités : soit comme le dit Florent, développer un site parallèle pour servir les mobiles, mais avec beaucoup d'inconvénients, dont celui de conformation (les deux sites doivent être maintenus et mis à jour simultanément), celui de pertinence (pourquoi telle info et pas telle autre ?), celui de cohérence du dispositif (comme pour handheld, où fixer la limite entre un gros PDA et un ultra-portable super petit ?)

La solution que je suis en train de tester/développer est un peu complexe mais finalement pas tellement. Elle ne marche évidemment que sur des sites à "taille humaine" : ça consiste à créer un seul contenu (c'est mon dada) mais de le servir de façon distincte. La difficulté consiste à pouvoir dès l'amont concevoir l'offre globale du site et ensuite d'en "exploser" le contenu (j'adoooore). Comment ?

En gros tu as au départ un document web hiérarchisé en h1 > h6. Mettons (là ça dépend vraiment de chaque site et de chaque contenu) qu'on fixe empiriquement la barre à h3 : ton document initial contient en dur TOUS les éléments jusqu'à h3. Tout ce qui inclus DANS (ou SOUS) h3 - conçu alors comme une boite contenant quelque chose : des "objets web" - est séparé. En version "non-détectée comme petit viewport" des includes appellent dynamiquement les contenus h3 à venir prendre leur place naturelle dans le flux. Le site s'affiche donc normalement.
C'est ensuite que ça se complique un peu. Une condition PHP avec un peu de regex remplit deux fonctions :
1. elle "mute" les h3 en liens <a href= (tu vois tout de suite pourquoi)
2. elle delete les appels include
En gros donc, elle crée dynamiquement un "second" document différent du premier.

Résultat : en "viewport réduit", tu affiches (soit optionnellement soit de façon contrainte, à toi de voir) la structure intégrale du site et propose des liens pour consulter les sous-parties comme documents autonomes => PHP génère alors un document à la volée constitué du contenu global jusqu'à h3 + le contenu demandé. Il n'y a qu'un seul site et l'intégralité de l'offre est consultable, ce qui est normalement le but de tout projet web.

Ça nécessite évidemment une structuration initiale rigoureuse mais (et hop, un petit coup de crossposting ) ça permet de n'avoir qu'un seul contenu auquel tout utilisateur pourra ultérieurement , s'il le veut ou s'il le peut, appliquer ses propres préférences.

Si tu crées en plus une CSS spéciale (viewport.css) qui dit comment gérer un certain nombre de choses, tu arrives au final à un site unique qui permet la "mutabilité des contenus" (il y a bien "mutation" dans le fait de passer un <h3> en <a href> selon certains critères). Je sais bien que le terme de mutabilité des contenus a beaucoup amusé certains, mais c'est là une application pratique comme une autre.

Ça reste bien sûr expérimental mais ça donne des résultats prometteurs. Ça fait bien sûr du boulot serveur supplémentaire mais le bénéfice peut le justifier.

a+

(edit : j'ajoute un petit graph qui explique le principe)

et j'ajoute qu'en terme de référencement on évite aussi le risque le le "petit" site soit mieux positionné par Google que le "gros", ce qui serait carrément désagréable
Modifié par Arsene (20 Oct 2008 - 12:00)

Arsene a écrit :
et j'ajoute qu'en terme de référencement on évite aussi le risque le le "petit" site soit mieux positionné par Google que le "gros", ce qui serait carrément désagréable

Éventuellement, si les contenus sont strictement identiques il suffit d'avoir les pages alternatives en disallow dans le robots.txt. Ou via des META qui vont bien. Ainsi les recherches pointent toujours vers des pages «normales», qui elles-mêmes proposent de consulter la version adaptée si pertinent (via détection du viewport).

Sinon, pour la problématique de l'adaptation des contenus et de leur éclatement... on peut faire ça de manière semi-normalisée + automatisme comme tu le suggères, ou directement dans le CMS.
Modifié par Florent V. (20 Oct 2008 - 15:30)

Salut,
merci Arsene de partager ta technique d'intégration, ça a l'air intéressant (je n'ai pas encore tout lu )
Comment fais tu pour détecter le navigateur sans JS? via PHP?
Il se peut que j'ai d'autres questions à te poser quand j'aurai tout lu.

Ma vision du webmobile a peu évolué, c'est vrai qu'il y a maintenant une absence de frontière nette entre media screen et handheld. J'ai souvent un train de retard concernant l'adoption et l'assimilation des dernières techniques/technologies.
Du point de vue des récentes évolutions du marché oui on peut dire que le media handheld n'est plus pertinent mais il est encore utile si on s'en tient aux implémentations actuelles des navigateurs mobiles.
Modifié par Hermann (21 Oct 2008 - 00:05)

Hermann a écrit :
Comment fais tu pour détecter le navigateur sans JS? via PHP?

Mélange de JS et media-queries. Voir cette discussion avec Patidou.
L'utilisation de JS n'est pas problématique puisque par défaut le mobile servira handheld si il sait ce que c'est, sinon il utilisera scrren par défaut.

Concernant handheld la question n'est pas celle de sa pertinence ou pas (après tout le W3C a toute légitimité à produire de la norme pour tous), elle est qu'un fabriquant profite de sa notoriété et de son sens du marketing pour ne pas en tenir compte et sortir à grand bruit un mobile qui n'en tient pas compte. Du coup on est confronté à un choix : ignorer handheld désormais, ou monter un commentaire conditionnel (un de plus....) pour les UA récalcitrants. C'est la solution retenue en rajoutant une détection de viewport : Apple a bloqué celui de l'iPhone à 940px.

Ok merci Arsene.

Ok bon après lecture de ta méthode, même si celle-ci semble très pertinente, c'est de toute façon trop compliqué à mettre en place pour moi, je ne fais pas de PHP... Je préfère m'attacher aux aspects de la conception que je connais déjà plus ou moins, ou moins techniques.
Merci quand même
Modifié par Hermann (23 Oct 2008 - 20:04)

Au risque de faire un peu de cross-posting hors-sujet, l'état de la réflexion chez Xerox au PARC de Palo Alto en avril dernier :
PDF à télécharger (EN - 1.4Mo)

Les pages 9 à 14 montrent comment un document se découpe en unités sémantiques pour réorganiser le flux (Reflow) par un genre d'OCR, comment ces unités se taggent (Keyphrases), et comment se met en place un truc qu'ils appelent CBAZ = Content based automatic zooming (Zoom automatique basé sur le contenu) qui permet au mobile d'afficher l'intégralité d'un contenu de façon plus utilisable.
La techno est sympa et assez juste sur le fond (elle ne notifie pas de couche graphique spécifique mais s'appuie sur une sémantisation structurelle du contenu web) mais a pour inconvénient principal de charger l'intégralité de la page, ce qui me paraît quand même un problème.
Sinon je trouve la démarche globale multi-supports assez intéressante. Le concept flou (nuage bleu) de "Seamless Documents" (documents sans coutures/unis/d'une seule pièce) est plutôt rigolo.

(par contre je ne suis pas arrivé à lire l'anim de la page 15 donc je ne sais pas ce qu'on y voit...)
Modifié par Arsene (28 Oct 2008 - 14:32)