Part III – Quelles sont les attentes de l’utilisateur pour votre site Web? Cela dépend du contexte.

Comment savons-nous ce qui intéresse le visiteur d’un site?

Nous devons considérer différents points avant d’opter pour une solution par rapport à une autre;

La moitié de la population mondiale accède à Internet à l’aide d’un appareil mobile. Est-ce à dire que l’autre moitié consulte les pages d’un site depuis un écran large, ordinateur de bureau ou téléviseur?

Il est cependant beaucoup plus facile de pointer vers un QR code avec un smartphone pour obtenir plus d’informations sur un sujet plutôt que de devoir saisir une URL complexe, caractère par caractère.

Il est important de considérer que globalement, 3% des personnes ont un handicap sévère et 15% ont un handicap modéré à grave, sans compter que ces chiffres augmentent respectivement jusqu’à 10% et 46% lorsque nous nous concentrons sur la population âgée d’au moins 60 ans.

La situation d’handicap n’est pas uniquement liée à un état physique; Nous devons étendre cette idée à de nombreuses problématiques d’accès… tels que regarder une vidéo sans casque, ou sans haut-parleur, nécessitant nécessairement le recours à des sous-titres qui, lorsqu’ils sont présents, sont parfois écrits dans une langue non maîtrisée.

Saviez-vous que 25% des personnes utilisant Internet parle la langue chinoise et 27% est un public anglophone? Ceux qui parlent français, portugais, russe, coréen, arabe, allemand, japonais, espagnol représentent, chacun, environ de 3% à 8% des utilisateurs. Cela donne 32% d’utilisateurs qui ne parlent donc pas forcément ni chinois, ni anglais.

Donc, si un site Web possède des sous-titres, en quelles langues doivent-ils être proposés?

Et que disons-nous à propos des 16% des utilisateurs qui ne sont pas représentés dans les chiffres mentionnés ci-dessus?

Par ailleurs, en tant que développeur ou concepteur, vous risquez fort d’être équipé de la dernière technologie informatique, ou encore naviguer sur le Web à l’aide de la dernière mise à jour d’un navigateur hypra moderne.

Mais qu’en est-il de vos utilisateurs?

Peut-être qu’ils utilisent une version désuète d’un navigateur oublié, ou encore proscrit… et, dans ce cas, comment seront affichées vos pages Web? Que voient les utilisateurs de ces navigateurs non recommandés?

Un autre élément important que nous devons prendre en compte est que lorsque nous distribuons du contenu, de nombreuses pages seront imprimées. Pour infos, simplement en Europe, plus de 33 300 pages sont imprimées chaque seconde.

Allez… soyons cléments… et disons maintenant que l’utilisateur possède l’un des derniers smartphones à la mode, qu’il puisse accéder à une bande passante adéquate, qu’il ne rencontre pas de problèmes de lisibilité ou d’ergonomie et qu’il dispose de tout le temps nécessaire pour trouver l’information qu’il souhaite, mais (et il y aura toujours un mais), l’utilisateur peut être à court de batterie et que dans cette situation il ne puisse pas charger ou consulter correctement l’ensemble du contenu.

Cela crée un paradoxe. Tout d’abord, il n’est pas possible de diffuser un contenu différent et réduit en fonction de tel ou tel périphérique, et, d’un autre côté, il n’est pas possible de fournir des contenus globaux, qui soient prêts à tout, au risque de surcharger la bande passante.

La seule référence à prendre en compte, pour nous guider dans cette démarche, doit être la capacité du périphérique à présenter de l’information, la bande passante tolérée et disponible et surtout de toujours veiller à ce que l’utilisateur puisse accéder à un contenu qui corresponde à la même qualité d’information, indépendamment de son contexte d’accès.

Comment servir le contenu approprié en Responsive Web Design?

Les Media Queries et les Breakpoints sont une des solutions. Ce type de requêtes et ces points de ruptures sont utilisés pour indiquer lorsqu’une mise en page, ou présentation, doit être appliquée à la place d’une autre.

Mais, outre ces situations, nous devons également employer un algorithme plus avancé pour spécifier lorsqu’un contenu plus approprié doit être livré, et pas simplement se réduire à afficher ou masquer une zone.

Il est vrai que beaucoup d’articles associent souvent les Breakpoints, ou du moins leurs déclencheurs, à la taille d’affichage de l’appareil.

Mais nous devons comprendre que si ces points de commutation entre différentes options de présentation, peuvent certainement être définis par une largeur, ils peuvent également être pilotés par d’autres paramètres tels que: la résolution ou l’orientation de l’écran, le type de périphérique utilisé, le niveau de couleurs ou l’aspect monochrome, la langue parlée, etc.

Il existe de nombreuses autres possibilités qui nous permettent d’adapter la mise en page et la présentation, et ce, en fonction des capacités du périphérique et du contexte d’utilisation et non pas uniquement en fonction de la taille de l’écran.

Ce qui devrait être affiché … Ce qui ne devrait pas, et … Comment?

Une autre série de questions importantes qu’il faut se poser sur le contenu concerne sa nature.

Est-ce que le contenu contient des animations qui seront difficiles à imprimer?

Est-ce que le contenu s’appuie sur une multitude d’images qui nuiraient aux personnes malvoyantes et, d’autre part, nécessite forcément une attention toute particulière afin de répondre au mieux aux différentes résolutions d’écran?

Le contenu, utilise-t-il des technologies spécifiques comme le format SWF Flash, qui ne fonctionnera pas sur les périphériques basés sur IOs?

Est-ce que le contenu affiche un gros titre occupant deux lignes sur un écran large, mais qui alors devra s’étaler entre 5 ou 6 lignes sur de petits appareils? De plus, si l’appareil est en mode portrait, ce gros titre sera-t-il toujours suffisamment lisible, ou explicite en tant que tel?

Beaucoup de ces situations démontrent une inégalité de présentation en fonction du contexte.

Cela nous ramène au cœur du problème: le contenu doit-il être différent car il est consulté sur différentes plates-formes?

Non!

Alors si le contenu est identique dans chacun des cas, comment pouvons-nous gérer la partie qui sera non utilisée, masquée, ou adaptée ? Et donc, comment éviter un éventuel transfert de données inutiles?

C’est tout un paradoxe.

Comment écrire précisément et définir le contenu?

Nous devons également admettre que souvent les développeurs de systèmes d’information, ou les responsables en Stratégie de contenu, ne sont ni les auteurs, ni les intégrateurs, qui vont publier ce contenu.

Les développeurs et les créateurs de contenu doivent prendre en compte cette présentation adaptative des publications en fonction des contextes, et ce, dès la rédaction.

Les auteurs, quant à eux, doivent être formés, et surtout sensibilisés à ces nécessités adaptatives, et à cette stratégie de contenu.

Tout ceci nous amène à aborder la partie technique de cette série d’articles sur le RWD et comprendre tous les outils qui nous aideront à distribuer un contenu identique, quel que soit le contexte dans lequel il sera consulté.

Et pour cela, je vous invite à nous rejoindre dans un prochain article pour poursuivre cette exploration sur l’application RWD à nos contenus.