Suite à la demande d'utilisateurs, j'ai réalisé une étude visant à faciliter la
création d'un article sous SPIP. Les premiers retours des utilisateurs sont très
satisfaisants. Aussi, je pense qu'il était intéressant de porter cette étude à
votre connaissance.
Cette étude de 20 pages se décompose en 4 chapitres :
- Les besoins
- Analyse de l'existant
- Conception de la saisie d'un article
- Conception de la saisie des options avancées d'un article
Bonjour,
C'est très intéressant, et cela a le mérite de formaliser un certain nombre de défauts et reproches récurrents.
Il semble malheureusement que le core soit victime sur ce sujet d'une grande résistance au changement, en général plutôt caractéristique des organisations hiérarchisée traditionnelles où l'innovation a toujours le mauvais goût de bousculer les frontières et de remettre en cause les territoires acquis de chacun.
Il y a de bonnes idées à reprendre dans ce document qui rejoignent certaines idées dont on a pu discuter ici et là de manière informelle. Il faut pousser pour que le core continue le nettoyage et la formalisation des API de Spip qui permettront de développer ces variantes d'interface "à coté" du noyau, puisque ce n'est pas de lui que viendra l'innovation.
A titre d'exemple, la version 2.0 (actuellement en beta2 !) permet de faire #FORMULAIRE_EDITER_ARTICLE
dans un squelette, et de rendre ainsi l'edition d'un article sur le site public beaucoup plus facile (sans devoir réécrite plein de code, et en réutilisant au maximum les composants du noyau de spip). Le formulaire a aussi été repensé du point de vue du html pour permettre un stylage le plus souple possible, sans pour autant necessiter de surcharger le formulaire par défaut de Spip.
Peux t'on mettre ta vidéo sur videos.spip.org ? Et faire un renvoi
vers ton article ?
Je suis tout à fait d'accord. Toutefois, cette vidéo illustre une étude et non
pas une fonctionnalité standard de SPIP. Aussi, le fait de la mettre sur le site
videos.spip.org risque de générer des confusions.
Suite à la demande d'utilisateurs, j'ai réalisé une étude visant à faciliter la
création d'un article sous SPIP. Les premiers retours des utilisateurs sont très
satisfaisants. Aussi, je pense qu'il était intéressant de porter cette étude à
votre connaissance.
Cette étude de 20 pages se décompose en 4 chapitres :
- Les besoins - Analyse de l'existant
- Conception de la saisie d'un article
- Conception de la saisie des options avancées d'un article
il y a eu une version intermédiaire de spip 193 qui proposait une navigation par onglet très intéssante aussi, elle était facultative mais elle a disparue
Bonjour,
C'est très intéressant, et cela a le mérite de formaliser un certain nombre de défauts et reproches récurrents.
Il semble malheureusement que le core soit victime sur ce sujet d'une grande résistance au changement, en général plutôt caractéristique des organisations hiérarchisée traditionnelles où l'innovation a toujours le mauvais goût de bousculer les frontières et de remettre en cause les territoires acquis de chacun.
Il y a de bonnes idées à reprendre dans ce document qui rejoignent certaines idées dont on a pu discuter ici et là de manière informelle. Il faut pousser pour que le core continue le nettoyage et la formalisation des API de Spip qui permettront de développer ces variantes d'interface "à coté" du noyau, puisque ce n'est pas de lui que viendra l'innovation.
A titre d'exemple, la version 2.0 (actuellement en beta2 !) permet de faire #FORMULAIRE_EDITER_ARTICLE
dans un squelette, et de rendre ainsi l'edition d'un article sur le site public beaucoup plus facile (sans devoir réécrite plein de code, et en réutilisant au maximum les composants du noyau de spip). Le formulaire a aussi été repensé du point de vue du html pour permettre un stylage le plus souple possible, sans pour autant necessiter de surcharger le formulaire par défaut de Spip.
Cédric
Bonjour,
Suite à la demande d'utilisateurs, j'ai réalisé une étude visant à faciliter la
création d'un article sous SPIP. Les premiers retours des utilisateurs sont très
satisfaisants. Aussi, je pense qu'il était intéressant de porter cette étude à
votre connaissance.
Cette étude de 20 pages se décompose en 4 chapitres :
- Les besoins
- Analyse de l'existant
- Conception de la saisie d'un article
- Conception de la saisie des options avancées d'un article
Je viens d'essayer la balise #FORMULAIRE_EDITER_ARTICLE dans la version 2.0
(beta2).
Avec cette balise j'arrive à proposer un article simple (titre,
descriptif, texte) depuis le site public.
C'est intéressant, mais l'étude va plus loin.
En effet, elle offre sur le site public les mêmes possibilités que l'espace
privé pour la création et la modification d'un article (ajout de pièces jointes,
ajout de mots-clés, etc.). Par ailleurs elle simplifie grandement l'insertion
d'une pièce jointe dans le texte d'un article.
Sur le volet technique, j'ai utilisé une approche de type MVC (Modèle Vue
Contrôleur), même si la partie "Modèle" n'est pas séparée.
il y a eu une version intermédiaire de SPIP 193 qui proposait une navigation par onglet très intéressante aussi, elle était facultative mais elle a disparue
Je viens d'essayer la balise #FORMULAIRE_EDITER_ARTICLE dans la version 2.0
(beta2).
Avec cette balise j'arrive à proposer un article simple (titre,
descriptif, texte) depuis le site public.
C'est intéressant, mais l'étude va plus loin.
En effet, elle offre sur le site public les mêmes possibilités que l'espace
privé pour la création et la modification d'un article (ajout de pièces jointes,
ajout de mots-clés, etc.). Par ailleurs elle simplifie grandement l'insertion
d'une pièce jointe dans le texte d'un article.
Nous sommes bien d'accord.
Je citais la balise ci-dessus comme un exemple de la démarche possible et de ce qu'il était possible d'attendre du core :
- une api permettant une réutilisation de composants pour reconstruire un interface autrement, sans devoir tout recoder.
A ce titre, la refonte technique des formulaires de pièces jointes est la prochaine étape, et cela devra evidemment se poursuivre pour les autres fonctionnalités telles que l'ajout de mot clé etc ...
Sur ce dernier point, je propose dans la version 2.0 du plugin agenda une variante que je trouve intéressante.
Sur le volet technique, j'ai utilisé une approche de type MVC (Modèle Vue
Contrôleur), même si la partie "Modèle" n'est pas séparée.
Oui, même si on ne lui donne pas ce nom, la refonte du code tend vers cela. Si tu regarde l'ensemble des #FORMULAIRE_EDITER_xx de la 2.0, tu pourras voir le nouveau schema que l'on va essayer de généraliser.
Bonjour,
C'est très intéressant, et cela a le mérite de formaliser un certain nombre de défauts et reproches récurrents.
Il semble malheureusement que le core soit victime sur ce sujet d'une grande résistance au changement, en général plutôt caractéristique des organisations hiérarchisée traditionnelles où l'innovation a toujours le mauvais goût de bousculer les frontières et de remettre en cause les territoires acquis de chacun.
Il y a de bonnes idées à reprendre dans ce document qui rejoignent certaines idées dont on a pu discuter ici et là de manière informelle. Il faut pousser pour que le core continue le nettoyage et la formalisation des API de Spip qui permettront de développer ces variantes d'interface "à coté" du noyau, puisque ce n'est pas de lui que viendra l'innovation.
A titre d'exemple, la version 2.0 (actuellement en beta2 !) permet de faire #FORMULAIRE_EDITER_ARTICLE
dans un squelette, et de rendre ainsi l'edition d'un article sur le site public beaucoup plus facile (sans devoir réécrite plein de code, et en réutilisant au maximum les composants du noyau de spip). Le formulaire a aussi été repensé du point de vue du html pour permettre un stylage le plus souple possible, sans pour autant necessiter de surcharger le formulaire par défaut de Spip.
Cédric
Bonjour,
Suite à la demande d'utilisateurs, j'ai réalisé une étude visant à faciliter la
création d'un article sous SPIP. Les premiers retours des utilisateurs sont très
satisfaisants. Aussi, je pense qu'il était intéressant de porter cette étude à
votre connaissance.
Cette étude de 20 pages se décompose en 4 chapitres :
- Les besoins
- Analyse de l'existant
- Conception de la saisie d'un article
- Conception de la saisie des options avancées d'un article
Compromis proposé par vincent, une catégorie R&D. Voici le texte que
je propose, donc à faire évoluer.
Tout ce qu'on peut faire avec SPIP mais qui n'est pas SPIP
{{Attention}}} : Vous trouverez des contributions qui ne sont, ne
seront pas implémentées dans les versions stables.
Suite à la demande d'utilisateurs, j'ai réalisé une étude visant à faciliter la
création d'un article sous SPIP. Les premiers retours des utilisateurs sont très
satisfaisants. Aussi, je pense qu'il était intéressant de porter cette étude à
votre connaissance.
c'est une etude ou ce sont des choses déjà réalisées ?
Il semble malheureusement que le core soit victime sur ce sujet d'une grande résistance au changement, en général plutôt caractéristique des organisations hiérarchisée traditionnelles où l'innovation a toujours le mauvais goût de bousculer les frontières et de remettre en cause les territoires acquis de chacun.
Ehbeh, ne crois tu pas que,
sous une forme très différente de celles auxquelles nous habitue la seigneurie
notable du capitalisme patronarcal, c'est bien là d'une certaine manière
ce qui se produit avec les LL (pour pas dire SPIP mais ça vient) ?
Depuis les core-codeurs, ex Mousquetaires, capables de presque tout
avec spip, dedans (core) ou dehors (plugins, serveurs, ...)
Jusqu'aux utilisateurs lambdas bien content de trouver des outils
supers et pas chers,
mais ayant toujours besoin de l'aide de plus initiés (merci les listes !)
et qui parfois mettent des années laborieuses à comprendre comment ça marche
jusqu'à finalement parvenir à coder avec succés un squelette
et à goûter la joie délectable et de constater le "territoire" parcouru,...
Et qui évidemment s'accrochent à leurs fraiche expertise, si âprement gagnés !
Le territoire en question, c'est la maîtrise d'un outil...
Pour faciliter le lâcher de territoire,
il faut que le nouveau territoire soit le plus facile d'accés !
Et la transition douce...
