Sitemap pour une navigation hybride Christophe Vuilleumier http://tecfa.unige.ch/perso/staf/vuilleum/ 2spam@isuisse.com 25.06.04 11.07.04 SVG XML XSLT sitemap cartographie métainformation navigation sémantique carte de site Dans le cadre de ce projet, j'ai choisi de développer une sitemap "hybride" interactive, représentant ma homePage à Tecfa, et permettant de naviguer au sein de celle-ci. Cette sitemap est dite "hybride" car elle permet une navigation tant opérationnelle que sémantique. Cette dernière a pour but de mettre en évidence l'aspect collaboratif du diplôme Staf, dans lequel s'inscrit le cours pour lequel ce projet est développé. Dans ce sens, elle fait apparaître les relations relative au champ sémantique de la collaboration, existant entre les différents éléments. Au niveau développement, le contenu est indépendant de la présentation. De cette manière, il est possible de faire varier le contenu selon les besoins sans avoir à se soucier de la mise en forme. Ou inversement. Ainsi, l'ensemble des étudiants Staf de la volée Jolan pourra réutiliser les fichiers développés et se créer ainsi une sitemap adaptée à leur besoins. Le contenu (structuré en XML) est transformé en SVG par une feuille de style XSLT, gérant la partie mise en forme. Lorsque l’on visite une ville, un lieu qui nous est inconnu, 2 cas de figure (au moins) sont possibles. Ou l’on est un aventurier et l’on aime se promener « au hasard » des chemins et des découvertes, ou alors on préfère (ou l'on a besoin) de se repérer, de savoir où on se trouve, comment aller à tel endroit, ce qu’il y a d'autre à voir, etc. Dans ce cas-là, il est agréable et utile de pouvoir consulter une carte, un plan. Il en est de même lorsque l’on visite un site web que nous connaissons peu ou prou : une carte du site se révèle un outil fort pratique pour se repérer et savoir ce qui se trouve à proximité.
Dans cet article, j'utiliserai le terme "sitemap" qui est plus concis que "carte de site" ou "plan de site" ; les francophones puristes voudront bien m'en excuser !
J'en profite encore pour préciser que, par soucis de praticité, j'emploie le masculin de manière "générique", indépendamment du genre.

Une sitemap ? Qu'est-ce que c'est ?

Une sitemap est un modèle représentant la structure d'un site web. Ce modèle peut être textuel, chaque lien étant représenté par un ou plusieurs termes ; les termes peuvent également être représentés par des images (abstraites ou non), etc.
Les sitemaps ne sont pas à confondre avec les indexes de sites. Chacun comble un besoin spécifique d’information. Les sitemaps fournissent une vue fortement "top-down" permettant de se faire une bonne représentation de la hiérarchie, par exemple, alors que les indexes de sites (simples listes alphabétiques) sont "plats" et permettent surtout une recherche alphabétique.
Les sitemaps constituent une forme de moyen de navigation que l'on pourrait qualifier de "supplémentaire". Les sitemaps ne se suffisent pas à elles-mêmes, elles ne sont pas autonomes. Elles "travaillent" de concert avec les moyens de navigation "standards". Imaginez un site web qui n'aurait, pour tout système de navigation, qu'une page représentant par des liens l'ensemble des pages disponibles. Quel capharnaüm ! et quel boulot pour y retrouver son chemin ! Et à chaque page visitée il vous faudrait revenir en arrière, repasser par la sitemap pour vous rediriger ailleurs ... Impensable ! En revanche, en tant qu'outil auxiliaire elles fournissent un bon moyen de visualiser et comprendre la structure d'un site. En ce sens elles peuvent se révéler fort utiles si l’utilisateur a par exemple de la peine à comprendre l'organisation d'un site ou à trouver son chemin.

Afin de se faire une idée de la diversité de ce qui se fait dans le domaine des sitemaps, on peut par exemple consulter le très riche Atlas des Cyberespaces, qui consacre une section aux cartes de sites web ; ou encore ce site, qui présente divers types de sitemaps (textuelles, imagées, etc.) générées tant par des machines qu'"à la main".

Mais si elle ne se suffit pas à elle-même ... qu'apporte-t-elle ?

