[spip-dev] Menus dans l'espace privé

Hello,

Je ne voudrais pas plagier certains bretons absents… mais les menus de l’espace privé on tendance à devenir une “kermesse totale” quand la liste des plugins activés s’allonge. Mon menu Configuration vient de dépasser la hauteur de mon écran il n’y a pas si longtemps.

En deux mots, l’affluence de plugins entraine à mon avis :

  • l’allongement des menus verticaux de façon anarchiques
  • qui perdent au bout d’un moment la pertinence pour laquelle on les a définis.

J’ai fait un petit proto sans ambition pour montrer ce qu’on pourrait obtenir si l’on “fixait” la premier niveau de menu (Maintenance dans le proto) et si on utilisait un sous-menu pour chacune des fonctionnalités incluses. Le proto est ici : Proto Menu Maintenance, la plupart des liens étant actifs (les onglets du haut ne font pas partis du proto mais permettent juste de passer d’une page à l’autre sans revenir à la première). Pour les libellés c’est un exemple ne vous y attachez pas trop.

Dans le même genre d’idée, le menu configuration est aussi problématique :

  1. Toutes les configurations de plugins n’y sont pas
  2. Certaines sont ailleurs que dans le menu de configuration
  3. alors que la liste des plugins actifs elles contient les icones de configuration de façon exhaustives

Est ce qu’on devrait pas avoir un seul item “Configuration des plugins” qui mènent sur une page un peu identique dans laquelle le menu de gauche serait identique à ce qui est proposé plus haut et listerait tous les plugins avec leur vrais noms pour mieux les repérer. Ce menu pourrait en plus être créé automatiquement à partir de l’existence d’une config.
Ou alors on utilise que la liste des plugins actifs pour aller dans la config.

Voilà un peu des petites réflexions uniquement sur ce sujet des menus.

+1 Configuration dépasse ma page également et je m’y perd dans les configuration via plugin ou menu du coup j’essaye d’expliquer …

Je ne voudrais pas plagier certains bretons absents... mais les menus de l'espace privé on tendance à devenir une
"kermesse totale" quand la liste des plugins activés s'allonge. Mon menu Configuration vient de dépasser la hauteur de
mon écran il n'y a pas si longtemps.

Je ne suis pas certain de comprendre quel sera le mode d'emploi de ce niveau intermédiaire.
Pourrais-tu préciser ?
La raison de ma question, c'est que le passage d'une page à une autre dans l'interface de SPIP3
est particulièrement long sur un hébergement mutualisé qui rame.
Rajouter un niveau de clic rendrait l'interface très relou à utiliser si il faut attendre entre chaque clic un rechargement de la page.
Mais la nouvelle archi proposée serait OK si le html de toutes ces pages
est en permanance chargé, mais caché, de même que celui des menus déroulants,
pour s'afficher à la demande.

Une solution complémentaire serait de mettre les entrées des menus de la partie privée
dans des objets SPIP, et d'ajouter un sélecteur générique.
On aurait une navigation "à là" Unity de Ubuntu.

Par ailleurs, comme les pages intermédiaires sont assez légères,
on peut imaginer qu'un plugin leur colle une colonne de droite personnalisée ?
Par exemple un plugin "mes_favoris_du_prive"...

JLuc

Yop,

« kermesse totale » quand la liste des plugins activés s’allonge. Mon menu Configuration vient de dépasser la hauteur de
mon écran il n’y a pas si longtemps.

Je ne suis pas certain de comprendre quel sera le mode d’emploi de ce niveau intermédiaire.
Pourrais-tu préciser ?

En fait l’idée est de limiter la taille du menu que tu appelles intermédiaire et même si possible qu’il devienne « figé » ce qui permettrait à la longue de développer une habitude pour les utilisateurs comme les boutons du bandeau.
Ainsi un plugin viendrait prendre naturellement sa place dans ce schéma sans allonger indéfiniment ce menu qui d’aileurs n’est jamais le même suivant l’ordre dans lequel on active les plugins.

