L’utilisateur hacker Vs les principes sémantiques.
La sémantique est la base même de toute notre communication. Pour autant, il existe entre l’idée et la publication, un utilisateur pour lequel nos systèmes complexes d’édition sont étrangers. Sa solution bien à lui ? Hacker le système afin de parvenir à la réalisation de son idée.
Notre capacité à communiquer est innée, tout du moins physiologiquement (capacité mécanique). Le fait même de communiquer en revanche, nécessite des acquis, obtenus par un apprentissage permanent.
Utiliser une interface de saisie, c’est comme parler une langue étrangère. Pour peu que nous ayons des difficultés à émettre une idée, nous réalisons un hack, un détournement. Et même si l’objectif est louable, cette situation peut rapidement devenir problématique. à posteriori
Mais avant, quelques définitions …
La sémantique est attrait au sens, à la signification (le signifié). Et cette branche particulièrement importante de la linguistique est dans notre cas la problématique première des outils de gestion de contenu : les utilisateurs ignorent son existance.
En fait, ils utilisent la branche symétrique de la linguistique qu’est la syntaxe, non pas dans un objectif de porter le message, mais uniquement de le représenter. Et là est toute la problématique.
En application, cela expose à des problèmes d’accessibilité (ex: l’attribut « alt » des images en HTML), de stockage et de parsage des données (compréhension par le code pour le manipuler), en SEO, …
Voyons plutôt …
Il existe une différence notable entre les systèmes et les visions des utilisateurs.
Un hack est une manipulation d’un système, de l’anglais to hack : tailler, couper quelque chose à l’aide d’un outil. En programmation, le hack est une solution rapide et bricolée pour contourner un problème, quel qu’il soit.
Dans notre cas présent, un hack n’est ni plus ni moins qu’une modification arbitraire du contenu en se basant uniquement sur sa visibilité et sa dispotion : sa syntaxe.
Prenons un exemple.
Dans l’idéal, le système est conçu pour répondre aux attentes de l’utilisateur en tous points.
Ici, imaginons un document que l’on souhaite modifié afin de faire une page de garde en centrant le texte horizontalement et verticalement. Le système dispose bien de ces fonctions. Il est donc aisé de travailler la disposition sans impacter la syntaxe.
Mais …
Mais dans la réalité, l’utilisateur n’a pas toujours connaissance de ces fonctions.
Il va donc passer par un « hack » pour arriver à ses fins.
Le résultat visuel est le même, mais le sens sémantique, lui se retrouve atteint puisqu’il s’agit d’une variation syntaxique.
D’ailleurs, j’ai déjà observé des utilisateurs imprimer ce fameux document, prendre une règle et mesurer pour s’assurer du centrage …
Sauf qu’il existe des cas ou ce hack peut poser de réels problèmes.
Imaginons un instant un site responsive dont on rédige le contenu disposé sur 3 colonnes en affichage desktop.
Certains utilisateurs vont concevoir l’aspect visuel en rédigeant ligne par ligne (et non colonne par colonne) leur contenu.
Voyez plutôt le résultat lorsque le site s’adapte sur de plus petits dispositifs : les parties supposées groupées ne sont visuellement plus associées. La syntaxe n’étant pas la bonne, les visiteurs ne comprennent plus le sens (la sémantique) du contenu.
Cette problématique concerne au final les machines, puisque ce sont elles qui doivent interpréter la syntaxe de ses utilisateurs pour reproduire en tous temps une sémantique.
Or nous retrouvons ces hacks utilisateurs dans bien des cas avec de multiples conséquences (notamment en accessibilité) :
- Les pages Kickstarter sont composées à 50% d’images pour remplacer les grilles, les tableaux et la personnalisation des couleurs. Un lecteur d’écran perd par conséquent 50% du contenu de la page
- L’absence de style pour souligner les titres le rédacteur du site d’un client a utilisé des caractères étoiles (« * ») pour générer ces lignes, à l’étoile près. Et lorsque nous avons fait les tests d’accessibilité, le lecteur d’écran lisait « étoile étoile étoile étoile étoile étoile étoile étoile étoile étoile étoile […] »
Prenons un instant pour comprendre ce qu’il se passe.
Un système comprend de nombreuses fonctionnalités offertes aux utilisateurs pour répondre aux contraintes. Cependant, l’utilisateur n’est pas systématiquement informé des contraintes.
C’est pourquoi les moyens mis à disposition ne sont pas forcément ceux employés. L’une des étapes importantes de l’utilisateur lors de l’utilisation du logiciel, c’est de se poser la question de « comment vais-je réaliser cette tâche ? ».
La question qui se pose donc, c’est de savoir si il existe une solution à cet utilisateur hacker ?
On pourrait envisager de réduire les possibilités de l’utilisateur, de fournir une documentation (n’est-ce pas déjà le cas ?), ou tout autre solution.
Mais si on résolverait nos problématiques engendrées par le hack, on ne règlerait pas le problème de l’utilisateur.
Alors non, il n’existe pas de solution universelle efficace.
Les systèmes évoluents constamment, l’utilisateur aussi, et il faut s’y adapter.
Cependant, pour réduire les hacks des utilisateurs, il faut penser à une solution.
Heureusement, nous savons pourquoi nous rencontrons cette problématique. Nous pouvons donc envisager des pistes de réflexion sur le modèle suivant :
Découverte -> apprentissage -> usage régulier -> utilisation experte
La première question à se poser, c’est de se demander si nous avons bien retiré les freins ?
Le système est-il adapté à l’utilisateur ? A-t-il les moyens de réaliser la tâche facilement sans immédiatement chercher un hack.
Bien entendu, on s’intéressera également au processus d’apprentissage.
L’algorithmie évolue depuis de nombreuses années. Et elle a encore un fort rôle à jouer dans l’objectif d’aider l’utilisateur.
Et des outils existent déjà en la matière :
- La correction typographique automatique et l’auto formattage en général;
- La détection automatique de contenu des images pour générer un texte;
- …
L’objectif ici est de faire le travail de l’utilisateur à sa place.
Mais il existe également un troisième levier sur lequel agir : la formation active de l’utilisateur.
On pourrait immédiatement penser à rédiger une doc. Mais qui lit la documentation du dernier appareil technologique qu’il vient d’acheter ? Pas grand monde …
Pour cela, nous pouvons alerter l’utilisateur (grâce à l’algorithmie vue précédemment) d’une problématique, et suite à cela, le guider pour corriger ces erreurs.
L’avantage de cette solution c’est qu’elle signale une problématique que l’utilisateur pourra éviter à posteriori. Il s’agit donc d’une formation au long terme de l’utilisateur, non seulement sur le système, mais sur la syntaxe et la sémantique.
Les utilisateurs d’interface de gestion de contenu omettent les attributs alt des images ? Inversent les niveaux de titres h1, h2, h3, … pour des raisons esthétiques ? Insèrent des caractères inappropriés ? Jouent avec des blocs qui ne sont pas prévus à cet effet ?
Et si ce n’était pas lié qu’à la configuration des éditeurs WYSIWIG et autres pages builders mais plutôt à une méconnaissance de la valeur des informations transmises par ces éditeurs ? Décortiquons le problème et analysons la situation et réfléchissons ensemble à comment mieux accompagner les contributeurs novices.