Le menu structuré : un archaïsme

Nous avons trop souvent l'habitude de structurer un site Web selon l'ancienne méthode, c'est-à-dire avec des catégories principales, une hiérarchie. Il n'est qu'une vision rigide de l'organisation ; une grille de lecture imposée par le développeur.

À cause de (ou grâce à) l'hypertexte, le menu n'est plus une structure unique, mais un maillage qui peut s'attaquer selon différents angles.

Ce maillage prend peu à peu sa place à travers les tags, qui proposent souvent une autre façon de naviguer.

Cependant, nous sommes encore trop attachés à nos habitudes pour abandonner le menu classique par thèmes, au risque de perturber les internautes.

Ce menu par thème, rigide et prédéfini, nous oblige à conserver un certain nombre de vieux réflexes qui compliquent grandement le processus de génération et de navigation. Nous devons gérer le menu multidimentionnel en parallèle du menu classique, ce qui fait une double maintenance.

C'est un peu plus compliqué et très souvent inutile si le menu dynamique est bien réalisé.

Maîtriser son code

La première des règles du développeur ou de l'administrateur est de contrôler le code qu'il génère.

Il est toujours étrange d'entendre un informaticien (professionnel) dire : je ne sais pas, c'est la machine/le framework qui génère/gère.

Ça ne devrait jamais arriver.

C'est parce que l'utilisateur n'avait pas la main sur le code que le mouvement Open Source est né.

En tant qu administrateur ou développeur de site Web, la qualité du code produit doit correspondre, au caractère près, à ce que vous avez décidé. Et si ce n'est pas le cas, vous devez pouvoir le changer.

Alors il faudra se creuser les méninges. Mais plus vous développerez de bouts de code et de modèles, plus les développements à venir seront rapides. Le plus difficile est de commencer, après ça roule tout seul. La machine est là pour vous aider.

Utiliser le X(HT)ML

Même si le HTML reste encore la référence dans l'imaginaire collectif, il n'est pas le format d'avenir.

Le format d'avenir est le XML. C'est pourquoi le W3C motive son usage (HTML transitionnel, strict, …).

La version XML du HTML est nommée XHTML. Il ne s'agit ni plus ni moins qu'un vocabulaire spécifique, hérité du HTML et orienté Web. Les navigateurs sont optimalisés pour interpréter ce format.

Ses avantages sont l'eXtensivité, c'est-à-dire l'ajout de dimensions, et sa syntaxe XML, c'est-à-dire l'usage d'une syntaxe souple et stricte à la fois.

Et cette syntaxe permet de relier la structure de la page à un ensemble incroyable de possibilités. Avec le format XML (ou XHTML), il est possible de passer la page à la moulinette et d'en extraire ce qu'on veut, en général par une ou plusieurs transformations XSL. Mais pas seulement.

Il est, par exemple, possible de :

• extraire les mots-clef ;

• extraire les menus de navigations ;

• convertir la page en un autre format (Docbook, PDF, Latex, …) ;

• extraire les informations sémantiques et alimenter une autre application avec (cf. GRDDL) ;

• …

Vous pouvez utiliser par défaut le format XHTML, ce qui nécéssitera peu de transformations pour produire un document final, mais vous pouvez utiliser d'autres formats, comme Docbook.

Séparer la structure de la forme

L'information visuelle n'a aucun intérêt pour la machine. Elle ne sait pas ce que c'est. Et cette information visuelle est souvent très complexe à traiter. Un document Word docx en est un parfait exemple.

La présentation est souvent (et doit être) la dernière étape du processus de création. C'est la couche de laque sur le tableau.

L'utilisation du XML permet de séparer la structure et l'information de la présentation et de vous faire gagner énormément de temps.

Séparer les opérations

Ce qui oblige souvent à employer du Web dynamique pour afficher des éléments statiques est le fait que nous mélangeons les opérations de natures différentes. Nous voulons inclure du menu dynamique dans un article (statique par définition).

Il faut donc concevoir le site de façon plus large, avec recul, en séparant les opérations selon leur nature : le statique d'un côté et le dynamique de l'autre.

En définitive, vous aurez un site ressemblant schématiquement à :

Informations

Source : source (.graphml)

Auteur : ccompagnon

