Développement et Technologies
Mutabilité des "contenus mobiles"
10 mars 2008
Quelles solutions disponibles ?
Si les mobiles d'aujourd'hui sont capables d'afficher des contenus web "riches" (multimédia...) et même d'interagir avec des applis 2.0, les limites technologiques (faibles capacités de transfert), économiques (coût au mégaoctet chargé, au temps de connexion, etc.) et ergonomiques (petits écrans) rendent leur usage en tant que "viewer web" assez inconfortable et parfois très onéreux. Si les limites technologiques et économiques sont faites pour être un jour dépassées, la taille des écrans ne risque pas de tripler de sitôt, à moins d'abandonner la notion même de "mobile".
Concernant ces "mobiles" (on a tendance aujourd'hui à réserver le mot "portable" aux ordinateurs) on est donc confronté à une question spéciale qui est celle d'adapter les contenus web à leurs contraintes. En gros 3 solutions prévalent actuellement :
1. Créer des sites spécifiques (en .mobil par exemple, ou par un sous-domaine type "mobile.mon-site.com")
2. Afficher des interfaces web complètes et proposer des fonctions zoom... c'est notamment le cas aujourd'hui des iPhone d'Apple, Viewty de LG ou N95 de Nokia.
3. Préparer, en partant d'un contenu unique (et donc commun), une restitution particulière pour ces outils.
La première solution présente l'énorme inconvénient d'obliger au développement initial de deux interfaces puis d'avoir à les maintenir en permanence, avec des coûts de mise à jour, de mise en miroir, d'actualisation des contenus plus importants et des risques d'erreurs non-négligeables.
La seconde solution rend l'utilisation des documents web assez éprouvante et même parfois exaspérante : l'affichage d'une page intégrale rend les textes illisibles et oblige donc à zoomer par zone; une fois le zoom activé, il est pénible alors de devoir sans cesse scroller pour prendre connaissance du texte : revenir en arrière pour lire le début de la ligne suivante, rescroller vers l'avant pour en lire la suite, se rappeler de quoi ça parlait pour qu'au retour arrière suivant on reprenne la lecture à la bonne ligne... tout ça est franchement inconfortable.
La troisième solution consiste à utiliser une feuille CSS spécifique ( handheld la bien nommée...) pour générer un affichage en rapport avec les contraintes du support. Le premier gros inconvénient de cette solution CSS est que de nombreux mobiles (tel l'iPhone) ne reconnaissent pas cette feuille et afficheront donc le contenu en screen comme n'importe quel écran d'ordinateur 10 ou 15 fois plus grand... On retombe alors dans le cas de figure précédent. Le second inconvénient est qu'en l'absence de "filtrage" par handheld, c'est l'intégralité des contenus qui est chargée, y compris par exemple certaines images indispensables mais qui ralentissent et renchérissent temps et coûts de consultation.
Alors est-on condamné à attendre un miracle ?
Non. Une quatrième solution s'appuie sur l'idée qu'après tout il n'est pas nécessaire d'afficher l'intégralité des contenus d'un seul coup, et qu'on peut très bien scinder le document en plusieurs sous-documents de formats inférieurs à consulter un par un... et aussi qu'il n'est pas nécessaire non plus d'envoyer vers le mobile les éléments ne participant pas directement au sens du contenu, notamment ceux relevant de sa mise en forme.
Toute la difficulté consiste lors de la requête serveur à reconnaître qu'il s'agit d'un UA mobile et à lui proposer des contenus différenciés. A charge ensuite, dans la logique de non-discriminance d'accès aux contenus numériques, à l'utilisateur de décider quel type de contenu il voudra consulter.
Reconnaître qu'il s'agit d'un mobile peut s'effectuer par des media-queries. Une fois cette reconnaissance effectuée, il s'agit de proposer un affichage "spécial mobile" par un bouton ou un lien. L'utilisateur décidera alors si il veut consulter le document tel quel ou si il passera par ce service optionnel proposé. Jusque là rien de bien nouveau. Là où ça se complique, c'est qu'il faut parvenir à scinder le contenu unique en plusieurs morceaux. Rappelons qu'il n'est pas question ici de créer des sous-contenus indépendants, ce qui équivaudrait à créer autant de sous-sites à maintenance compliquée et à coûts de production élevés. Le concept d' industrialisation des process de production précise qu'on doit s'orienter à la fois vers l' automatisation et vers l' unicité du modèle de production : un seul modèle d'outil produit du contenu le plus automatiquement possible.
La question posée par la découpe du contenu unique en autant de sous-contenus que nécessaire se heurte à celle des outils de navigation permettant à l'utilisateur d'accéder à ces sous-contenus virtuels... un système de menus spécifiques devra donc être développé pour passer d'un sous-contenu à un autre pour garantir au final la prise de connaissance complète du document initial. Or ces menus ne sont pas présents dans le contenu initial !... A partir de là deux possibilités : soit les créer au moment de la fabrication du contenu (solutions CMS puis les masquer aux utilisateurs non-mobiles - ce qui représente là aussi des contraintes supplémentaires, des coûts associés et des accroissements de volumes-données transitant sur les réseaux -, soit de les créer à la volée et à la demande. Du coup, ce n'est plus le même contenu qui est envoyé à l'UA ! Il y a bien "mutation des contenus".
Quelques exemples :
1. Mon document est structuré en sections <h1>, <h2>, <h3> et <h4>. Je décide de maintenir la structure <h1> et <h2> en l'état (présentation par défaut) et d'opérer des découpes dès les niveaux <h3>. Par un script approprié (sur base regex PHP par exemple) je remplace tous les <h3> par un système de liste-menu <ul><li><a> (il y a donc bien mutation...) et extrait du contenu tout ce qui est structurellement inférieur à <h3> : h4, paragraphes, images, etc. Du coup j'affiche une sorte de page-sommaire présentant mes titres en h3 comme autant de têtes de rubriques renvoyant par un simple click aux sous-contenus non-chargés. Du coup j'ai limité temps de connexion et coût de chargement au minimum utile et nécessaire. Du coup j'ai trié et organisé dynamiquement mes contenus selon les capacités du couple UA-utilisateur. Du coup aussi toute la structuration sémantique de mon contenu prend son sens opérationnel : elle ne sert pas à "faire joli" ou à "faire accessible" ou à "faire pour les aveugles" mais à intervenir et interagir sur le contenu lui-même. C'est à ça que servent les contenus normalisés s'adressant à des outils normalisés.
2. Mon document contient des textes très longs parce que le développement du sujet abordé m'y oblige. Je suppose qu'un utilisateur d'ordinateur scrollera de sous-titres en sous-titres (ou qu'un utilisateur de synthèse vocale ou d'outils d'aide technique sautera de h[n] en h[n]...) pour se créer une image globale du discours développé et s'arrêtera là où il souhaitera consulter telle ou telle partie qui l'intéresse. Mais alors quid de l'utilisateur de mobiles ? Le contraindrai-je à péniblement défiler au stylet ou au bouton de navigation l'intégralité du texte, ou lui permettrai-je également de passer de volumes en volumes jusqu'à l'endroit qui l'intéresse ? Si je retiens cette dernière solution, j'opterai alors pour un protocole de restitution consistant par exemple à limiter l'affichage des paragraphes aux trois premières lignes ou aux 100 premiers mots, à charge pour lui, utilisateur, de décider si la suite l'intéresse ou pas. Il n'y a plus là d'interaction directe avec la structuration sémantique, mais interaction avec l'ergonomie de l'outil par la prise en compte de ses spécificités d'affichage restreint. (Variante : mon document contient de nombreuses images illustrant de façon pertinente les textes qui forment le contenu général. Ne pas accéder à ces images serait pénalisant pour la somme d'informations complémentaires qu'elles apportent ; d'un autre côté toutes les charger serait long et coûteux.)
En résumé la mutabilité des contenus consiste à s'appuyer sur la structuration normalisée de ces derniers pour les transformer en fonction de besoins spécifiques, ponctuels et particuliers, dont l'affichage sur mobiles n'est pas l'un des moindres. Les solutions "non-mutantes" (...par exemple jouer avec CSS et ses fonctions de display pour "masquer" des éléments de contenus) ne résolvent pas ces questions de restitution et d'utilisabilité sur mobiles dans la mesure où pour être opérantes le contenu doit préalablement être chargé, or tout l'enjeu est justement d'éviter ces temps et coûts ; d'où l'obligation de générer des contenus "mobiles" au niveau du serveur et non du client (UA). La différence entre une partie de contenu masquée et une partie de contenu non-distribuée prend alors tout son sens : dans un cas le contenu unique est restitué intégralement mais affiché partiellement, dans l'autre il est partiellement restitué mais intégralement affiché. C'est bien en cela qu'il y a "mutation des contenus".
