Coucou,
j'ai reçu ces remarques, dont certaines pourraient nous donner
quelques pistes d'amélioration.
La bonne définition du vocabulaire me paraît très importante.
Surtout au niveau de la conception. Car c’est avec des “mots” que l’on “pense” une conception, qu’elle est formulée, documentée et évaluée. Professionnellement, j’ai “revu” beaucoup de documents de spécification et/ou de conception du logiciel. L’ambiguïté de vocabulaire s’y est avéré le meilleur traceur vers les insuffisances et/ou anomalies enfouies dans ces documents.
Augmenter la rigueur du glossaire existant ?
Le temps me fuit mais, s’il s’ouvre, je me joindrai à un tel chantier.
La bonne définition du vocabulaire me paraît très importante.
Surtout au niveau de la conception. Car c'est avec des "mots" que l'on "pense" une conception, qu'elle est formulée, documentée et évaluée. Professionnellement, j'ai "revu" beaucoup de documents de spécification et/ou de conception du logiciel. L'ambiguïté de vocabulaire s'y est avéré le meilleur traceur vers les insuffisances et/ou anomalies enfouies dans ces documents.Augmenter la rigueur du glossaire existant ?
Le temps me fuit mais, s'il s'ouvre, je me joindrai à un tel chantier.
Quelques pages sont en train de se créer pour ça dans le carnet wiki de SPIP-Contrib :
http://www.spip-contrib.net/Nomenklatura
http://www.spip-contrib.net/Contresens-SPIP
http://www.spip-contrib.net/Autres-termes-epingles
À compléter 
Tout comme l'article d'un journaliste, les "remarques sur SPIP" peuvent être
pertinentes ... ou pas ! Il y a quelques temps déjà, l'excellent mensuel de
réflexion du "Diplo", "manières de voir", avait consacré un numéro spécial à
la formation des journalistes (de plus en plus superficielle, axée sur la
vente au détriment de l'investigation).
Bref, les remarques listées ci-dessous en disent sans doute plus sur la
dégradation de la qualité du travail des journalistes que sur l'ergonomie de
SPIP ...
Voici pourquoi :
Coucou,
j'ai reçu ces remarques, dont certaines pourraient nous donner
quelques pistes d'amélioration.Je n'ai pas besoin de faire un très long article pour critiquer SPIP.
Je trouve l'ensemble très satisfaisant.
La seule chose qui me dérange est l'imprécision du vocabulaire. Cela
entraîne des défauts d'ergonomie.
La croyance dans le mode d'emploi est une façon de se dédouaner du
problème. Exemple type, très gênant "Logo de l'article" pour l'image
principale. Un logo c'est quelque chose de précis :
Logo — Wikipédia
Un titre de journal est un logotype. Pas l'image principale d'un article.
Ce sont essentiellement des détails comme celui-ci, liés à la terminologie,
que j'aurais à reprocher.
Dans SPIP, le logo d'un article, d'une rubrique, ou d'un auteur n'est PAS une
"image principale". La BDD et la plupart des squelettes bien faits réutilisent
ces logos, réduits, dans des listes. SI ce champ s'appelle "logo", c'est bel
et bien parce que son usage est celui d'un logo ! Si certains squelettes
utilisent les logos pour implémenter une notion "d'image principale", c'est un
détournement fonctionnel. Une meilleure solution serait à mon sens de pouvoir
utiliser des mots-clés sur les documents pour les utilisateurs qui veulent
créer cette notion "d'image principale" qui n'existe pas dans SPIP, et qui
surtout n'a en aucun cas la généricité de la notion de logo. Les usages de
SPIP étant très variés, tous les sites n'ont pas besoin, loin s'en faut, de
cette notion "d'image principale d'un article". Il existait un plugin "mots
partout" qui permet déjà de faire ça, mais des mot-clés sur les documents, ça
semble assez générique pour pouvoir faire partie de la dist pluto que d'un
plugin, non ?
Mais ce n'est pas un défaut propre à SPIP, c'est tout le web qui hésite sur
les mots.
Non : ça, c'est un défaut propre à certains "journalistes", qui fait
irrésistiblement penser à cette histoire du type qui prend l'autoroute à
l'envers, et qui en entendant à la radio : "attention ! Un fou a pris
l'autoroute à l'envers", s'exclame : "c'est pas UN fou ! Y'en a plein !"
Si je prends l'"avatar" que l'on trouve un peu partout, c'est un terme
auquel on s'est habitué. Mais il n'en reste pas moins vrai‹outre le fait
que c'est un glissement sémantique issu du monde du jeu‹qu'il est inductif
et qu'il semble interdire de mettre sa véritable photo.
Toutefois, on peut réfléchir s'il est justifié que dans SPIP, le fameux
avatar soit devenu le "Logo de l'auteur"
Là, encore, il y a confusion. Le logo de l'auteur n'est PAS un avatar. Un
"auteur" peut être une association, une personne morale, qui n'a pas d'avatar
mais qui a un logo.
Même chose pour cette étrange pratique du pseudonyme qui s'est généralisée
alors que ce devrait être une exception, utilisée seulement lorsque c'est
justifié.
ça, c'est la "tarte à la crème" des journalistes "old school" qui flippent de
voir le web leur piquer leur lectorat sans jamais s'interroger sur leurs
responsabilités ! Et c'est surtout mensonger : le "nom de plume" des
journaleux, c'est EXACTEMENT la même chose que le pseudo de l'internaute,
contrairement à ce qu'écrivait un plumitif du Monde encore hier ou avant-hier.
Réfléchir à tout cela est aussi un élément technique important.
De ce point de vue, je trouve dans SPIP une bonne volonté évidente. Mais le
travail épistémologique reste à mon avis insuffisant.
S'il existe un forum SPIP qui s'intéresse spécifiquement au vocabulaire, je
serais très content d'y participer ici et là.
Il y a un travail qui serait passionnant à faire sur l'adaptation des
vocabulaires de la presse traditionnelle (papier, radio, télé) aux
spécificités du web. C'est quelque chose de trop important pour le laisser
se former exclusivement sous la plume des publicitaires !
Car, je suis désolé, mais le jargon web (celui qui devient référent) se
précise dans les agences de pub où la nécessité pécuniaire de nommer ce que
l'on vend fait loi.
La création d'un vocabulaire commun stable et d'un glossaire serait de
première utilité dans le monde de l'Open, et dans celui de SPIP, dédié à la
presse, plus encore.
Car je suis certain (mon expérience me le prouve chaque jour), que les
rédacteurs et journalistes sont profondément réfractaires à la lecture des
modes d'emploi. En revanche, on consulte aisément un glossaire ou un
dictionnaire.
ça, c'est incontestable ! Les critiques formulées le prouve !!!
Et puis c'est important pour l'atmosphère ! Quand on fait un journal, on ne
peut pas faire l'économie de cette réflexion au quotidien.
Reste que SPIP est un magnifique projet que je suis très content d'avoir
découvert.
En conclusion, ces "remarques" prouvent AMHA que :
- il faut sans doute que l'aide soit au maximum contextuelle, sur chaque
élément d'interface privé, pour qu'un utilisateur "lambda", tel que par
exemple un journaliste, ait une chance de la lire et d'éviter de confondre
logo et photo de Une ou logo et avatar. Pourquoi ne pas réfléchir à un
mécanisme d'aide générique, contextuel, unifié et intégré entre core et
plugins ? Et "ajaxifié" avec de belles bulles d'aide contextuelle ,
éventuellement ?
- et sur les questions de vocabulaire, il importe de prendre en compte tous
les usages de SPIP, de viser la généricité, et donc de se méfier des
généralisations abusives à partir d'un usage spécifique voire d'un
détournement fonctionnel lié à une méconnaissance de SPIP ...
Cdt,
dF
Je viens de compléter la réflexion sur le vocabulaire spipien par un billet argumenté :
http://romy.tetue.net/825
problème. Exemple type, très gênant "Logo de l'article" pour l'image
principale. Un logo c'est quelque chose de précis :
Logo — Wikipédia
Un titre de journal est un logotype. Pas l'image principale d'un article.
Ce sont essentiellement des détails comme celui-ci, liés à la terminologie,
que j'aurais à reprocher.Dans SPIP, le logo d'un article, d'une rubrique, ou d'un auteur n'est PAS une
"image principale". La BDD et la plupart des squelettes bien faits réutilisent
ces logos, réduits, dans des listes. SI ce champ s'appelle "logo", c'est bel
et bien parce que son usage est celui d'un logo !
Oui, à la réflexion, je ne vois pas de meilleur terme. Le « logo » tel qu'employé dans SPIP est bien identifiant de l'objet qu'il représente.
Si certains squelettes
utilisent les logos pour implémenter une notion "d'image principale", c'est un
détournement fonctionnel. Une meilleure solution serait à mon sens de pouvoir
utiliser des mots-clés sur les documents pour les utilisateurs qui veulent
créer cette notion "d'image principale" qui n'existe pas dans SPIP, et qui
surtout n'a en aucun cas la généricité de la notion de logo. Les usages de
SPIP étant très variés, tous les sites n'ont pas besoin, loin s'en faut, de
cette notion "d'image principale d'un article". Il existait un plugin "mots
partout" qui permet déjà de faire ça, mais des mot-clés sur les documents, ça
semble assez générique pour pouvoir faire partie de la dist pluto que d'un
plugin, non ?
Non
C'est encore un usage détourné des mots-clés, une bidouille pour pallier un besoin ponctuel, mais non générique. Dans cas cas, mieux vaut générer des « logos » à partir d'une image désignée comme principale (à partir d'une contrib comme celle-ci : http://romy.tetue.net/521par exemple). La désignation de l'image principale peut se faire en ajoutant un numéro « 1. » dans le titre de celle-ci.
-- Romy
Concernant les mot-clés, ce n'est PAS un usage détourné, si l'on admet qu'il
puisse exister des mot-clés techniques servant à modifier le comportement
et/ou le contenu d'une page publique selon la valeur dudit mot-clé.
Techniquement, ajouter un numéro ou un code quelconque au titre d'un document
revient à stocker deux informations de natures distinctes dans un même champ
de BDD, et c'est donc à la fois une bidouille et un détournement d'usage par
rapport à l'utilisation de mot-clés techniques.
L'usage de mot-clés en général et de mot-clés techniques sont à la fois assez
génériques pour mériter de aire partie du core (c'est d'ailleurs le cas SAUF
hélas pour les documents), et pas assez générique pour constituer une option
activée par défaut. Ce que je suggère, c'est juste de rajouter une OPTION de
configuration au core pour permettre d'activer des mot-clés sur les documents,
plutôt que de devoir compter sur un plugin externe au core genre "mots
partout" ou pire encore sur une bidouille au niveau des titres des documents.
Il reste toutefois un souci de vocabulaire et de présentation relatif à la
distinction entre mot-clés en général et mot-clés techniques : cette
distinction n'est pas native dans SPIP, et elle est généralement faite au
niveau des squelettes avec un filtre au niveau de la requête permettant de
masquer les mot-clés techniques en tant que de besoin. Une solution plus
propre et plus génrique serait d'ajouter un champ booléen à la table des mot-
clés pour distinguer les deux types de mot-clés au niveau de SPIP lui-même. La
création d'un tel champ "officialiserait" en quelque sorte l'usage de mot-clés
technique, seule véritable bonne solution pour faire dépendre le comportement
d'une page publique de choix de l'utilisateur.
Cdt,
dF
Je viens de compléter la réflexion sur le vocabulaire spipien par un billet
argumenté : http://romy.tetue.net/825
OK avec tout (c'est très pertinent), SAUF avec la dernière partie proposant de
fusionner rubriques et mot-clés. La proposition peut sembler au premier abord
séduisante, mais elle s'arrête en fait au milieu du gué : en effet, on peut
non seulement faire celà mais aller bien plus loin en créant une structure
"d'objets" typés permettant de classer n'importe quel objet dans un OU
PLUSIEURS autre(s) objet(s). Si on le fait pour les "catégories", alors le
mieux serait sans doute de restructurer la BDD autour de cette notion
généralisée de "catégories", afin de permettre d'y associer n'importe quel
type d'objet : autre(s) catégorie(s), article(s), brève(s), auteur(s)
document(s), nouveau(x) type(s) d'objet(s) personnalisés, etc.
Même en se limitant à fusionner rubriques et mot-clés en catégories, dès lors
que l'on moderniserait SPIP pour permettre des classifications d'objets (ex:
article) dans plusieurs catégories, la hiérarchie d'un objet peut devenir
multiple, ce qui nécessiterait des changements induits dans le traitement des
hiérarchies d'objets SPIP.
Bref, cette réflexion amène à proposer de moderniser la structure actuelle de
BDD de SPIP, pour permettre d'implémenter des relations "plusieurs vers
plusieurs" entre objets SPIP.
Pourquoi pas ? Il y a de toute façon dans SPIP des "reliques" fonctionnelles,
comme par exemple la table des brèves conçues comme des "sous-articles" sans
tous les champs d'un article, alors qu'à l'inverse la table articles contient
tous les champs pour stocker les brèves.
Mais il ne fait nul doute que ce serait un gros chantier ...
Bonjour,
Une nouvelle table de mots technique serait plus logique.
En effet, les utilisateurs ne doivent pas être induits en confusion.
Il est déjà compliqué d'expliquer ce que sont les mots clés, en particulier par rapport à l'utilisation des "mots clés" du moteur de recherche.
Alors les mots techniques comme des mots clés, si c'est un détournement, depuis l'origine de SPIP, et ça ne simplifie pas la compréhension des utilisateurs.
Pourquoi donc ne pas séparer, une bonne fois, clairement les deux puisque nous avons vu depuis 10 ans que jamais ne s'est démentie l'utilisation et l'utilité de mots clés technique ?
C'est pas faux. Donc +1
Stanislas
Bonjour,
L'utilisateur ne sait pas comment sont faites les tables.
Pourquoi une nouvelle table si la structure est la même ?
Une unique table avec un champ définissant l'usage (technique ou non), usage qui lui sera différencié au niveau de l'interface utilisateur pour que ce soit bien distinct.
Car on pourrait imaginer une autre usage des mots clésn auquel cas faudrait-il encore créer une table ?... ou un simple champ extra.
* Stéphane Santon tapuscrivait, le 15/07/2011 23:21:
Bonjour,
L'utilisateur ne sait pas comment sont faites les tables.
Pourquoi une nouvelle table si la structure est la même ?
D'accord. Mais entre mots-techniques, mots partout, motus... c'est un
poil complexe car déjà pas répertoriés au même endroit dans contrib... Je
ne doute pas qu'il y a là une logique de développement, mais pour
l'utilisateur lambda c'est un peu le jeu de piste... 
Cordialement
Stanislas
Ce que je suggère, c'est juste de rajouter une OPTION de
configuration au core pour permettre d'activer des mot-clés sur les documents
Les mots-clés ne font plus partie du noyau.
Une solution plus
propre et plus génrique serait d'ajouter un champ booléen à la table des mot-
clés pour distinguer les deux types de mot-clés au niveau de SPIP lui-même.
C'est à peu près ce que fait le plugin "Mots techniques" qui distingue techniquement les deux, et qui permet donc, même si ce n'est pas forcément déjà le cas, de pouvoir faire des interfaces différentes pour les différentes types de mots.
Jamais eu besoin. Et encore moins depuis l'apparition de Compositions.
Je suis tout à fait d'accord qu'il reste des manques, mais c'est une solution bien plus propre et donc ça me parait plus viable, plus pérenne, de passer du temps à améliorer cette méthode que de continuer de bidouiller des vieux hacks en tentant de les moderniser.
Bien sûr ça ne fait pas tout, alors que les mots c'était "pour tout et n'importe quoi". Mais pour chaque usage particulier il vaut mieux essayer de trouver une méthode qui lui soit propre.
Pour avoir plusieurs modèles de squelettes à choisir : Compositions. Pour faire des sélections manuelles en pages d'accueil : Sélection d'articles. Pour faire des menus en sélectionnant précisément le contenu : Menus. Etc. Ce ne sont que des exemples qui peuvent être imparfaits, incomplets, mais je trouve ça plus propre. Selon le principe "un module = une fonctionnalité".
> Ce que je suggère, c'est juste de rajouter une OPTION de
> configuration au core pour permettre d'activer des mot-clés sur les
> documentsLes mots-clés ne font plus partie du noyau.
Pour éviter toute confusion : l'idée suggérée était de permettre (en option)
d'activer des mot-clés sur les documents à partir de la dist, sans avoir
besoin pour celà du plugin "mots partout" ou d'un quelconque autre plugin qui
ne ferait pas partie de la dist.
> Une solution plus
> propre et plus génrique serait d'ajouter un champ booléen à la table des
> mot- clés pour distinguer les deux types de mot-clés au niveau de SPIP
> lui-même.C'est à peu près ce que fait le plugin "Mots techniques" qui distingue
techniquement les deux, et qui permet donc, même si ce n'est pas
forcément déjà le cas, de pouvoir faire des interfaces différentes pour
les différentes types de mots.
Là encore, la fonctionnalité semble suffisamment générique pour mériter de
faire partie de la dist, en tant qu'option.
Enfin, en ce qui concerne le plugin Compositions, il ne répond pas aux mêmes
besoins fonctionnels que l'usage de mot-clés techniques, qui est bien plus
générique puisque rattaché directement à un objet SPIP et non à une page de
squelette entière. On peut vouloir faire varier le comportement d'un objet
dans une page sans pour autant vouloir changer toute la page ni l'affichage
d'autres objets de même type dans la même page. Par exemple, un mot-clé
technique associé à un article peut permettre de gérer très facilement la
notion d'article archivé (et masquer lesdits articles de certaines listes
d'articles). Ce type d'usage ne correspond absolument pas à celui du plugin
Compositions, qui est considérablement moins souple que l'usage de mot-clés
techniques.
J'ai dû mal m'exprimer, j'ai dit que le plugin Compositions correspondait à UNE utilisation des mots-clés qui était le choix d'un modèle de squelette directement depuis l'interface SPIP.
Ensuite j'ai cité exprès d'autres plugins qui correspondent à chaque fois à d'autres anciennes utilisations des mots-clés en bidouille.
Ceci pour montrer que d'après moi le mieux est que pour chaque usage, pour chaque besoin, on peut trouver ou fabriquer un plugin correspondant précisément à cet usage et l'améliorer lui.
Les mots-clés que tu appelles "techniques" sont effectivement un usage qui persiste depuis le début car au départ il n'existait pas de système de plugin, puis celui-ci existait mais avec peu de choix complexes pendant un long moment. De ce fait, l'usage de mots-clés techniques a continué puisque c'était la seule manière ! Ce n'est qu'un usage "par défaut", ça ne prouve absolument pas que ça continue d'être pertinent dans la majorité des cas.
Depuis, petit à petit, on arrive à un point où le panel des plugins devient conséquent, et où on peut soit déjà faire, soit imaginer, à chaque fois un plugin pertinent pour chaque besoin.
Si l'usage de mot-clés technique est constant depuis les débuts de SPIP ou
presque, c'est pour une excellente raison : celà correspond à une structure de
données pertinente, générique, souple, et puissante.
Ou selon un autre point de vue : un fourre-tout difficile à maintenir sur le long terme, surtout quand on fini par utiliser ce système pour 12 fonctionnalités différentes sur le même site. Sans parler de l'ergonomie qui fait que toutes ces fonctionnalités sont alors dans un même bloc d'interface.
Le seul inconvénient de cette méthode est l'absence de distinction native
entre mot-clés de navigation et mot-clés technique, qui peut parfois engendre
des confusions pour les utilisateurs. Le plugin Mots-technique tente d'y
remédier, mais il s'agit d'une distinction qu'il serait AMHA intéressante
d'intégrer à la dist (avec choix d'activer ou non l'option dans le panel de
configuration des mot-clés).
Que les mots-clés techniques soit à part ne change rien à ce que je dis précédemment : pleins de fonctionnalités n'ayant rien à voir se retrouve à être gérer avec la même méthode et dans le même bloc d'interface.
Enfin, en ce qui concerne le plugin Compositions, il ne répond pas aux mêmes
besoins fonctionnels que l'usage de mot-clés techniques, qui est bien plus
générique puisque rattaché directement à un objet SPIP et non à une page de
squelette entière. On peut vouloir faire varier le comportement d'un objet
dans une page sans pour autant vouloir changer toute la page ni l'affichage
d'autres objets de même type dans la même page. Par exemple, un mot-clé
technique associé à un article peut permettre de gérer très facilement la
notion d'article archivé (et masquer lesdits articles de certaines listes
d'articles). Ce type d'usage ne correspond absolument pas à celui du plugin
Compositions, qui est considérablement moins souple que l'usage de mot-clés
techniques.J'ai dû mal m'exprimer, j'ai dit que le plugin Compositions correspondait à UNE utilisation des mots-clés qui était le choix d'un modèle de squelette directement depuis l'interface SPIP.
Compositions ne permet toujours pas autant que les mots.
Deuxio, non seulement ça permet moins, mais en plus c'est plus complexe à mettre en œuvre.
Tertio, je ne comprends pas l'intérêt d'essayer de faire aussi bien, mais autrement, ce qui se fait déjà très bien avec des mots.
De mon point de vue, c'est une mauvaise approche.
Ceci pour montrer que d'après moi le mieux est que pour chaque usage, pour chaque besoin, on peut trouver ou fabriquer un plugin correspondant précisément à cet usage et l'améliorer lui.
Concernant les Compositions et l'application de variantes de squelettes, etc. le mieux serait d'utiliser ce qui ce fait déjà. La mécanique des mots-clés est tout à fait satisfaisante pour cela. Le problème est moral (« les mots-clés, c'est le mal ») et ergonomique (« les utilisateurs s'y perdent »). Mieux vaudrait donc travailler à l'interfaçage utilisateur, plutôt que de re-développer tout un bouzin qui, en plus, ne fait pas aussi bien.
-- Romy
> Enfin, en ce qui concerne le plugin Compositions, il ne répond pas aux
> mêmes besoins fonctionnels que l'usage de mot-clés techniques, qui est
> bien plus générique puisque rattaché directement à un objet SPIP et non
> à une page de squelette entière. On peut vouloir faire varier le
> comportement d'un objet dans une page sans pour autant vouloir changer
> toute la page ni l'affichage d'autres objets de même type dans la même
> page. Par exemple, un mot-clé technique associé à un article peut
> permettre de gérer très facilement la notion d'article archivé (et
> masquer lesdits articles de certaines listes d'articles). Ce type
> d'usage ne correspond absolument pas à celui du plugin Compositions, qui
> est considérablement moins souple que l'usage de mot-clés techniques.J'ai dû mal m'exprimer, j'ai dit que le plugin Compositions
correspondait à UNE utilisation des mots-clés qui était le choix d'un
modèle de squelette directement depuis l'interface SPIP.
OK. L'inconvénient est d'avoir rajouté une structure de données redondante
avec la notion de mot-clé technique. L'avantage d'avoir isolé
fonctionnellement ce besoin est contrebalancé par la dépendance à DEUX
plugins, Compositions et Bonux, d'une part, et par le fait de couvrir moins de
besoins fonctionnels que la notion de mot-clés techniques.
Ensuite j'ai cité exprès d'autres plugins qui correspondent à chaque
fois à d'autres anciennes utilisations des mots-clés en bidouille.
Isoler les fonctions, c'est bien, mais repérer les structures de données
communes permettant de mutualiser et de simplifier le code, c'est mieux.
Si on peut répondre à des besoins variés avec la notion générique de mot-clé
(technique), c'est bien plus simple à maintenir et à faire évoluer que de
dépendre des évolutions d'une floppée de plugins "microfonctionnels".
Ceci pour montrer que d'après moi le mieux est que pour chaque usage,
pour chaque besoin, on peut trouver ou fabriquer un plugin correspondant
précisément à cet usage et l'améliorer lui.Les mots-clés que tu appelles "techniques" sont effectivement un usage
qui persiste depuis le début car au départ il n'existait pas de système
de plugin, puis celui-ci existait mais avec peu de choix complexes
pendant un long moment. De ce fait, l'usage de mots-clés techniques a
continué puisque c'était la seule manière ! Ce n'est qu'un usage "par
défaut", ça ne prouve absolument pas que ça continue d'être pertinent
dans la majorité des cas.
Ce qui rend l'usage de mot-clés techniques pertinent, c'est d'abord et avant
tout la structure de données sous-jacente, dont la cardinalité des relations
entre tables permet des relations "plusieurs vers plusieurs".
Si l'on "doit", pour les besoins d'un plugin spécifique, recréer une structure
de données identique ou presque, celà finit par alourdir tout sans réelle
nécessité.
Depuis, petit à petit, on arrive à un point où le panel des plugins
devient conséquent, et où on peut soit déjà faire, soit imaginer, à
chaque fois un plugin pertinent pour chaque besoin.> Si l'usage de mot-clés technique est constant depuis les débuts de SPIP
> ou presque, c'est pour une excellente raison : celà correspond à une
> structure de données pertinente, générique, souple, et puissante.Ou selon un autre point de vue : un fourre-tout difficile à maintenir
sur le long terme, surtout quand on fini par utiliser ce système pour 12
fonctionnalités différentes sur le même site
Oui : c'est un autre point de vue. Le mien est que si on peut répondre à 12
besoins fonctionnels différents avec une structure de données unique, c'est
sans nul doute que celle-ci est particulièrement pertinente. Et bien plus
facile à maintenir que 12 plugins ayant chacun leur structure de données
personnelle reproduisant peu ou prou les mêmes cardinalités entre tables.
. Sans parler de l'ergonomie
qui fait que toutes ces fonctionnalités sont alors dans un même bloc
d'interface.
Là dessus, entièrement d'accord !!! C'est LE seul problème de cette approche,
mais il est bien réel. Une solution serait de pouvoir personnaliser facilement
ces blocs selon leur fonction(s) dans l'interface privée. Les versions dev de
SPIP intègrent désormais la possibilité de l'envisager sans efforts
titanesques, grâce d'une part à la nouvelle gestion des mot-clés (v 2.3 ou 3.0
?) qui en quelque sorte implémente nativement le futur-ex plugin Mots-Objets,
et d'autre part au passage de l'interface privée en templates.
Cdt,
dF
Je ne partage pas non plus l'acharnement contre les motclés.
Les motclés sont une technologie simple, robuste, polyvalente et éprouvée.
Ne serait-ce que parcequ'il n'y a ainsi qu'un unique apprentissage,
une unique implémentation, et une unique maintenance,
ils ont un gros avantage vis a vis de solutions spécialisées,
car si il faut remplacer les motclés par 3 outils différents "mieux adaptés"
il est évident qu'il y aura 3 temps d'apprentissage,
et 3 codes différents à implémenter et à maintenir...
De plus, au regard de la simplicité canonique des motclés,
les compositions n'ont elles pas un code plus complexe,
nécessitant des compétences plus rares, et plus difficile à maintenir ?
Enfin, la critique des motclés mène à la création de 'mots techniques'
essentiellement pour améliorer l'interface avec l'utilisateur.
Dans ce cas, n'est ce pas plutôt un sélecteur de motclés mieux paramétrable
(selon le contexte) qu'il faudrait en fait ?
JLuc... on s'éloigne un peu du sujet initial là...
Je rebondis sur votre discussion qui m'intéresse au plus haut point ^^. Pour une raison différente de la votre cependant : la migration du plugin mots_techniques vers SPIP 3 pose un problème technique justement du fait du passage en squelettes de l'interface privée.
En effet, mots techniques cache, par défaut sur les boucles des squelettes tous les mots ou groupes de mots déclarés techniques, avec pour corollaire, dans SPIP 3, que dès qu'on a définit un groupe technique, on ne le voit plus dans l'interface privée par défaut (il manque, dirons-nous le critère {tout} sur les boucles MOTS / GROUPES_MOTS).
Cela étant dit, il est peut être envisageable que le plugin «mots techniques» s'utilise dans le privé, depuis une autre page (?exec=mots_techniques) par exemple. Cela permettrait, dessus de n'afficher que ces mots là. La contre partie est tout de même lourde de conséquence : une partie du code est dupliquée, alors que l'affichage, est peu ou prou le même : on veut la même chose que les groupes / mots normaux.
Il faudrait réussir effectivement à rendre cette distinction plus claire. Joseph (je crois) avait d'ailleurs pour SPIP 2 fait un plugin «attribut» qui dupliquait déjà tous le code des mots, pour les séparer (même la table pour le coup).
Bref... je rejoins aussi Romy et Daniel sur certains points : l'utilisation des mots clés est bien plus pratique et rapide que les compositions HORMIS le fait qu'il manque un «identifiant» non numérique sur les mots, permettant d'utiliser <multi> sur les titres, tout en pouvant utiliser l'identifiant dans les squelettes, car {mots.titre=actualites} ne fonctionne que si le #TITRE du mot est réservé à cet usage, alors même que le titre du mot devrait servir à afficher Actualités ou News... et {mots.id_mot=5} est trop spécifique à un site donné.
Mes 2 sous,
Matthieu.
Je ne partage pas non plus l'acharnement contre les motclés.
Les motclés sont une technologie simple, robuste, polyvalente et
éprouvée.
Ne serait-ce que parcequ'il n'y a ainsi qu'un unique apprentissage,
une unique implémentation, et une unique maintenance,
ils ont un gros avantage vis a vis de solutions spécialisées,
car si il faut remplacer les motclés par 3 outils différents "mieux
adaptés"
il est évident qu'il y aura 3 temps d'apprentissage,
et 3 codes différents à implémenter et à maintenir...
Je suis bien d'accord et j'en arrive à regarder ce qui se fait ailleurs
: un exemple au hasard : Drupal utilise la "taxonomie" : c'est
utilisable pour faire ce qu'on peut faire avec les rubriques et les mot
clef de Spip mais avec une plus grande richesse et une plus grande
souplesse. (Pas taper :-))
Pour l'avoir un peu utilisé, je trouve ça très pratique du point de vue
du concepteur du site comme de celui de l'utilisateur.
Mes 2 sous,
Sylvain