"Où suis-je ?" est censé être la première question à laquelle une carte devrait pouvoir répondre. Cependant, sur le Web, cette question est fortement concurrencée par une autre : "Qu'y a-t-il d'autre à voir ?", et son corollaire : "Comment y arriver ?" C'est là l'avantage de la sitemap : apporter quelque chose en plus de la possibilité de simplement "naviguer" de manière standard, opérationnelle. Contrairement à un simple listing représentant tout ce qui est disponible sur le site (comme le font certaines prétendues siteMaps qui sont en fait des indexes et présentent une telle quantité d'information qu'il devient difficile d'y trouver ce que l'on cherche sans parcourir le tout), le but d'une sitemap est double. D'une part montrer les relations existant entre les éléments ; d'autre part, donner de l'information sur l'information elle-même. Cela peut être fait de nombreuses façons : variation de couleurs ou de formes, dessins de lignes ou de flèches entre certains éléments, regroupement d'éléments, etc.

Un des aspects les plus importants à prendre en considération lorsque l'on construit une sitemap est celui de l'utilisateur. Quelle est l'expérience que l'on désire lui faire ressentir ? Que recherche-t-il en naviguant sur ce site ?

Deux cas de figure se rencontrent :
Une navigation sémantique ?

On distingue habituellement deux types de navigation :

En utilisant un mode sémantique de navigation, en choisissant les relations que l'on veut mettre en avant on peut guider l'utilisateur et ainsi lui proposer des chemins qui sinon lui seraient peut-être restés inconnus. De plus, c'est un bon moyen de lui donner un aperçu de se qui se trouve également à disposition et qui pourrait l'intéresser.

Développer une sitemap ?

Lorsqu'il s'agit de développer une sitemap, comme avant toute chose, il s'agit de savoir ce que l'on veut faire ... et pourquoi. Dans mon cas, il a fallu que je prenne en compte un facteur de plus, et non des moindres : ce que j'allais être capable de faire ! En effet, un des buts de ce projet était de faire connaissance avec SVG et de me perfectionner en XSL(T).

Une sitemap pour quel site ?

