Le but de ce billet est de présenter un des objectifs que je me fixe systématiquement lorsque je démarre un nouveau site, ou lorsque je reprends un site existant : tenter à tout prix de réduire le champ fonctionnel du système. Simplifier à mort.
Il y a deux raisons fréquentes pour créer des sites inutilement complexes :
— de part sa courbe d’apprentissage très progressive, SPIP est un outil épatant pour les bidouilleurs ; et un bidouilleur, par nature, a envie de tout activer pour tout essayer...
— on choisit SPIP en partie pour sa richesse « à la sortie du paquet » ; du coup, on a tendance à définir le contenu de son site en fonction des différentes possibilités (« tiens, il y a des brèves, alors hop, mon site aura des brèves » et ainsi de suite).
Or, une trop grande richesse fonctionnelle induit des difficultés énormes :
— le développement du site devient très complexe ; il faut des squelettes abracadabrantesques pour afficher toutes les informations ;
— le site devient incroyablement compliqué à faire évoluer ; reprendre un site qui a été conçu avec des bidouilles dans tous les coins est quasiment impossible ;
— les rédacteurs ont dû mal à comprendre la logique éditoriale ; trop de complexité rend la publication d’informations pénible (devoir sélectionner quatorze mots-clés, renseigner des champs abscons, ne pas comprendre où est publiée l’information...) ; beaucoup de sites s’arrêtent parce que ceux qui les mettent à jour finissent par sauter par la fenêtre ;
— il est très difficile de proposer une navigation cohérente et compréhensible sur le site public (c’est un point très important) ;
— si quelqu’un doit payer pour faire développer le site, plus le cahier des charges est lourd, plus c’est cher.
Simplifier la structure a un énorme avantage : cela libère du temps pour la conception du graphisme et de la navigation du site public, ça concentre l’énergie lors de la création du contenu (en limitant la dispersion sur une trop grande diversité d’outils de publication). Par ailleurs, puisque j’aime beaucoup les filtres graphiques, simplifier la structure du site facilite également le travail de conception des automatismes graphiques.
Voici donc quelques conseils destinés à simplifier autant que possible un site sous SPIP.
Ne définissez pas votre site en fonction des possibilités de SPIP, mais en fonction de son contenu. Ça n’est pas parce que votre site tourne sous SPIP que votre site doit utiliser des brèves et des sites référencés. Écrit comme ça, c’est évident ; dans la pratique, ça ne l’est pas.
Pour commencer, n’activez que les objets indispensables. On fait de très beaux sites avec uniquement des rubriques et des articles...
— Est-ce que les brèves, les sites référencés, la syndication, les documents dans les rubriques, les logos de survol, les mot-clés... sont indispensables à votre site ?
— S’agit-il d’un usage systématique ? Si c’est un usage ultra-ponctuel, envisagez de ne pas activer une fonctionnalité pour le faire, et voyez s’il n’est pas possible de faire autrement (publier un article avec quelques liens faits à la main, mettre un formulaire ultra-spécifique dans un squelette...).
— L’utilisation est-elle pérenne ? Notamment : est-ce que vous aurez continuellement de l’information à publier avec telle fonctionnalité ? Il est facile d’alimenter un site avec, disons, des articles réguliers ; mais suivre des sites, alimenter en brèves, etc., est un travail supplémentaire, et il est rare qu’il soit correctement suivi.
— La charge de travail induite par un type d’information ultra-spécifique est-elle « rentable » ? Est-ce que ça intéressera réellement des visiteurs sur le type de site que vous montez ? Si 99% des visiteurs viennent sur votre site pour trouver votre adresse avant de monter sur leur vélo, est-il « rentable » de vous lancer dans une « veille technologique de tout ce qui se fait dans le domaine » ou de publier « tous les déplacement à l’étranger de notre glorieux PDG » ? Dans la pratique, on constate qu’une partie du site qui n’est que très peu visitée finit par ne plus être alimentée : il y a toujours plus « utile » à faire sur le site que de mettre à jour le bout de site que personne ne visite jamais.
Réduisez le nombre de champs des articles. Avez-vous besoin d’un surtitre et d’un soustitre ? Et s’il en faut un, préférez conserver le soustitre, et ne pas utiliser le surtitre. Maquetter la présentation des articles et des liens vers les articles est beaucoup plus facile et précis si on n’a pas de surtitre à prendre en compte. Le descriptif reste dans tous les cas utile pour forcer les #INTRODUCTION. Le chapo n’est pas toujours indispensable. Avez-vous vraiment besoin d’un postscriptum et d’un lien hypertexte ?
De la même manière, n’utilisez que les plugins dont vous avez besoin. Les plugins qui ajoutent des objets à gérer dans l’espace privé et demandent une mise en forme sur le site public augmentent évidemment la complexité du site : travail sur les squelettes, navigation à bien penser, compréhension par les rédacteurs... Personnellement, je n’utilise qu’un ou deux (ou aucun) plugins qui ajoutent de l’information dans le site. Je préfère quelques plugins dont l’usage est transparent, ou qui facilitent la création de l’ergonomie du site public.
Ne détournez pas une fonctionnalité de son objet. Un article est un article, une rubrique est une rubrique, une brève est une brève, un auteur est un auteur... Un article n’est pas un morceau d’information qu’on affiche ailleurs que dans sa rubrique, une brève n’est pas destinée à réaliser des encadrés dans des articles... Si vous détournez une fonctionnalité de son but initial, l’interface privée perd sa cohérence, certains automatismes deviendront difficiles à contrôler (le moteur de recherche qui mène vers des pages qui ne riment à rien, par exemple), et surtout les rédacteurs finiront par s’arracher les cheveux.
N’utilisez pas les mots-clés comme outils techniques. Tout le monde le fait, et ça tourne toujours au pénible. Voyez si vous pouvez faire autrement :
— est-ce que vous pouvez vous en sortir avec des champs #EXTRA ajoutés aux articles ?
— est-ce qu’il existe un plugin qui fait exactement ce dont vous avez besoin sans bidouille ?
— est-ce que vous avez vraiment besoin de cette fonction ? Parce que, d’expérience, l’usage des mots-clés techniques, ça coûte plus cher à l’usage que de se passer d’une fonctionnalité qui repose sur une bidouille.
— et si vraiment, vraiment, vous utilisez des mots-clés techniques, limitez-vous à une petite poignée de mots-clés. Et utilisez les options de réglage avancé des mots-clés pour restreindre leur apparition.
En règle générale, si vous avez besoin d’activer beaucoup de fonctionnalités pour réaliser le site, si vous croyez devoir détourner une fonctionnalité, si vous rencontrez des difficultés à concevoir l’ergonomie du site public, posez vous toujours cette question : est-ce qu’il n’y aurait pas un problème de logique éditoriale dans ce site ?
Limitez la profondeur de la hiérarchie de rubriques. SPIP permet de créer autant de rubriques, et autant de niveaux de sous-sous-sous-...-rubriques que l’on veut. Mais une hiérarchie trop profonde complique la tâche : il n’est plus possible de réaliser un graphisme élégant, il est difficile de créer une navigation publique compréhensible, et les rédacteurs finissent par avoir du mal à déterminer où publier leur information. Il faut tenter, avant même la création des squelettes :
— de déterminer un nombre très restreint de secteurs (rubriques à la racine) ; par exemple quatre ou cinq secteurs principaux ;
— de construire une hiérarchie de rubriques limitée à quelques niveaux (par exemple : les secteurs contiennent des rubriques qui contiennent des sous-rubriques et c’est tout).
Une des raisons du succès des blogs, c’est l’extrême simplicité de la structure. Plus que la simplicité d’usage de l’outil, c’est la quasi-absence de structuration du site qui libère l’écriture (on écrit, on publie, et les billets se présentent les uns à la suite des autres).
Prévoyez l’utilisation (et la non-utilisation) des logos. Décidez à quels endroits les logos sont obligatoires (les principales rubriques par exemple) dans votre site, et concevez ensuite votre maquette en considérant les logos d’articles comme optionnels (parce qu’il vaut mieux publier une information en ligne que ne rien publier parce qu’on attend une image pour le logo). Par ailleurs, vous n’avez généralement pas besoin des logos de survol. Des placements de logos anarchiques, ça va vous compliquer la tâche.
Essayez de ne pas avoir en même temps des sous-rubriques et des articles dans une rubrique. On peut, mais il est beaucoup plus difficile de créer une interface élégante quand on doit mélanger des listes d’articles et de sous-rubriques.
Simplifiez la structure de vos forums. SPIP propose par défaut des forums hiérarchisés : on peut fabriquer des fils de discussion à partir de n’importe quel message et réponse de message. C’est très riche, précis, puissant, mais :
— c’est particulièrement difficile à maquetter,
— tout le monde ne sait pas utiliser correctement une telle structure de forum, d’autant moins que les forums se sont multipliés sur le Web, et ont adopté des structures plus simples. Les utilisateurs se sont habitués à des structures de forums très simples.
À moins d’avoir un besoin spécifique, généralement il est préférable de proposer des forums structurés ainsi :
— un unique fil de discussion, chronologique ; ça fonctionne très bien ; les blogs du Diplo (sous SPIP) présentent ainsi des forums très clairs ;
— plusieurs fils sous un article, mais chaque fil est lui-même non hiérarchisé ; par exemple sur Plugins.spip, on peut soit ouvrir un nouveau sujet de discussion sous l’article, soit répondre à une discussion déjà démarrée.
Utilisez les filtres graphiques. Tout ce que vous pouvez réaliser de manière automatique avec les filtres graphiques vous simplifiera la tâche. Traitements des images et images typographiques permettent de faire un site beaucoup plus beau et vivant... en travaillant moins lors des mises en ligne d’article. Évidemment, c’est un investissement initial pour les maîtriser et concevoir une maquette qui les exploite, mais ensuite ça facilite la vie du site.
Essayer de réunir les éléments de navigation dans des éléments communs (appelés par #INCLURE). Si les différents squelettes (articles, rubriques...) fonctionnent avec exactement les mêmes appels de noisettes :
— le site est plus facile à développer et à maintenir,
— la structure de vos pages est sans doute plus cohérente,
— la navigation proposée aux visiteurs est donc certainement plus facile à comprendre.
Si vous êtes obligé de développer des éléments de navigation différents pour chaque squelette, demandez-vous si la structure de votre site n’est pas la source d’un problème de logique éditoriale.
Utilisez les « modèles » avec parcimonie. Les « modèles », ce sont ces nouveaux « raccourcis » qui permettent d’ajouter des automatismes puissants dans le corps des articles, à la manière de <img> et <doc> (mais avec plus de richesse). N’en intégrez pas plus de deux ou trois dans votre site :
— ils demandent évidemment du travail de maquettage sur le site public ;
— trop de variété de présentation des éléments sélectionnés manuellement lors de l’édition de chaque article peut nuire à la cohérence du site (ergonomie changeante d’un article à l’autre) ;
— les rédacteurs n’en mémorisent que quelques uns et n’utiliseront pas forcément les plus adaptés.
Faites-vous un site perso. Si vous gérez et réalisez le site pour un groupe d’amis, votre association ou votre entreprise, montez-vous un site perso à côté. Rien que pour vous. Et bidouillez sur ce petit site. Ça vous évitera de sur-investir le site collectif au risque de le transformer en usine à gaz. Ça semble évident, mais dans la pratique...
J’arrête là. Il y a bien sûr beaucoup de moyens de se simplifier la vie par la suite. Mais le but de ce billet est de vous engager à tenter la simplification avant même le développement sur site.