Construire ses règles de transformation

En règle générale, le UX designer construit le modèle de document pour réaliser son site (lorsque celui-ci n'est pas déjà imposé). Il répond à la question Qu'est-ce que je veux présenter ?

Ceci est juste lorsqu'il ne s'agit que de Web, c'est-à-dire de la partie interactive homme-machine.

Mais cette consruction n'est pas efficace si vous voulez aller plus loin.

La première question à se poser n'est pas Qu'est-ce que je veux présenter ? mais Qu'est-ce que je veux pouvoir en faire ?

Cette question apportera comme réponse une solution technique, c'est-à-dire un bout de code qui remplira sa fonction et atteindra votre objectif. Votre objectif n'est pas que le lecteur lise l'article, se repère dans les menus. Ça, c'est accessoire. C'est important, c'est primordial même, mais cela ne nécessite aucune intelligence. Aujourdhui, la plupart des outils de conception web le font très bien (en réalité : très mal d'un point de vue informatique, mais c'est invisible la plupart du temps).

Car l'important d'une information n'est pas l'information elle-même, mais ce qu'on peut en faire. Une information dont on ne peut rien faire n'a aucune valeur (au sens personnel et humain, pas au sens capitaliste).

Lorsque nous lisons une information, l'interprétation que nous en avons provient de ce que nous pouvons en faire. Si je comprends une information c'est que, d'une façon ou d'une autre, j'ai pu et su en faire quelque chose. En cela, elle a de la valeur.

Lorsqu'un designer travaille l'apparence d'un site, il cherche à donner de la valeur à l'information et s'occupe préférentiellement de l'expérience utilisateur, mais beaucoup moins de l'expérience développeur. D'autre part, cette valeur est généralement limitée à l'humain. La machine ne peut rien en faire.

Quel intérêt que la machine puisse en faire quelque chose ? Traiter l'information automatiquement. Et c'est là que de bout de code prend tout son sens.

Si je veux pouvoir charger mon agenda à partir d'un événement contenu dans une page Web, il faut un bout de code pour ça. Et il faut aussi que la structure sous-jacente soit adaptée. L'expérience prouve que cette structure façonne plus la page Web que la présentation car l'efficacité du bout de code dépendra de l'efficacité de cette structure.

Il faut donc penser d'abord à ce que vous vouler faire de l'information pour constuire le code qui va la récupérer. Si ce code est inédit, alors il faudra un certain nombre d'essais et d'erreurs avant de trouver la structure optimale. Mais une information qui ne peut pas être récupérée est une information qui ne sert à rien.

Nous se déduisons donc :

1. Les règles de transformation (règles métiers) impliquent le code.

2. Le code implique la structure adaptée (code + structure = règles techniques).

3. Toutes les structures mises bout à bout forment le modèle de votre document, auquel vient s'ajouter la partie UX.

Élaborer des procédés

Une fois que vous avez construit vos règles de transformation, vous disposez d'un ensemble d'outils, de bouts de code, chacun faisant une chose.

Pour exécuter toutes ces règles, vous devez le faire à la main, dans un ordre bien précis, tel une recette de cuisine.

L'informatique permettant d'automatiser les choses, vous devez vous simplifier la vie en automatisant les opérations, c'est-à-dire en élaborant des procédés, que vous connaissez peut-être mieux sous les anglicismes process ou worflow.

Il s'agit d'enchaîner les exécutions des règles de manière automatique afin de dérouler toutes les transformations dans l'ordre.

Informations

Source : source (.graphml)

Auteur : ccompagnon

L'élaboration de ces procédés nécessite un système capable d'exécuter des procédés.

Ce peut être natif au système, comme le shell UNIX, ou supplémentaire comme XProc. L'objectif étant de choisir celui qui vous sera le plus agréable et le plus souple à l'usage.

Il peut être local, sur votre machine de développement, ou distant, sur un serveur. Le choix final appartenant souvent à l'usage multi-utilisateur. Si vous êtes seul, alors vous aurez tendance à exécuter les procédés en local. Si vous travaillez à plusieurs, vous devrez incorporer votre travail dans un ensemble plus large de documents et les procédés devront s'exécuter sur ce corpus complet.

Les règles techniques élémentaires

Dès le départ, il faut penser à tout. Mais il est difficile, voire impossible, de penser à tout. Imposez-vous donc la discipline élémentaire suivante, pour laquelle vous développerez le code adéquat :

• Chaque document doit être généré depuis un modèle (et seulement depuis un modèle. Pas de modification manuelle). Cela permet de vérifier a minima que la structure XML est correcte et que toutes les autres transformations fonctionneront.

• Chaque modèle doit être identifié par une version (par exemple la propriété softwareVersion de schema.org ou juste la propriété version de schema.org).

• Chaque document doit être attaché à un modèle (le document généré doit comporter quelque part le modèle et la version qui l'a généré).

• Chaque document généré doit être validé par des règles automatisées afin de vérifier sa conformité (la conformité évite la fragmentation et les exceptions, ce qui simplifie les migrations).

Composition de la source

La source est le premier document qui sera produit après l'intervention humaine. Elle peut être composée entièrement à la main, dans un éditeur de texte ou à partir d'un autre langage.

Que doit-il y avoir dans la source ?

Pour faire simple : tout ce qui ne peut pas être déduit. C'est-à-dire (de façon non exhaustive) :

• Le contenu de l'article (structure incluse : paragraphes, titre, …) ;

• les métadonnées de l'article : auteur(s), contributeur(s) ;

• les métadonnées des sous-éléments de l'article : images, vidéos, …

• la sémantique : dates, lieux, personnes, références, …

• les mots-clefs.

Pour des raisons pratiques, le format de la source est le XHTML permettant de disposer de la puissance du XML tout en permettant un affichage rapide dans un navigateur pour tester le rendu et valider le contenu (correction).

Composition du modèle

Le modèle est la transformation qui prend la source et génère son rendu final après validation de la conformité de la source.

Il s'occupe d'ajouter tout ce qui peut être déduit ou paramétré : titre principal, insertion des menus et des composants supplémentaires (publicités, scripts, …), ajout du bas de page (footer), génération des sémantiques supplémentaires (OpenGraph,…), etc.

Génération et gestion des parties dynamiques

Une fois qu'on dispose de l'article statique, il faut s'occuper de la partie dynamique (normalement unique puisque tout est rassemblé dans un seul et unique mécanisme), c'est-à-dire celle qui change en fonction de l'exploration de l'internaute.

Sauf cas exceptionnel, dans la grande majorité des cas, cela se limite aux menus.

Les menus de navigation sont générés exclusivement à partir des données statiques des articles ou de leurs sources. Toute modification d'une source entraîne une recompilation des menus.

Comme nous l'avons vu, gérer les menus de façon multidimentionnelle à partir des mots-clef nous simplifie grandement le travail car nous n'avons besoin que d'une petite application qui prend un paramètre (le mot-clef recherché) et renvoie la liste des articles associés, avec un petit résumé du contenu.

Cette seule et unique application gère la navigation à elle seule, de façon dynamique. Elle n'est juste qu'une base de liens. Elle ne gérera aucun contenu et n'en génère aucun.

Elle ne tient qu'en quelques lignes de codes : elle est donc facile à développer, facile à maintenir et rapide à s'exécuter.

Si le nombre d'articles est faible (200 à 300), la base de données sous-jacente peut être sous forme de fichiers. Si le nombre d'articles est plus conséquent, elle peut être sous la forme d'une vraie base de données ou sous la forme d'un sous-ensemble de métadonnées (en général, un grep suffit pour obtenir ce sous-ensemble).

L'utilisation des menus

À présent, tous les mots-clef sont en base (ici un fichier XML). Voyons comment l'interroger.

À partir des mots-clefs, vous pouvez créer une page web (statique) qui référence tous les mots-clef.

À partir des mots-clefs de chaque article, vous pouvez intégrer ceux-ci soit en début soit en fin d'article de façon automatique à la génération, soit par l'usage d'un lien comme :

Ce lien fait référence au script tag.sh et lui passe en paramètre tag=CSS, qui sera analysé de la façon suivante :

Il ne reste plus qu'à rechercher simplement toutes les pages contenant le mot-clef CSS et les afficher dynamiquement, soit par une requête sur la base de données, soit par un filtre :