Prototype de navigation pour l’interface SPIP

Le bandeau supérieur actuel de l’espace privé n’est plus aussi satisfaisant. Il pose plusieurs difficultés, certaines bien connues et régulièrement décriées dans les forums des utilisateurs, et de nouvelles, liées à l’arrivée des plugins, de plus en plus nombreux sous SPIP 2.

Voici un prototype rassemblant mes idées pour améliorer cette navigation. Il s’agit d’un « prototype fonctionnel », c’est-à-dire un truc cliquable mais qui ne présume ni de l’aspect graphique ni de la qualité du code. Il propose aussi un ré-agencement éditorial des menus et des pages liées, qui reste discutable — certains intitulés, notamment, seraient à reformuler.

Je me suis surtout attachée à clarifier, occuper moins de surface sans rien omettre, tout en permettant de recevoir des items additionnels (ici signalés en gris clair) de façon extensible (ajoutés par les options et les plugins, toujours plus nombreux).

Progressons par enrichissements successifs

Avant d’essayer, notez que je conçois les choses dans cet ordre :

1. une navigation page à page, basique et tout terrain ;
2. enrichie d’une navigation rapide sous la forme d’un menu déroulant (en CSS simple), certainement activé par défaut, mais désactivable (dans mes préférences personnelles) ;
3. ensuite enrichie de comportements JS kikou (dont je me contrefiche pourvu qu’ils soient facultatifs) ;
4. et enrichie d’icônes et habillage graphique (dont je me fiche aussi).

Progresser ainsi par enrichissements successifs permet, à condition que chaque couche d’enrichissement ne massacre pas celle qui la précède, de produire une interface qui reste correctement utilisable, même sans ces enrichissements — c’est-à-dire même sans javascript, sans image, sans couleur et même sans feuille de style —, bref accessible quelques soient les conditions de navigation. Second avantage, loin d’être négligeable : on s’épargne d’avoir X interfaces à maintenir, tel qu’actuellement (interface graphique, interface textuelle, etc.), en n’en produisant plus qu’une seule.

C’est donc là : http://romy.tetue.net/IMG/demo/inte...
Cliquez sur le faux bouton « valider » du formulaire de login, puis un peu partout (visitez chaque item) et même sur les liens « Voir le site public » et « Me déconnecter » :-)

Trois registres distincts :
identité, navigation complète et raccourcis

Dans ce proto, les items de navigation se répartissent, comme une tranche napolitaine, en trois registres horizontaux de faible encombrement et aux rôles bien distincts :

1. Discret, le premier registre est identifiant : il me rappelle le site sur lequel je travaille (à droite) et ma session (à gauche) et... c’est tout, car les noms du site et de l’utilisateur peuvent être longs et encombrants. Ce registre donne les repères élémentaires, actuellement absents de l’espace privé de SPIP, et qui permettent de se situer : où suis-je ? avec quel compte suis-je connecté ? dans quelle langue ?
2. Vient ensuite une indispensable barre de navigation complète, qui permet d’accéder à l’ensemble des pages de l’interface, de façon exhaustive. Elle reprend la navigation habituelle du bandeau haut, en reventilant un peu les items.
3. Le troisième registre propose des outils et des raccourcis d’accès rapide, non indispensables mais si pratiques qu’on ne sait plus s’en passer : liens de création directe, plongeur de rubriques, recherche, etc.

Navigation déroulante OU PAS

La seconde barre de navigation, qui apprécierait d’être, comme auparavant, dotée d’icônes, déplie ses menus au survol, mais sans recouvrir les éléments dépliants de la barre inférieure (dont l’infernal plongeur de rubrique), pour éviter de se prendre les pieds dans le tapis. Ces menus se déplieraient désormais à la verticale, afin de pouvoir recevoir un plus grand nombre d’items.

Une telle barre de navigation à menus déroulants, que je critique habituellement sur les publications web, est ici adaptée, puisque dans un environnement de type applicatif. Elle doit cependant être pensée comme facultative.

