Terminologie champ "hors service" #18

Closed
opened 2 years ago by maieul · 9 comments
maieul commented 2 years ago
Collaborator
There is no content yet.
Poster
Collaborator

Reflechir à une terminologie generique, cf discussion il y a longtemps sur la zone

Reflechir à une terminologie generique, cf discussion il y a longtemps sur la zone
rastapopoulos changed title from Terminologie champ "hors service2 to Terminologie champ "hors service" 2 years ago

De qui de quoi il s'agit, un peu plus de description ? :)

De qui de quoi il s'agit, un peu plus de description ? :)
Poster
Collaborator

Oui, tu as raison de me relancer.

En gros c'est la question d'offrir la possibilité de désactiver des champs : ils ne seraient plus affichés ni postés, mais les réponses qui auraient ces champs en base conserverait les valeurs.

Tu avais fait remarquer lorsque j'avais ouvert la discussion sur la zone qu'il fallait trouver, en dehors de la question ergonomique, une terminologie generique pour "un objet qui ne sert plus, mais qui n'est pas à effacer pour autant".

Le ticket vise à recenser les propositions, pour ce mettre d'accord.

Et en te répondant, je me suis rendu compte qu'en fait, peut être tout simplement "archive" / "archivé" serait le bon terme.

Oui, tu as raison de me relancer. En gros c'est la question d'offrir la possibilité de désactiver des champs : ils ne seraient plus affichés ni postés, mais les réponses qui auraient ces champs en base conserverait les valeurs. Tu avais fait remarquer lorsque j'avais ouvert la discussion sur la zone qu'il fallait trouver, en dehors de la question ergonomique, une terminologie generique pour "un objet qui ne sert plus, mais qui n'est pas à effacer pour autant". Le ticket vise à recenser les propositions, pour ce mettre d'accord. Et en te répondant, je me suis rendu compte qu'en fait, peut être tout simplement "archive" / "archivé" serait le bon terme.

Ah ça y est oui je me souviens de cette discussion. Et je disais que ça valait pour Menus, pour le Noizetier, etc, pas juste pour les saisies. Ya plusieurs plugins qui en théorie devraient tous permettre de désactiver un élément sans le supprimer, pour pas devoir reconfigurer ensuite.

On est sur internet, mettons des liens, il s'agit de cette conversation : https://www.mail-archive.com/spip-zone@rezo.net/msg47620.html

Ah ça y est oui je me souviens de cette discussion. Et je disais que ça valait pour Menus, pour le Noizetier, etc, pas juste pour les saisies. Ya plusieurs plugins qui en théorie devraient tous permettre de désactiver un élément sans le supprimer, pour pas devoir reconfigurer ensuite. On est sur internet, mettons des liens, il s'agit de cette conversation : https://www.mail-archive.com/spip-zone@rezo.net/msg47620.html
Poster
Collaborator

yep, voilà.

yep, voilà.

Quand on compare avec ce qui existe, notamment dans les autres CMS, ce qui est le plus utilisé semble être "Enable / Disable" qui est neutre et correspond à n'importe quel élément (d'un menu, d'un bloc, etc) qu'on veut à loisir utiliser ou pas de manière binaire sans le supprimer.

Mais le problème c'est que spécifiquement pour les formulaires le mot "disable" a déjà un autre sens, et est déjà utilisé.

Donc pour l'instant, autre que "disable", la terminologie la plus courante, déjà utilisée donc déjà connue, c'est : "Publier / Dépublier". En ergonomie il faut en priorité utiliser un terme déjà connu quand ça correspond au plus proche de la fonctionnalité, le moins possible en introduire des nouveaux.

Que ce soit pour Saisies, Menus, Noisettes… est-ce qu'on considère que par défaut c'est publié, si ya rien (ce qui permet en plus d'être compatible avec l'ancien), et que c'est plutôt un attribut qui indique que c'est DÉpublié ? Ou bien même si c'est à priori toujours binaire, on prévoit le fait qu'un jour on peut avoir d'autres idées, et donc on fait plutôt un attribut "statut" qui peut prendre n'importe quelles valeurs (mais qui de base serait "actif" et "inactif" ou "publie" et "depublie") ?

Pour les saisies au niveau technique je mettrais ça dans le tableau d'options, et donc ça serait soit :

'options' => array(
	'depublie' => true | 'on' | 'oui'
)

soit :

'options' => array(
	'statut' => 'inactif' | 'depublie'
)

Et au niveau interface, comme dit dans le fil email, ça ne doit pas être caché dans les tréfonds des onglets, pour moi ça doit vraiment être ajouté de base dans les boutons d'actions immédiats qu'on voit pour chaque saisie, au même endroit que Duppliquer, Supprimer, etc. (Et du coup comme ya les deux à côté, on comprend très bien la différence entre "Supprimer" et "Dépublier").

