Amélioration de la zone de changement de statut

Bonjour,

Actuellement, le bouton changer n’apparait qu’après la sélection d’un statut différent de l’actuel.
Et ce bouton apparait en dessous.

Je constate en formation que beaucoup de gens oublient de cliquer sur changer.

Je propose le changement suivant :

  • afficher le bouton [Changer] en style désactivé dès le chargement de la page (classe .btn_desactive)
  • l’afficher à droite de la liste et non en dessous

Voici ce que ça pourrait donner :
image

Et actif :
image

Et voici le code que j’ai mis dans spip/spip: Dépôt officiel du core SPIP * Anciennement présent sur svn://trac.rezo.net/spip * Les plugins-dist faisant partie de la distribution SPIP sont présents dans https://git.spip.net/SPIP/[nom du plugin dist] - prive/formulaires/instituer_objet.html at master - spip - SPIP on GIT pour obtenir ce résultat.
C’est assez crade avec les styles inline.
Mais ça permet de tester.

<div class="instituer_objet">
	[(#ENV{_publiable}|non|et{#ENV{statut}|=={prepa}|oui})
	<p class="small"><:texte_proposer_publication:></p>
	]
	<div class="formulaire_spip formulaire_editer formulaire_instituer[ formulaire_#FORM formulaire_#FORM-(#ENV{_objet})][ formulaire_#FORM-#ENV{_objet}-(#ENV{_id_objet})]">
		[<p class="reponse_formulaire reponse_formulaire_ok" role="status">(#ENV**{message_ok})</p>]
		[<p class="reponse_formulaire reponse_formulaire_erreur" role="alert">(#ENV*{message_erreur})</p>]
		[(#ENV{editable})
		<form method='post' action='#ENV{action}'><div>
			[(#REM) declarer les hidden qui declencheront le service du formulaire
			parametre : url d'action ]
			#ACTION_FORMULAIRE
		]
			#SET{name,statut}#SET{obli,'obligatoire'}#SET{erreurs,#ENV**{erreurs}|table_valeur{#GET{name}}}
			<div class="editer-groupe">
				<div class="editer editer_[(#GET{name})] statut_#ENV{#GET{name}}[ (#GET{obli})][ (#GET{erreurs}|oui)erreur]">
					<label for="formulaire_#FORM-#ENV{_objet}-#ENV{_id_objet}-#GET{name}">[(#ENV{_label}|_T)][(#ENV{_aide}|oui)#AIDER{#ENV{_aide}}]</label>[
					<span class='erreur_message'>(#GET{erreurs})</span>
					]<span class="show" style="display:flex;">
					[(#ENV{editable})
						<span class="gauche"><select style="width:auto;" class="select statut" name="#GET{name}" id="formulaire_#FORM-#ENV{_objet}-#ENV{_id_objet}-#GET{name}">
						[(#ENV{_statuts}|table_valeur{#ENV{#GET{name}}}|non)
							<option value="#ENV{#GET{name}}">&nbsp;&nbsp;&nbsp;#ENV{#GET{name}}</option>
						]
					]
						<BOUCLE_choix(DATA){source table, #ENV{_statuts}}{si #ENV{editable}}>
							<option value="#CLE"[(#ENV{#GET{name}}|=={#CLE}|oui)selected="selected"]
								style="background-image:url([(#CLE|puce_statut{#ENV{_objet}}|extraire_attribut{src})]);">&nbsp;&nbsp;&nbsp;[(#VALEUR|_T)]</option>
						</BOUCLE_choix>
					[(#ENV{editable})
					</select></span>
					<span class="droite" style="padding-left:1em;"><input type='submit' class='btn submit btn_desactive' value='<:bouton_changer:>' /></span>
					]
					[(#ENV{editable}|non)
					<span class="show">
						<span class="statut">[(#ENV{#GET{name}}|puce_statut{#ENV{_objet}})] [(#ENV{_statuts}|table_valeur{#ENV{#GET{name}}}|_T)]</span>
					</span>
					]
				</div>
			</div>
			<!--extra-->
			[(#ENV{editable})
			
		</div></form>
		]
	</div>
</div>
<script type="text/javascript">
	function update_select(statut_default){
		var selected = this.options[this.selectedIndex];
		var boutons = jQuery(this).attr('style',jQuery(selected).attr('style')).closest('form').find('.btn');
		if (selected.value!=statut_default)
			boutons.removeClass('btn_desactive ');
		else
			boutons.addClass('btn_desactive ')
	}
	jQuery(function($){
		$(".formulaire_#FORM .show select")
			.each(function(){update_select.apply(this,['#ENV{#GET{name}}']);})
			.on('change',function(){update_select.apply(this,['#ENV{#GET{name}}']);})
			.on('keyup',function(){update_select.apply(this,['#ENV{#GET{name}}']);});
	});
</script>

Et plus généralement, maintenant qu’on a la classe .btn_desactive je propose de changer tous les comportements de boutons masqués et apparaissant pour valider l’action à visibles et désactivés via la classe .btn_desactive et rendus actifs là où ils étaient rendus visibles.

C’est en particulier le cas pour les boutons d’ajout de mots clefs.

Ah oui, et voici l’apparence du sélecteur déroulé :
image

Et avec dans la CSS :

.infos .formulaire_instituer .statut_publie .show {
background: linear-gradient(90deg, #9dba00, transparent);
}

ça donne un bien meilleur contraste pour le bouton :
Inactif :
image

Actif :
image

Je suis plutôt d’accord pour dire que ce choix de boutons masqués (là et ailleurs) n’est pas une bonne idée ergonomique. Et que trop de gens oublient de valider ensuite.

Une autre solution serait soit que le form s’autovalide soit que ce ne soit plus un select mais un menu contenant des boutons d’actions mais… c’était il me semble parfaitement voulu que ça reste en deux clics, pour forcer à réfléchir car changer le statut est une action importante à ne pas faire à la légère (donc pas forcément en un clic sans faire exprès).

Du coup en restant bien en deux clics, je suis assez d’accord pour voir le bouton mais en désactivé.

Ticket puis PR plutôt pour débattre de ça plutôt qu’ici ?

1 « J'aime »

En fait, j’ai fait ça ici plutôt qu’en PR pour 2 raisons :

  • le copié/collé d’image pour mettre directement, c’est super pratique
  • j’ai fait ça version crade parce que je ne sais pas bien quel balisage utiliser dans l’admin, et si @tcharlss pouvait faire ça bien, ce serait super :wink:

Je suis pas trop fan du bouton désactivé.
Je préfèrerais aucun bouton et une validation automatique après la réponse à une question du style « êtes-vous sur… ». Après je ne sais pas si c’est accessible ou pas.

1 « J'aime »

Ça, c’est ce qu’on avait avant, avec SPIP 2.1 : une boite de dialogue navigateur.

voir Evolution #4182: Changer le statut par simple sélection dans la liste sans avoir à cliquer sur [Changer] - SPIP - SPIP Core (Forge de développement)

Allez un 4ème avis un peu différent des autres, sinon on s’ennuierait :slight_smile:

Je trouve aussi préférable de mettre le bouton sur le côté s’il y a assez de place, moins de risque de ne pas y faire attention. À mon avis ça résoudrait pas mal de cas où les gens oublient de cliquer dessus.

En revanche j’ai un doute sur la nécessité de l’afficher en permanence, même si désactivé : tant qu’on a pas cliqué, il n’y a rien à changer, ça fait du bruit pour rien.

Enfin, s’il fallait le garder tout le temps, quelques remarques sur l’affichage et les variantes :

  • la différence ne semble pas assez marquée pour les boutons désactivés. Là c’est une simple opacité baissée, mais ça semble pas suffisant (c’est copié de bootstrap). Au début j’avais mis un filter: grayscale(100%), à rétablir ?
  • Sinon pour ces cas là avec un fond de couleur, il y a une variante .btn_inverse. Combinée à .btn_secondaire ça passerait mieux peut-être
  • Enfin, pas de dégradé à cet endroit là svp :stuck_out_tongue:
1 « J'aime »

Ça donne ça :
image

(au passage, le message : Le statut a déjà été modifié apparait parce que j’ai rechargé la page, et que l’action de changement de statut est rejouée, cf Anomalie #3556: Message "Le statut a déjà été modifié" sur actualisation de la page après avoir modifié le statut. - SPIP - SPIP Core (Forge de développement)).

Et quand le bouton est actif :
image

Sinon, 100% d’accord sur le filtrer gris ! Ce serait beaucoup plus clair.

Sur la notion de bruit pour rien tant que pas cliquable, je ne sais pas.
Est-ce qu’il y a des études d’ergonomie sur le sujet ?

Ceci semble indiquer que les boutons doivent rester visibles : 15 bonnes pratiques UX pour le design de vos formulaires de contact

Et j’ai testé avec

	if (selected.value!=statut_default)
		boutons.removeClass('btn_desactive btn_inverse');
	else
		boutons.addClass('btn_desactive btn_inverse')

L’effet est sympa de passer du bouton désactivé vert pale au bouton actif bleu.

Et en lui donnant le focus, c’est encore plus marquant :

		boutons.removeClass('btn_desactive btn_inverse').focus();

image

Eh ben un cinquième avis, qui va être un peu cinglant, désolée.
j’en discutais hier avec une amie qui est graphiste et qui a participé à la SPIP party de Toulouse à tenter d’élaborer une réflexion naïve sur l’espace privé.
On ne parlait pas directement de SPIP mais du manque de prise en compte en amont de l’idée même de concept.
Ah oui donc, c’est quoi conceptualiser une interface ?
Hé bein c’est ne pas s’attacher à sa forme mais essayer de comprendre son usage et ce qui est nécessaire, cela permet d’être créatif et d’inventer des interfaces qui ne sont pas forcément conformés à nos habitudes (qui en général nous empêche de voir plus loin pour nous rassurer en restant à ce que l’on connait).
C’est là qu’on parle de design …
Du coup, franchement, je ne vois pas l’intérêt du bouton à droite du select ni même cette présentation.
Comment se questionner sur ce concept ? parce que si on se pose la question de « à quoi ça sert » « où ça sert » « combien de fois ça sert » etc on voit bien qu’il y a différentes façon de valider un statut pratiquement sur tout objet SPIP avec en option différents statuts (pas que publié en ligne, ça peut être aussi le statut qu’on veut, comme « n’existe plus sur le site source »)

Ici on a plusieurs codes couleurs pour indiquer le statut : vert si le statut est valide ou rouge refusé. On a une dexuième information redondante (donc à priori inutile) sur ce statut qui est la puce carrée devant le texte, verte ou rouge etc qui en plus se télescope avec le statut précédent qui occupe le background.
Tiens, et c’est aussi une autre façon de changer le statut avec la même puce carré qui permet de changer au survol quand on va sur les listes … Ne faudrait-il pas homogénéiser cela ?

Mais aussi, si l’internaute oublie qu’iel peut changer ou doit valider le statut, posons nous la question si il n’y a pas un souci d’ergonomie plus profond sur les actions possible dans le site ( User d’un verbe d’action comme « Changer le statut » pour conceptualiser et inscrire une action sur l’ensemble du site ?). Ici le présent utilisé au-dessus « Cet article est : » questionne sur la possibilité d’une action de l’internaute, la phrase est tronquée et se poursuit dans un select, c’est pas un peu étrange ?

En bref, pas facile de critiquer sans proposer, mais j’invite juste à avoir une réflexion collective sur le concept d’interface en soulevant ces points plutôt que de garder à priori les mêmes schémas pas bien explicites ou d’en renforcer la difficulté d’appréhension.

: + 1

+1 à quoi ? (tu peux sélectionner un texte et cliquer sur le répondre juste en dessous du texte) (tu peux aussi répondre précisément à un post plutôt que le répondre tout en bas)

Et bien c’est au message de @touti que je plussoie.

Et cliquer sur le flèche répondre en bas d’un message ne fait pas ce que j’attends, pas grave.

Et aurais-tu des propositions ?

Du coup, je vous propose ces deux images pour vous donner une idée, j’ai essayé de ne pas rompre avec les habitudes mais j’ai essayé de suivre le raisonnement que j’expose plus haut

Et j’ajoute l’interface actuelle visible sur contrib
https://contrib.spip.net/ecrire/?exec=article&id_article=5351

3 « J'aime »

Je suis d’accord avec ces constats :

  • une partie des gens oublient de valider
  • le mélange visuel au même endroit entre l’état actuel et le futur état voulu est… carrément pas bon ergonomiquement (en disant ça gentil, en fait c’est plutôt : c’est horrible)
  • il y a en partie une incohérence entre la manière de faire cette action dans la page du contenu et dans les listes

Une réflexion sur le quoi et comment :

  • Il s’agit de changer le statut d’un contenu. C’est un élément pour le moins très important, et qu’il ne faut pas faire à la légère : ça conditionne dans de nombreux cas sa visibilité en ligne, ou autres « droits » du même genre (ça va être envoyé par mail ou ceci cela). Bref c’est vraiment une action forte.
  • Je comprends donc totalement la réflexion, et qui n’a pas du tout été fait « parce que c’est l’habitude », mais bien par choix ergonomique, de dire : attention, faut pas le faire juste en cliquant sans faire exprès, c’est bien volontairement qu’il y a besoin de deux clics.
  • MAIS… ce choix et totalement en contradiction avec les puces de changement rapide dans tous les listes ! Qui une fois accepté une première fois, permettent de changer ce même statut en un seul clic et pour plein de contenus d’un coup même « sans faire exprès » car c’est au survol que ça s’ouvre, et donc ya aucune action volontaire, si on clique sans faire exprès sur un truc qui s’est ouvert au survol, paf.
  • Ajoutons aussi, que sur la page dédié d’un contenu, on y est donc allé déjà par un clic, il y a déjà eu une première action volontaire de dire « je me rends sur l’admin dédié à ce contenu ». Ce n’est donc plus forcément aussi important que le changement de statut soit en deux clics sur cette page, il me semble.

Il me semble donc :

  • plus important que surtout dans les listes on ne puisse pas changer le statut en un seul clic non voulu, et que donc ça ne soit plus au survol, mais bien avec 1) un premier clic sur la puce qui ouvre la boite pour changer 2) un deuxième clic pour changer
  • moins important d’avoir deux clics dans les pages dédiées, mais ça pourrait rester deux clics aussi (mais pas trois, là ça ferait vraiment trop et ta dernière proposition fait trois clics il me semble : bouton modifier => changer dans une liste => bouton valider)

C’est pas mal cette idée d’un bouton « Modifier » comme pour l’URL ou les dates. Et du coup comme on clique déjà volontairement dessus, quand ça ouvre la liste pour changer, là dans la liste un seul clic suffirait.

Réflexion tout de même sur le long terme/l’extensibilité : le fait d’avoir un select avec un bouton à valider = un formulaire classique, pour ce « formulaire_instituer », peut être utilise à l’extension. En effet, cela permet d’imaginer que pour certains contenus et pour certains statuts, quand on les choisit, ça ouvre/ajoute d’autres champs qui seraient propres à ces statuts/contenus. Par exemple un statut « Refusé » pourrait parfaitement obliger à remplir un champ « Raison » qui apparaitrait en dessous (exemple de fonctionnalité que pourrait très bien ajouter un plugin hein). Et donc si le statut se change directement, sans validation classique, impossible d’étendre avec ce genre de comportements en plus.

Le 3 juin 2021 à 15:10, RastaPopoulos via Discuter de SPIP <noreply@discuter.spip.net> a écrit :

  • plus important que surtout dans les listes on ne puisse pas changer le statut en un seul clic non voulu, et que donc ça ne soit plus au survol, mais bien avec 1) un premier clic sur la puce qui ouvre la boite pour changer 2) un deuxième clic pour changer

Le problème que ça introduit, c’est que tu ne peux plus découvrir qu’il y a cette possibilité si on ne le dit pas.

Arnaud

@arno t’arrêtes de répondre avec 12 adresses :stuck_out_tongue: (faut fusionner celui là dans l’autre aussi ?)

Le problème que ça introduit, c’est que tu ne peux plus découvrir qu’il y a cette possibilité si on ne le dit pas.

Comme… 100% des choses en mobile first/touch ? Il me semble qu’aucune fonctionnalité au monde ne devrait se découvrir juste par le survol, surtout de nos jours avec les tactiles. Ça ne permet pas de le rendre accessible et compréhensible à vraiment tout le monde.

Donc là ce que je disais est juste une direction vers laquelle je trouve qu’il faudrait aller, mais oui clairement : ça signifie qu’il va falloir réfléchir à comment rendre ça compréhensible au max de gens, sans survol. :slight_smile: