[spip-dev] Les compléments d'objet, moins importants que le contenu

Dev
1

Un certain nombre de personnes sont d'accord sur le sujet : il doit y avoir une refonte profonde de l'admin, pour prendre encore mieux en compte la modularité (les plugins peuvent vraiment ajouter des choses un peu partout et ça devient illisible).

Mais je ne vais PAS parler de ce truc long et compliqué. Donc pas de hors sujet s'il vous plaît. :slight_smile:

Je voudrais proposer une modif en amont, qui concerne juste *l'interface actuelle* : ne pas ajouter les choses complémentaires AVANT le contenu principal d'un objet.

Si c'est complémentaire, c'est que ça vient en plus, pour classer ou donner des informations supplémentaires. Mais ce n'est pas LE contenu de l'objet qu'on visionne.

Actuellement, avec 10 mots clés, aucun auteur, juste les mots, et bien le vrai contenu est en dehors même sur un 21 pouces !

Ainsi, rien que pour parler des choses fournies par défaut, il faudrait déplacer *en bas* : les mots-clés, les auteurs, et peut-être même l'URL.

Au niveau technique, que ce soit le pipeline complements_objets ou le commentaire/balise sur lesquels certains se branchent, je propose donc de les déplacer en bas.

On me dit "mais le problème sera inversé pour ceux qui ont des articles longs et qui vont devoir scroller". Sauf qu'à mon avis ce sont eux les cas plus rares, mais surtout d'autant plus vrai que les mots peuvent être activés sur bien d'autres choses que les articles ! (et pareil pour les auteurs, ou tout autre trucs_liens)

Voilà, ça ne demande quasiment rien à faire, c'est surtout un choix de dire : nous voulons lire d'abord le contenu principal de l'objet sur lequel nous sommes PUIS les infos supplémentaires.

2

Je me corrige un peu : le pipeline afficher_complement_objet qu'ajoute l'échafaudage est *déjà* au bon endroit, après le #wysiwyg qui doit contenir le contenu principal.

Donc ce qu'il faut corriger surtout ce sont les plugins qui ajoute directement par "affiche_milieu" et en faisant ce truc très malpoli :
$flux = MON_truc.$flux

Ce qui signifie : j'ai le dernier mot puisque je m'insère par pipeline mais EN PLUS je m'insère avant ton contenu parce que je pense que je suis plus important que toi.

Super l'égocentrisme quoi...

3

C’est vrai que les choses s’empilent avec le temps et qu’il y a surement des choses “simples” à faire pour améliorer les choses.

Je me demande juste s’il est judicieux de faire des ajustements préventifs si ça doit encore bouger plus tard. Les utilisateurs n’aimant pas trop les changement fréquents… Évidemment, si le chantier de l’ergonomie, c’est pour dans 10ans, ça vaut surement le coup de faire ces modifs :slight_smile:

Si j’ai bien compris, l’idée est de proposer qqch de très simple, rapide à mettre en place.
Dans ce cas, j’ose une autre idée que j’avais suggéré en commentaire dans ce ticket : http://core.spip.org/issues/2289
Ça me paraissait assez rapide aussi mais je n’ai pas du tout une bonne vision du boulot que ça représente, ni des histoires de compatibilité…
Aussi, si je tombe sur le coup du “Mais je ne vais PAS parler de ce truc long et compliqué. Donc pas de hors sujet s’il vous plaît”,
dans ce cas, merci d’oublier ce paragraphe très vite sans y rebondir :wink:

Je serais également curieux de savoir si qqn à une idée de la manière dont le “chantier de l’ergonomie” de spip va s’effectuer.

  • plutôt une grosse refonte d’un seul coup lors d’un changement de version majeure ?
  • plutôt petit à petit au cours d’apports successifs, comme celui proposé ici ?
  • plutôt pas d’idée précise et en fonction des bonnes volontés ?

Julien

4

* RastaPopoulos tapuscrivait, le 29/09/2012 15:05:

Je me corrige un peu : le pipeline afficher_complement_objet qu'ajoute
l'échafaudage est *déjà* au bon endroit, après le #wysiwyg qui doit
contenir le contenu principal.

Donc ce qu'il faut corriger surtout ce sont les plugins qui ajoute
directement par "affiche_milieu" et en faisant ce truc très malpoli :
$flux = MON_truc.$flux

