[spip-dev] Je découvre SPIP, Zpip et le plugin menu...

Dev
1

J'essaye actuellement SPIP sur un poste de travail qui n'est pas le
mien et où tout est nouveau pour moi et dont l'ergonomie n'est pas
idéale. Cette situation de dépaysement total est très intéressante car
elle me montre SPIP d'une autre façon : privée de mes repères et
ressources personnelles, je redécouvre et galère comme une débutante.

Pour que ça nous soit utile, je prends le temps de noter mes remarques
au fur et à mesure. Après avoir réussi à installer un SPIP tout neuf
en début de semaine, ce jeudi (24 décembre) j'installais Zpip...

=== Installation de Zpip
(d'après.: http://www.spip-contrib.net/Installer-Zpip-pas-a-pas )
- beaucoup de plugins à installer... et ce n'est pas très pratique
comme manip sur mon poste
- quand on découvre, tout ça d'un coup (plusieurs plugins nouveaux,
c'est pas évident du tout... un zip contenant tout serait certes
bienvenu mais pas seulement : en situation de découverte de zpip, avec
beaucoup d'éléments nouveaux, il n'est pas évident de repérer ce qui
fonctionne normalement ou pas, et ça induit un comportement de
tâtonnement, par essai-erreur, non performant.

Bref si l'ensemble fonctionne correctement, la voie pour y arriver
n'est pas encore correctement balisée.

=== Plugin Menu
- Inutile d'afficher en continu le bouton « enregistrer » sur le
panneau de config d'un menu
- Choix des nouvelles entrées à ajouter : revoir l'ordre de façon à
présenter les plus simples en premier (rubriques d'abord, puis
rubriques dynamiques) + revoir l'iconographie en cohérence avec
l'interface actuelle afin de permettre d'identifier les objets
semblables
- la page de test spip.php?page=test_menus&identifiant=navigation ne
marche pas : (« Aucun squelette 'test_menus.html' n'est disponible...
Erreur de compilation »)
- le lien « voir en ligne » a un comportement surprenant : il renvoie
en page d'accueil du site public !! Il devrait afficher le menu
seulement : ainsi, quand ça marche pas, c'est + facile de s'en rendre
compte (plutôt que d'avoir à décrypter une page d'accueil inconnue
sans savoir où devrait apparaître ce menu ni même si il devrait y
apparaître).
- Semble y avoir un bug : il faut créer une rubrique dynamique pour que

=== Plugin Menu + zpip
- Il faudrait ajouter une page dédiée dans la doc du plugin Menu,
genre « Le plugin Menu dans Zpip », car on ne pense pas à aller
chercher ça dans Zpip ; où serait précisé :
-- qu'il faut indiquer un identifiant spécifique pour que le menu créé
soit automatiquement pris en compte dans zpip
- l'intitulé « barrenav » n'est pas évident et présume trop de la mise
en forme ; « navigation » serait préférable pour cette navigation
principale. Ou « menu »... Peut-être faut-il prévoir dans zpip un
préfixe pour caractériser tous les éléments de navigation : « nav-...
»

=== Plugin Zen Garden
- La page est vide par défaut, alors qu'on s'attend à trouver une
galerie pleine de thèmes prêts à l'emploi...
- Il manque un message indiquant ce qu'on doit faire (Est-ce à moi de
remplir la galerie ? Comment ? etc.)
- Pourquoi n'affiche-t-elle pas automatiquement les thèmes que j'ai
déjà, stockés dans mon repertoire /plugins/ ?
- On se demande quel est son intérêt : elle permet juste d'affecter
des thèmes, comme le panneau des plugins mais avec une vignette de
prévisu en plus...
- Pourquoi créer un répertoire /themes/ à la racine ? ça m'impose de
déplacer les thèmes que j'ai stocké ailleurs, alors que je veux juste
*essayer* : je devrais les re-déplacer après... spontanément je les
aurais mis *dans* /zen-garden/. C'est d'ailleurs ce que je viens de
faire par erreur :stuck_out_tongue:
+ ça me fait beaucoup de répertoires ouverts là, sur mon ordi, pour
juste essayer un nouveau truc...

=== SPIP
- c'est la première fois que je ressens si cruellement le manque d'une
base de données de démarrage (je n'ai pas la mienne et je m'étonne que
ce soit si long à faire :
-- il manque un bouton « créer une nouvelle rubrique » accessible
depuis chaque page (et non pas une sous-rubrique, qui impose de la
déplacer après chaque création)
-- confusion entre création d'article et de rubrique : on crée trop
facilement l'un en pensant faire l'autre !

Jeudi soir : je n'ai pas encore vraiment *vu* Zpip...

Suite au prochain épisode :slight_smile:

-- Romy

2

Je poursuis, ce mardi 12 janvier, ma découverte de Zpip. Toujours dans
les mêmes conditions : sur un environnement de travail inhabituel et
tabula rasa, qui me place en situation de débutante.

J'ai réussi à installer toussa et j'ai découvert qu'on pouvait
facilement changer de thème, c'est épatant, mais ce que j'aimerais
maintenant, c'est faire mon site, tout simplement (sans partir d'un
thème existant). Je ne vois pas très bien comment faire, par où
commencer... Complètement perdue.

=== Par où commencer ?
Je ne sais pas comment démarrer et m'en réfère à la méthode habituelle
de surcharge : pour tester, je place un fichier article.html dans un
répertoire squelettes, puis un fichier body-layout.html...
Renseignement pris, ce n'est pas la bonne méthode. Il manque
certainement un tuto de démarrage qui expliquerait avec un exemple.
Dans quel répertoire doit-on construire son site ?

=== Écrire un thème pour Zpip ?
http://www.spip-contrib.net/Ecrire-un-theme-pour-Zpip
Cet article (qui me semble lié nulle part et que je n'aurais jamais
trouvé si on ne m'avait pas filé le lien à la main) ne répond pas aux
questions de démarrage que je me pose :
- si le « thème est constitué d'un répertoire », où dois-je ranger
celui-ci ? en sous-rep de /squelettes/ ? dans /plugins/ ? avec un
fichier plugin.xml dedans ?
- est-ce que les feuilles de styles apportées par un plugin (par
exemple mon reset ou mon framework habituel) sont prises en compte ?
ou faut-il tout reproduire/centraliser dans mon répertoire thème ?
- est-ce que l'ancienne méthode (une feuille de style perso déposée
dans le répertoire /squelettes/) fonctionne toujours ?
- la création d'un thème est-elle obligatoire ? même sans intention de
distribuer et partager ledit thème ?

J'ai testé différentes possibilités mais, pas certaine d'avoir besoin
de « faire un thème », je décide finalement de construire mon site
comme d'habitude, directement dans le répertoire /squelettes/.

=== Nomenclature de body-layout.html
Quelques remarques en passant (non exhaustives) :
- manque d'homogénéité entre le nom de la class parente et celui de
l'inclusion (class="nav" pour inclure/barre-nav)
- la navigation principale ne devrait-elle pas s'appeler "navigation",
comme souvent ?
- un nom anglais (footer) vient se perdre dans cette nomenclature francophone

Je n'aurais malheureusement pas l'occasion de poursuivre plus loin mes
explorations. Zpip est abandonné.

