Utilisateur:Lgd/Projet:Keep it simple, stupid!

Quand créer un nouveau modèle ?

• ne pas créer ni importer un modèle sans s'être assuré qu'un modèle existant ne remplit pas une fonctionnalité similaire, qu'il y ait des différences de mise en forme ou non.
• ne pas multiplier les modèles qui sont des variantes de la même fonctionnalité pour pouvoir varier la mise en forme du contenu.
• évaluer la nécessité de chaque nouveau modèle, mettre en balance le surcroît de complexité qu'il entraîne et l'importance de ce qu'il apporte (simple mise en forme, autre)
• favoriser les modèles qui facilitent l'édition, c'est à dire qui sortent des articles des syntaxes complexes rendant plus difficile les contributions (exemple: le modèle relevé météo)

Quand ajouter un nouveau paramètre ?

• évaluer la nécessité de chaque nouveau paramètre d'un modèle existant, mettre en balance le surcroît de complexité qu'il entraîne et l'importance de ce qu'il apporte (simple variante de mise en forme, etc.)
• ne pas multiplier les paramètres et variantes de mise en forme d'un même modèle (couleur, alignement, etc.)

Jusqu'où automatiser ?

• ne pas créer de modèle produisant un texte rédigé générique (une phrase identique d'un article à l'autre, un paragraphe entier, etc.) : chaque contenu rédigé doit être librement modifiable en éditant l'article).
• ne pas déporter dans des sous-modèles les contenus de tableau modifiables par les contributeurs : le contenu éditable doit se trouver soit directement dans l'article (les valeurs passées aux paramètres du modèle), soit dans le modèle lui-même (exemple: une palette de navigation) et non dans un sous-modèle appelé par celui-ci : chaque contenu de type données de tableau, de diagramme etc. doit être librement modifiable en éditant soit l'article soit un modèle immédiatement modifiable depuis l'article (lien modifier adapté).
• les capacités de la syntaxe wiki, des fonctions parseurs et des mots magiques sont limitées. Éviter de bricoler en les détournant pour obtenir à tout prix un modèle plus puissant. Si vous avez vraiment besoin de fonctionnalités puissantes, il faut apprendre et utiliser Lua.
• les modèles ne servent pas à stocker des données. Éviter de simuler une base de données à l'aide d'un faux modèle : attendre Wikidata.

Comment coder ?

