La navigation

Un site Web conséquent pose le délicat problème d'une navigation facile, claire, mais gérable par le webmaster. Il n'existe évidement pas de solutions toute faite pour résoudre ce problème. Voici cependant quelques pistes de réflexions.

Au menu ce soir ...

La plupart des sites n'ont rien trouver de mieux qu'un menu pour présenter leur système de navigation. Je parle évidement des sites importants (avec de nombreuses pages) et dynamiques (mis à jour régulièrement). Les sites "représentatifs" (genre: mon entreprise est sur Internet: voici mon logo, mon adresse et mon adresse email, mais je ne sais pas encore très bien comment on utilise le mail) n'ont pas de problème de navigation, puisque quasiment pas de pages sur lesquels naviguer.

Un site scout classique, que ce soit celui du national, celui d'une Codépie ou celui d'un groupe, est nécessairement très structuré. On trouve une section pour chaque unité ou chaque branche, etc. L'approche consistant à découper son site en fonction des centres d'intérêts du visiteur (s'agit-il d'un scout, d'un chef scout, d'un ancien scout, d'une personne extérieure au mouvement), que j'ai dû introduire en 1997 sur le site de Ferney et que le National a choisi par la suite sur son site ;-) est également courante. Le problème de la navigation est donc très présent sur les sites scouts.

La première manière de résoudre ce problème est de l'ignorer ! Comme sur de trop nombreux sites, on met un bouton Back qui ramène à la home page sur toutes les pages, et le problème est résolu. On peut même essayer les boutons Back, Home, Next, avant de se rendre compte que sur un site dynamique avec de nombreuses pages, c'est tout bonnement ingérable, même avec un bon éditeur HTML comme Dreamveawer.

La deuxième manière de résoudre ce problème consiste à utiliser un menu fixe. Il trouvera avantageusement sa place dans une frame à gauche de l'écran dans la plupart des cas, ou en ayant recours à des SSI dans des cas plus rares. Dès que le site est conséquent et que la frame du menu scrolle sur des kilomètres, on se rend compte que cette solution n'est pas adaptée à la taille du site.

La troisième approche est relativement similaire, on utilise une applet Java dans une frame (comme sur le site du National ou sur la précédente version du site de Ferney). J'aurais tendance à dire que c'est la bonne solution, à quelques détails prêt:

• il faut déjà trouver ou développer une applet qui ait des fonctionnalités sympas quelques soient la plate forme, le browser, etc...
• il est sympa que cette applet s'adapte aux dimensions de l'écran de l'utilisateur, ce qui est rarement le cas.
• la hiérarchie du site est transmise à l'applet par un format généralement propriétaire (et non des liens), et si on veut que les moteurs de recherches indexent correctement le site, il faut faire une autre page avec tout le sitemap en liens, ce qui est difficile à gérer si le menu de navigation n'est pas stocké dans une base de données.
• enfin, l'utilisation des frames est vivement déconseillé par les professionnels.

Les frames

Les frames facilitent grandement le travail de développement d'un système de navigation. Pourtant, les professionnels et les sites professionnels (Apple, Microsoft, Adobe, etc..) y ont rarement recours. Pourquoi ? Principalement à cause des utilisateurs novices qui ne savent même pas ce qu'est une frame.

• si depuis le menu Favoris de IE, vous ajoutez un favori sur une page contenant des frames, c'est la frame principale qui est gardée en mémoire.
• de même, l'utilisation des boutons Impression et Refresh est délicat pour un utilisateur novice sur une page framée.
• certains moteurs de recherche ne suivent toujours pas les liens définis dans un frameset.
• lorsqu'un moteur de recherche renvoie une de vos pages à l'issue d'une requête de l'utilisateur, il manque la navigation si votre site utilise des frames. Vous avez intérêt à avoir un bouton home sur chaque page qui pointe sur la page de définition du frameset, ou un Javascript client qui réoriente l'utilisateur directement vers la bonne page avec son menu de navigation.
• enfin, si vous avez un look très "découpé", sachez que Netscape, selon les plate-formes et les versions, attribut aux frames des dimensions assez aléatoires (vous demandez 250 pixels de large, et vous obtenez 240 pixels sur PC, 260 pixels sur Mac, etc).
• la barre de titre du navigateur ne change pas au cours de la navigation.

Ce ne sont là que quelques-uns des reproches que les professionnels font aux frames. On constate assez rapidement que sur tous les gros sites, les frames ne sont utilisées que lorsqu'elles ont une réelle plus-value. C'est le cas de MSDN Online. Non seulement la plupart des problèmes présentés ci-dessus sont résolus par un mélange de scripts clients et serveurs assez gratinés, mais en plus, le contenu du menu se charge au fur et à mesure de la navigation dans les menus. En outre, une synchronisation du menu en fonction de la page actuelle est possible. C'est donc un petit bijou de navigation, géré par une usine à gaz !

L'approche du site de Ferney

Alors attention. La conclusion de cet article n'est évidement pas: le site de Ferney est parfait, faites pareil ! D'autant plus que, les connaisseurs l'auront remarqué, l'interface de navigation est en gros celle du site de Microsoft. J'ai fait le choix de ce système pour les raisons suivantes:

• une double navigation (barre horizontale et barre verticale) est fonctionnelle. Comme le site n'a pas beaucoup de menus de premier niveaux, mais beaucoup de sous-niveaux, on a moyen d'organiser ainsi une information très structurée.
• on évite les frames et tous les développements Javascript qui vont avec.
• la surface occupée par la navigation par rapport au contenu est quasiment optimisée.
• on ne charge que la navigation nécessaire pour la section en cours (les menus sont "contextuels").
• le tout est, à mon point de vue, assez esthétique, sans nécessiter de charger beaucoup d'images uniquement pour la navigation.
• enfin, moyennant certaines astuces de développements, toute la navigation tient dans un seul et unique fichier; étant centralisée, elle est beaucoup plus simple à gérer pour moi, et le site est d'autant plus évolutif et dynamique.

En fait, chaque article du site est dans un fichier ASP autonome. Tous les ASP des articles sont rigoureusement identiques. Ils comprennent un appel à une fonction (Body();) qui génère le header et toute la navigation, l'article proprement dit, et un autre appel de fonction (EndBody();) pour générer le HTML de bas de page. Aucun paramètre particulier n'est transmis à ces fonctions. En modifiant 2 fonctions, je peux donc modifier toute l'interface du site, sans avoir à modifier individuellement les ASP de chaque article.

Les connaisseurs remarqueront tout de suite qu'il y a un problème: comment afficher des menus contextuels si on ne transmet pas le contexte aux fonctions via une variable ? En fait, on connaît le contexte, tout simplement grâce à la position de l'ASP dans l'arborescence du site. L'ASP de cet article par exemple se trouve sous /site/techno/, autrement dit, section A propos de ce site, sous-section Les conseils d'un pro. En analysant le chemin d'accès d'un article, il est alors possible de régler tous les paramètres de l'interface (look via les feuilles de style et navigation) pour chaque section du site depuis une seule fonction.

On obtient ainsi un site uniformisé mais personnalisable, avec une gestion entièrement centralisée, ce qui peut permettre d'envisager sans trop de crainte de gérer facilement une centaine de pages Web.