Votre blog sur un téléphone portable, really ready ?

Des fois c’est facile, des fois… pas facile. Pourtant, un site web ou un blog devraient être accessibles depuis n’importe quel périphérique, y compris un téléphone portable. Après la lecture du billet de Nico, j’ai testé mon blog sur le site .mobi qui a évalué ma page d’accueil sur une échelle de 1 à 5 en fonction de sa lisibilité sur un petit écran, de sa taille et de l’estimation de sa vitesse (ou coût) de chargement. Le tout en une trentaine de tests. Strict is the way…

Comme vous pouvez le constater, avec une note de 2 sur 5, mon blog n’est pas mobile ready. A cause notamment du marquage XHTML non valide au regard des possibilités de traitement des navigateurs embarqués. Au moins ais-je échappé à la shame frame ^^

Le résumé des tests est sans appel, mais plein d’enseignements : un lien sur chaque élément pris en compte détaille les raisons de l’échec. Sans oublier les avertissements ou les commentaires sur les spécificités non bloquantes à prendre tout de même en considération pour une meilleure accessibilité de mon contenu sur ces petits appareils.

Résultats des tests

Ce blog échoue donc lamentablement à sept d’entre eux :

1. La page n’est pas conforme à XHTML-MP (wap 2.0, formulation de XHTML à l’usage des périphériques mobiles), ni même à un autre langage comme :
   • i-mode (cHTML)
   • wap 1.0 (WML)
2. Le marquage XHTML n’est de toute façon pas valide ! C’est vrai que j’ais laissé la DTD Strict Made in Dotclear alors que je devrais mettre une DTD Transitionnal. (c’est fait depuis la capture),
3. Taille des images. Au moins une image n’a pas de hauteur ou de largeur spécifiée,
4. Mesures. Des dimensions spécifiées en pixel ou de manière absolue sont détectées dans la feuille de style,
5. Feuilles de style. Mon utilisation des feuilles de style n’est pas en accord avec les bonnes pratiques. L’usage des styles en ligne en est principalement la cause. Mais aussi l’utilisation des balises sup ou del mal prises en charge par les navigateurs mobiles,
6. La taille de la page (en incluant les images et les feuilles de styles) est trop importante : si le code HTML se stabilise à 68 ko, la page complète pèse dans les 277 ko… Depuis, j’ai remplacé Prototype et script.aculo.us par la Splash Box de Xuxu pour l’effet lightbox, et j’ai installé jQuery en version compressée pour le reste : j’ai économisé plus de 50 ko,
7. La page est liée à trop de ressources externes, (images, feuilles de styles et autres objets) ce qui ajoute du temps au chargement de la page.

Avertissements et commentaires

Grâce à ces derniers, j’en ai appris davantage sur les éléments à prendre en compte lorsqu’on veut cibler les navigateurs embarqués dans les appareils mobiles. Répétez avec moi :

1. J’évite de concevoir mes pages web avec des propriétés display ou float,
2. Je garde sur un coin du bureau un post-it pour me souvenir que la plupart des périphériques mobiles ne supportent pas Javascript,
3. Je mets le focus sur les champs input pour faciliter la saisie, et je fournis des valeurs sélectionnées par défaut,De toutes manières, étant données les limitations typiques des formulaires sur les appareils mobiles, une interface utilisateur devrait autant que possible en minimiser l’usage,

   Lorsque c’est possible, je privilégie les checkbox, radio, et autres button qui ne nécessitent pas de saisie fastidieuse,

4. Je me retiens d’utiliser des tableaux qui sont par nature difficiles à rendre sur ces petits appareils,
5. J’utilise les accesskeys sur tous les liens,
6. Pour finir, je place un fichier sitemap.gz à la racine du site. Chez moi il s’appelle sitemap.xml… je changerais le nom à l’occasion.

Résumé

Pour être mobile ready un site web devrait donc :

1. Posséder un code XHTML non seulement valide, mais conforme au XHTML-MP, ou en tout cas débarrassé de certaines balises comme sup, del, ou table,
2. Spécifier les dimensions des images,
3. Abandonner les unités de mesures fixes (sauf peut-être pour les images) au profit des unités relatives comme em, ex ou %,
4. Éviter les styles CSS en ligne comme style= »border: 0; » par exemple,
5. Limiter (voire supprimer) les liens vers les ressources externes comme les scripts, ou les balises object,
6. Etre léger, léger…

Malgré le haut-débit et la puissance des processeurs, l’allègement des pages web est toujours d’actualité

Le poids des mots, le choc des photos

Faire un site adapté aux périphériques mobiles ne se limite pas à modifier quelques balises et à en supprimer d’autres. Car même en ne visant que les navigateurs compatibles WAP 2.0, le poids total des pages handicape la plupart des blogs et des sites web.

Toutefois, rien n’est gravé dans le marbre et il est toujours possible d’alléger la page. A cet égard, le choix d’une librairie Javascript légère et évolutive est essentiel. Nous faisons trop souvent comme si le chargement des éléments tels que les CSS ou Javascript dans le cache du navigateur à la première requête, nous autorisait à être léger sur l’accessibilité et à avoir la main lourde sur les effets graphiques ou les animations.

Suite à ces tests, je me suis rappelé que chaque jour, près de 75% des visiteurs venaient ici pour la première fois, et qu’une partie non négligeable, repartait après la première page vue. Ces visiteurs-là n’ont pas le temps d’apprécier les bienfaits de la mise en cache par le navigateur ! Reste l’étude de la mise en cache via PHP qui pourrait — avec compression gzip — faire l’objet d’un autre billet.

L’avenir appartiendrait-il aux flux Atom et RSS…

On peut envisager de détecter le navigateur et décider de charger ou non ces ressources, mais cette approche ne règle pas les autres particularités des navigateurs embarqués concernant notamment les propriétés float. Et encore je ne parle même pas des unités de mesure trop souvent définies en pixels.

Pour moi, la solution se trouve du côté des flux Atom ou RSS qui vont à l’essentiel du contenu. A cet égard, j’ai trouvé I Feed You qui permet de convertir un fil RSS/Atom au format Wap et i-mode pour suivre l’actualité d’un site ou un blog très simplement depuis un mobile.

…avec du semacode dedans ?

C’est déjà pas mal. Mais sachez que nous pouvons épargner cette fastidieuse saisie de l’adresse du flux en question en utilisant les tags visuels de semacode.

Alors n’hésitez plus, et créez un code barre pour le flux RSS/Atom de votre blog. Il sera ainsi facilement accessible aux utilisateurs d’un mobile avec appareil photo.

PS : Si vous connaissez un bon lecteur de flux pour téléphone portable, ou d’autres solutions, c’est le moment de dégainer 🙂

Stay tuned and mind the gap!