Pour conclure, je trouve Zpip destiné à des grands débutants (par ses
thèmes qui se changent d'un clic) ou aux spipmestres chevronnés (par
la méthode avancée qu'il propose), mais peut-être pas au webmestre
amateur (qui, sans Zpip, n'avait que 2 ou 3 fichiers à manipuler pour
pondre son site, que ce soit en surchargeant juste quelques bout de
page ou en recodant tout).

-- Romy

3

je suis plutôt d'accord avec toi; Ce qui me gêne le plus avec les thèmes et zpip c'est d'avoir à aller tantôt dans le répertoire du plugin zpip, tantôt dans le répertoire du thème sélectionné, tantôt dans le répertoire squelettes suivant les personnalisations à apporter.

Je suppose que c'est la première étape du processus et qu'une fois qu'on a assimilé tout le bouzin il devrait y avoir moyen de tout stocker au même endroit, j'y suis pas encore.
Donc les thèmes pré-installés c'est bien si on n'y change rien ensuite (mais ça doit être rare).

dd

4

ZPIP = LateX. C'est pas faute d'avoir rabâché ce sujet depuis le lancement de la première version de SPIP...

Je m'auto-cite (l'année dernière):

«
- il y a un point que je n'ai pas vraiment abordé: on se focalise en ce moment sur une opposition entre «débutants» et «utilisateurs confirmés» (à ce sujet: l'idée de passer les débutants en rédacteur «pour se faire la main» et de passer les confirmés en admin ne correspond plus à la réalité des usages; ça a pu être un peu vrai à une époque, ça ne l'est plus du tout). En réalité, si on relit les vieux argumentaires sur spip-dev, l'idée est différente. Le souci principal dans SPIP était de proposer une courbe d'apprentissage progressive et continue.

Pour ceux qui connaissent, j'utilise régulièrement l'image de TeX, un système de traitement de texte très ancien mais toujours très puissant: TeX est un moteur «nu», assez difficile d'accès, mais qui offre une courbe de progression quasiment géniale: j'ai travaillé pendant 10 ans avec TeX, c'était mon métier, et j'ai appris de nouveaux trucs tous les jours pendant 10 ans; puis est arrivé LaTeX, une sorte de surcouche de TeX, qui offre d'office une floppée d'automatismes très puissant: hé bien tout d'un coup tout le monde s'est mis à faire du LaTex et à savoir faire un livre lisible mais sans acquérir de compétences supplémentaires et sans être réellement capable de personnaliser réellement sa mise en page. Avec TeX: on commence en étant totalement nul, incapable de produire un document potable, et progressivement on acquiert des techniques, on se fabrique ses bibliothèques d'automatismes, et on finit par savoir absolument tout maîtriser, avec des automatismes quasiment inimaginables avec XPress ou Indesign. Avec LaTeX: tout le monde devient rapidement capable de produire des documents au rendu propre mais uniforme, et n'acquiert jamais la moindre compétence qui permettrait d'aller plus loin. TeX offre une courbe d'apprentissage sous forme de droite ascendante, chaque jour permet d'apprendre de nouvelles choses. LaTeX impose une courbe d'apprentissage en escalier: on franchit rapidement un pallier énorme, mais ensuite on stagne à ce niveau.

Pourquoi cet exemple? D'abord parce que ça a longtemps façonné les réflexions autour de SPIP. Et aujourd'hui: pour souligner le fait que le souci n'est pas, à mon avis, l'opposition entre débutants et utilisateurs confirmés, mais dans la courbe de progression que permet le système. C'est particulièrement flagrant dans le système de boucles: oui il y a un investissement au départ, mais ensuite on progresse de jour en jour pendant des années (je trouve de nouvelles techniques à chaque fois, rien qu'avec les boucles, ce qui ne cesse de me sidérer), là où d'autres systèmes proposent des «thèmes» clé en main immédiatement exploitables, modulaires et tout, mais dont la réalisation est grosso modo réservée à quelques ingénieurs de SSII.
»

Pour être tout à fait clair: je n'ai jamais, de toute ma carrière, rencontré quelqu'un qui aurait commencé avec LaTeX et qui serait devenu compétent en quoi que ce soit de relatif à la mise en page d'un livre. Alors que des utilisateurs de TeX qui ont développé leurs compétences en autodidacte, tout le temps.

A*

5

Pour conclure, je trouve Zpip destiné à des grands débutants (par ses
thèmes qui se changent d'un clic) ou aux spipmestres chevronnés (par
la méthode avancée qu'il propose), mais peut-être pas au webmestre
amateur (qui, sans Zpip, n'avait que 2 ou 3 fichiers à manipuler pour
pondre son site, que ce soit en surchargeant juste quelques bout de
page ou en recodant tout).

ZPIP = LateX. C'est pas faute d'avoir rabâché ce sujet depuis le lancement de la première version de SPIP...

Je m'auto-cite (l'année dernière):

...

Pour être tout à fait clair: je n'ai jamais, de toute ma carrière, rencontré quelqu'un qui aurait commencé avec LaTeX et qui serait devenu compétent en quoi que ce soit de relatif à la mise en page d'un livre. Alors que des utilisateurs de TeX qui ont développé leurs compétences en autodidacte, tout le temps.

Ce qui permet en permanence de progresser à l'humanité dans son ensemble c'est de capitaliser sur des technos et de les assembler pour en faire de plus puissantes.

Alors oui, quand on utilise un assemblage de technos, une surcouche, on a pas la maîtrise de tous les petits constituants si on a pas pris le temps de tout démonter et remonter.
Oui, on peut acquérir une meilleure maitrise de toute la techno en refaisant tous les pas du progrès par soi même.
Il est parfois nécessaire de tout re-demonter pour comprendre, progresser, et apporter une nouvelle amélioration.

Mais la même argumentation peut aisément être déployée sur bien d'autres sujets.

Et pourtant tu utilise ta voiture qui est un assemblage de technologies, sans avoir pris le temps de chercher à comprendre comment la fabriquer par toi même, ou en tout cas sans l'avoir montée par toi même. Cela vaut sans doute aussi pour ton ordinateur, ton OS, le super logiciel vectoriel que tu utilises pour dessiner tes icônes...

En résumé il est passionnant de reprendre et redécouvrir par soi même tout le champs du savoir dans un domaine technologique mais :
-* personne n'a le temps de le faire pour l'ensemble des techniques qu'il utilise au quotidien
-* tout le monde n'a pas la capacité de le faire

On peut donc militer pour inciter les gens à ne pas utiliser des produits tout faits. Mais où s'arrêter ?
On peut aussi considérer qu'il est plus enrichissant de commencer par le binaire, qui a une courbe d'apprentissage bien plus progressive et permet d'aborder plein de notions ultérieures ...

Pour être tout à fait clair : il n'y a pas de voie unique et beaucoup d'utilisateurs n'ont pas envie de réinventer la roue tous les matins.

Cédric

6

