Contactez-nous

1

Simplifier son SPIP

15 décembre 2008
par ARNO*

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.

  • Loiseau2nuit
    Janvier 2009

    Je regrette vivement de ne pas être tombé sur cet article avant de lancer la refonte en Spip 2 du mien, de site perso.

    Merci une fois encore pour cette lecture instructive.

  • Athama
    Mars 2009

    je suis évidemment de cet avis... je conseille aussi pour ceux qui comme moi ne veulent pas perdre du temps en codage (ou ne peuvent coder des choses complexes) de prendre des squelettes simples. Ca sert à rien d’utiliser un squelettes lourds où on peine à utiliser toutes les fonctionnalités.

  • Romain
    Octobre 2009

    C’est un plaisir de lire un article comme ça : vous mettez les mots justes sur une philosophie de codage ( que dis-je... de vie :) à laquelle je crois dur comme fer : plus c’est simple, plus c’est élégant et efficace.

    Les mots me manquent parfois pour expliquer ça à des utilisateurs qui se méprennent sur cette volonté de simplicité, et y voient de la facilité, ou même de la flemme ; mais je continue de penser que "quand c’est trop compliqué, c’est qu’il y a forcément plus simple".

    Avec cet article excellent, me voilà bardé d’arguments, merci !

  • Alberto
    Février 2010

    Tout est bon dans la cochon :-)

    A part les mots clés techniques car "si vraiment, vraiment, vous utilisez des mots-clés techniques, limitez-vous à une petite poignée de mots-clés." en faisant comme ça on peut facilement exploiter les boucles et squelettes de la dist tout en sachant “à peu près” ce qu’on fait. Et créer un secteur spécialisé dans l’agenda [p. ex. en lui accrochant un mot clé] c’est, apparemment, ce que fait un plugin comme Sarka

    Donc avec trois ou quatre mots clés (sommaire, menu, agenda, breves) et quelques Rubriques dédiées, plus « 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.../... » et roule, quelques modifs des squelettes fournis dans la dist plus css = 100% spip.

    200% merci !

  • Stanislas
    Mars 2010

    Article qui fait une synthèse de fondamentaux, merci pour ce travail.

    Mais dans le même temps, il me fait remonter le regret que spip n’ait pas fait de progrès pour aider les rédacteurs à suivre facilement la logique éditoriale du site dans l’espace privé.

    Il manque cruellement la possibilité de différencier les secteurs ou même les rubriques.

    Par exemple, il faudrait :

    • avoir des articles avec plus ou moins de champs activés selon les besoins des rubriques
    • pouvoir renommer le nom des champs dans l’espace privé toujours selon les besoins de la rubrique
    • avoir des mots clés en fonction des besoins des rubriques

    Tu évoques les mots clés techniques... c’est sans doute parce qu’ils manquent...

    Pourquoi se restreindre sur les mots clés ? C’est un excellent moyen de donner au rédacteur ou admin restreint le contrôle de la page publique lorsque les mots clés conditionnent son affichage

    Détourner pourquoi pas, il manque une date de fin d’affichage dans l’espace publique, alors moi je détourne la date de publication initiale... pourquoi ne pas faire le choix d’ un plugin ? Parce que si l’on est pas un cador du php et de l’api de spip, plus on a de plugins et plus l’angoisse de la mise à jour grandit...

    Les modèles cela peut être très intéressant mais même peu nombreux et opportuns il n’y a pas le moyen en dehors d’un plugin de les faire apparaître au rédacteur dans l’espace privé...

    Cordialement

    Stanislas

  • Angeline Denvers
    Avril 2010

    Je suis en 3ème année du collège prise de technologies de l’information et a été chargé de rédiger research papers sur les différents types de plate-forme web. J’ai pu en savoir plus sur SPIP il ya trois mois et a été vraiment intéressé au sujet de ses différentes fonctionnalités. J’espère que ce que je peux si je base des informations contenues dans ce site car il ya un certain nombre de postes qui donnent des informations beaucoup.

  • filnug
    Décembre 2010

    Article vraiment intéressant qui me fait rebondir sur l’interface privée de spip. Je trouve dommage qu’un système comparable au plugin "compositions" ne soit pas directement intégré. De même, le plugin champs extra est vraiment indispensable et devrait lui aussi être de base dans spip. Sans compter la difficulté pour nombre de personnes à s’orienter dans l’interface privée. Le plugin bandeau résout qq promblèmes, mais on est encore loin du compte...

Qui êtes-vous ?
Votre message

Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.