Si tu prends mon exemple du menu Maintenance, l’activation de tous les plugins donnerait 14 lignes « mélangées » et alors que l’intérêt de les voir à un même niveau n’est pas certain (comme le plugin Wordpress2Spip par exemple). Et c’est encore pire avec le menu configuration qui dépasse la plupart du temps la hauteur de mon écran !

En plus ça permet plus de flexibilité et donc de précision sur l’organisation vu qu’on a un niveau supplémentaire de raffinement. Je ne sais pas si mes libellés sont bons mais je trouve que ça se lit assez bien. Je pense qdonc qu’il y a un aspect « pédagogique » (j’allais dire ergonomique mais je me suis retenu) dans cette organisation et ces libellés.

Dans ce même ordre d’idée mais un peu en dehors de ce thread, je trouve que finalement à la longue le bouton Squelettes contient un peu tout et n’importe quoi et souvent d’ailleurs de la configuration de plugin qui serait plus appropriée dans Configuration.
Et il manque un bouton Développer pour mettre l’ensemble des outils de dév qui se multiplient et qui ont du mal à trouver leur place actuellement sauf à bourrer encore plus le menu Maintenance.

La raison de ma question, c’est que le passage d’une page à une autre dans l’interface de SPIP3
est particulièrement long sur un hébergement mutualisé qui rame.
Rajouter un niveau de clic rendrait l’interface très relou à utiliser si il faut attendre entre chaque clic un rechargement de la page.

Par ailleurs, comme les pages intermédiaires sont assez légères,
on peut imaginer qu’un plugin leur colle une colonne de droite personnalisée ?
Par exemple un plugin « mes_favoris_du_prive »…

Oui c’est exact.
C’est pour cela que quand tu cliques sur l’item Nettoyer par exemple tu obtiens directement la page de la fonction habituelle qui est vider le cache. En cela on a rien perdu.
Par contre pour les autres - cad les plugins - on a un clic supplémentaire c’est indéniable.

Alors oui je te rejoins sur cette histoire de favoris, peut-être qu’une gestion d’actions favorites permettrait de combler cette lacune, je t’avoue que même aujourd’hui j’en ressens déjà le besoin.

Bonjour Eric,