Pour conclure, je trouve Zpip destiné à des grands débutants (par ses
thèmes qui se changent d'un clic) ou aux spipmestres chevronnés (par
la méthode avancée qu'il propose), mais peut-être pas au webmestre
amateur (qui, sans Zpip, n'avait que 2 ou 3 fichiers à manipuler pour
pondre son site, que ce soit en surchargeant juste quelques bout de
page ou en recodant tout).

-- Romy

je suis plutôt d'accord avec toi; Ce qui me gêne le plus

Je ne voulais pas faire une critique négative et je me rends compte que je n'ai pas su aller jusqu'à transformer ça en propositions + constructives. Je pense qu'il manque peu : quelques améliorations d'interface, pour aller encore plus à la rencontre du débutant (avec une galerie de thème *prête à l'emploi*, etc. et pourquoi pas un éditeur de squelettes directement dans l'espace privé ?) et un bon gros tuto, étape par étape, illustré et simple, peut-être sur un site dédié-démo, pour le webmestre amateur. Les autres sauront se débrouiller avec spip-contrib.

7

La séparation de l'espèce humaine entre:
- ceux savent et qui codent
- ceux qui ne savent pas et cliquent sur des boutons,
c'est aussi un total contresens concernant SPIP, puisque c'est exactement contre cela que SPIP s'est construit. SPIP s'est construit sur l'idée que l'outil pouvait faciliter l'apprentissage. À la fois apprendre à construire l'aspect éditorial d'un site Web, et les techniques d'un site Web.

On cause ici du choix de la structure des squelettes; pas du choix entre squelettes et pas squelettes. On fournit déjà des squelettes, depuis l'origine de SPIP. Et ils font déjà la même chose que ZPIP. La différence, c'est que les squelettes «standards» ne permettent pas facilement certaines choses (et revanche, l'argument sur leur redondance ne me semble pas franchement pertinent, parce qu'il n'y a que peu de choses redondantes). Et l'autre différence, c'est que c'est illico l'usine à gaz (quand je fais créé un site de A à Z, je refais tout, et avec la structure «traditionnelle», et il est tout de même impressionnant de constater qu'à chaque fois, il y a très peu de fichiers à fabriquer et qu'il y a assez peu de redondances dans les fichiers). Quelqu'un dans le forum sur contrib dit «niveau d'abstraction supplémentaire», ce qui est une façon carrément gentille de le dire.

Avec la structure habituelle des squelettes, tous les automatismes pour faire un site SPIP sont présents. Ça n'est pas comme si j'allais recoder mon ordinateur en binaire pour faire mon site Web ou réinventer le moteur à explosion pour aller en ville.

Après, je m'en fous un peu, tant que c'est un plugin. C'est juste que le truc génial-kikou qui va révolutionner SPIP, je considère que c'est un contresens. Alors Romy écrit, noir sur blanc (sur mon écran), très exactement ce que je dis: c'est génial pour commencer, c'est génial quand on est super-chef, mais c'est pas du tout pratique pour les «intermédiaires» (ce que je traduis, depuis des années par l'analogie LaTeX: la courbe de progression est immédiate au début puis plus personne n'est capable de progresser pour dépasser la simple installation d'un squelette tout fait), maintenant elle peut toujours dire que ça doit être lu comme une critique «positive»: moi je pense simplement que c'est exactement le contraire de l'idée même de SPIP.

Depuis que SPIP existe, je passe mon temps à rencontrer des gens qui ont «appris» avec SPIP. C'est SPIP qui les a poussés à faire du HTML, et/ou des CSS, et/ou du javascript, et/ou bidouiller du PHP, et/ou regarder ce qu'est une base de données... Oui, tout le monde dit «les squelettes de base sont moches», et ensuite personne n'est mort et tout le monde est carrément content d'avoir appris quelque chose. Si on veut une communinauté de consuméristes pousse-bouton, ça n'a aucun intérêt pour un logiciel libre.

Le fait que SPIP pousse à apprendre des trucs n'est pas un bug. C'est une caractéristique.

ARNO*

8

Bon, je me réponds illico: «C'est juste que le truc génial-kikou qui va révolutionner SPIP, je considère que c'est un contresens.» c'est très excessif. Mais c'est l'introduction du «apprendre le binaire» qui m'y a poussé :slight_smile:

Pour être moins négatif: je pense que c'est largement contreproductif de se focaliser là dessus (je veux dire: ZPIP et templates tout faits). Avec ça, on reste avec un site pas très joli (vraiment), et surtout mal fichu, avec une page d'accueil faiblarde et une structure de rubriques qui ne casse pas des briques. Et en revanche on hérite d'une structure des squelettes pas intuitive pour deux sous.

Et toujours ce vieux contresens:
(1) SPIP permet de faire énormément de choses, ce qui dans tous les cas rend pénible la création de squelettes génériques (sur du non-générique, on ne gère pas les liens de traduction dans les articles et basta);
(2) le graphisme du site dépend de son ergonomie et de son contenu; un aspect direct: si je veux vraiment typer l'aspect de mon site, la méthode la plus efficace est de recadrer systématiquement les logos dans la navigation; mais ça impose aux webmestres de choisir des logos qui vont bien avec le graphisme du site; du coup, là aussi, impossibilité de faire de «beaux» squelettes génériques parce qu'on ne va «jamais» se permettre de recadrer à la dure les logos;
(3) il y a une bonne trouzaine de méthodes pour sélectionner les éléments à «mettre en Une»; du coup, les squelettes génériques n'en intègrent jamais aucune. Donc page d'accueil inexistante, qui se contente d'aligner les derniers articles publiés et les derniers messages des forums. Ça va pour quelques sites éditoriaux, et tous les autres sites ont besoin d'autre chose de beaucoup plus structuré et adapté que ne fournira pas un squelette générique.

Le contresens est là: par définition, un squelette générique atteint très rapidement ses limites. Qu'il soit plus ou moins «joli» ne change rien aux points 1, 2 et 3: par définition, le squelette générique est fondamentalement un truc limité et inadapté à «mon» site. Ça n'est pas, contrairement à la croyance générale, parce que ce serait «compliqué à installer» et qu'on résoudrait ces questions par du «pousse-bouton». D'où: puisque par définition un squelette générique est inadapté, sa meilleure caractéristique est d'amener l'utilisateur à apprendre à le modifier pour l'adapter à ses besoins. D'où le système de squelettes et de boucles, parce que les squelettes PHP comme le faisaient tous les autres, ça me hérissait le poil. D'où la notion de «courbe d'apprentissage» qui est central dans SPIP. Pas «je pousse et ça mousse».

A*

9

Je suis assez d'accord avec 1) 2) et 3), mais la ou je ne le suis pas
c'est sur ton analyse que zpip prétendrait être un squelette
générique.
Il n'en est rien. Fonctionnellement il ne fait ni plus ni moins que la
dist actuelle.

En revanche, ce qui est propose est un ensemble de conventions et une
organisation plus modulaire qui facilite les échanges et la
réutilisation.
En gros, le but est de pouvoir jouer ensemble aux lego avec des
briques que l'on peut s'echanger et qui s'emboitent les unes dans les
autres, plutôt que chacun fabrique ses briques a son format et passe
son temps a adapter les briques du copain.

Alors, oui. Comme pour les lego, la boite est fournie avec une belle
photo sur le dessus et un mode d'emploi pour faire pareil. Mais ça n'a
jamais été un frein pour fabriquer et inventer plein de variantes.
Et si on accepte de Composer avec la forme des briques, on peut faire
des chouettes constructions.
Et avec le temps, de plus en plus de modèles de base existeront.

Pour revenir au concret, ton exemple de la home est parfait. Chacun en
est réduit a faire son petit truc dans son coin 100 fois parce que la
structure actuelle des squelettes dist ne permet pas de proposer une
brique prête a l'emploi. Avoir une, deux, trois solutions de base
(re)utilisables va devenir possible.

Ma conception du logiciel libre est plutôt fondée sur le partage et la
collaboration, qui permettent un enrichissement mutuel et global du
savoir. Cela passe par l'acceptation de ne pas maitriser soi même
l'ensemble des connaissances et d'accepter d'utiliser des composants
faits par d'autres.

Pour reprendre mon analogie des legos, on peut utiliser les briques
sans maitriser la technique d'injection et de moulage des plastiques.
Et même si on la maitrise, on a pas forcement envie de se fabriquer
soi même ses briques a chaque fois.

Je n'oppose pas ceux qui savent a ceux qui utilisent en presse bouton.
Je pense que fondamentalement chacun peut faire les deux, être un jour
un presse bouton sur un sujet, et apprendre et developper la techno
depuis la base sur un autre.

Pour developper l'exemple sans retourner au binaire, tu apprécie bien
au quotidien d'utiliser un OS tout fait et prêt a l'emploi alors qu'il
y a pourtant toutes les technos disponibles en libre. Et que les
ayatholas de Linux sont tout aussi scandalises que toi que des
développeurs perdent leur temps a dev des surcouches comme KDE ou
Gnome alors que la ligne de commande a une courbe d'apprentissage bien
plus progressive et permet de tout faire (et Ramsus Leerdorf a le même
discours que toi lorsqu'il parle de l'inutilite des systèmes de
template qui sont une surcouche de PHP qui permet pourtant déjà de
tout faire)

Et pourtant tu utilises bien des outils graphiques ?
Pour la même raison, d'autres, tout aussi curieux, compétents, et
imaginatifs que toi ont envie de trouver des outils plus directement
utilisables pour faire leur site web. Ça ne fait pas d'eux d'obscurs
ignorants presse boutons.

Et aller dans ce sens ne me parait nullement contraire a l'esprit du
LL ni de SPIP.
Comme pour Linux on peut proposer des distrib "ligne de commande" et
des distribs avec surcouche graphique presse bouton.
Rien de cela ne s'oppose.

Cédric

10

Moi je voudrais rebondir sans trop rentrer dans les détails ni sur une guerre rangée, mais mon "expérience" et "appréhension de ZPIP" ne s'est pas faite en un jour, et Cerdic doit s'en souvenir, et c'est en ça que je rejoins largement ce qu'a décrit tétue.

- De prime abord, pourquoi donc installer ZPIP ? Pourquoi utiliser une hiérarchie de fichier déjà toute faite alors que la mienne, quasi identique (basée sur de nombreuses inclusions) me satisfait pleinement et en plus me semble plus verbeuse ? (normal je l'utilise depuis bien plus longtemps et la fait moi même évoluer).

- Ensuite la question des thèmes (puisque ZPIP est appelé thème, ou du moins fait penser que grâce à lui nous pourrons avoir des thèmes). Pourquoi utiliser ZPIP (qui sert aux thèmes) alors même que chaque site dispose d'un graphisme original ?

Je pense qu'il y a juste une incompréhension sur l'intérêt et l'utilité de ZPIP.

Quand j'ai posé ces deux questions, Cerdic m'avait répondu (a très juste raison) qu'il s'agissait de retrouver une structure commune, qui permette à n'importe qui (à terme) de se retrouver facilement dans un squelette qui n'est pas le notre.
Aujourd'hui je code de beaux squelettes, compliqués. N'importe qui d'entre vous mettant le nez dedans, doit prendre le temps de comprendre la logique de construction qu'il impose, même si au final, il est plutôt puissant et chouette d'utilisation.

ZPIP va donc me permettre (quand je m'y serais formé et que j'aurais gommé mes réflexes actuels) de pouvoir partager effectivement toutes les briques que je peux poser. Mieux, ZPIP va donc permettre des collaborations grandement facilité, car tout le monde parlera la "même langue de squelette".

Et c'est bien à ça que ça doit servir ! (comme vient de le dire cerdic).

Cependant je suis parfaitement d'accord avec Tetue : où est la notice ?

Pour ma part :
- j'ai d'abord installé ZPIP (à contre coeur, et forcé par cym, je l'avais abandonné de ma première expérience, car je n'avais absolument pas compris son utilité). Et sa batterie de trucs pour changer les thèmes (zen-garden + différents thèmes au pif).
- J'ai regardé et lu
- J'ai compris que de mon utilité (créations originale à chaque fois) ne résidait pas dans les thèmes, je les ai virés. Du coup j'ai aussi viré zen-garden (marche arrière toute).
- Je me suis alors posé la question de la maintenabilité de la chose. Est-ce que je vais devoir commiter dans mon dossier plugin un squelette ?? °_0 Non... Pas question. Mais ça marche aussi quand je le fou dans squelettes.
- J'ai surchargé un fichier, pour voir. Ca marche.
- J'ai copié tout le plugin dans squelettes, et j'ai viré le plugin !
- Sauf qu'on dit bien que ZPIP doit permettre les thèmes. Du coup j'ai regroupé le dossier thème dans mon dossier squelettes (pourquoi donc, alors que je n'en ai qu'un seul, je devrais le sortir de ce dossier), ce qui permettra, si demain d'autres personnes veulent skinner la chose, de changer juste un petit chemin, je conserve la structure telle qu'elle est.
- Ensuite, ZPIP a des fichiers à la racine qui à mon sens n'ont rien à y faire. Plusieurs fichiers CSS, éparpillés, JS ou autre.
- Je me suis donc regroupé tout ça (pour faire propre) dans un répertoire themes/ dans squelettes/ qui contient le copy left, un dossier css/ img/ et js/ au moins, je trouve ça propre et bien rangé.
Voilà ma base. Je ne l'ai pas encore éprouvée, et n'ai donc pas encore le recul pour savoir si oui, ou non, ça me pose à l'usage des problèmes ou pas.

Le vrai problème que je rencontre dès maintenant, c'est "comment" suivre l'évolution de ZPIP (de sa nomenclature donc, qui évolue) alors même que du fait de la spécialisation de mes squelettes, j'ai dévié de la branche originale... (et j'ai désinstallé le plugin, puisque de toutes façons je le surcharge).

Existe-t-il un moyen simple de suivre cette évolution ?

ZPIP me semble une très bonne idée, mais c'est vrai que perso, je navigue à vue :slight_smile:

11

Ce qui est drôle c'est que vous ayez lancé la discussion sur spip-dev,
alors qu'elle concerne un plugin de la zone...

Pour moi l'*usage* de ZPIP est double :

1. Faire très vite des sites "pas trop moches", pour lesquels je n'ai
ni le temps ni l'envie de consacrer des ressources de dev. On choisit
un thème et c'est parti.

2. Normaliser certains trucs (ex: la div #contenu-principal) de façon
à ce que les plugins un peu bateau (ajouter un bouton ici ou là)
puissent s'accrocher de façon simple (plug and play) à des conventions
courantes. De ce point de vue il est souhaitable de s'accrocher à des
conventions ou pratiques déjà existantes, quand c'est possible.

Je crois aussi que ça serait une bonne base de travail pour rendre
"thémable" l'espace privé.

Pour TeX vs Latex, il faut bien voir que je connais plus d'un étudiant
en maths qui aura passé plus de temps à "parfaire sa connaissance de
TeX" qu'à écrire sa thèse... on peut ne pas forcément trouver ça
idéal.

-- Fil

12

Hello,

Je commence par le début du fil…

=== Par où commencer ?
…
Dans quel répertoire doit-on construire son site ?

Pour sarka, qui utilise ses thèmes avec Zen Garden comme ZPIP, j’ai préparé un kit de démarrage constitué de quelques fichiers.
Ensuite, dans un article qui n’est pas encore paru :(, je propose de créer un thème « mon thème » à partir de ce kit (cela revient à décompresser le kit dans themes/) et ensuite l’ayant activer de développer les modifications dans ce thème directement.
En plus, cela permet de distribuer rapidement le thème si besoin.

L’idée m’est venue aussi de créer un framework plus interactif de développement de thème mais je cherche encore la bonne approche…

ce qui me gêne surtout dans les thèmes ZPIP est que les css ne sont pas dynamiques. On en a déjà discuté et si je peux admettre que ce n’est pas forcément la bonne méthode (enfin, j’en suis toujours pas totalement convaincu) cela empêche quand même de surcharger simplement les images utilisées dans les css. Et ça c’est dommage…
Mais ZPIP en est à ses débuts aussi, donc il faut expérimenter et ensuite améliorer.

=== Nomenclature de body-layout.html
Quelques remarques en passant (non exhaustives) :

  • manque d’homogénéité entre le nom de la class parente et celui de
    l’inclusion (class=« nav » pour inclure/barre-nav)

Une nomenclature n’a d’intérêts que d’exister et d’être appliquer. Il n’y a pas de bonne ou mauvaise nomenclature et encore moins de bon et mauvais nommages. Alors cessons de se polariser sur les termes et publions une nomenclature afin que l’on puisse pleinement en profiter et faire profiter les utilisateurs de ZPIP.

Pour conclure, je trouve Zpip destiné à des grands débutants (par ses
thèmes qui se changent d’un clic) ou aux spipmestres chevronnés (par
la méthode avancée qu’il propose), mais peut-être pas au webmestre
amateur (qui, sans Zpip, n’avait que 2 ou 3 fichiers à manipuler pour
pondre son site, que ce soit en surchargeant juste quelques bout de
page ou en recodant tout).

Je ne crois pas, en tout cas ce n’est pas ce que moi je perçois. Peut-être que ce constat est du au manque de doc et de finalisation comme la nomenclature mais aujourd’hui il suffit de quelques clics pour avoir un site perso qui ressemble à… quelque chose.

Eric

13

Yop,

La suite...

je suis plutôt d'accord avec toi; Ce qui me gêne le plus avec les thèmes et zpip c'est d'avoir à aller tantôt dans le répertoire du plugin zpip

Alors là si tu y vas c'est une erreur ! Tu n'as jamais rien à y faire justement !

, tantôt dans le répertoire du thème sélectionné,

Idem, si tu personnalises ne le fais pas dans les répertoires d'installation des plugins ou des thèmes.

tantôt dans le répertoire squelettes suivant les personnalisations à apporter.

Alors là c'est le souci que je relevais dans mon mail précédent, du surtout aux images dans les css. Mais pour personnaliser un thème je dupliquerais ce thème pour modifier la copie directement sous themes/mon_theme_modifie/.

Je suppose que c'est la première étape du processus et qu'une fois qu'on a assimilé tout le bouzin il devrait y avoir moyen de tout stocker au même endroit, j'y suis pas encore.
Donc les thèmes pré-installés c'est bien si on n'y change rien ensuite (mais ça doit être rare).

Euh pas tant que ça finalement si je regarde la liste des sites sur sarka et les thèmes sont de plus en plus utilisés tels que. Il ne faut pas oublier que les utilisateurs ne sont pas limités aux quelques dizaines d'abonnés aux listes SPIP....

Eric

14

Yo,

Le fait que SPIP pousse à apprendre des trucs n'est pas un bug. C'est une caractéristique.

En quoi cette caractéristique est-elle incompatible avec le fait de vouloir un site SPIP rapidement sans avoir le temps d'apprendre pendant 10 ans comment le faire ?

ZPIP est un squelette, comme l'est ou l'a été Sarka-SPIP et il rendra les mêmes services à nos pauvres consommateurs... Et donc ? ZPIP ne remplace rien, si il ne fait rien avancer à ton avis il reste inoffensif, je ne vois donc pas l'intérêt de ce débat.

On en rediscute l'année prochaine à Antony :wink: ?

Eric

15

Mais je ne suis pas «contre» ZPIP. Simplement Romy poste un message, et je rebonis pour faire remarquer que ça correspond à ce que je répète sur le principe du saut dans la courbe d'apprentissage, point que j'illustre habituellement par l'opposition TeX/LaTeX. Et cette question de «courbe de progression» est une question que me tient à cœur, centrale dans SPIP à mon avis.

Et, oui, si les gens veulent utiliser LaTeX pour pondre rapidement un document, qu'ils le fassent. Mais le prix, c'est que ça interdit en pratique de dépasser le niveau: «j'utilise un truc tout fait».

Bref: ZPIP pourquoi pas. Mais ça n'est ni enthousiasmant ni la panacée.

Et je soutiens par ailleurs que, pour moi, la «difficulté» dans SPIP n'est pas dans l'apprentissage des squelettes, ni dans l'installation d'un dossier /squelettes récupéré sur le Web. Je pense au contraire que SPIP est un des rares systèmes proposant une courbe d'apprentissage aussi progressive.

Par ailleurs je suis assez dubitatif sur l'idée que, ça y est, on va avoir une tonne de trucs trop puissants partagés et installables par petits bouts. Depuis l'origine on a:
- le système de squelette qui permet de faire des sites avec base de données sans faire de requêtes en mySQL ni insérer la moindre ligne de PHP;
- la stricte séparation entre le HTML et les CSS, ce qui devrait permettre de livrer des feuilles de style trop puissantes pour changer radicalement l'interface de son site;
- les «include» et la popularisation du terme «noisettes» qui devrait permettre de livrer plein de petits modules trop sympas;
- les /modeles, qui également devraient permettre du partage de machins trop puissants;
- Layoutgala depuis la 2.0, avec déjà une nomenclature.
Résultat des courses: ben pas grand chose. Du coup, une nouvelle solution technique pour pallier ce manque de «squelettes tout faits clés-en-main je-clique-et-c'est-beau», je suis pas trop convaincu que ce soit (a) la solution, (b) le véritable problème.

Ensuite, je vois que ça se traduit rapidement, dans les discussions, par «les gens qui veulent monter un site vite fait». Et je pense que, dans les discussions qu'on a sur l'évolution de l'espace privé, on a un biais similaire. Je n'ai rien contre ce public précis, mais à mon avis, ça n'est pas là la force de SPIP; pas par péché ergonomique, mais par conception même du produit. SPIP tentait de favoriser la création de sites réalisés à plusieurs, et relativement complexes tout en étant correctement structurés et faciles à maintenir dans ce cadre (liens transversaux, liens de traduction...). Or, je pense qu'on se focalise (trop) sur l'aspect Pousse-Mousse du produit, ces aspects de la publication s'améliorant régulièrement et ses travers sujets à discussion, mais que des parties entières de SPIP, plus avancées, il n'y a aucune amélioration depuis des lustres ni, surtout, réelles discussions. Par exemple (un peu au débotté):
- Quand on me répond que les forums internes, personne ne les utilise, ça me désole: si on a un site avec quelques dizaines de rédacteurs qui ne se connaissent pas, les forums internes sont indispensables; plutôt que de les pousser sous le tapis, il y aurait plutôt à en refondre l'ergonomie pour les remettre au goût du jour.
- Un truc vraiment puissant de SPIP, c'est la gestion des traductions; sauf que l'interface n'a jamais été poussée (à une époque, on avait une page publique dédiée pour suivre les besoins de traduction de spip.net), alors qu'il y a un boulevard d'amélioration possible.
- La gestion des dates (et de calendriers) est vieillie et poussive.
- Le moteur de recherche depuis la 2.0 est planté si on n'installe pas le plugin Fulltext (dont je pense qu'il aurait largement vocation à rejoindre les «extensions» fournies d'office).
- CFG reste un truc bizarre à l'interface incohérente.
- Etc.

Personnellement, même si je trouve épatant de faire un site perso avec SPIP, je ne suis pas certain que ce soit notre intérêt de focaliser autant notre énergie sur cette façon d'utiliser SPIP. Parce que pour un site perso, c'est utiliser un marteau pour écraser une mouche. «Monter un site perso vite fait en deux clics et publier son truc», c'est pas comme si le choix se résumait entre «SPIP ou apprendre PHP», quand même :slight_smile: Et si le principal intérêt pratique de ZPIP pour l'instant, ce qu'on peut y convertir en 1/2 heure des templates conçus pour des systèmes déjà existants et beaucoup moins compliqués que SPIP, ça me semble un peu contreproductif.

Arnaud

16

Salut,

Bon, désolé je pensais faire court mais en en fait j'ai pas mal de choses à dire sur le sujet :wink:

Depuis que SPIP existe, je passe mon temps à rencontrer des gens qui ont «appris» avec SPIP. C'est SPIP qui les a poussés à faire du HTML, et/ou des CSS, et/ou du javascript, et/ou bidouiller du PHP, et/ou regarder ce qu'est une base de données...

Je fais parti des gens que tu cites, j'ai commencé à jouer avec jQuery et PHP parce que SPIP les utilisent.

Oui, tout le monde dit «les squelettes de base sont moches», et ensuite personne n'est mort et tout le monde est carrément content d'avoir appris quelque chose.

Certaines personnes installent un SPIP et n'ont qu'un seul besoin : écrire sur le web, rien de plus. Et dans cette catégorie de personnes il y en a pas mal qui ne veulent pas ou n'ont pas le temps d'apprendre le HTML, les CSS, les boucles SPIP et encore moins le PHP.

Je pense faire pas mal de SAD (Service Après Don) pour savoir que ces personnes seront bien contentes d'avoir le truc qu'elles désirent rapidement : ce "truc" qu'il soit un squelette, un thème ou une fonctionnalité sous forme de plugin doit avant tout fonctionner tout de suite et sans avoir à bidouiller.

Si on ne propose pas ce type de solution à ces personnes elle n'en mourront pas, mais leur projet de site sous SPIP mourra peut être...

Le fait que SPIP pousse à apprendre des trucs n'est pas un bug. C'est une caractéristique.

Je suis totalement d'accord avec toi sur ce point et je trouve la formule plutôt sympa, ça ferait un bon slogan :wink: Je vois aussi SPIP comme un outil pour des personnes "motivées" à mettre les mains dedans, crocher dans le bouzin ou toute autre formule du style.

Mais, pourquoi se passer d'un outil qui permet déjà de contenter en même temps :

- les utilisateurs pressées qui veulent un truc "qui a de la gueule" rapidement sans se prendre la tête
- et les utilisateurs chevronnés qui comprendront plus vite la "kermesse d'inclures" et l'organisation des fichiers qui en découle.

Reste, à prendre en compte les utilisateurs intermédiaires, j'y reviendrai plus loin dans ce message.

Pour être moins négatif: je pense que c'est largement contreproductif de se focaliser là dessus (je veux dire: ZPIP et templates tout faits). Avec ça, on reste avec un site pas très joli (vraiment), et surtout mal fichu, avec une page d'accueil faiblarde et une structure de rubriques qui ne casse pas des briques. Et en revanche on hérite d'une structure des squelettes pas intuitive pour deux sous.

Juste pour reprendre l'exemple de la page d'accueil "faiblarde". Un utilisateur de Z qui souhaite garder la navigation par défaut et juste modifier le contenu de la colonne principale n'a qu'un fichier à surharger : contenu/page-sommaire.html. Plutôt simple non ? C'est juste une logique à assimiler, mais une fois que c'est fait je pense qu'on peut avancer très vite.

Et c'est là que Z devient intéressant, grâce à cette nomenclature les autres plugins peuvent rapidement fournir des pages "génériques" pour afficher leur contenu. Je prends l'exemple du plugin tickets que tu dois connaître "un peu" :wink: Ce plugin ne proposait pas de pages publiques pour afficher les objets et fonctionnalités qu'ils propose. Mais, par chance, marcimat l'utilise sur programmer.spip qui utilise des squelette Z. Je n'ai eu qu'à copier les fichier qui gère le contenu des pages "tickets" de programmer.spip.org pour les déposer dans le plugin tickets.

Ainsi le plugin tickets, s'il est activé sur un site qui utilise un squelette Z (pas forcément zpip), propose d'office des pages publiques pour gérer les tickets comme sur programmer.spip.org. Et ça c'est quand même sympa de la part d'un plugin, non ? Cela permet de mutualiser des bouts de pages d'un squelette (ou plugin) à un autre.

Revenons au cas des utilisateurs intermédiaires qui veulent un site qui a de la gueule et qui fasse plein de choses que la dist ne fait pas. Si on compare les différents cas de figures on aurait :

A) J'installe un squelette tout fait (sarka au hasard ^^) et là je dois assimiler toute la logique de "construction" du squelette avant d'obtenir ce que je souhaite. Mais j'ai le chance car il y a une bonne équipe qui assure le SAD derrière sarka (/me mode lance des fleurs à tonton Eric).

B) Je suis "motivé" et je vais me faire un truc perso à partir de la dist (ou à partir de rien) même pas peur ^^ (c'est ce que je faisais encore tout dernièrement pour presque tous les sites que j'ai eu à faire). Dans ce cas je commence à travailler sur un site qui n'a pas du tout de gueule (pauvre dist, tout le monde dit du mal d'elle).