• éviter les modèles dont le code devient trop complexe à force de mutualiser des cas trop nombreux : préférer des modèles spécifiques plus légers et plus aisés à maintenir
• limiter la profondeur de sous-modèles (plus d'un niveau de sous-modèle est déjà à éviter si possible)
• ne pas créer ou modifier de modèle sans le documenter ou mettre sa documentation à jour

Comment nommer ?

• nommer explicitement le modèle et ses paramètres : il s'agit d'éviter d'imposer dans les articles un « {{nZFTr3 | pxw = | s1 = | s2 = }} »
• s'il existe d'autres modèles avec des paramètres similaires, utiliser les mêmes noms de paramètres plutôt que des variantes inattendues
• renommer raisonnablement : ce n'est qu'un nom de modèle à usage interne, ce n'est pas un drame s'il n'est pas conforme aux règles typographiques de l'Imprimerie nationale.

Premier jet

Contrairement à une légende répandue, le souhait de ceux qui s'occupent sérieusement des aspects techniques n'est pas de multiplier à plaisir les syntaxes qui compliquent les articles, mais au contraire de répondre à des besoins mesurés en veillant à la plus grande simplicité possible pour les rédacteurs. Ce qui est loin d'être évident tant les demandes, besoins, initiatives etc. sont multiples, désorganisées et impulsives.

Analyse

On peut distinguer 5 6 niveaux de complexité du code source wiki d'un article :

• le premier est celui de la syntaxe wiki élémentaire, le minimum vital pour répondre à des besoins de structuration du contenu élémentaires :
  • des titres de section
  • des liens internes et externes
  • des tableaux
  • des images
  • des notes et références
  • autre ?
• un second niveau qui découle d'une demande de structuration et de sémantique plus riches, qui valorise Wikipédia pour ses lecteurs, en favorisant les diverses exploitations de son contenu :
  • modèles de citation
  • modèle d'indication de la langue
  • modèle dfn en cours de discussion
  • modèles d'abréviation
  • modèles bibliographiques (au moins en principe, le code étant encore loin d'être sémantique. Ils ne nécessitent d'autre pas forcément une telle abondance de paramètres et de rafinements typographiques pour répondre à ce besoin)
  • ...
• le troisième niveau découle du souhait d'enrichir les contenus eux-mêmes :
  • extension timeline
  • modèles d'infobox
  • arbres généalogiques
  • cartes enrichies
  • galeries
  • géolocalisation
  • ...
• le quatrième répond au besoin de fournir une navigation suffisante ou de l'enrichir :
  • modèles de navigation en dehors du texte : palettes, autres projets, dynasties
  • modèles de navigation au fil du texte : modèles de dates, de liens internes
  • modèles de liens externes
• le cinquième est celui des modèles et syntaxes qui ne répondent qu'aux besoins de maintenance éditoriale ou technique, de suivi etc. des rédacteurs. C'est celui de la « cuisine interne »
  • bandeaux divers en tête ou en pied d'article, voir dans les sections
  • {{refnec}} etc.
• le sixième niveau est celui des souhaits de mise en forme graphique et typographique :
  • options de mise en forme des tableaux (couleurs, etc.)
  • options de mise en forme des modèles précédents via de nouveaux paramètres de couleur, etc.
  • modèles dits de « petits drapeaux » et de logo de lignes de bus, de chemin de fer, de métro, etc.
  • modèles de boîtes déroulantes (qui souvent permettent d'esquiver la question : ce contenu est-il pertinent et si oui, est-ce bien dans l'article lui-même ?)
  • modèles insérant des espaces insécables
  • ...

Ces niveaux ne donnent qu'une image incomplète de la question de complexité : en effet, les usages peuvent faire varier considérablement la complexité de telle ou telle syntaxe, modèle, etc. Par exemple :

• les ref vont d'une syntaxe minimale à des techniques complexes (harvsp, name…)
• les tableaux peuvent s'alourdir considérablement avec les options et styles de mise en forme
• l'appel à un modèle peut être plus ou moins lourd en fonction des options de mise en forme et de contenu qui y sont ménagées
• ...

Par ailleurs, la syntaxe wiki est en elle-même un obstacle : conçue pour être intuitive et aisée au prix de possibilités réduites, elle est totalement impropre à supporter des codes plus étendus (exemple criant des fonctions parseurs dont le code devient rapidement illisible dès qu'il est question de tableaux, comme dans le cas des infobox). Malheureusement, son impératif majeur (« Keep it simple, stupid ») est constamment enfreint en raisons des exigences des contributeurs eux-mêmes

Enfin, l'analyse ci-dessus montre que le problème a déjà une première composante éditoriale, mais celle-ci est plus importante encore : la complexité est également issue de la multiplication de règles, conventions et usages d'écriture et surtout de leur application immédiate, avec un niveau d'exigence élevé imposé dès les premiers stades d'une contribution. La pression pour complexifier les choses vient donc en fait essentiellement des rédacteurs de contenu.

Des solutions ?

Les possibilité de remédiation locales sont limitées et dépendent largement de la capacité des contributeurs à arbitrer sur leurs exigences ci-dessus :

• déplacer dans les styles de common.css les options de mise en forme qui peuvent être rendues génériques : appliquer une classe peut donner une syntaxe considérablement plus simple qu'une accumulation de styles en ligne (donner l'exemple très probant de la classe .alternance v. le modèle {{Ligne grise}} pour les tableaux, ou celui des modèles d'arbres). Cela nécessite cependant acceptent d'avoir un jeu d'option de mise en forme plus réduit (mais du coup plus cohérent à travers les différents articles).
• déporter vers des modèles les syntaxes bricolées ponctuellement qui peuvent être mutualistes (mais du coup avec des possibilité de contenu ou de rendu plus limitées)
• déporter vers un namespace annexe des syntaxes définitivement complexes comme les timeline
• déporter vers un namespace annexe l'appel de certains modèles particulièrement volumineux, comme les infobox
• alternativement au namespace, activer les sous-pages de l'espace principal et gérer par exemple les bandeaux temporaires d'en-têtes, les modèles d'homonymie et les infobox (bref, tout ce qui précède l'introduction dans la source wiki) dans une sous-page {{Foo/en-tête}} unique par article. Mais l'activation des sous-page de MAIN n'est pas évidente en raison des articles comportant un slash en titre et du problème de suivi (le suivi d'une page n'entraîne pas celui des sous-pages)
• préférer plusieurs modèles simples (en termes de paramètres) et très utilisés à un modèle multi-paramètres sans réelle valeur ajoutée (exemple: Modèle:Étymologie)
• définir des priorités en matière de richesse de la mise en forme et de souci typographique (la mode actuelle multipliant les {{nobr}} et autres modèles d'espaces insécables réels ou simulés connaît par exemple quelques excès).
• garder en mémoire le principe de conception « be cool to be strict », c'est à dire autoriser des saisies approximatives ou spontanées en garantissant que le résultat sera tout de même correct (exemple classique : les multiples syntaxes autorisées par mediawiki pour insérer un saut de ligne <br>). Dans le cas des modèles, il s'agit par exemple de gérer les noms de paramètres initiaux de modèles de en.wp en même temps que le paramètre francisé, afin de faciliter les copiés-collés de modèles similaires (title et titre, etc.)

D'autres solutions relèvent du développement de mediawiki et de ses extensions :

• simplifier l'édition à travers l'interface d'édition : par exemple le gadget ProveIt qui tente actuellement de simplifier l'édition des références, l'extension LiquidThreads pour faciliter l'usage des pages de discussion.
• développements en cours pour un éditeur Wysiwyg
• ...