[spip-dev] Menu SPIP bien rempli avec des options supplémentaires

Dev
1

Hello,

Voici une nouvelle proposition pour le menu, qui reprend les éléments de Cerdic.

http://www.patagium.net/IMG/demo/menu-spip2.html

On constate que l'organisation proposée permet d'enrichir facilement les entrées de menu avec des fonctionnalités issues de plugins.

Un sopin particulier à été apporté à la précision des termes employés, pour rendre le tout le plus précis possible, et maximiser l'intuitivité (affordance quoi !).

Une réfléxion à mener serait sur l'intitulé "Auteurs", serait-il plus précis de parler d'"utilisateurs" (dont certains sont auteurs, mais d'autres pas).

BoOz

2

Si tu le dis.
Mais est-ce que tu pourrais intégrer TOUS les mêmes éléments des menus que l'on voit dans le lien de Cédric. Pour pouvoir comparer sur la même base plus exhaustive.

3

C'est ce que j'ai fait. Saut ceux que je n'ai pas pu comprndre. "Vocabulaire éditorial" par exemple.

Si je peux avoir l'explication je les rajoute.

Je n'ai pas non plus mis toutes les entrées de "édition", leetc en fin de menu comprends les trucs du type "marchés publics" , "plan". Qui dépassent le cadre général de ma proposition, mais ne remettent pas en cause le classement.

Je veux bien disuter sur quelques entrées particulières à préciser si vous voulez.

BoOz

RastaPopoulos wrote:

4

Je repasse sur spip dev.

C’est ce que j’ai fait. Saut ceux que je n’ai pas pu comprndre. « Vocabulaire éditorial » par exemple.

C’est la fonction « Dictionnaire indexé » du plugin « Recherche étendue » qui te permet de visualiser le champ sémantique éditorial de ton site, dans un objectif de référencement.

Je ne connais pas ce plugin ni l’usage qu’on peut en avoir, mais je ne vois pas bien la logique de le placer dans « Suivi éditorial » avec la messagerie.

S’il s’agit d’affiner le référencement, je le placerais dans « administration ».

Je crois vraiment que ton entrée « suivi éditorial » n’est pas intuitive ni utile, et rassemble des éléments hétéroclites ajoutant de l’entropie.

Quant à l’entrée « réactions » je te rejoins sur le contenu, mais l’intitulé « activité du site » me semble plus précis.

Tu n’a peut-être pas compris non plus les entrées

La plupart sont dans le menu, mais avec un nom reformulé (suposément plus clair). Je précise ci-dessous les deux cas non reportés par manque de clareté.

Suivi Editorial > Articles syndiqués : permet de suivre/visualiser/modérer l’ensemble des articles syndiqués sur le même mode que les forums

C’est dans mon onglet « édition » > « sites », je ne vois pas le lien avec les forums.

Suivi Editorial > URLs Signifiantes : permet de suivre/visualiser/éditer les URLS signifiantes (propres, arbos, libres …). L’intérêt d’une page d’admin globale est de voir les entrées analogues ou avec un même terme …, pour optimiser tes URLS et ton référencement

C’est dans mon entrée « édition > url propres »

Suivi Editorial > Liens sortants&sites références : plugin checklink (ou équivalent de Nicolas Hoizey) qui te permet de suivre toutes les urls référencées dans tes contenus éditoriaux, et notamment les liens brisés

C’est de l’administration alors. Administration > Vérification des liens.

Suivi Editorial > Contenus Disponibles en pré-prod : déjà discuté sur la liste
Suivi Editorial > Contenus Disponibles en pré-prod : déjà discuté sur la liste

C’est dans l’onglet Administration > Importer des données.

ainsi que

Réactions > Statistiques avec phpMyAdmin
Réactions > Réponses aux formulaires
Réactions > Réponses aux sondages
Réactions > Suivi des notes

Ils sont dans Activité du site

Réactions > Inscrits aux SMS infos

Ils sont dans Auteurs

Je n’ai pas non plus mis toutes les entrées de « édition », leetc en fin de menu comprends les trucs du type « marchés publics » , « plan ». Qui dépassent le cadre général de ma proposition, mais ne remettent pas en cause le classement.

l’exercice consiste justement à montrer que la classification tient la route même avec beaucoup plus de fonctionnalités que le spip core. Evacuer la difficulté avec un etc… en fin de chaque menu ne démontre donc rien.

Oui et bien rajoutes les dans édition si tu veux, comme dans ta proposition. On est d’accord pour ces item là. Ils ne sont pas significatifs du coup.

BoOz

5

Je repasse sur spip dev.

oups

C’est ce que j’ai fait. Saut ceux que je n’ai pas pu comprndre. « Vocabulaire éditorial » par exemple.

C’est la fonction « Dictionnaire indexé » du plugin « Recherche étendue » qui te permet de visualiser le champ sémantique éditorial de ton site, dans un objectif de référencement.

Je ne connais pas ce plugin ni l’usage qu’on peut en avoir, mais je ne vois pas bien la logique de le placer dans « Suivi éditorial » avec la messagerie.

C’est un outil de suivi du contenu éditorial, et plus particulièrement du vocabulaire utilisé et du champ sémantique. Tu n’en as peut-être pas l’utilité, mais d’autres l’ont.

S’il s’agit d’affiner le référencement, je le placerais dans « administration ».

Administration concerne les outils de maintenance

Je crois vraiment que ton entrée « suivi éditorial » n’est pas intuitive ni utile, et rassemble des éléments hétéroclites ajoutant de l’entropie.

Au contraire, elle rassemble tous les outils qui donnent une vue sur le contenu éditorial
Chaque outil permet d’avoir une vision différente, sous un point de vue particulier, c’est son intérêt.

Quant à l’entrée « réactions » je te rejoins sur le contenu, mais l’intitulé « activité du site » me semble plus précis.

Tu n’a peut-être pas compris non plus les entrées

La plupart sont dans le menu, mais avec un nom reformulé (suposément plus clair). Je précise ci-dessous les deux cas non reportés par manque de clareté.

Suivi Editorial > Articles syndiqués : permet de suivre/visualiser/modérer l’ensemble des articles syndiqués sur le même mode que les forums

C’est dans mon onglet « édition » > « sites », je ne vois pas le lien avec les forums.

Edition > Sites permet d’éditer les sites, pas de faire le travail de modération des sites syndiqués. Aujourd’hui SPIP propose de modérer automatiquement les rss, mais si tu veux utiliser cette option, il n’y a aucune page de suivi des contenus syndiqués dans leur ensemble, et tu es obligé d’aller voir site par site les nouveaux contenus, de les valider ou non etc …
C’est en l’état inutilisable. Donc soit l’option de modération des articles syndiqués dégage, soit il lui faut une page dédiée à la modération. Je citais les forums car le fonctionnement de modération est analogue : on a besoin d’une page centralisée qui permet de suivre tous les contenus.

Suivi Editorial > URLs Signifiantes : permet de suivre/visualiser/éditer les URLS signifiantes (propres, arbos, libres …). L’intérêt d’une page d’admin globale est de voir les entrées analogues ou avec un même terme …, pour optimiser tes URLS et ton référencement

C’est dans mon entrée « édition > url propres »

Suivi Editorial > Liens sortants&sites références : plugin checklink (ou équivalent de Nicolas Hoizey) qui te permet de suivre toutes les urls référencées dans tes contenus éditoriaux, et notamment les liens brisés

C’est de l’administration alors. Administration > Vérification des liens.

De l’administration dans ta classification, certes. Mais encore une fois ce n’est pas un outil de maintenance, mais de suivi des liens utilisés.

Suivi Editorial > Contenus Disponibles en pré-prod : déjà discuté sur la liste
Suivi Editorial > Contenus Disponibles en pré-prod : déjà discuté sur la liste

C’est dans l’onglet Administration > Importer des données.

ainsi que

Réactions > Statistiques avec phpMyAdmin

Je ne vois pas

Réactions > Réponses aux formulaires

Je ne vois pas

Réactions > Réponses aux sondages
Réactions > Suivi des notes

Ils sont dans Activité du site

Réactions > Inscrits aux SMS infos

Ils sont dans Auteurs

Je ne les vois pas non plus.
Et tu m’expliquera le rapport avec les auteurs … Ce sont des visiteurs qui ont juste donné leur numéro de portable pour recevoir de l’info par SMS

Je n’ai pas non plus mis toutes les entrées de « édition », leetc en fin de menu comprends les trucs du type « marchés publics » , « plan ». Qui dépassent le cadre général de ma proposition, mais ne remettent pas en cause le classement.

l’exercice consiste justement à montrer que la classification tient la route même avec beaucoup plus de fonctionnalités que le spip core. Evacuer la difficulté avec un etc… en fin de chaque menu ne démontre donc rien.

Oui et bien rajoutes les dans édition si tu veux, comme dans ta proposition. On est d’accord pour ces item là. Ils ne sont pas significatifs du coup.

Ce qui est significatif c’est le mélange dans le cas d’un menu complet.
Avec juste ce qu’il faut de mauvaise foi, je crois comprendre que tout ne rentre pas dans ton menu, donc.

Cédric

6

Je crois vraiment que ton entrée « suivi éditorial » n’est pas intuitive ni utile, et rassemble des éléments hétéroclites ajoutant de l’entropie.

Au contraire, elle rassemble tous les outils qui donnent une vue sur le contenu éditorial
Chaque outil permet d’avoir une vision différente, sous un point de vue particulier, c’est son intérêt.

Chaque entrée du menu est une vue du contenu éditorial - statistique en est une également par exemple : je ne vois pas de pertinence commune à toutes les entrées de ton menu suivi éditorial.

Ce que je vois bien en revanche c’est que proposer un menu avec des entrées proches comme tu le fais « éditorial », « suivi editorial » et dedans « suivi de l’activité éditoriale » est confus.

Suivi Editorial > Articles syndiqués : permet de suivre/visualiser/modérer l’ensemble des articles syndiqués sur le même mode que les forums

C’est dans mon onglet « édition » > « sites », je ne vois pas le lien avec les forums.

Edition > Sites permet d’éditer les sites, pas de faire le travail de modération des sites syndiqués. Aujourd’hui SPIP propose de modérer automatiquement les rss, mais si tu veux utiliser cette option, il n’y a aucune page de suivi des contenus syndiqués dans leur ensemble, et tu es obligé d’aller voir site par site les nouveaux contenus, de les valider ou non etc …
C’est en l’état inutilisable. Donc soit l’option de modération des articles syndiqués dégage, soit il lui faut une page dédiée à la modération. Je citais les forums car le fonctionnement de modération est analogue : on a besoin d’une page centralisée qui permet de suivre tous les contenus.

Oui, alors j’ai réuni toutes ces entrées dans « édition > suivi des modifications » en effet, on peut vouloir suivre, les articles syndiqués, mais aussi bien d’autres éléments.

Ils sont dans Auteurs

Je ne les vois pas non plus.
Et tu m’expliquera le rapport avec les auteurs … Ce sont des visiteurs qui ont juste donné leur numéro de portable pour recevoir de l’info par SMS

Oui, j’ai préciser qu’on pouvait discuter la dessus. En effet SPIP désigne sous « Auteurs » des auteurs et des utilisateurs. Mais cela n’enleve rien à la pertinance de regrouper dans une entrée ce qui concerne les « gens ». On veut savoir si le type est abonné, inscrit a tel ou tel truc, et probablement il aura une page perso qui recapitule tous ses services.

Avec juste ce qu’il faut de mauvaise foi, je crois comprendre que tout ne rentre pas dans ton menu, donc.

Sans mauvaise foi, tu verras que tout rentre (ajoute « statistique avec phpmyvisite » sous « statisitique » mentalement, quand même, c’est évident, je ne crois pas devoir recopier les entrées triviales pour qu’on saisissent la pertinance du classement)

BoOz

7

Salut

Une réfléxion à mener serait sur l'intitulé "Auteurs", serait-il plus précis de parler d'"utilisateurs" (dont certains sont auteurs, mais d'autres pas).

En réfléchissant :

Tous ceux qui sont en mesure de cliquer sur l'icône "Auteurs" ont un point commun : ils se sont connectés au site pour accéder au B.O. Il serait donc logique d'avoir comme intitulés d'icône : connectés, logués, membres du site ... ( je sais c'est pas sexy comme intitulé) puis dans le menu déroulant la liste des niveaux d'investissement dans le site : administrateur , administrateur restreint, rédacteur, visiteur ; chacun de ces articles renvoyant à une page "ex Auteurs" spécifique en gardant à l'esprit que certains peuvent apparaître sur plusieurs pages. Cas d'un administrateur restreint qui publie dans des rubriques dont il n'est pas administrateur. Sur cette page une petite puce à gauche du nom indiquerait si la personne en question est en ligne.

voilà

Corrobori

8

Bonsoir a tous,

Je suis "de loin" mais avec beaucoup d'intéret ces propositions, et
contro-verses,
de nouveaux menus pour notre "bon vieux Spip"....
D'abord je voudrais dire bravo !
Bravo pour ces efforts -Booz et Cedric, et Romy en tete....et d'autres,
Bravo pour -enfin- proposer une interface plus "actuelle / fonctionnelle /
simple"
Car j'ai TROP souvent rencontrer un refus 'impulsif' sur la vieille frise,
meme avec ses évolutions depuis 2004, peu fonctionnelle pour ne pas dire
"naïve"
(cela m'a souvent fait penser aux frises qui ornent nos ecoles... ;-).

Maintenant j'aimerais vous proposer (j'ose) de distinguer entre :
- le contenu précis des menus (les distingos entre B et C sont pertinents,
mais...)
- l'apparence plus professionnelle, mais aussi plus classique que
j'aperçois,
  qui peut redevenir personnalisable/enrichie avec des #ICONE ou non...

AMHA, un premier pas sera déjà de proposer une présentation standard de
menus déroulants,
quite a gérer leurs arborescences avec un plan intégré, annexé en fichier
XML
(ce qui permettrait tres facilement de recarrosser les répartitions),
le tout dans la dist de base, voire dans un plugin ?

Cette etape permettrait de gommer tres vite nombre de réticences "de forme"
que beaucoup evoquent souvent sur SPIP.

Et l'organisation des menus suivra....

Mes 2 sou(hait)s
Cdlt
Yx

"BoOz" <booz@rezo.net> a écrit dans le message de news:
gp8618$rq6$1@ger.gmane.org...
Hello,

Voici une nouvelle proposition pour le menu, qui reprend les éléments de
Cerdic.

http://www.patagium.net/IMG/demo/menu-spip2.html

On constate que l'organisation proposée permet d'enrichir facilement les
entrées de menu avec des fonctionnalités issues de plugins.

Un sopin particulier à été apporté à la précision des termes employés,
pour rendre le tout le plus précis possible, et maximiser l'intuitivité
(affordance quoi !).

Une réfléxion à mener serait sur l'intitulé "Auteurs", serait-il plus
précis de parler d'"utilisateurs" (dont certains sont auteurs, mais
d'autres pas).

BoOz

9

J'ai une expérience contraire : ce qui plait dans SPIP, c'est aussi
son côté hors-normes, "non professionnel".
Ca dépend à qui, tu me répondras, et tu auras raison.

-- Fil

10

"Fil" <fil@rezo.net> a écrit dans le message de news:
bfc33ad70903111407t44720707kefc6dbddc6872564@mail.gmail.com...
J'ai une expérience contraire : ce qui plait dans SPIP, c'est aussi
son côté hors-normes, "non professionnel".

Reactions dès qu'on a des "adultes", meme si j'aime bcp cette interface
stylée

Ca dépend à qui, tu me répondras, et tu auras raison.

alors, est-il possible de proposer une meilleure facon de personnaliser
et ré-organiser le fonctionnement et style du menu de l'interface privée

Il me semble que c'est l'idée la plus unanime de tout ce travail
+1
Yx

11

Ben c'est déjà le cas. Le test grandeur nature dans SPIP-Contrib est fait avec un plugin "Bandeau" qui permet de définir le menu en XML.
Donc techniquement, même s'il y a encore du boulot bien sûr, c'est ré-organisable.

12

BoOz a écrit :

Voici une nouvelle proposition pour le menu
http://www.patagium.net/IMG/demo/menu-spip2.html

et hop ! (tm) une image comparative :
   http://www.circaete.net/vrac/bandos_10_03_2009.jpg

13

Encore faut-il définir « non professionnel »... :wink:

De tous les retours que j'ai eu, personnellement ou professionnellement, ce qui plaît dans SPIP c'est que ça sent la réflexion fonctionnelle, alors que la plupart des autres outils sentent le délire de techniciens/développeurs.

Un exemple frappant, de plus en plus d'outils de gestion de contenus proposent sur la gauche un explorateur arborescent générique dans lequel sont allègrement mélangés l'arbo des contenus quels qu'ils soient, l'arbo des menus front (qui peut être différente), l'arbo des fichiers (templates, css, js, etc.). Incompréhensible par un pur fonctionnel, mais rassurant pour un développeur, il a tout sous la main.

D'outil fonctionnel et mal codé, SPIP est devenu au fil des ans fonctionnel et bien codé. J'espère qu'il ne deviendra jamais bien codé mais pas fonctionnel.

Peut-être la réflexion actuelle sur le menu est-elle aussi complexifiée par le fait qu'on veut tout montrer dans les démos, alors que la plupart des « vrais » utilisateurs de SPIP ne verront ensuite qu'une petite partie de tout ça.

-Nicolas

14

Petite remarque annexe :

Le plugin CFG est un plugin *pour les développeurs*. Il n'a absolument aucun sens pour les utilisateurs. Donc ça ne veut pas dire grand chose de mettre un lien pour accéder à "CFG".

Donc soit il faut intégrer les pages de config directement dans les menus, soit on garde un clic supplémentaire avec une page de garde, mais il faut renommer ("configuration des extensions" ou autre truc dans le genre)(d'ailleurs pourquoi SPIP utilise le mot "plugins" alors que TOUT le reste a une recherche de cohérence linguistique et non jargoneuse).

Mais bon. C'est pas le plus important pour l'instant.

15

YannX wrote:

Cette etape permettrait de gommer tres vite nombre de réticences "de forme"
que beaucoup evoquent souvent sur SPIP.

Peux tu être plus précis ? là tu délivres des généralités inexploitables, or on est désormais dans une phase du débat dite "au taquet", qui ne souffre plus les approximations, j'en suis personnelement à ma 4eme proposition, Tetue et Cerdic on bien du en faire péter deux ou trois.

Et l'organisation des menus suivra....

Non, c'est justement ca qui est dur à faire : organiser efficacement.

Malgré les apparences, je ne te jette pas du débat, mais relis les épisodes précédents, on est déjà au stade ou tu souhaiterais qu'on soit.

Les points à discuter selon moi :

- Le cas des auteurs
- L'ergonomie des outils interractifs (messagerie etc)
- Les éléments de suivi éditorial (les publications, les modifications)
- Les remarques pertinantes sur l'ergonomie, l'affordance, la présentation de l'ensemble.

BoOz, sur les dents, on est chauds là, c'est parti pour accoucher d'un bandeau : concentration ^^

16

RastaPopoulos wrote:

Le plugin CFG est un plugin *pour les développeurs*. Il n'a absolument aucun sens pour les utilisateurs. Donc ça ne veut pas dire grand chose de mettre un lien pour accéder à "CFG".
Donc soit il faut intégrer les pages de config directement dans les menus, soit on garde un clic supplémentaire avec une page de garde, mais il faut renommer ("configuration des extensions" ou autre truc dans le genre)

Tout à fait, c'est le sens de ma formulation "etc... autres configuration CFG" à remplacer mentalement par lesdites entrées liées au CFG :
http://www.patagium.net/IMG/demo/menu-spip2.html

BoOz

17

Bonsoir,

et d'abord un grand merci aux contributeurs plus efficaces que moi qui m'ont
personnellement répondu !
je vais tenter d'expliciter mieux mon approche (je m'apercoi que je suis
fort disert ci-dessous) :
1°/ l'apparence compte bcp : ce n'est que bien après que l'analyse
fonctionnelle ressort !
je lance le developpement intranet de plusieurs espaces collaboratifs avec
SPIP,
je n'aurais jamais osé le faire avec l'interface 1.9/v2 si ce n'etait dans
une collectivité.

2°/ j'entends bien les préoccupations de cohérence fonctionnelle de Cedric
et Booz,
pour omettre les autres, mais je vais vous dire pourquoi je n'interviens pas
dans ce debat :
le niveau des discussions me parait tres precis déja, trop peut-etre et je
me souviens
des difficultés de "coupeur de cheveux en 4" que j'avais en definissant des
menus
dans des applications plus traditionnelles, pour ne pas ramener ma fraise
sans REEL etude.
   Plus particulièrement, certains points d'organisation dépendent
totalement du contexte,
il suffit de voir par exemple les approches opposées sur les visiteurs,
auteurs, redacteurs...

3°/ j'ai donc deux axes successifs d'amélioration ; car vos maquettes ont
aussi beaucoup
apporté sur l'apparence plus professionnelle, plus stricte (trop
certainement pour bien des usages libres .-)
  -1- avoir une apparence plus facilement (re)-modifiable,
    car depuis 3 ans, je ne me souviens que d'une proposition de Paulo ou
