Comme Cédric le suggère, je bascule ce flux sur spip-dev.
C'est dommage qu'on ait discuté pendant 6 mois sur la liste spip-dev sans que tu intervienne (si ce n'est pour dire que la discussion ne m!ne à rien), et que maintenant tu nous annonce dans un mail à la team (alors que ce genre de discussion n'a rien à y faire), que rien ne va et tout est à jeter.
- Mon mail commence par dire (rapidement) que c'est bourré de trucs épatants. Mais qu'il y a des trucs qui ne vont pas, et je récapitule ce qui, à mon avis, ne permet pas de sortir une version stable.
- Dans ta réponse, tu dis «il y a beaucoup de travail avant que la branche dev actuelle soit sortable», et je ne dis pas autre chose. Je ne dis pas que tout est à jeter, je dis également qu'il reste beaucoup de travail.
- Je suis intervenu, d'autres sont intervenus, et: il reste du travail, et je ne pense pas que la version actuelle (de dév, donc modifiable et c'est tant mieux) reflète les points de vus exprimés depuis 6 mois. Je ne pense pas que la version actuelle résulte d'un consensus, c'est encore work-in-progress. Ça n'est pas une critique, ça me semble normal dans le processus de développement, simplement ça veut dire qu'il y a encore du boulot.
Il m'a semblé que la discussion sur l'ergonomie de l'espace privé s'est terminée en queue de poisson;
où en sommes-nous finalement ?Pour moi c'est impossible à sortir en l'état, et surtout pas en tant que «2.1». Si c'était une «3.0-en-vrac», je dis pas, mais là on est censés faire plus stable et cohérent que la «2.0», pas tout casser en disant qu'on lissera les difficultés par la suite.
Sur ce point je suis d'accord, il y a beaucoup de travail avant que la branche dev actuelle soit sortable. Quel que soit son nom.
On est d'accord! :-))
Surtout: l'idée étant d'avoir le «core» et des extensions plus faciles à mettre à jour de façon désynchronisée, je pense que la version actuelle est encore moins sortable.
Oui, c'est encore trop bancal, il y a des choses sorties, d'autres pas complètement, d'autres pas. Sur les choses sorties, comme les forum, il y a des organisations d'interface à repenser.
On est d'accord. Je peux préciser pourquoi j'aborde ce point dans un mail consacré à l'évolution d'interface. Il faut qu'on arrive à des solutions d'interface qui soient globalement cohérentes et satisfaisantes, de façon à ce que le cycle de développement des «extensions» ne demande pas de remodeler l'interface à chaque fois. Sinon tout dépendra encore de la structure de l'interface.
D'abord: y'a une tripotée de trucs qui fonctionnent de manière épatante.
Note bien: c'est moi qui ait écrit cette phrase. Donc le contraire de «tout est à jeter».
Les trucs qui, à mon avis, ne fonctionnent pas:
- l'aspect «travail collectif» dans l'espace privé est carrément passé à la trappe; je ne trouve pas d'entrée pour le(s) forum(s) privé(s), l'agenda et la messagerie sont planqués avec des icones muettes. Autant dire que c'est à la poubelle. Je vieux bien que tout ça a terriblement vieillit, mais le principe même d'outils de travail collectif est dans le principe même de SPIP. Si on veut corriger ça avec cette interface, c'est juste foutu.
commençons par refaire l'agenda et la messagerie alors.
Mais il faut se rendre à l'évidence. Ces outils, dans leur état actuel, ont tellement vieilli qu'ils ne sont pas utilisés par les les utilisateurs qui leur préfèrent dans tous les cas des outils modernes, même externe au site.
Non, pour deux raisons:
- si on vire le gros bouton consacré au travail collectif dans l'espace privé, on s'interdit de travailler-développer cet aspect. Avec l'interface actuelle, il passe à la poubelle et on ne pourra plus le remettre en valeur;
- en virant le gros bouton, on s'interdit même d'orienter le développement de plugins destinés à ce travail collectif, comme mon plugin «Tickets».
L'aspect travail collectif dans l'espace privé est dans la nature de SPIP. C'est même ce qui justifie nombre de ses choix d'interface (que d'aucuns trouvent contraignants). C'est ce qui justifie aussi d'avoir un véritable espace privé plutôt qu'un site public éditable.
- la focalisation sur le menu «Édition» est, j'insiste, un aspect problématique. «Édition», c'est naviguer dans les rubriques, se placer au bon endroit, et créer l'objet qu'on veut y installer (un article notamment). Les autres entrées du menu, ce sont uniquement des listes «alternatives» pour retrouver certains objets, essentiellement ceux qui ne rentrent pas bien dans la structure des rubriques: notamment les mots-clés. C'est pour ça qu'il n'y a pas de page «Tous les articles», parce que ça n'a aucun sens (il y «mes articles», ce qui est différent). Du coup, là on introduit un déséquilibre, et je n'ai pas lu grand chose sur les problèmes que ça induisait.
Avoir une page 'tous les articles' a un sens. Cela correspond à un besoin que plein de monde essaye de remplir avec un bricolage (avec un squelette public par exemple...). Cela ne correspond pas à ta vision, je l'ai bien compris.
Pour ma part, et comme pour tous les autres sujets ou visiblement on ne se comprend pas, j'en ferai un plugin. J'ai donc laissé tombé ce débat.
La question n'est pas la présence d'une page «Tous les articles».
Ce que je souligne, c'est le fait que l'interface de SPIP n'est pas à l'origine modulaire, mais intégrée. On relie tout à la structure du site, qui est avant tout la structure hiérarchique des rubriques. C'est un élément très important, justement, pour orienter la création et l'alimentation d'un site par ses différents auteurs vers la cohérence.
D'où le fait que le gros bouton «Édition» menait vers «naviguer.php», et pas vers une liste des articles ou autre. Les autres éléments sont des sous-menus qui complètent. Mais:
- les entrées de ces sous-menus n'étaient pas destinées à être des listes de chaque objet gérés par SPIP (interface modulaire), mais uniquement les objets mal reliés aux rubriques (mots-clés), et un peu tout de même de suivi d'objets, avec à chaque fois une notion de présentation adaptée et pas de simple liste (sites référencés);
- là j'ai vraiment le sentiment qu'on s'impose une logique purement modulaire, où chaque objet doit être présent indépendamment.
Je ne dis pas que c'est très mauvais. C'est sans doute une évolution nécessaire, et la présence de nombreux plugins impose aussi cette évolution. Mais: ça pose des problèmes. Le principal étant d'oublier l'aspect intégré de l'interface et l'ergonomie destinée à promouvoir une structuration cohérente et logique des sites. Autre aspect: cette orientation «modulaire» n'est pas forcément plus pertinent pour aider les «débutants». Voir comment, par exemple, seule la page «naviguer» existait jusqu'à présent pour les rédacteurs; ça n'est pas pour rien.
- les «auteurs» ne sont pas un élément éditorial, mais c'est la gestion des droits et des visiteurs. C'est problématique. et ça correspond au paragraphe précédent: la logique première de l'«édition» dans SPIP, c'est «naviguer.php»; après on peut essayer de blinder des sous-menus pour faire une liste et donner une impression de modularité, mais ça n'est jamais terriblement logique (et plus dangereux qu'autre chose).
- le plus gros problème, c'est le fait que le gros bouton mène à une page vide qui me prend pour un débile. Et ça, je persiste à considérer que c'est juste pas possible. Je vais pas développer, mais c'est la pire régression dans l'interface.
Dommange, c'est au contraire la meilleure amélioration, qui eviter de 'cacher' des pages derrières ces grosses icones que aucun utilisateur débutant ne pense jamais à cliquer.
Perso je n'ai jamais constaté ça. M'enfin en admettant que, tout de même, il y ait un blocage sur ces gros boutons.
D'abord, ces boutons étaient, faut pas oublier, les seuls boutons accessibles aux rédacteurs. Ce qui signifie qu'on parle d'un problème d'une personne qui est admin sur un site, mais qui ne trouve pas qu'on peut cliquer sur un gros bouton, et qui n'apprendra jamais qu'on peut cliquer dessus. Franchement, je ne suis pas convaincu.
Faire chier, en revanche, tous les autres admins pour quelques cas isolés d'admins qui ne seraient pas capables de cliquer sur un gros bouton (mais qui finiront bien par s'en rendre compte!), ça fait vraiment cher payé.
D'où ma proposition de transformer ces pages en «tableaux de bord». La liste des «boutons de plugin» qui sont actuellement seuls et au centre passeraient en colonne de gauche, et au centre on ferait un peu comme pour la page «Accueil»: chaque élément de «sous-menu» irait y inscrire ce qu'il veut: en gros des accès rapides et des résumés des infos.
- les pages de configuration personnelle pour remplacer les modifications directes via les raccourcis du bandeau de couleur, c'est totalement artificiel. S'il y avait des tripotées de nouveaux machins à configurer, pourquoi pas, mais là on voit bien que ces pages n'apportent rien à ce qui existait avant. Sauf une tripotée de clics en plus.
Au moins fil a récemment évoqué ça.
- et le problème de la répartition des menus, dont je pige bien qu'elle ne peut pas être discutée pendant des siècles, mais qui donne franchement pas un résultat satisfaisant actuellement. Le plus gros: la différence entre «édition», «publication» et «activité» me semble illisible. Pourquoi «gérer les forums» (qui sont du contenu éditorial super-important, puisqu'il est sur le site public) est dans «Activité», ça n'a rien d'évident.
J'ai posté là dessus au début, et surtout d'autres l'ont fait largement. Perso je n'ai pas le sentiment que les amendements répondent aux différents commentaires d'alors.
- dans les sous-menus, on a des soucis de cohérence, avec un bordel total avec le système d'onglets. Ça me semble normal, mais ça me semble dénoter qu'on est loin de pouvoir sortir une version. Exemple: dans Activité, on a «Statistiques» et «Liens entrants»; «répartition des visites» (qui était un sous-menu) est devenu un onglet des stats.
- en règle général, suite du point précédent: on multiplie les onglets. C'est une grosse régression par rapport à l'évolution de SPIP. Une des idées de la précédente grosse évolution, c'était de limiter le nombre de clics. Accéder quasiment à tout via les sous-menus. Et réserver les onglets aux fonctionnalités très spécifiques, et/ou moins fréquemment utiles.
ton opinon reflète celle des utilisateurs expérimentés qui veulent avoir accès à tout très vite. Mais passe à la trappe les profils plus débutants qui au contraire préfèrent une information plus segmentée qui leur permet de mieux appréhender les fonctionnalités. Evacuer l'un ou l'autre n'est pas une solution, et l'enjeu est de trouver les solutions qui permettent de conjuger les deux.
Non: ralentir les utilisateurs expérimentés n'a pas de raison d'améliorer la logique pour les débutants. Je ne vois pas en quoi les onglets aideraient les débutants à comprendre l'interface. En revanche, ça enquiquine tous les autres.
Est-ce que ça ne dénote pas une difficulté dans le système de sous-menus: ils ne permettent pas de regrouper des groupes d'éléments (lignes séparatrices par exemple) comme on en a l'habitude dans les menus de nos systèmes d'exploitation. Si de telles séparations existaient, est-ce que ça ne résoudrait pas la difficulté?
- je crois que le système de changement de skin n'est pas intégré. Ça me semble vital pour justifier un tel changement d'interface.
c'est pas fini, faut coder...
Ça n'est pas un reproche, hein. Je dis juste que ce système me semble vraiment important dans l'optique de l'évolution d'interface.
D'autant que là, sachant qu'un tel système va arriver, j'ai poussé le bouchon dans mon interface «bling-bling». Moi j'aime, évidemment, mais un des buts de l'évolution, c'est de surmonter ce point de blocage.
- les grosses icones du dessus ne vont pas, faut que je les fasse. Mais bon, comme je pense par ailleurs que la structure des menus ne fonctionne pas non plus..
ARNO*