Parce que deux logiques s'opposent:
- la plupart des CMS ont une logique d'interface modulaire: chaque type d'élément est présenté de manière plus ou moins indépendante; j'ai donc des objets, avec des entrées spécifiques dans le menu de navigation, et je peux créer un élément de ce type d'objet depuis sa page; et ensuite je le raccroche à autre chose si nécessaire. Ce qui fait, notamment, qu'on obtient des interfaces que certains adorent, que je déteste, ou je créé «un article» et que, dans cet article, on me demande d'indiquer un «topic», des «tags», etc.
- l'interface de SPIP repose sur la hiérarchie de l'information, et n'est pas modulaire: on _navigue_ dans l'espace privé, on se place dans la bonne rubrique, et on créé l'article. De fait, la notion d'article est directement liée à celle de rubrique, et quand je sélectionne la rubrique (présélectionnée, de fait), j'ai conscience de la structure hiérarchique du site. Je ne choisis pas un «topic», j'installe très clairement l'article dans la hiérarchie des rubriques.
Ensuite, l'évolution des sites et l'évolution du système ont amené des entrées spécifiques.
- les éléments transversaux (les mots-clés) ont besoin d'une présentation séparée, puisqu'ils ne dépendent pas de la hiérarchie. Il faut donc pouvoir les gérer hors hiérarchie, ils ont donc une page en propre;
- les brèves étant conçue pour leur simplicité (bon, après, l'usage réel se discute), façon «fil d'information», il semblait naturel d'en faire une page spécifique, qui permet une insertion ultra-rapide de ces brèves. Je reste sur la page des brèves, je clique directement sur «Créer une brève» correspondant à la rubrique, je tape mon texte, je valide, et j'ai un bouton de validation immédiat (les brèves n'avaient pas de sélecteur de statut, mais un bouton «Publier». C'était conçu pour être beaucoup plus rapide que pour les articles. Clic-clic-clic, publié.
- pour les sites syndiqués, il y a eu un besoin très spécifique: suivre les flux RSS de ces sites. Donc les regrouper à un endroit. Paf: page spécifique pour les sites syndiqués (qui sont pourtant dans la hiérarchie des rubriques).
=> À noter, pour les rédacteurs, on n'a pas de sous-menus au survol des gros boutons (ça va donc sans doute changer), parce qu'on considère qu'ils doivent passer par _naviguer_ pour rédiger leurs articles. Ce qui indique bien que les pages spécifiques selon le type d'objet c'est avant tout une tâche de suivi de la publication, bien plus que des pages de rédaction.
Maintenant, on se donne les moyens de multiplier les sous-menus. Et les plugins ont introduit avec force la logique «modulaire» dans SPIP. Mais forcément, tout cela se télescope. La page «Tous les articles» entre en plein dans ce problème:
- il semble assez naturel de mettre la page «Tous les articles» dans «Edition»;
- mais tout le monde décrit cette page comme étant un moyen de «retrouver» des articles; ça n'est donc pas de l'édition, c'est autre chose (notamment du suivi de publication).
C'est pour cela que les pages destinées à «retrouver» des articles existent déjà dans SPIP: «tout le site» (présentation hiérarchisée sur une seule page) et «navigation rapide» (présentation par onglets) et, évidemment, «recherche». Et il est notable que ces pages n'étaient pas accessibles par les menus du haut, mais dans la barre colorée. Contrairement à une idée répandue: il y avait toujours une logique dans ces choix.
Donc, maintenant: on se fait une rubrique «Édition» qui ne serait plus accessible que par les sous-menus. Et «Rubriques» devient une entrée comme les autres. Je pense que c'est potentiellement catastrophique: on adopte une interface uniquement modulaire dans un système qui est conçu à l'inverse. Maintenant: si je veux créer un article, logiquement je vais dans l'entrée «Articles» de ce sous-menu, et surtout pas dans «Rubriques» (mon but n'est pas de créer une rubrique). Et là, j'ai perdu la notion de navigation dans la hiérarchie des rubriques.
Pour résumer:
- contrairement à ce que je vois passer, une page «tous les articles» dans le sous-menu «Édition» n'a absolument rien d'évident:
+ ça n'est explicitement pas une page d'édition, mais avant tout une page pour «retrouver» un truc;
+ ça minore beaucoup la notion de «naviguer dans les rubriques» qui permettait à SPIP de mettre en avant, de manière très forte, la structure des rubriques du site; c'est un des aspects qui fait que SPIP est très adapté à la création de sites éditoriaux: on va naturellement vouloir placer l'article dans sa rubrique, même quand on est «rédacteur»; contrairement à d'autres CMS où je fabrique un objet-article, et qu'ensuite seulement je lui colle un topic et des tags.
- il existe déjà au moins deux pages dont le but était retrouver des articles: «Tout le site» et «Navigation rapide»:
+ ces deux pages n'étaient justement pas accessibles par «Édition», pour des raisons logiques fortes (ce ne sont pas des pages d'édition),
+ pourtant y'a du travail intéressant de ce côté.
Idées différentes/complémentaires:
+ recoder la «navigation rapide» en full AJAX, en exploitant mieux la taille de l'écran; une telle page, bien foutue et efficace, pourrait devenir beaucoup plus fonctionnelle; sur un petit site, non, sur un gros site, oui.
+ séparer en deux la page «Tout le site» selon ses deux fonctions: faire une vraie page d'affichage en «mode plan», et faire une vraie page de suivi des traductions.
+ retravailler l'interface d'affichage des résultats de la page «recherche», et pouvoir s'y pluguer. Le moteur de recherche interne, c'est un élément très important pour retrouver ses petits, la nouvelle présentation du champ de recherche est un plus, mais pour la présentation des résultats c'est très perfectible.
+ la page «calendrier mensuel» est foutraque, parce qu'on y mélange le suivi de publication et les événements personnels; elle est donc considérée beaucoup plus comme le calendrier qui n'est pas utilisé; or, une navigation graphique dans le temps n'est pas inutile; faire une page de «calendrier des publications» spécifiques, qui permettrait de suivre les articles, les articles référencés, etc, selon leur date, ça pourrait devenir efficace. Et intégrer une présentation «liste» dans le calendrier.
En gros: reprendre ce qui existe déjà mais ne fonctionne pas bien (parce que vieilli, mal fichu, mélangeant trop d'éléments, ou simplement planqués dans l'interface). Il y a donc là déjà 4 pages pour naviguer dans le site et retrouver ses petits, qu'on pourrait remettre en selle.
ARNO*