Pour commencer, il a s'agit de décider du site pour lequel j'allais développer cette sitemap. Et pourquoi. Cela a déterminé un certain cadre au sein duquel il a fallu évoluer.
J'ai choisi de prendre ma HomePage à Tecfa comme cible pour ce développement. Nous verrons plus loin que c'est plus particulièrement la "page travaux" qui m'a intéressé.
La raison en est la suivante : le cours au sein duquel ce projet s'inscrit fait partie du diplôme Staf. Cette formation est en partie basée sur l'apprentissage collaboratif. Et c'est précisément cet aspect collaboratif que j'ai voulu mettre en avant. J'emploie le terme "en partie" car certains cours sont suivis de manière individuelle et les produits qui en sont issus sont bien évidemment rendus individuellement (Staf 12, Staf 14). Pour d'autres cours encore, le mode de travail (individuel/collaboratif) était à choix (Staf 13, Staf 16, Staf 17 et Staf 18).
D'une manière générale, si l'on parcours les pages travaux des étudiants de la volée Jolan, on constate que (quand la page est à jour, ce qui est loin d'être le cas la plupart du temps ;) la balise permettant de spécifier si un travail a été effectué avec quelqu'un d'autre ("Participants") n'est que très peu utilisée (par moins de la moitié des personnes). De ce fait, une personne extérieure pourrait très bien ne pas se rendre compte de cet aspect et passer complètement à côté. De plus, je pense que cet aspect fait partie intégrante de la formation que nous avons suivie et de l'expérience que nous avons vécue durant cette première année et je trouvais dommage qu'il ne transparaisse pas plus. J'ai donc voulu pallier cette faiblesse. J'ai également voulu montrer les relations existant entre les différents cours : certains ont les mêmes enseignants et les mêmes assistants, d'autre les mêmes assistants mais d'autres enseignants, ... les combinaisons sont variées !
La sémantique que j'ai décidé de mettre en place, et en avant, est donc la collaboration.
Le "centre" du dispositif est donc constitué de la "page travaux" permettant l'accès aux différents cours, exercices et produits réalisés durant cette première année. Autre partie importante : celle que j'ai appelée "Jolan's" et qui regroupe les liens vers l'ensemble des HomePages de mes collègues.

Les relations sémantiques que j'ai retenues sont :

Pour un cours :
Pour un enseignant
Pour un assistant :
Pour un produit :
Pour un étudiant Jolan :
Le choix de la sémantique a fortement influencé la construction de la sitemap car je voulais que ce dispositif soit également utilisable pour une navigation non-sémantique : pour rechercher un élément particulier. De ce fait, pour permettre à la fois une navigation sémantique tournant autour de l'aspect "collaboration" et à la fois une navigation opérationnelle, hiérarchique permettant la recherche spécifique, j'ai décidé de développer une sitemap que je qualifie d'hybride.

Hybride ?

En quoi cette sitemap est-elle hybride ? J'utilise ce terme pour exprimer le fait qu'elle permet à la fois une navigation sémantique, et à la fois une navigation hiérarchique. Ceci afin de porter égale attention aux deux avantages fondamentaux que peut apporter une sitemap : d'une part permettre la recherche d'un élément en particulier et d'autre part permettre à l'utilisateur de se faire une idée de ce qu'il peut y avoir d'autre à consulter, suivant une logique sémantique prédéfinie.
Pour une recherche spécifique, il est utile de comprendre la structure du site et en cela une vision hiérarchique est favorable. La navigation sémantique, elle, est à même de donner un aperçu de ce qu'il y a d'autre à consulter.
Pour satisfaire cette volonté, il fallait que ma sitemap soit à la fois hiérarchique, et à la fois sémantique (autant dire non-hiérarchique ...) !
Pour permettre cet hybridisme, la sitemap a une structure hiérarchique, qui se "déploie" à mesure que l'utilisateur l'ouvre ; cette structure est augmentée de liens sémantiques, s'affichant au survol des boutons concernés.

En forme ? mais ... laquelle ?

Il existe de nombreuses façons de représenter la structure d'un site web : treemap, cone tree, hyperbolic tree, dome tree, etc. Il n'est pas possible de dire "Voici comment devrait être une sitemap !" ou de déterminer quelle forme est la meilleure ; chaque type a son utilité, et ses avantages. Il s'agit de faire son choix en fonctions de ses objectifs.
Pour ma part, j'ai choisi d'utiliser un diagramme en arbre, à même de représenter le plus "intuitivement" la hiérarchie et la structure. Nous avons déjà tous eu à faire avec un arbre généalogique, par exemple. Nous savons intuitivement que la relation "haut - bas" représente la hiérarchie et celle "gauche - droite" les alternatives. C'est un "background" dont j'ai voulu profiter pour rendre plus "familier" le dispositif et sa prise en mains.

Vous avez dit "ergonomique" ?

"A site map should not be a navigational challenge of its own. It should be a map."

Comme le souligne Jakob Nielsen (2002), "Une carte de site ne devrait pas être un challenge de navigation en elle-même. Elle devrait être une carte."
Avant tout, pour atteindre ses objectifs et être utile, il faut que tout utilisateur, aussi novice de l'utilisation d'un tel "outil" qu'il soit, puisse rapidement le prendre en main et s'en servir efficacement. Il est donc impératif que son utilisation soit rapidement et simplement compréhensible ; en deux mots : intuitive, ergonomique.
C'est un aspect qui a primé dans les choix faits durant tout le processus de développement. Ceci en devant également composer avec la volonté de proposer un résultat "esthétiquement plaisant". C'est une concurrence qu'il n'est pas toujours facile de gérer ...

Considérations graphiques

Je dois rappeler ici que le graphisme n'a pas été ma préoccupation principale. Celle-ci était, je l'ai dit, de me familiariser avec SVG et de travailler mon XSLT.
De plus, dans un soucis d'ergonomie, j'ai voulu un graphisme très sobre, sans frous-frous, pour éviter l'effet "Las-Vegas" : une multitude de petits effets visuels qui n'apportent rien et au contraire détournent l'attention de l'utilisateur. Pour finir, le graphisme est à la hauteur de mon manque de talent graphique, tout simplement !
Je reviens plus longuement sur les aspects graphiques et leur influence sur l'ergonomie dans la partie Discussion de ce travail.

Et ... comment s'y prendre ?

Savoir ce que l'on désire faire et pourquoi est une bonne chose, mais encore faut il savoir comment !

Séparer le contenu de la présentation

Dans le cadre de ce projet, j'ai décidé d'utiliser une "philosophie" qui commence petit à petit à se faire sa place et qui est porteuse d'avenir : séparer le contenu de la forme. Rendre indépendants ces deux aspects a un avantage principal : vous pouvez modifier à l'envie (ou au besoin) le contenu sans avoir à vous occuper d'adapter la présentation. De même, à partir d'un même contenu, on peut générer des formats de présentation différents. Le langage XML permet une telle séparation. Il a l'avantage de permettre, à travers une feuille de style XSLT, de générer du SVG, un format graphique dont nous verrons plus loin des avantages.

Vous avez commandé un XML accompagné de sa DTD ?

Commençons par nous préoccuper du contenu. Comme annoncé plus haut, celui-ci est séparé de la présentation : il est contenu dans un fichier XML.
Pour information ou pour rafraîchir les mémoires, voici en quelques mots ce qu'est le langage XML.

XML est, depuis début 1998, une recommandation du W3C (World Wide Consortium ; consortium indépendant à but non lucratif, pour des standards ouverts) (avec une révision mineure en octobre 2000). Le W3C le présente ainsi : "Le format universel pour les documents et les données structurés sur le Web".

On peut dire que XML est une version allégée de SGML (lui même le grand frère du HTML, norme ISO depuis 1986). Contrairement à HTML, XML est un langage dit "ouvert". On entend par là qu'il est possible de créer ses propres balises. C'est en fait un langage qui permet de définir des formats de documents pour ensuite créer des documents respectant les formats prédéfinis. XML n'est donc pas en lui-même un format de document. Ce n'est pas non plus un langage de remplacement pour HTML. Il est considéré comme un "méta langage".
La force de XML réside dans le fait qu'il est capable de décrire n'importe quel domaine de données, grâce son extensibilité : il permet de structurer syntaxiquement les données qu'il contiendra.

La différence principale entre XML et HTML ? Ils ont été développés dans des buts différents :

MISE EN PAGE
XML est un format qui permet la description de données, non pas leur présentation. C'est un langage tiers qui assure la mise en page. Il existe différentes solutions pour mettre en forme un document XML :
STRUCTURE DES DOCUMENTS XML
Il est possible de contrôler et vérifier la syntaxe d'un document XML à l'aide d'un fichier DTD. Celui-ci décrit la structure des documents qui y font référence, dans un langage spécifique. Un document XML doit obligatoirement suivre les règles de notation XML ; en plus il peut devoir suivre une syntaxe spécifique, décrite dans une DTD.

DECODAGE D'UN DOCUMENT XML
L'extraction des données du document s'effectue à l'aide d'un outil appelé "analyseur", plus connu sous la francisation de son nom : parseur (de l'anglais "parser"). Le parser a une double utilité :Dans le cadre de ce projet, c'est Instant Saxon qui est utilisé, une version réduite de Saxon qui intègre parser (AElfred parser, de Microstar) et processeur XSLT. Nous verrons plus loin l'utilité d'un processeur XSLT.

LES AVANTAGES DE XML
La puissance de cette norme réside dans sa simplicité.
Vous prendrez bien une petite XSLT ... pour arriver à vos fins !

Nous avons vu que le document XML ne contient que les données. Soit. Mais alors qui va se soucier de la présentation ? XSLT ! Voici en quelques mots ce qu'est et ce que peut faire XSLT.

XSLT est un dialecte de XML. C'est, avec XSL-FO, une des deux composantes de XSL. C'est un langage de transformation de documents XML en d'autres documents XML. Son complément (XPath) permet de définir des parties d'un document XML.
Nous avons vu plus haut qu'un document XML peut être représenté comme une structure arborescente. XSLT permet la transformation de documents XML par l'entremise de feuilles de style contenant un certain nombre de règles de gabarit (terme traduit, peu usité ; on lui préfère l'original : "template rules").
Chaque "template rule" définit un traitement à effectuer sur un élément (noeud) de l'arbre source.
A l'aide du processeur XSLT (Instant Saxon, dans le cas de ce projet) une structure logique arborescente est crée à partir du document XML. Celle-ci est appelée arbre source. Par la suite, l'ensemble des "template rules" définies dans le fichier XSLT sont appliquées à cet arbre source pour produire un arbre résultat.
L'arbre source peut être complètement remodelé, filtré, transformé (on peut ajouter ou supprimer du contenu), tant et si bien que l'arbre résultat peut être très différent de l'arbre source.
Le document produit (output) peut, nous l'avons vu plus haut, être en PDF, XHTML, SVG, WML, etc. Nous allons maintenant voir l'avantage du format graphique SVG et pourquoi il a été choisi dans le cadre de ce développement.

Je vous sers le tout en SVG ?

SVG est une recommandation du W3C depuis septembre 2001. A partir de là, il s'est très vite placé comme concurrent de Flash.
SVG (Scalable Vector Graphic) est une grammaire XML permettant de définir des graphismes vectoriels en 2D pour le web et d'autres applications (le format SVGT [SVG Tiny] est par exemple destiné aux téléphones cellulaires et autres PDA). SVG a été inventé en 1998 pour répondre à un besoin de graphiques légers, dynamiques et interactifs. Il est issu d'un groupe de travail regroupant, entre autres, Micro$oft, Kodak, Adobe, IBM, Sun Microsystems, Netscape, Xerox, Apple, ...
SVG a de nombreux avantages comparé aux autres formats d'image, et particulièrement JPG et GIF, qui sont les formats graphiques les plus utilisés sur le web aujourd'hui.
En voici les principaux :

Au niveau de la conception :Au niveau du rendu graphique :
L'inconvénient principal de SVG ? Sa jeunesse.
Le plug-in nécessaire au visionnement d'images SVG est encore peu répandu et n'existe simplement pas pour certains.
Dans le cadre de ce développement, j'ai utilisé le plug-in 6.0 beta d'Adobe.
Au niveau développement également, SVG soufre encore d'un manque d'outils (d'autant plus de gratuits).

SVG est le format graphique que j'ai choisi pour ce développement : il sera obtenu par transformation XSLT à partie du document XML.

Et ... concrètement ?

Il me faut tout d'abord spécifier que le temps m'a manqué pour arriver au terme de ce développement. Cependant, une version "allégée" du dispositif est disponible ; celui-ci est fonctionnel, bien qu'il ne comporte qu'une partie de ses fonctionnalités finales : ce dispositif ne permet actuellement qu'une navigation opérationnelle. La partie "sémantique" de la navigation n'a pas pu être achevée au moment de la remise de cet article.
Je tente cependant d'expliquer quelles sont les fonctionnalités absentes et comment elles devraient se présenter.

Les différents éléments sont les suivants :
  • Le fichier DTD contenant les règles de syntaxe pour le fichier XML
  • Le fichier XML contenant toute l'information concernant ma HomePage utile au développement de la sitemap
  • Le fichier XSLT contenant les règles de transformation du XML en SVG
  • Le fichier SVG : le dispositif à proprement parler (navigation opérationnelle uniquement)

Lorsque la page contenant le fichier SVG est chargée, elle affiche uniquement un cercle représentant ma HomePage :
Il faut ici que je précise un élément qui est constant pour tout le dispositif :
  • Lorsque vous cliquez sur une forme, cela "ouvre" le noeud correspondant
  • Lorsque vous cliquez sur du texte, cela charge l'url correspondante
Pour inciter l'utilisateur à faire la différence entre les deux, les formes changent de couleur lorsque la souris les survole :
De même que le texte :

Lorsque l'utilisateur clique sur le bouton [MOOmin's] (mon pseudo sur le MOO) représentant ma HomePage, cela commence à déployer le dispositif : d'une part le bouton MOOmin's remonte et devient mi-transparent de manière à montrer qu'il n'est plus sélectionné et d'autre part les boutons constituant le niveau un cran inférieur s'affichent : StAF, représentant ma "page travaux" et "JOLAN's", représentant les liens vers les HomePages de chacun des étudiants de la volée Jolan.

Ensuite, s'il clique sur le bouton "JOLAN's", les deux boutons initiaux "glissent " vers la gauche de manière à ce que le bouton JOLAN's se retrouve au centre du dispositif, signalant en cela qu'il est "sélectionné" (le bouton StAF devient également mi-transparent). D'autre part, cela fait apparaître les formes représentant la HomePage de chaque Jolan :
Par choix esthétique, le texte ne s'affiche pas automatiquement et les formes formant les boutons ne sont pas différenciées. Ce n'est qu'au survol de la souris que la forme sélectionnée se différencie et que le texte/lien s'affiche :


Si en revanche l'utilisateur clique sur le bouton "StAF", l'ensemble glisse cette fois-ci vers la droite jusqu'à ce que le bouton StAF soit au centre :

Les boutons représentant chaque cours Staf apparaissent alors :
A nouveau, il faut les survoler pour que le texte/lien apparaisse :

Il en va ensuite de même pour les boutons représentant chaque exercice de chaque Staf :
/
On remarque que cette fois, le texte correspondant au Staf sélectionné apparaît également au même moment, ceci par soucis d'ergonomie afin que l'utilisateur sache en permanence de quel staf est tel ou tel exercice.
Il en est de même lorsque la souris survole un bouton représentant un produit :




Ce qui n'a pas encore été développé :
Le temps m'a manqué pour pouvoir développer la partie sémantique de la navigation. De ce fait, seule la relation a été implémentée.
Devra être ajouté :
  • La relation "Egalement effectué avec"
    Lorsque l'utilisateur survolera un bouton représentant un Jolan, il verra apparaître des liens vers l'ensemble des produits effectués en collaboration avec le Jolan en question. Qu'il survole ce bouton dans la partie JOLAN's ou lorsqu'il apparaît au survol d'un produit.
  • La relation "Enseigné par"
    Lorsque l'utilisateur survolera un bouton représentant un cours Staf, cela affichera un lien vers la HomePage de l'enseignant de ce cours.
  • La relation "Enseignant également"
    Au survol d'un bouton représentant la HomePage d'un enseignant, cela affichera un lien vers les pages d'accueil des autres cours donnés par cette personne.
  • La relation "Assisté par"
    Lorsque l'utilisateur survolera un bouton représentant un cours Staf, cela affichera un lien vers la HomePage de l'assistant de ce cours.
  • La relation "Assistant également"
    Au survol d'un bouton représentant la HomePage d'un assistant, cela affichera des liens vers les autres cours pour lesquels cette personne est assistante.
  • La relation "En collaboration avec"
    Au survol d'un produit ayant été réalisé en collaboration avec un autre Jolan, un bouton représentant la HomePage de la personne s'affichera et permettra ainsi d'en charger l'url
  • L'affichage du nom complet au survol
    Lorsque la souris survolera les différents éléments, leur nom s'affichera sous forme de bulles : nom du cours, de l'exercice ou du produit


La sitemap sera accessible depuis chacune des pages constituant ma HomePage à Tecfa, sous forme d'un lien "siteMap". Jakob Nielsen et Donald Norman, ont constaté lors d'une étude que 63% des sites avec sitemap avaient choisi ce terme. Il me paraît donc bénéficier de l'avantage de la familiarité, dont je compte profiter.
La sitemap se lancera au moyen d0une fonction Javascript, dans une petite fenêtre aux dimensions calquées sur celles du dispositif. Cette fenêtre sera "minimaliste" : pas de barre de liens, ni de barres d'état, ni de boutons, bref le strict minimum afin qu'elle ne prenne pas trop de place sur l'écran. Les liens ne se chargent pas dans la même fenêtre mais directement dans celle contenant ma page travaux.



Comme je l'ai dit, je regrette d'avoir été juste au niveau temps. J'ai en effet eu beaucoup de plaisir à développer ce qui a été fait et je pense qu'avec encore un peu de travail cela peut être un outil très pratique et atteignant tout a fait ses objectifs.
Comme je l'ai dit plus haut, le dispositif actuel est déjà 100% fonctionnel, même s'il lui manque les fonctionnalités liées à la navigation sémantique. Cependant, le fait qu'il soit déjà fonctionnel est un élément qui a son importance, car cela rend possible une analyse nettement plus poussée que s'il était "inutilisable".

Je discute ici les tenants et aboutissants de ce projet. Je tente également de déterminer ce qui pourrait, à l'avenir, être amélioré.
Je commencerai par passer en revue les différents éléments constitutifs du dispositif pour finalement m'intéresser à celui-ci, notamment à son ergonomie. Je précise d'emblée que je ne compte pas réaliser une analyse ergonomique digne de ce nom, mes prétentions étant bien plus modestes : simplement m'assurer de l'utilisabilité générale auprès de quelques utilisateurs potentiels.



DTD (& XML)

Je n'ai que peu à dire sur la DTD.
La cible de la sitemap étant ma HomePage, il fallait que je puisse en décrire chaque élément en regard des choix que j'ai faits concernant la sémantique. Chaque élément constituant le dispositif est décrit dans la DTD, il comporte un ou plusieurs attributs, selon les besoins structurels ou sémantiques du dispositif.
La DTD a évolué durant le développement, en fonction des besoins, notamment au niveau de l'architecture. J'ai commencé par une version un peu allégée, qui s'est étoffée à mesure que le dispositif se développait. J'ai par exemple transformé un partie des éléments en attributs d'autres éléments, pour les reprendre plus facilement dans le document Xslt.
J'ai ajouté quelques attributs dans un but purement fonctionnel. A titre d'exemples, SVG n'étant pas pratique pour le positionnement (au pixel !), pour faire en sorte que les groupes d'exercices et de produits soient horizontalement centrés par rapport au dispositif, j'ai dû utiliser des constantes selon le nombre d'éléments. Ces constantes sont définies dans des attributs spécifiques : exs_x, pour les groupes d'exercices et prods_x pour les groupes de produits.

Je dirais de cette DTD qu'elle est sobre mais efficace. Elle n'est ni compliquée ni très sophistiquée, cependant elle définit bien les contours du document XML et en cela atteint un des buts de ce développement : que tous les étudiants Jolan puisse "réutiliser" les fichiers et ainsi se créer une sitemap adaptée à leur HomePage ; la DTD en sera le "cadre".

Quand au fichier XML il contient toutes les informations nécessaires au développement de la sitemap. Les données sont bien évidemment authentiques et reflètent véritablement ma HomePage à Tecfa.


XSLT

Le fichier XSLT est celui qui m'a posé le plus de difficultés. J'ai tout d'abord eu de la peine à concevoir ce dont j'avais besoin, ce qui m'a amené comme je l'ai dit à modifier l'architecture de la DTD pour l'adapter aux besoins "techniques".

D'une manière générale, j'applique une "template rule" à chaque élément se trouvant dans la DTD, pour en spécifier les caractéristiques de présentation. Pour les éléments de la DTD ayant plusieurs occurrences dans le document XML (les exercices, par exemple) je me sers de l'instruction <xsl:for-each> qui permet de générer une "boucle" faisant afficher autant de représentations que se trouvent d'éléments dans le XML.

Je dois bien avouer que pour certains points, le code pourrait être plus propre. En fait, je me suis de temps en temps retrouvé face à des impasses "techniques", blocages dont j'ai quelques fois eu de la peine à trouver la raison ... et donc la solution. De ce fait, pour m'en sortir, j'ai parfois un peu "bricolé" le xslt ... Il est possible que le code soit donc plus "lourd" qu'il n'aurait pu l'être.
Cependant, du moment où le SVG se génère "tout seul", je pense qu'il est acceptable de produire "plus de code que nécessaire". Ceci tant que la taille du fichier SVG ne s'en retrouve pas exponentialisée, bien évidemment !

Pour ce qu'il reste à développer du dispositif, je ne me fais pas vraiment de "soucis". Ce ne sont en effet pas des problèmes techniques mais le manque de temps qui a été le véritable obstacle. De ce fait, je pense savoir comment terminer le dispositif, ce que je compte effectivement faire. J'y reviens dans la partie Conclusion.


SVG, graphisme et ergonomie

Pour ce qui est du SVG en lui-même, comme je l'ai dit, je suis loin d'être un artiste et j'ai préféré ne pas me lancer dans un graphisme compliqué dont je n'ai pas les moyens. Graphisme qui, en plus d'être esthétiquement limite, risquait de porter atteinte à l'utilisabilité du dispositif. C'est pourquoi j'ai opté pour la simplicité. Mais je désirais pourtant que cela soit esthétiquement agréable, attirant et agréable d'utilisation. De ce fait, j'ai préféré jouer avec les formes et les couleurs, avec l'opacité des éléments, etc. pour arriver à un résultat le plus ergonomique possible.
Par exemple, par désir esthétique les différentes formes et textes mettent 1 seconde à s'afficher entièrement (c'est en fait leur opacité qui est modifiée), mais les zones cliquables le sont dès le début, par soucis d'ergonomie. J'ai porté un soin tout particulier à ce qu'aucun choix esthétique ne vienne entraver l'ergonomie.

Je l'ai fait "tester" à quelques personnes (en son état actuel de développement). Comme je l'ai dit plus haut, je n'ai pas prétendu à une véritable analyse ergonomique. Simplement m'assurer du fait qu'il fonctionne et que des utilisateurs potentiels puisse apprendre rapidement et sans trop de difficulté à s'en servir.
Les résultats sont satisfaisants, car aucune "malfaçon" n'a été relevée. J'entends par là qu'aucun problème au niveau du fonctionnement n'a été signalé. De plus, toutes les personnes ont dit avoir apprécié le graphisme, également pour sa simplicité. Petit "problème" esthétique : dans la partie Jolan, les boutons restent parfois fois en jaune si la souris passe rapidement verticalement sur les noms de étudiants. Dans le même ordre d'idée on voit parfois (pendant une fraction de seconde) des formes qui sont en train d'être effacées, ce qui n'est pas du meilleur effet.
L'ergonomie ne semble pas avoir posé de problème car ces utilisateurs ont rapidement su s'en servir pour naviguer au sein des exercices, produits et autres éléments de ma HomePage. J'ai cependant peur que cela reste un peu abscond pour une personne extérieure. Je l'ai en effet testé avec des personnes qui savaient que je faisais cette formation et en cela les résultats sont peut-être quelque peux biaisés. En tous les cas il serait nécessaire de réitérer ces "tests" avec des personnes totalement étrangères à cette formation. Je n'en ai malheureusement pas eu le temps à ce jour.
Dans le cadre d'un développement plus poussé, il serait également nécessaire de mener une véritable étude ergonomique, digne de ce nom.

Cependant ce fait, je dois avouer être assez content du résultat. En effet je pense avoir réussi à allier esthétique et ergonomie, pour un efficacité maximum, sans pour autant que cela ait notoirement compliqué le développement.

Améliorations possibles

Bien qu'il y ait de nombreuses améliorations à apporter à ce dispositif et mise à part les fonctionnalités liées à la navigation sémantique, j'ai essayé de lister ici les principales améliorations à apporter. Que chacun se sente libre, à la lecture de cet article, de me communiquer toute remarque utile à l'amélioration de ce dispositif ...
  • Que l'on sache où l'on se trouve : que le dispositif indique la page consultée actuellement
  • Qu'il soit 100% "automatique" : que les réglages pour la mise en page se fassent entièrement automatiquement. Pour l'instant il est nécessaire de spécifier un ou deux paramètres "à la main". Du coup un Jolan aurait à "adapter" quelques variables à ses besoins. A l'avenir cela ne devrait pas être nécessaire
  • Que les pages s'ouvrent directement dans la page où se trouve le lien Javascript lançant le dispositif (pour l'instant il ouvre une nouvelle fenêtre au premier click ; ensuite tous les liens s'ouvrent dans cette même fenêtre)

En conclusion, je voudrais tout d'abord dire le plaisir que j'ai eu à me lancer dans ce projet, dans ce développement. Raison pour laquelle je regrette d'autant plus de ne pas être arrivé au terme de celui-ci. Car je suis convaincu qu'avec encore du travail ce dispositif peut s'avérer vraiment utile et efficace dans les buts qu'il s'est fixé ; c'est pourquoi je compte bien terminer le dispositif en lui apportant les fonctionnalités sémantiques qui lui manquent.
Je suis d'autre part satisfait d'avoir travaillé mon XSLT car je n'avais jamais utilisé ce langage pour produire du SVG et je pense avoir beaucoup appris à ce niveau-là. Cela a été fort utile et j'en ai encore bien plus à apprendre que je n'en ai déjà appris !
Finalement, je suis ravi d'avoir découvert SVG. C'est un langage dont les possibilités (associé à d'autres techniques) sont tellement vastes que cela donne envie de s'y plonger ! D'autre part, je viens de découvrir les recommandations SVGT (SVG Tiny) pour les téléphones cellulaires et SVGB (SVG Basic) pour les PDA et autres assistants électroniques. Je dois avouer que j'ai bien envie de m'y essayer ... The problem(s) with sitemaps XML @ W3C.com Maps of Abstraction Navigation opérationnelle et sémantique SVG Viewer 6.0 beta (Adobe) Research into Tree Visualisation Introduction to SVG @ sun.com Quelques principes pour une navigation sémantique Sitemaps: map the user's experience Site Map Usability (Jakob Nielsen, 2002) Site Map Usability Guidelines (Nielsen & Norman, 2002) Sitemaps and site indexes : What they are and why you should have them. SVGfr.org Web Site Maps from Dynamic Diagrams NetLingo: The Internet Dictionary SVG Named Color Codes Instant Saxon Learn DTD @ w3schools.com Tutoriel SVG @ pilat.free.fr Sitemaps : What to Do ? Learn XML @ w3schools.com Learn XSLT @ w3schools.com Learn XPath @ w3schools.com XML @ coverpages.org XML @ allhtml.com XML @ laltruiste.com XSLT @ w3c.org XSLT - Le langage de transformation de documents XML SVG Open KevLinDev SVG Tutorials Scalable Vector Graphics: The Art is in the Code Interactive, dynamic Scalable Vector Graphic