Introduction
Lorsque le web a commencé a démarré auprès du public [avant le boom et le ‘bust’ des années 2000], il y a eu une période que l’on nomme désormais ‘The Browser Wars’ [la guerre des navigateurs], entre Netscape Navigator et le petit nouveau, Internet Explorer de Microsoft. Chacun implémentaient sauvagement ses propres balises [incompatibles et non-normalisées] ainsi que ces technologies propriétaires [ActiveX ?] dans son navigateur dans le but de gagner l’affection des développeurs et le public. Les différences étaient telles qu’il devenait courant soit d’adopter l’un plutôt que l’autre [d’où les badges – ce site est optimisé pour XXXX] 
ou de développer au moins deux versions d’un site afin de cibler les fonctionnalités de chaque navigateur. C’était une pratique gaspilleuse à la fois en temps et en argent. Mais c’était aussi une solution fragile car, souvent, en ciblant les navigateurs d’après le HTTP User Agent String, le navigateur était mis à jour avant le script de détection [qu’on appelait un ‘sniffer’ ou renifleur] – le résultat était que le serveur ne pouvait donner le contenu approprié et délivrait à la place un message disant que le navigateur était soit inconnu, soit trop ancien !
La pratique d’optimiser pour un navigateur donné, ou de créer de versions multiples d’un site, a cessé graduellement au fur et à mesure que le projet Web Standards s’est répandu en militant pour le respect des normes du Web, à la place des initiatives personnelles ou propriétaires. Récemment, Jeffrey Zeldman, un des initiateurs et évangeliseurs du projet a regardé en arrière pour constater du progrès accompli. C’est un article court et intéressant; allez le lire.
Pour la plupart, ceci est désormais un problème résolu. Nous pouvons désormais employer des techniques tels ‘progressive enhancement’ [amélioration progressive] afin d’adapter pour et prendre en compte des améliorations futures des navigateurs. Jeffrey Keith d’adactio a récemment posté en ligne une présentation qu’il a donné et qui fait le lien entre ces différents techniques, de fluid à responsive, la montée de la normalisation web, la flexibilité et adapatabilité du web, et comment aborder la suite. C’est très complet.
La fausse promesse du RWD [responsive web design – les sites adaptatifs]
Le design responsive de sites construit sur la notion de fluidité, toujours présent sur le Web, comme nous l’a rappelé Jeremy Keith, et la séparation de contenu [HTML], présentation [CSS], et comportement [JS] proné par le mouvement Web Standards. Proposé d’abord par Ethan Marcotte dans un article qui a fait date sur le site A List Apart, le design adaptatif pour des sites [RWD – responsive web design] utilise une possibilité de CSS – les Media Queries – afin de créer une présentation spécifique pour les différents appareils de consultation – TV ou desktop, tablette ou mobile… Le site MediaQueri.es est rempli d’exemples de ces adaptations.
Avant de poursuivre, il est utile de dire que je m’intéresse ici principalement aux sites [mais pas seulement] de contenu éditorial, poursuivant une série de réflexions à propos de la presse et autres contenus textuels dans un monde numérique.
Le [redoutable] Craig Mod a écrit une série d’articles qui examinent notre rapport avec l’écrit sur support numérique. Voir ici, et ici, mais c’est un sujet de réflexion constant pour lui, donc si le sujet vous intéresse comme il m’intéresse, je vous conseille fortement d’explorer les archives sur son site.
Dans un article qui, personnellement, m’a beaucoup intéressé, Mod propose différents ‘modes’ [ou contexts] pour la lecture. Il parle de lit, genoux, et petit déjeûner. En traduction, il parle d’une manière de faire une présentation responsive pour les eBooks et la lecture. Il propose que chaque moment crée le besoin d’une expérience spécifique. C’est un bon début, mais à mon avis, il ne va pas assez loin. À mon avis, chaque moment crée le besoin d’une manière différente pour recevoir et réagir au contenu, pas seulement la présentation. Ce que je propose renoue avec la notion de reniflement [sniffing] sur le web, mais dans ce cas, nous chercherions à détecter le contexte de lecture puis servir le contenu et une présentation adaptée.
Les lecteurs qui visitent un site aujourd’hui le font, de plus en plus depuis un appareil mobile. Bientôt, selon le site, ce sera majoritairement mobile. Nous arrivons au point de basculement et les choses ne peuvent qu’accélerer par la suite. Mais aujourd’hui, les sites sont encore créés pour un monde de desktop et de haut-débit, une pratique que le design responsive [RWD] encourage. Or, très souvent les appareils mobiles ont un débit limité et un contrat qui plafonne les données transférées, tandis que les sites envoient des pages lourdes [en images, scripts, publicités, traqueurs…] où une partie de ce contenu n’est pas affichée, et qui n’est pas optimisée ni pour l’appareil, ni pour le moment. Car le principe de base du RWD est de garder le même contenu, et de n’adapter que la présentation à l’appareil. Or, pour des appareils toujours allumés, toujours actifs, toujours connectés est de s’adapter à nos besoins plutôt que de reformater le meme contenu.
Vers un nouveau paradigme
Il est difficile [voire impossible] de parler en termes absolus, voilà pourquoi, en fin de compte, l’utilisateur doit toujours avoir la main sur la situation. Si le besoin ou la motivation est suffisement fort, il peut décider de lire sur un petit écran ou un écran de télévision. Les sites qui bloque les mobiles sur une version ‘optimisée’ mobile sans offrir la possibilité de changer sont aussi fautifs que les sites qui persistent à donner une version ‘haut débit’ à tout le monde. Ici, la notion de responsive est une solution positive justement parce que c’est toujours le même contenu, on ne limite pas les choix de l’utilisateur, et le designer peut préparer pour des écrans ou formes de présentation qui n’existent pas encore.
Mais les usages nous disent que, la plupart du temps, on n’emploie pas une tablette comme un téléphone mobile, ni un desktop comme une montre ou une télévision. Dès lors, il est intéressant d’essayer de comprendre le contexte de lecture, et les besoins du lecteur dans ce contexte.
D’après l’article de Craig Mod, je vais proposer que nous avons besoin d’au moins trois niveaux de lecture : Titres télégraphiques – ceux-ci devraient permettre au lecteur de balayer rapidement des données denses, et d’être informé par cette lecture ; le deuxième niveau serait un développement des titres, apportant un synthèse des informations de la suite, mais qui peut être assimilée rapidement en balayant le paragraphe ; le dernier niveau est l’article complet qui demande concentration et attention prolongée.
Le premier niveau de lecture est idéal pour des moments où l’on cherche simplement à balayer les informations pour saisir les actualités rapidement et globalement, par exemple, le matin, ou dans le métro, ou entre deux autres activités de la journée. Ça va de soi qu’un site ou app qui utilise ce type de système aura aussi besoin d’un filtre ou un outil de tri rapide, permettant au lecteur de bien cerner ses champs d’intérêt, ainsi qu’un système permettant de mettre des titres en réserve pour une lecture approfondie par la suite. La navigation [ou la bascule] entre ses trois niveaux doit aussi être intuitive pour le lecteur pour ne pas le perdre dans les complexités de navigation et d’interface.
Dans ce modèle, on comprend tout de suite qu’il serait gaspilleur de récharger l’ensemble des informations [ce qui peut se passer avec le RWD]. Au premier niveau, l’app ou le site ne ferait que de stocker du contenu qui n’aura que très peu de chance à être consulté, gaspillant ainsi la bande passante et le quota pour le transfert des données.
L’étape logique pour la suite serait donc un système de présentation selon le contexte de lecture et non pas la simplicité de ‘je change de vêtements mais je suis toujours pareil en-dessous’ du RWD.
Il y a un développement intéressant dans l’interface du dernier Nest, le thermostat connecté. L’interface détecte la proximité de l’utilisateur et varie et contextualise l’affichage. Comme je ne l’ai pas vu fonctionner, reste les questions de comment il fait pour gérer des spectateurs multiples à des distances variables, quel est le temps de rafraîchissement et de latence de l’appareil – mais c’est déjà un début d’approche. Et comme, je pense que le champ de recherche sera sur des appareils mobiles, qui sont, à priori, personnels, ces problèmes n’existent pas dans ce contexte.
À suivre demain.
— Image d’entête : On the tube par Julie Kertesz, sous licence CC BY-NC-ND