Luis
    pour offrir une CSS placant le menu d'interface privée en vertical
gauche
   ET C'EST TOUT !
   J'avais un peu regardé le code à l'epoque, et j'ai vite tourné
casaque.... ;-( excusez-moi )

  -2- puisqu'il y a débat (infernal, au taquet, sans pitié... car au coeur
de l'usage), et j'approuve,
   ne peut-on avoir une solution qui permette de ne pas s'enfermer dans une
SEULE interface ?
    c'est-a-dire avoir une interface facilement transformable (déjà en terme
d'organisation)
    donc utiliser un format de paramétrage de l'arborescence des menus ?
A ce moment je pense qu'aujourd'hui la forme standard de representation
d'une structure
evolutive s'appelle....... un format XML quelconque ; aussi militerai-je
pour un tel format
comme descriptif de la base structurelle des menus !
J'avoue que ce n'est que ce soir, a lecture -enthousiaste- de vos retours,
que j'ai pris conscience que finallement : SPIP gerer deja tout en XML !!
- les sauvegardes (sauf que j'avais souhaité un niveau de plus sur
l'identification des tables)
- les plugins (voir les evolutions cachées de plugin.xml )

alors, je vous propose de dire : prévoyons l'avenir !
- les exemples parfois extremes de rajouts les plus fous de plugins dans une
branche du menu pourraient
depasser les tailles des plus grands de nos ecrans......
=> prevoyons de pouvoir "couper/transformer" une arboresccence
   (meme à la mano sur un simple fichier texte xml)
=> batissons une structure DTD de menu.xml (voir du coté de XUL peut-etre ?)
    avec des possibilités d'extension pour enrichir chaque option de menu
    (icone, couleur, logo, texte + traduction, libellé d'appel, syntaxe
d'appel et parametres..)
=> implantons cette structure en moteur (type, j'ose, comme les CVT
peut-ete...)

Cette structure sera prete a recevoir la DIST-MENU-TYPE optimisée
fonctionnellement
et cette fois-ci en dehors de toute contrainte présentation, par les plus
pointilleux et exigeants
des experts qui ont investi sur cette question d'amélioration....

mais ce sera alors tres facile a modifier en profondeur.....

Laissez-moi rever un peu (mais c'est deja dans mes tuyaux, qd je pourrais)
!!
SPIP est un excellent CMS, mais il offre d'autres spécificités :
- il beneficie deja d'un work-flow (3 niveaux actuellement, mais statique)
- ses squelettes proposent une base assez simple et totalement integrable
   de presentation des données
- et il peut interroger deja plein de bases de données (oui Marcimat,
   j'y reviendrai, a interooger Progress, Oracle et SQLserver ;-))
- outre la gestion de tables de liaisons automatisée (génail cette
"evidence" ),
et la traditionnelle boucle hiérarchique (structure indispensable en
interrogation de bases de données,
et qu'il serait peut-etre utile de généraliser a d'autres tables....encore
une idée)
- voila qu'il se prepare à accepter des ecrans de saisie paramétrable (CVT
ou EXTRA)
- je n'ai pas parlé des apports de qualificatifs : les mots-clés
- me reste plus qu'a pouvoir inserer des traitements dans les CVT,
et nous avons un générateur/framework d'applications complet
... et encore j'ai gommé toutes sortes de plugins.....

=> dites-vous que peut-etre alors, la notion d'auteur redacteur ou editeur,
n'aura peut-etre plus rien a voir avec le domaine traité,
et que le travail approfondi sur le menu, indispensable pour la premiere
prise en main de l'outil,
risque d'etre en ce cas une gene (je n'oserai faire une comparaison avec
plusieurs axes développés et abandonnées dans les SPIP precedents)

Or ce point (le paramétrage de l'interface privé) reste statique, ignoré,
"boudé" des développeurs et createurs de plugins,
a l'exception admirable de ce nouveau travail sur les menus : pourquoi ?
Pourquoi n'y a-t-il rien sur les menus et structures de l'interface privée
sur spip-contrib ?
Je vois une première reponse qui concerne l'impossibilité me semble-t-il,
de changer les invariants actuels du core....

         Et donc mon raisonnement a plusieurs etages est :
          - factorisons ce qui est intangible (passer d'une structure à un
affichage menu)
          - isolons le, ou les deux points de modification : l'apparence
d'un coté,
          et la structure meme des menus, pour faciliter leur prise en
modification par d'autres
         pour que des forks d'usage puisses co-exister, sans tomber dans le
piege qui coula Agora
          - et gardons encore dans le noyau les seules fonctionnalités
indispensables !

Si nous (presomptueux, car je ne sais qu'utiliser) savons un "moteur"
d'appel des plugins
simplement paramétré par un petit fichier XML, je suis certain que les
developpeurs
de menu-deroulants ou autres sauront tres facilement adapter leur travail à
l'interpretation
d'un fichier menu-arbores.xml decrivant la structure arborescente d'appel de
moults ecrans d'interface
en y rajoutant un zeste optionnel d'enrichissements graphiques, qui donnera
une base ouverte.

Je m'excuse d'avoir ete si long, j'espere que je suis comprehensible
car pas toujours habitué a une telle explication en "aveugle".
Ayant participé un peu aux discussions de -et sur- wikini.net
j'en garde une certaine préférence pour l'enrichissement collaboratif du
texte
qui n'a pas la meme souplesse par mail ou par SPIP
Malheureuement je n'ai pas de SPIP ni de wiki public a ce jour pour
publier et vous offrir d'amender cette reflexion, mais n'heitez pas.

Je n'ai pas du tout mal pris la reflexion de Booz, et je voudrais encore
dire combien j'ai apprécié son attention.
Je ne pense pas etre actuellement utile dans ce (leur débat),
mais suggérer une voie d'évitement au risque de re-figeage qui pourrait
reprendre l'interface fonctionnelle de SPIP.
Peut-etre que j'ai VRAIEMENT manqué le fondement de base
et que cette architecture (ou une equivalente) est déjà sous vos bandeaux,
j'avoue que je n'ai pu assez approfondir ces derniers temps.

Merci de votre attention,
@suivre
Yx

18

Oui, je confesse que je n'avais pas identifié ce résumé,
j'ai fini par le retrouver (c'etait le 13/02 à 17h...)

Au temps (qui passe PAS) pour moi !
Ouf, merci !
Yx
Bravo !
mais en plus, je vais pouvoir essayer !!!

"BoOz" <booz@rezo.net> a écrit dans le message de news:
49B8E85A.10006@rezo.net...
YannX wrote:

Malgré les apparences, je ne te jette pas du débat, mais relis les
épisodes précédents, on est déjà au stade ou tu souhaiterais qu'on soit.

"BoOz" <booz@rezo.net> a écrit dans le message de news:
gn45sr$mh8$1@ger.gmane.org...
Hello,

Pour ceux qui n'ont pas tout suivi, le menu se défini en xml

Connexion · GitLab

Et il est surchargeable par les plugins.

BoOz, sur les dents, on est chauds là, c'est parti pour accoucher d'un
bandeau : concentration ^^