C) Je pars d'un site qui tourne sous Z avec un thème activé. Dans ce cas j'ai déjà l'avantage de commencer à travailler sur un site qui "a de le gueule" (j'ai trouvé un thème qui me convient assez dans la galerie de thèmes de contrib qui ne cesse de s'enrichir). Et c'est tout de même plus motivant de commencer à apprendre "la bidouille " pour travailler sur un site "dont on est fier" que sur un site dont on ose même pas filer l'url dans un message de forum de contrib car on le trouve "trop moche"...

Reste le problème du "niveau" requis (ou la première marche comme on le dit souvent) pour commencer à bidouiller du Z. Les trois choses qu'il faut assimiler pour commencer sont :

- la notion d'inclure un autre squelette (on le fait déjà dans la dist). J'ai fait mon entrée dans la communauté par le biais de spipclear qui est lui aussi basé sur une "kermesse d'inclures" et de filtres de test. Cela m'a plutôt "tiré vers le haut" et poussé à apprendre des trucs. On en revient à ce qu'on considère tous les deux (et il n'y a pas que nous) comme une caractéristique de SPIP.

- l'organisation des fichiers d'un squelette Z (il y a déjà un début de doc là dessus sur contrib, c'est certainement perfectible mais on a déjà de l'info dispo).

- les specs ou conventions de nommage pour que le squelette soit compatible avec les thèmes. Là dessus on aussi déjà de la doc en cours de rédaction sur contrib (pas encore publiée car tout n'est pas encore figé je pense). Et ce point ne semble pas être le plus problèmatique quand on voit comment certaines personnes se sont "appropriés" le truc et ont publiés des thèmes pendant le mois de décembre 2009.

Et si le principal intérêt pratique de ZPIP pour l'instant, ce qu'on peut y convertir en 1/2 heure des templates conçus pour des systèmes déjà existants et beaucoup moins compliqués que SPIP, ça me semble un peu contreproductif.

Comme l'ont déjà dit plusieurs personnes, ZPIP n'est qu'un exemple de squelette similaire à la dist qui respecte la nomenclature Z. Et c'est cette nomenclature qui fait que les thèmes sont compatibles avec d'autres squelettes Z. On peut très bien imaginer d'autres squelettes "spécialisés" dans l'affichage de collection de vidéos, d'objets ou de photos à la flickr basés sur les specs de Z.

Je ne vois pas Z comme une solution qui permet de faire du SPIP à la chaine de manière industrielle car je fais plutôt de "l'artisanat". Z permet les deux, c'est ça qui est bon. Comme le dit Cedric :

En revanche, ce qui est propose est un ensemble de conventions et une
organisation plus modulaire qui facilite les échanges et la
réutilisation.

Avec Z on peut aussi bien faire du "pousse-mousse" comme tu le dis et du "cousu main" tout en facilitant les échange. C'est déjà pas mal pour un début, non ? :wink:

17

Bon, en bref, zpip c'est super,
mais ce serait encore plus super si la mécanique de zpip
... était facile à comprendre, à modifier et à étendre !
(d'où structuration, nomenclature, documentation,...)

Ainsi on a la puissance d'un latex et la gradualité d'un tex... :wink:

Et pour le plein goût de zpip, qui est le partage et la réutilisation,
il faudra surement pouvoir non seulement choisir les thèmes visuels
avec le switcher, mais aussi piocher dans une liste
de "noisettes fonctionnelles" :
- liste des 10 articles les + récents
- liste des 10 derniers articles avec le motclé "ALaUne"
- liste des 10 articles avec les commentaires les + récents ...
- liste des 10 articles les + consultés
- liste des 10 articles les + commentés
etc pour la page sommaire par ex, avec accés au paramétrage adéquat
(nombre d'articles, restriction à une rubrique,...)

JLuc

18

Si on raisonne en terme de produit, il semble bien que l'érosion continue des Parts du Marché du produit SPIP traduit un décalage progressif par rapport au public, et tend vers une inadéquation sur la cible moyenne pondérée des consommateurs potentiels, avec le risque d'une sortie pure et simple du marché concurrentiel des outils de publication.

Peut être qu'une révision du plan produit serait opportune ?

Cédric
(un troll ? ou ça ? :wink: )

19

Troll, oui, mais c'est intéressant en ce que ça me semble confirmer ce que je disais regretter dans mes messages précédents.

=> D'abord, tu détournes mon propos pour lui donner le sens d'un argument marketing. Or un «produit» n'est pas un objet marketing, c'est simplement le résultat créatif d'une activité (Wikipedia). Un «public» n'est pas une part de marché, surtout que je dis que, pour ma part, orienter SPIP vers ce public (qui ne souhaite pas apprendre de SPIP) n'est pas une bonne idée, alors que vous m'avez tous répété qu'il faut absolument que SPIP soit utilisable par les gens qui veulent «juster installer et publier». Bref, j'utilise le mot «public» dans un sens qui, s'il était pris dans un sens marketing, serait l'antithèse de la recherche de part de marché.

=> Mais ce faisant, tu me balances très exactement un argumentaire marketing: la crainte que SPIP perde tellement de parts de marché qu'il finisse par ne plus y être présent, et donc il faudrait réévaluer les objectifs du produit (sens marketing cette fois) pour éviter cette érosion des parts de marché. Ça n'est pas mon propos, c'est le tien.

Je pense que ça confirme ce que je disais dans le mail précédent.
1. Je pense qu'il existe déjà d'excellents logiciels libres faciles à installer avec de beaux templates: notamment Wordpress.
2. Je ne vois pas l'intérêt de réorienter SPIP vers un clone de Wordpress, parce que (a) Wordpress fait parfaitement ce pour quoi il a été conçu, (b) SPIP n'a pas été conçu pour faire ce que fait Wordpress qui est un logiciel maintenu et développé avec une bonne communauté, donc il ne le fera jamais aussi bien.
3. Cependant, je constate que: (a) la préoccupation qui s'exprime désormais en permanence, c'est cette orientation pour «toucher» avec SPIP des gens qui ont déjà à leur disposition Wordpress, (b) les développements ergonomiques s'orientent clairement vers cela, au détriment des aspects spécifiques de SPIP qui soit fonctionnent, soit ont fonctionné et ne demanderaient qu'à être remis au goût du jour.

Bon, je suis crevé ce soir, mais je vais essayer de résumer rapidement, en espérant pas trop m'emmêler les pinceaux:
1. une des forces de SPIP est d'être conçu pour gérer des sites à plusieurs; on peut l'utiliser tout seul, mais une de ses caractéristiques, c'est d'avoir un flux éditorial, des outils de travail collaboratif et de suivi éditorial, tout cela dans une interface qui reste finalement peu complexe par rapport aux tâches qu'elle permet (parce que gérer un flux éditorial n'a rien d'une évidence); que certains s'agacent de la présence d'outils et de fonctionnalités collaboratifs dans SPIP parce qu'ils ne l'utilisent que pour faire des sites tout seul, c'est évidemment un contresens;
2. SPIP est conçu pour proposer une courbe d'apprentissage très progressive; c'est un produit relativement unique par cet aspect; la communauté qui existe et qui fait que SPIP existe encore, pour très large partie, est motivée par le fait que SPIP a servi de support à leur apprentissage;
3. cette courbe d'apprentissage n'est pas uniquement pensée pour les aspects techniques (HTML, CSS, PHP, jQuery...), mais pour une large part pour la maîtrise éditoriale d'un site qui grossit et est réalisé à plusieurs. Cet aspect est transparent mais n'a rigoureusement rien d'évident. Savoir monter et gérer un site qui grossit avec plusieurs intervenants sur une longue période est l'une des choses les plus méconnues et difficiles à réaliser.

Or, ce que je crains et constate, c'est une évolution vers un système «à la Wordpress»: pour simplifier à l'extrême:
1. j'installe et je publie, tout seul sur mon site;
2. je ne souhaite à aucun moment apprendre quoi que ce soit en dehors de cela;
3. je ne souhaite jamais avoir affaire à une «communauté».

Ce qui donne dans la pratique:
- disparition par erreur du bouton «Proposer mon article à la publication» pour les rédacteurs;
- vieillissement des outils de discussion interne dans l'espace privé, puis leur quasi disparition de l'interface (version dev);
- disparition de l'espace dédié pour gérer les droits et les accès;
- nouvelle interface «rédacteurs» pas du tout pensée et pas du tout réalisée;
- à chaque fois que je pose la question de la courbe d'apprentissage, même en rebondissant sur un mail de Romy qui dit pourtant cela en d'autres termes, je me fais jeter sur le thème «oui mais il faut répondre aux attentes des gens qui veulent juste installer le truc et publier».

Ma conclusion:
- je ne suis pas opposé, mais alors pas du tout, à ce qu'on travaille à faciliter l'utilisation pour ce public qui veut juste installer et publier; je dis que ça ne me semble ni pertinent ni la panacée, parce que Wordpress le fait déjà très bien, m'enfin je ne vais pas refuser que d'autres gens utilisent le système;
- en revanche, ce qui me chagrine, c'est que cette «révision du plan produit» se fait clairement en cassant et en oubliant de mettre à jour ce qui fait l'originalité de SPIP (et, à mon avis, constitue toujours sa raison d'être utilisé par beaucoup de monde, notamment dans le monde associatif): travailler à plusieurs avec une gestion éditoriale complète sur des sites riches, avec des rédacteurs et des administrateurs, et parvenir à travailler ensemble sur un gros site grâce à un système qui facilite le travail éditorial collectif et collaboratif. Et, tant qu'à faire, en permettant à celui que ça intéresse de progresser à son rythme en utilisant le système comme support et motivation pour son apprentissage.

Or, dans les évolutions de ces derniers temps, je vois des choses qui témoignent: qu'on oublie que beaucoup de sites sont faits avec des rédacteurs, que beaucoup de sites sont gérés en équipe, que gérer un site éditorial complexe n'a rien d'une évidence, que beaucoup de sites agrègent une communauté active, qu'un site peut être multilingue avec des traducteurs, et que gérer un site à plusieurs est ce qui fait la force de SPIP.

Si vous voulez «réviser le plan produit», pour moi l'orientation elle est là: SPIP a été l'un des premiers logiciels à faire ce genre de choses, il continue à être un de ceux qui le font encore avec une interface qui ne demande pas la lecture d'un mode d'emploi (je parle de cette activité éditoriale complexe, pas de l'interface «j'installe et je publie, hein); en revanche beaucoup de ces aspects sont en déshérence technique et ergonomique depuis des années, et les derniers développements auraient tendance à ne pas améliorer les choses. Pensons réellement le système pour qu'il maintienne et développe: (a) un véritable fonctionnement d'outil collaboratif dans l'espace privé, (b) une gestion améliorée des droits et des accès, (c) un flux éditorial dans une structure collaborative au goût du jour, (d) préservons la courbe d'apprentissage, à la fois dans la conception du produit (qui permet à tous les niveaux l'apprentissage progressif) et dans une véritable documentation (il y a du mieux, hein, j'ai déjà dit à quel point programmer.spip.org était une bonne nouvelle) et à mon avis on ne se posera plus de questions de «parts de marché».

Arnaud

20

Hello,

Bon, rapidement, les idées qui me viennent à la lecture de tout ça.

D'abord, d'accord avec Fil: qu'est-ce qu'une discussion sur Zpip vient faire sur spip-dev ? Et totalement d'accord avec la liste d'Arnaud sur les améliorations du core, mais justement il faudrait les faire plutôt que de recommencer le troll qui remontre qu'Arnaud privilégie le rayon de courbure de la courbe d'apprentissage de SPIP alors que Romy se soucie de son point d'orgine, faux débat puisqu'une courbe a forcément l'un et l'autre et qu'ils sont définissables indépendamment.

Je reprends donc ta liste:

les forums internes sont indispensables; plutôt que de les pousser sous le tapis, il y aurait plutôt à en refondre l'ergonomie pour les remettre au goût du jour.

Yep, mais l'ergonomie c'est pas mon fort, tu as des idées ?

- Un truc vraiment puissant de SPIP, c'est la gestion des traductions; sauf que l'interface n'a jamais été poussée (à une époque, on avait une page publique dédiée pour suivre les besoins de traduction de spip.net), alors qu'il y a un boulevard d'amélioration possible.

Tu as l'air de parler de:
http://www.spip.net/?page=trad
mais c'est tout le chantier trad_lang auquel tu penses je présume, car effectivement le multilinguisme reste un point fort de SPIP et c'est très dommage que ça n'ait pas bougé depuis la 1.7.2 en fait. Autrement dit à partir de mon arrivée, et je réalise que j'ai dû donner l'impression que ça ne m'intéressait pas, alors que je n'avais simplement pas d'idées. Il y a un an j'avais demandé à Florent de mettre tout son matériel sur la zone, ce qu'il a fait:

et j'avais commencé à explorer, et puis d'autres priorités me sont tombés dessus.

- La gestion des dates (et de calendriers) est vieillie et poussive.

Oui: SPIP est un outil collaboratif dont les calendriers ne le sont pas. Et cette contradiction est d'autant plus dommage que les bons outils de gestions de calendriers partageables sont payants: il y a un vrai manque côté logiciel libe à ma connaissance.

- Le moteur de recherche depuis la 2.0 est planté si on n'installe pas le plugin Fulltext (dont je pense qu'il aurait largement vocation à rejoindre les «extensions» fournies d'office).

Le pb est plus général je crois. Vu les tonnes de vidéo et MP3 que possède un site, l'indexation audio est à présent le vrai besoin: les journaux en ligne qui ne retranscrivent plus les interviews, ils font comment pour être référencés correctement ? L'indexation des galeries de photos est du même ordre. Pour moi c'est là les sujets d'avenir en matière d'indexation (mais perso, ça ne me branche pas trop sur le plan technique cela dit).

- CFG reste un truc bizarre à l'interface incohérente.

Oui maintenant que j'ai regardé plus en détail CFG me parait une fausse piste, que CVT a rendu définitivement obsolète: pour étendre SPIP on a donné des interfaces de programmation (pour le compilateur, les formulaires, les serveurs SQL),
pourquoi tout à coup une extension par interface graphique qui mémorise dans la table des meta des données peu facilement exploitables ? Il vaudrait mieux améliorer l'interface de programmation à la table des meta.

Et je retiens aussi ça de Romy:

pourquoi pas un éditeur de squelettes directement dans l'espace privé ?

ça j'y pense depuis longtemps, mais on revient à un autre pb: tant que la syntaxe des squelettes restera un gros paquet d'exceptions et non qq règles simples, faut pas y compter.

Bon, comme on dit, c'est mon opinion et je la partage ...

Committo,Ergo:Sum