D'abord un grand merci pour le travail mené avec saveauto
Je decouvre ce midi qu'encore deux nouvelles release sont passées,
et un coup d'oeuil au 4303 m'informe de tes avancées.
(y'a encore l'icone de saveauto 1.0.5 qui n'apparait pas)

En fait je viens voir grace a ton message sur IRC :
++++ pour approuver (sur ce que j'ai compris)
D'ailleurs, avec mes 'talents' CSS ;-( je suis actuellement
incapable de proposer un menu prive à la WP, qui va dans ton sens..
(unecollègue trouve d'ailleurs

J'ai compris que le mini-bandeau du haut n'est pas visé ?
Dommage, car je trouverais que ces paves juxtaposés
- en les rajoutant sous le bandeau actuel"grands titres"
- et en reprenant automatiquement les categories des plugins (pas SVP)
- pour inserer directement chaque bouton d'un plugin
dans un sous-menu de cette catégorie

Et meme demande du "sous-choix" par defaut (cf.JLuc)

Cela reste un peu flou, car j'ai du mal a "voir" la distinction
entre boutons des menus-sous-menus et "onglet"

En discutant avec un collègue, je proposerai meme la demarche suivante:
- deux sous-bandeaux (au format du haut) à la place du titre "Maintenance" en horizontal
-> le premier contient les (boutons-onglets.carrés) d'appel des SPIP natif (et des plugins intégrés à la distribution....)
-> en-dessous un second bandeau (tout aussi mince) pour les groupes de plugins (des categories/sous-categories. ? ?.) avec une liste depliante
  + la boite de menus que tu generalises

Je prevoirais une evolution vers un vrai menu a la WP
(avec deux/trois/niveaux deroulants)
ce qui permet de regler le probleme des longueurs d'affichage,
(si la liste est trop longue, on la replie..)
et se révele plus facile a la longue
/retour à l'exmple WP, que je n'aime pas par ailleurs
(d'ailleurs c'est un retour aux normes CUA)

Espérant etre comprehensible... lol
YannX

Même si dans l'absolu c'est une idée qui peut être intéressante un jour, je ne vois pas l'intérêt de le faire dans le cadre de l'interface actuelle.

Comme je le vois pour l'instant, c'est du genre à continuer de modifier par-ci par-là l'interface actuelle, et donc continuer d'ajouter des couches sur des couches sur des couches alors qu'il faudrait plutôt repartir au propre. Ce qui risque fortement de ne faire que compliquer les choses, au lieu de concevoir un truc global.

Hé hé,

Hello,

Yop,

« kermesse totale » quand la liste des plugins activés s’allonge. Mon menu Configuration vient de dépasser la hauteur de
mon écran il n’y a pas si longtemps.

Je ne suis pas certain de comprendre quel sera le mode d’emploi de ce niveau intermédiaire.
Pourrais-tu préciser ?

En fait l’idée est de limiter la taille du menu que tu appelles intermédiaire et même si possible qu’il devienne « figé » ce qui permettrait à la longue de développer une habitude pour les utilisateurs comme les boutons du bandeau.
Ainsi un plugin viendrait prendre naturellement sa place dans ce schéma sans allonger indéfiniment ce menu qui d’aileurs n’est jamais le même suivant l’ordre dans lequel on active les plugins.

Si tu prends mon exemple du menu Maintenance, l’activation de tous les plugins donnerait 14 lignes « mélangées » et alors que l’intérêt de les voir à un même niveau n’est pas certain (comme le plugin Wordpress2Spip par exemple). Et c’est encore pire avec le menu configuration qui dépasse la plupart du temps la hauteur de mon écran !

En plus ça permet plus de flexibilité et donc de précision sur l’organisation vu qu’on a un niveau supplémentaire de raffinement. Je ne sais pas si mes libellés sont bons mais je trouve que ça se lit assez bien. Je pense qdonc qu’il y a un aspect « pédagogique » (j’allais dire ergonomique mais je me suis retenu) dans cette organisation et ces libellés.

Je ne suis pas super fan de rajouter un niveau intermédiaire. Quand il sera plein, on recommence avec un autre niveau intermédiaire de plus ?

L’argument d’ajouter une page intermédiaire pour ne plus avoir de menu « qui dépasse » la hauteur de l’écran n’est pas très solide, car on a déjà ça aujourd’hui : si ton menu dépasse la hauteur de l’écran, tu peux quand même accéder à tous son contenu par la page intermédiaire qui est disponible en cliquant directement sur « Configuration » (et par laquelle on passe de toute façon à chaque fois sur les iTrucs).
Donc le scenario du menu « plein de trucs » n’est pas amélioré par la sous catégorisation en sous-sous menus (sauf à créer aussi des sous-sous niveaux de menu déroulant, non utilisables sur tous les dispositifs tactiles).
Et le scenario plus conventionnel du menu pas plein est lui dégradé en obligeant à passer par une page/etape intermédiaire.

A mon sens, il faut déjà bien définir ce qui doit aller ou pas dans ce menu.
Il est gratifiant pour un auteur de plugin de faire apparaitre son icone dans ce menu, mais c’est souvent contre-productif.
Je vais prendre l’exemple du plugin Facteur : c’est un plugin que le webmestre configure une 1 fois dans la vie du site (ou en tout cas vraiment rarement), qui n’a rien d’éditorial. A ce titre, je crois qu’il n’a rien à faire par défaut dans le menu configuration.
On devrait donc exclure du menu « configuration » la configuration des plugins qui sont techniques, et à la charge du webmestre, car celui-ci saura très bien retrouver l’accès dans la page des plugins pour une fonction qu’il utilise une fois tous les 4 matins.

On peut envisager néanmoins, de donner un accès direct à ces configurations dans la colonne de gauche, en extension de menu dupliqué de configuration qui s’y trouve déjà.

Par ailleurs, on peut améliorer l’aspect visuel en réduisant la hauteur de chaque item d’un menu principal quand celui-ci a plus de N items.

Dans ce même ordre d’idée mais un peu en dehors de ce thread, je trouve que finalement à la longue le bouton Squelettes contient un peu tout et n’importe quoi et souvent d’ailleurs de la configuration de plugin qui serait plus appropriée dans Configuration.

Pour moi, justement non.
Dans ce menu squelette on y mets ce qui permet de modifier l’apparence et les fonctionnalités du site public, dans la mesure où ça ne nécessite pas de devoir éditer les squelettes à la main.
C’est parfois une simple configuration de plugin, mais ça n’a pas pour autant de raison d’être dans le menu Configuration. La mediabox en est le parfait exemple.

Et il manque un bouton Développer pour mettre l’ensemble des outils de dév qui se multiplient et qui ont du mal à trouver leur place actuellement sauf à bourrer encore plus le menu Maintenance.

Je crains vraiment que l’introduction d’une entrée de ce type ne fasse que renforcer l’impression que SPIP ne s’adresse plus qu’aux codeurs poilus et pas aux gentils utilisateurs qui viennent pour publier.
Je vois bien que certains plugins sont des outils de développement et qu’aucune entrée ne correspond vraiment, mais si cette entrée existe, ça veut dire qu’on va y mettre par exemple le validateur XML natif comme l’avait proposé Emmanuel il y a longtemps, et donc que ce menu sera toujours là, pour tous les administrateurs, y compris tous ceux qui ne sont pas développeurs.

En la matière je crois qu’on risque surtout de faire peur aux GUS en leur mettant un menu « Developpement » qui leur fera penser bien vite qu’ils se sont trompés d’outils, pour simplifier la vie de codeurs poilus…
Pas sûr que ça soit un mouvement très heureux.
Ou alors, peut-être en faisant comme dans Safari : ce menu Développement serait toujours caché (même si il y a des choses dedans) sauf si on va cocher un case spécifique dans la configuration avancée ?

La raison de ma question, c’est que le passage d’une page à une autre dans l’interface de SPIP3
est particulièrement long sur un hébergement mutualisé qui rame.
Rajouter un niveau de clic rendrait l’interface très relou à utiliser si il faut attendre entre chaque clic un rechargement de la page.

Par ailleurs, comme les pages intermédiaires sont assez légères,
on peut imaginer qu’un plugin leur colle une colonne de droite personnalisée ?
Par exemple un plugin « mes_favoris_du_prive »…

Oui c’est exact.
C’est pour cela que quand tu cliques sur l’item Nettoyer par exemple tu obtiens directement la page de la fonction habituelle qui est vider le cache. En cela on a rien perdu.
Par contre pour les autres - cad les plugins - on a un clic supplémentaire c’est indéniable.

Alors oui je te rejoins sur cette histoire de favoris, peut-être qu’une gestion d’actions favorites permettrait de combler cette lacune, je t’avoue que même aujourd’hui j’en ressens déjà le besoin.

A reflechir…
Mise en favori manuelle ou automatique d’après les pages les plus utilisées ?
Où est l’accès à ces favoris ?

Cédric

Yo,

Je ne suis pas super fan de rajouter un niveau intermédiaire. Quand il sera plein, on recommence avec un autre niveau intermédiaire de plus ?

Ben non car le but c’est justement d’arriver à le « figer ». On pourrait dire en simplifiant que la proposition c’est de standardiser deux niveaux de menus plutôt qu’un afin de ranger un peu mieux les plugins.

L’argument d’ajouter une page intermédiaire pour ne plus avoir de menu « qui dépasse » la hauteur de l’écran n’est pas très solide, car on a déjà ça aujourd’hui : si ton menu dépasse la hauteur de l’écran, tu peux quand même accéder à tous son contenu par la page intermédiaire qui est disponible en cliquant directement sur « Configuration » (et par laquelle on passe de toute façon à chaque fois sur les iTrucs).
Donc le scenario du menu « plein de trucs » n’est pas amélioré par la sous catégorisation en sous-sous menus (sauf à créer aussi des sous-sous niveaux de menu déroulant, non utilisables sur tous les dispositifs tactiles).
Et le scenario plus conventionnel du menu pas plein est lui dégradé en obligeant à passer par une page/etape intermédiaire.

C’est pas exactement ce que j’ai dit. Je trouve aussi que ça éclaire le menu et la compréhension de ces fonctions incluses. Quand tu regardes la page Sauvegarder, avoir en menu toutes les options de sauvegarde base en SQLite, base en MySQL, Mes fichiers perso et la config je trouve ça pertinent non ?
Mais c’est peut-être subjectif.

A mon sens, il faut déjà bien définir ce qui doit aller ou pas dans ce menu.
Il est gratifiant pour un auteur de plugin de faire apparaitre son icone dans ce menu, mais c’est souvent contre-productif.
Je vais prendre l’exemple du plugin Facteur : c’est un plugin que le webmestre configure une 1 fois dans la vie du site (ou en tout cas vraiment rarement), qui n’a rien d’éditorial. A ce titre, je crois qu’il n’a rien à faire par défaut dans le menu configuration.
On devrait donc exclure du menu « configuration » la configuration des plugins qui sont techniques, et à la charge du webmestre, car celui-ci saura très bien retrouver l’accès dans la page des plugins pour une fonction qu’il utilise une fois tous les 4 matins.

Ah ben ça c’est une règle qui pourrait très bien être expliquée et utilisée oui. J’ai d’ailleurs exprimé dans mon premier mail que je comprenais pas pourquoi il y avait des plugins avec et sans lien de configuration.

D’ailleurs le menu Configuration c’est la configuration de quoi ?? J’y reviendrais dans le cas des squelettes.

Pour moi, justement non.
Dans ce menu squelette on y mets ce qui permet de modifier l’apparence et les fonctionnalités du site public, dans la mesure où ça ne nécessite pas de devoir éditer les squelettes à la main.
C’est parfois une simple configuration de plugin, mais ça n’a pas pour autant de raison d’être dans le menu Configuration. La mediabox en est le parfait exemple.

Mediabox, Zen Garden, Sarka-SPIP soit mais Gravatar, Comments, Socialtags, Court-circuit, Dublin Core, Exclure secteur, Fabrique, Skeleditor, refbase… je suis pas sur que ce soit si évidemment logique.

Et il manque un bouton Développer pour mettre l’ensemble des outils de dév qui se multiplient et qui ont du mal à trouver leur place actuellement sauf à bourrer encore plus le menu Maintenance.

Je crains vraiment que l’introduction d’une entrée de ce type ne fasse que renforcer l’impression que SPIP ne s’adresse plus qu’aux codeurs poilus et pas aux gentils utilisateurs qui viennent pour publier.
Je vois bien que certains plugins sont des outils de développement et qu’aucune entrée ne correspond vraiment, mais si cette entrée existe, ça veut dire qu’on va y mettre par exemple le validateur XML natif comme l’avait proposé Emmanuel il y a longtemps, et donc que ce menu sera toujours là, pour tous les administrateurs, y compris tous ceux qui ne sont pas développeurs.

En la matière je crois qu’on risque surtout de faire peur aux GUS en leur mettant un menu « Developpement » qui leur fera penser bien vite qu’ils se sont trompés d’outils, pour simplifier la vie de codeurs poilus…
Pas sûr que ça soit un mouvement très heureux.
Ou alors, peut-être en faisant comme dans Safari : ce menu Développement serait toujours caché (même si il y a des choses dedans) sauf si on va cocher un case spécifique dans la configuration avancée ?

Penses-tu qu’en laissant l’interface devenir confuse au fil de l’ajout de plugins c’est pas un risque non plus ?

Mais de toute façon loin de moi l’idée d’inclure toujours ce menu dans le bandeau mais uniquement quand cela est nécessaire cad quand un plugin de ce type est activé. Et je suis d’accord avec toi que SPIP de base ne doit pas l’afficher. J’ai pensé comme toi à ce que font certains navigateur et je trouve ça mieux que de répartir ces outils dans les différents menus ce qui n’a aucun sens.

C’est exact que globalement on pourrait faire une passe sur les plugins SPIP 3 pour voir si les emplacements sont judicieux. J’essayerais de faire un recensement et de le publier ce week-end.

A reflechir…
Mise en favori manuelle ou automatique d’après les pages les plus utilisées ?

Non par choix uniquement les trucs auto à la office je suis pas fan.

Où est l’accès à ces favoris ?

Je verrais bien un bouton à la suite des raccourcis créer un article… qui ouvrirait un petit menu de quelques items favoris. Un peu comme on avait dans SPIP 2.

Il me semble que de nombreuses avancées de SPIP ont commencé par des plugins, comme le bandeau actuel (avant le mini-bandeau), comme Bonux et Iterateur...

Ne peut-on pas , si ce n'est deja réalisé dans les evolutions,
simplement passer la "presentation" du menu privé en plugins-dist
(debrayable si le webmestre le repasse dans plugins),
et laisser le soin à une seconde etape (plus ouverte) de
proposer des plugins-menus-privés, qui organiseraient
des modes d'affichage différents.....

Par ailleurs, un "effet de bord" de cette discussion met en evidence
le nombre croissant de plugins (souvent minimalistes) jugés
utiles par de nombreux spipeurs....

Plutot que d'envisager une "uzine à gaz" pour gérer leur accumulation,
peut-etre revenir à une autre forme d'intégration..... mecanique !
Je ne trouve plus aucune explication pour ecrire sans passer par des plugins ET la définition des pipelines uniquement dans paquet.xml :
Ce doit pourtant etre possible ??

Mes sousdé-biles
YannX

Quelques remarques (un peu naïves) en vrac :

  • Y aurait-il une ouverture du troisième niveau au survol du second niveau ?
  • La page du premier niveau ne devrait-elle pas présenter les niveaux 2 et 3 ?
  • Ne faudrait-il pas dès lors un fil d’Ariane pour savoir où on se trouve dans le système ?
  • Un des soucis est aussi les pages avec un tout petit formulaire de config (comme les révisions) qui aurait finalement pu être directement ajouté à une page telle que Fonctions avancées. Peut-être serait-ce pertinent de regrouper plusieurs configurations sur une même page.
  • Il me semble qu’il faut aussi être vigilant avec cette tendance à tout mettre dans la colonne de gauche. Sur pas mal de pages de config, vu que le sommaire des entrées de configuration est affiché dans la colonne de gauche (et fait doublon avec le bandeau d’ailleurs), le message d’avertissement sort de l’écran et n’est plus visible sans faire défiler la page. Or, il me semble que ce message d’avertissement devrait être visible en premier.
  • D’ailleurs, cette liste des pages de config n’est pas présente sur toutes les pages de config.
  • Ou faudrait-il exploiter mieux les colonnes de gauche et de droite pour ceux qui utilisent le Grand écran (l’option par dféaut étant toujours le petit écran) ?
    Cordialement

Joseph