Quand on compare avec ce qui existe, notamment dans les autres CMS, ce qui est le plus utilisé semble être "Enable / Disable" qui est neutre et correspond à n'importe quel élément (d'un menu, d'un bloc, etc) qu'on veut à loisir utiliser ou pas de manière binaire sans le supprimer. Mais le problème c'est que *spécifiquement pour les formulaires* le mot "disable" a déjà un autre sens, et est déjà utilisé. Donc pour l'instant, autre que "disable", la terminologie la plus courante, *déjà utilisée* donc déjà connue, c'est : "Publier / Dépublier". En ergonomie il faut en priorité utiliser un terme déjà connu quand ça correspond au plus proche de la fonctionnalité, le moins possible en introduire des nouveaux. Que ce soit pour Saisies, Menus, Noisettes… est-ce qu'on considère que par défaut c'est publié, si ya rien (ce qui permet en plus d'être compatible avec l'ancien), et que c'est plutôt un attribut qui indique que c'est DÉpublié ? Ou bien même si c'est à priori toujours binaire, on prévoit le fait qu'un jour on peut avoir d'autres idées, et donc on fait plutôt un attribut "statut" qui peut prendre n'importe quelles valeurs (mais qui de base serait "actif" et "inactif" ou "publie" et "depublie") ? Pour les saisies au niveau technique je mettrais ça dans le tableau d'options, et donc ça serait soit : ``` php 'options' => array( 'depublie' => true | 'on' | 'oui'… ) ``` soit : ``` php 'options' => array( 'statut' => 'inactif' | 'depublie' ) ``` Et au niveau interface, comme dit dans le fil email, ça ne doit pas être caché dans les tréfonds des onglets, pour moi ça doit vraiment être ajouté de base dans les boutons d'actions *immédiats* qu'on voit pour chaque saisie, au même endroit que Duppliquer, Supprimer, etc. (Et du coup comme ya les deux à côté, on comprend *très bien* la différence entre "Supprimer" et "Dépublier").
Poster
Collaborator
  1. Niveau interface, je suis totalement d'accord avec toi
  2. Il me semble qu'il faut ne pas casser l'existant, et donc par défaut c'est publié/actif si on ne précise pas le statut
  3. Sur le vocabulaire, SPIp n'a pas de dépublié, mais uniquement du "publié" + d'autre statuts. Du coup je me demande si Hors ligne serait pas plus pertinent que depublié qui rapproche trop d'un objet editorial alors que ce n'est pas vraiment un objet
1. Niveau interface, je suis totalement d'accord avec toi 2. Il me semble qu'il faut ne pas casser l'existant, et donc par défaut c'est publié/actif si on ne précise pas le statut 3. Sur le vocabulaire, SPIp n'a pas de dépublié, mais uniquement du "publié" + d'autre statuts. Du coup je me demande si **Hors ligne** serait pas plus pertinent que **depublié** qui rapproche trop d'un objet editorial alors que ce n'est pas vraiment un objet
Owner

Moi je pense qu'on s'en fiche que ce soit technique ou pas un objet éditorial, les utilisateurs ils en savent rien du tout que les saisies c'est un tableau sérialisé ou un objet éditorial, alors que les entrées de Menus ou les noisettes là c'est vraiment dans des tables (mais ça pourrait tout autant être des tableaux sérialisés aussi).

Ce qui compte c'est l'action pour les gens et cette action est bien la même que pour tout autre contenu éditorial : parfois on veut que l'élément soit publié (= visible dans le site) parfois dépublié (= pas visible dans le site), et cela sans rien supprimer. C'est donc bien exactement pareil que enlever le statut "publie" d'un article pour le remettre en brouillon si on ne veut plus qu'il sorte publiquement.

Donc pour l'instant je maintiens mon point de vue : "Dépublier" est très bien et correspond au même champ lexical que le reste des contenus du site (la seule différence étant que là c'est publié par défaut, et l'action est de dépublié, un peu l'inverse des autres contenus, mais le champ lexical est le même).

Moi je pense qu'on s'en fiche que ce soit *technique* ou pas un objet éditorial, les utilisateurs ils en savent rien du tout que les saisies c'est un tableau sérialisé ou un objet éditorial, alors que les entrées de Menus ou les noisettes là c'est vraiment dans des tables (mais ça pourrait tout autant être des tableaux sérialisés aussi). Ce qui compte c'est l'action pour les gens et cette action est bien la même que pour tout autre contenu éditorial : parfois on veut que l'élément soit publié (= visible dans le site) parfois dépublié (= pas visible dans le site), et cela sans rien supprimer. C'est donc bien exactement pareil que enlever le statut "publie" d'un article pour le remettre en brouillon si on ne veut plus qu'il sorte publiquement. Donc pour l'instant je maintiens mon point de vue : "Dépublier" est très bien et correspond au même champ lexical que le reste des contenus du site (la seule différence étant que là c'est publié par défaut, et l'action est de dépublié, un peu l'inverse des autres contenus, mais le champ lexical est le même).

La suite sera au bon endroit dans le plugin Saisies : spip-contrib-extensions/saisies#174

La suite sera au bon endroit dans le plugin Saisies : https://git.spip.net/spip-contrib-extensions/saisies/issues/174
rastapopoulos closed this issue 4 months ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.