Ce qui signifie : j'ai le dernier mot puisque je m'insère par pipeline
mais EN PLUS je m'insère avant ton contenu parce que je pense que je
suis plus important que toi.

Super l'égocentrisme quoi...

En fait, il me semble que Cédric avait commencé un truc pas mal du tout
avec des onglets où tout était déjà chargé d'avance.
Et l'usage que j'ai en formation pour distinguer la page d'édition du contenu d'un article et "l'autre", c'est de parler de celle qui permet de modifier les "propriétés" de l'article.
Du coup, ne serait-ce pas 3 écrans/onglets qu'il faudrait :
- Prévisualisation (l'actuel écran y mélangeant les propriétés)
- Propriétés
- Édition

Mes 2 sous.

5

Je me demande juste s'il est judicieux de faire des ajustements
préventifs si ça doit encore bouger plus tard. Les utilisateurs n'aimant
pas trop les changement fréquents... Évidemment, si le chantier de
l'ergonomie, c'est pour dans 10ans, ça vaut surement le coup de faire
ces modifs :slight_smile:

Je me pose souvent la même question, oui oui.

Mais vu que ça traîne depuis un baille, voilà pourquoi je proposais un truc rapide et qui ne change pas grand chose fonctionnellement. C'est juste un "échange de blocs" de haut en bas.

- plutôt pas d'idée précise et en fonction des bonnes volontés ?

Je crois que pour l'instant c'est toujours ce point. :slight_smile:

6

C'est possible, oui. Mais ça c'est un changement complet d'interface. HORS SUJET. 0. :smiley:

7

En fait, il me semble que Cédric avait commencé un truc pas mal du tout
avec des onglets où tout était déjà chargé d'avance.

Du coup, ne serait-ce pas 3 écrans/onglets qu'il faudrait :
- Prévisualisation (l'actuel écran y mélangeant les propriétés)
- Propriétés
- Édition

Oui ça correspond parfaitement aux 3 aspects d'un objet qui a un contenu éditorial.

Il serait par contre péniblement contreproductif de repousser les propriétés
loin dans le pied de la page,
car on a autant de raison de vouloir y accéder qu'à la prévisu du contenu.

JLuc

8

* JLuc tapuscrivait, le 30/09/2012 15:12:

Il serait par contre péniblement contreproductif de repousser les
propriétés
loin dans le pied de la page,
car on a autant de raison de vouloir y accéder qu'à la prévisu du contenu.

+1

9

Bonjour,

personnellement, j'apprécie justement qu'ils apparaissent *en haut* ... parce que le travail de rédaction est ainsi organisé chez moi :
1 - écrire un nouvel article, on tape ça bien, propre, net, sans bavure (et après on n'en parle plus)
2 - on valide et la page suivante nous montre justement *en haut* qu'il FAUT (c'est comme ça chez moi) ajouter quelques mots-clés (quasi rédactionnel pour certains)
3 - il y a aussi des chargés de publication qui ok vérifie l'orthographe et la grammaire, mais surtout s'assure rapidement que tous les mots clés importants soient en place.

Je vois justement ces mots-clés (ça marche aussi pour les auteurs) comme des éléments qui chapeautent le contenu. Un article sans auteur c'est comme une lettre anonyme, on n'aime pas ça. On met bien la rubrique en haut, c'est bien pour situer, contextualiser l'objet, non ?

mes 2 sous.

10

Ciao

En effet je ne suis pas sur que ce soit une bonne idée, car on inverse
le problème.
Si cela est mis en place alors, on aura plus tard "Un certain nombre
de personnes sont d'accord sur le sujet " c'est à dire que ce n'est
pas intuitif/pratique/... d'avoir ces propriété apres le contenu.

L'idée des onglets ou autre approche d'ergonomie est à creuser,
autrement ce ne sera qu'un palliatif provisoire insatisfaisant.

Km

11

Hello,
et si le vrai pb de l'admin c'était l'orientation ? Les écrans sont beaucoup plus larges que hauts. Pourquoi ne pas avoir un système de panneaux latéraux qui permettrait d'avoir le formulaire d'édition de l'article en entier dans sa hauteur ?
Corrobori

----- Mail original -----

12

Ça peut être une bonne idée à condition de rester "responsive" car si
les écrans des *ordinateurs* sont plus larges que hauts, ce n'est pas
toujours le cas des *fenêtres* (les miennes font environ 800 de large
par exemple), ni des autres appareils (tablettes & co).