Les items de premier niveau de la barre de navigation renvoient chacun à une page sommaire (ce qui tord définitivement le cou au problème régulièrement soulevé dans les forums et épinglé au Ticket #1749, entre autres), laquelle liste les pages intérieures et présente leurs contenus, de façon à ce que celles-ci restent accessibles dans tous les cas, même lorsque le menu ne déplie pas.

Le fait que le menu soit dépliant n’est qu’un plus, un raccourci rapide, qui ne fonctionne pas nécessairement dans toutes les configurations logicielles (on s’épargnera les contorsions pour le rendre fonctionnel sous IE6, non ?) et qui devrait être désactivable au bon vouloir de chacun.

Ré-agencement des menus

Chaque menu regroupe les tâches susceptibles d’être effectuées par une même personne et les informations qui lui seraient utiles, selon les différents rôles possibles, bien que ceux-ci ne soient pas ainsi distingués dans SPIP : rédacteur, modérateur, administrateur, webmestre. Il s’agit surtout de fournir un menu à chacun, sans l’encombrer avec des tâches qui ne le concernent pas. L’attribution des droits, notamment par les plugins, n’en sera que simplifiée.

1. Le premier menu, « Édition », permet aux rédacteurs de consulter et d’éditer (c’est-à-dire créer, modifier ou supprimer) les contenus du site : lister et trier les articles, écrire une nouvelle brève, ajouter un document, modifier le rubriquage, mais aussi éditer d’autres types d’objets, ajoutés par les plugins ;
2. le menu suivant permet, si les options correspondantes sont activées, de suivre l’activité éditoriale du site (suivi de versions, calendrier, messagerie et forums internes, etc) ; serait-ce le rôle du rédac’chef ?
3. le menu suivant permet de gérer, s’il y a lieu, les contributions externes et tout ce qui relève de l’interactivité du site avec ses internautes (forums, pétitions, listes de diffusion, abonnements, etc.), ce qui est généralement le rôle des modérateurs ;
4. le menu suivant regroupe les opérations d’administration et de maintenance ordinaire : sauvegarde de la base, gestion du cache et des accès, etc. que seuls les administrateurs peuvent effectuer ;
5. tandis que le dernier, « configuration », ne sert qu’une fois dans la vie du site puisqu’il regroupe les réglages qu’effectue le webmestre après l’installation.

Ce réagencement des menus suppose qu’il faille revoir (regrouper ou tronçonner) certaines pages, mais cela n’est pas abordé ici.

À retenir des problématiques déjà discutées...

Ce prototype a été suivi d’échanges et d’autres prototypes (de Matthieu Marcillaud, BoOz, etc.). Pour éviter de répéter (les mêmes erreurs ou mêmes discussions plus ou moins trollesques), voici, pour mémo, quelques-unes des problématiques déjà discutées :

• Choix de la langue : il doit rester constamment visible et être facilement identifiable comme tel : lorsqu’on débarque sur l’interface dans une langue que l’on ne connaît pas, la priorité est de pouvoir en changer. C’est plus facile à dire qu’à faire, dans la mesure où il n’existe pas de convention visuelle internationale pour la compréhension de la chose. Le logo des Rolling Stone ?
  Techniquement il ne doit plus être constitué d’un menu select, car il est inutile d’alourdir chaque page de la liste des 40 langues. C’est donc un lien vers la page de choix personnel de la langue.
• Boutons de création rapide : mieux vaut les avoir constamment sous la main. Pour éviter d’avoir à déplier un menu pour y accéder (c’est trop impraticable et dissimulé pour des actions aussi fondamentales et courantes), j’ai introduit des raccourcis visuels. Notez que ces pictos (qu’il convient de redessiner) ne sont pas « sans aucun texte », puisqu’ils sont correctement dotés d’une alternative textuelle (alt) et d’une infobulle (title). Ils s’adressent donc autant aux non-voyants qu’aux voyants.
• Merde, j’ai déjà la mémoire qui flanche…