Ergonomie de l'espace privé - Pistes ?
Avec l'ouverture aux nouveaux objets éditoriaux, les pages rubriques dans l'espace privé vont vite devenir lourdes (cf. capture n°1). Et ceci, à cause de l'alternance des listings, des boutons de création, etc. => logique mais difficile d'avoir une vision d'ensemble...
Un logiciel de base qui a résolu ce pb depuis longtemps : les gestionnaires de fichiers. S'en inspirer permettrait d'avoir une meilleure vue d'ensemble et une meilleure ergonomie. cf. un montage rapide sur la capture n°2. Je n'ai pas remis le 'voir en ligne' et le 'supprimer' qu'il faudrait intégrer quelque part (menu d'action ?), ni le logo : que je vois plutôt en partie modification ou alors intégré entre titre et texte... pour avoir qqch pleine page. mais avis aux ergonomes !
Dans les gestionnaires de fichier, on trouve aussi généralement un menu permettant de choisir le type d'affichage. et afin de contenter tout les utilisateurs SPIP, et en restant simple. On pourrait avoir le choix parmi, des 'vues' :
- vue dissociée par type et statut (~ Spip2/3)
- vue synthétique (s'inspirant de la capture n°2)
- vue synthétique mais avec un accent particulier mis sur les contenus proposé à l'évaluation
- et surtout pouvoir définir ses propres 'vues' (un simple squelette ajouté dans un dossier ?...) SPIP proposerait quelques 'vues' de base, d'autres pouvant être facilement créées par les contributeurs pour qu'ils puissent s'approprier plus facilement cet espace privé. (Ex: j'ai un site avec une seule rubrique collaborative et dans celle-ci, il y a plus d'un millier d'articles. impossible de retrouver quoi que soit car c'est classé par mot clé. Du coup, l'habitude fait que je passe par les boutons d'admin de l'espace public, mais bon, si j'avais un jour la possibilité de faire une petite vue perso 'trié par mot clé', je pourrais alors rendre la vue actuelle de cette rubrique exploitable côté privé !)
Selon la rubrique, il peut aussi être intéressant d'avoir des vues distinctes. Cela devrait pouvoir se configurer d'une manière ou d'une autre. (((et en poussant à l’extrême, il existe des CMS ou on peut choisir une vue pour chaque rubrique, avec des notions d’héritage du parent, et de vue "par défaut"...))) Bref.
Sur l'autre rive : du côté public, on a souvent besoin de réaliser des listing mixtes (des dernières mises à jour par exemple). On trouve des astuces, ici et là, mais ça reste plutôt compliqué, limité et à la performance discutable.
Techniquement :
Aujourd'hui, est-il possible de boucler facilement/efficacement sur tous les types d'objets éditoriaux ? J'ai aperçu des nouvelles boucles <BOUCLE_objets(DATA){source table,#REM|lister_tables_objets_sql}> Je ne sais pas encore vraiment m'en servir. Est-il possible de s'en sortir avec ça ? c.à.d d'arriver à obtenir la capture n°2 ?
J'ai vraiment le sentiment que c'est le nerf de la guerre. Et que sans possibilité simple/efficace de boucler sur des objets divers, les perspectives de faire évoluer, d'améliorer petit à petit l'ergonomie du back-office restent un peu compliquées. Je me trompe peut être.
Qu'en pensez vous ?
Je vous livre ci-après une petite réflexion que je m'étais faite il y a quelques temps. Concernant une évolution du MDD qu'il me semblait obligatoire pour traiter ces problématiques... En apercevant récemment les boucles 'DATA', je me dis que tout ça a déjà du être discuté et tranché... Qu'importe, voici en l'état :
Quand on regarde le modèle de données, on voit de plus en plus de tables avec des couples (objet/id_objet) C'est cool pour la généricité et ça donne l'impression d'une perche tendue : Il est tentant d'imaginer avoir une table 'spip_objets'. Tous les couples (objet/id_objet) devenant du coup de simples relations standards (id_objet).
La structure de la table spip_objets définirait une sorte de standard minimal, un contrat pour tous les types de contenu éditoriaux et sur lequel le CMS pourrait s'appuyer plus facilement.
Exemple :
spip_objets | |- id_objet |- type (= article, brève, choux, navet...) |- titre |- description (peut faire partie des attributs de base, pour les listings, rss, etc.) |- statut |- des dates (création, publication, dernière modif) |- ... spip_articles | |- id_article |- id_objet |- sous_titre |- sur_titre |- texte |- ps spip_navets | |- id_navet |- id_objet |- et pourquoi pas 'rien de plus' (mais la table devra exister, d'autant plus en cas d'évolution ou d'ajout de champs ultérieur...) - et tout simplement pour l'homogénéité.
Il devient possible d'avoir des boucles généralistes simples :
#TYPE - #TITRE - #DESCRITPION
avec jointure automatique dans l'autre sens :
#TITRE - #DESCRITPION - #TEXTE
ça soulève surement beaucoup de questions point de vue compilation, et de l'utilité ou non, et de la possibilité d'une jointure de la table objet vers... les autres (1->n !!) ? C'est pas forcément concevable ou possible, mais peut être que c'est pas nécessaire non plus :
- si ça sert pour des listing simples (d'attributs de base)
- pour des listing complets, inviter a imbriquer des boucles des types voulu pour un nb limité de résultat.
Mais il faudrait tout de même au minimum qu'il soit possible d'avoir qqch comme :
#URL_OBJET
Si tout cela est concevable, l'intégration des nouveaux objets éditoriaux devrait être encore facilité. Car les interfaces de l'espace privé s'appuieraient à fond sur spip_objets, que ce soit pour les documents, forums, langues, statistiques, etc. Et par conséquent, il n'y a plus d'inconnu pour ces services, et donc encore moins de pipelines à remplir.