Bonjour,
Un chtit problème constaté sur spip 3.0.4 ce jour :
Si on modifie simplement le mois de publication d'une contrib sans changer le jour, la date de publication n'est absolument pas changée.
Cela semble dire que le choix du menu déroulant ne soit pas utilisé comme élément de comparaison à l'original au moment de la validation, non ?
@+
Philippe
Salut,
tu parles de la date de publication de l'article sur un article publié :
?exec=article&id_article=1
Changer
remplacer le 8 par un 9 de 05/08/12
Changer
Si oui, je ne reproduis pas sur grml.eu .
Non, je ne parle pas de remplacer la valeur de mois mais de choisir un mois différent dans le sélecteur de mois, action qui n'entraine pas directement de changement dans la valeur correspondante du champs, ce qui me semble une anomalie ergonomique.
@+
Philippe
Ah oui ok.
Mais ces deux sélecteurs ne sont que des éléments de *navigation* interne au datepicker de jQueryUI. Ce ne sont pas des boutons ni des liens, il n'y a qu'un clic sur une date qui modifie le champ.
D'ailleurs, si on est sur le 31 janvier, et qu'on passe en février, ça n'aurait aucun sens de changer la valeur du champ. 
ben...
Déjà sur le "aucun sens", je trouve l'argument un peu "limite"...
On sait bien que les manips de dates de publications sont souvent utilisées à différents usages empiriques du CMS, mais bon...
Ne serait-ce que pour réordonner rapidement une rubrique d'actus...
Tout ce que tu dis c'est que le datepicker de jQueryUI est malfoutu : on devrait pouvoir y changer tout élément de date indépendamment des autres pour que l'application soit complète.
Les "subtilités" décrites entre choix "de navigation" et "choix effectif" des valeurs passant forcément au-dessus de la tête de l'utilisateur lamba que je suis, faisant cette remarque.
Bonne continuation.
Merci pour ta réponse.
@+
Philippe
Peut-être n'as-tu pas saisi la subtilité de ma phrase : si on est sur le 31 janvier, et qu'on passe en février, ça n'a *effectivement* aucun sens de changer le mois. À moins que tu ais beaucoup d'article à dater du 31 février, ce dont je doute.
Peut-être n'as-tu pas de ton côté compris la simplicité de mon constat : on est le 5 août, et si je veux juste reculer la date d'un article d'un mois, au lieu de simplement changer le mois de l'article, je dois absolument cliquer aussi sur un jour, même si ça n'a pas d'importance.
Je n'attendais pas vraiment que tu cherches à dévier sur la gestion des erreurs de date que la finalisation d'une application calendaire de qualité standard suppose.
Je comprend peut-être tes réponses de travers, mais ce qu'elles suggèrent c'est qu'à une simple remarque d'utilisateur sur une fonction déterminée non-finie, la première réaction reçue c'est préconiser à l'utilisateur en question de modifier son comportement.
Cela me semble assez parlant.
@+
Philippe
Je suis d’accord avec toi sur ce (mauvais) reflexe qu’on a parfois (trop souvent ?) d’expliquer pourquoi c’est comme ça au lieu d’être à l’écoute de la réaction d’un utilisateur devant un élément d’interface qui lui pose problème, ce qui suggère un défaut ergonomique.
Réaction de développeur, que l’on doit constamment surveiller. Mais chassez le naturel…
Tu fais donc très bien de souligner ce point.
Pour revenir au fond de ta remarque, le fonctionnement du selecteur de date utilisé dans le changement de date de publication est pourtant assez conventionnel : on est dans un champ de date, on clic sur l’icone du calendrier pour le voir s’afficher, on va à la (nouvelle) date que l’on veut saisir, et on clic dessus. Cette dernière action a pour effet de changer la valeur date dans le champ de saisie, contrairement à toutes les autres actions intermédiaires.
Donc les questions qui se posent sont ici
En réfléchissant un peu plus, je me dis que ce sont peut-être la présence des 2 select de mois/année qui induisent ici en erreur. Leur présence dans un mini-calendrier est peu conventionnelle, et ils suggèrent plutôt une action de choix dans la saisie plutôt qu’une action de navigation dans le calendrier. Le but de mettre ces 2 select était de pouvoir se déplacer rapidement à une date éloignée via le mini-calendrier. Mais peut-être sont-ils contre-productif du point de vue de la compréhension de l’interface de saisie.
Du coup je me demande :
Peut-être qu’au final, le plus simple et plus compréhensible serait (en tout cas ici), que tout déplacement dans le mini-calendrier modifie la date saisie (que l’on change de mois via une fleche, un select…), auquel cas il faudrait en supplément 1 bouton de validation dans le mini-calendrier (si on ne clic pas dans une date pour valider, il faut une autre action « évidente » car tout utilisateur ne pensera pas à cliquer en dehors du calendrier pour signifier qu’il a fini). L’inconvénient de ce mode de fonctionnement est qu’on perd tout de suite la visualisation de la date qui était actuellement sélectionnée, ce qu’il faut donc prévoir de rétablir d’une autre façon.
Comme quoi une petite question peut en entraîner beaucoup d’autres…
Cédric
Salut,
Ton analyse est complète, rien à dire.
- doit-on les supprimer et revenir à une navigation plus conventionnelle dans ce type d'aide à la saisie (mois precedent/suivant via fleches) ?
Je dirais oui, pour éviter et les confusions et l'usine à gaz. Cela fait un bail que j'utilise spip et modifie des dates, et sans pour autant me poser en modèle, le comportement m'a franchement déconcerté (je m'y suis repris par trois fois avant de comprendre que le changement de mois n'avait aucun effet en soi). Le système on navigue, on selectionne la date, on valide est beaucoup plus clair d'utilisation, même si c'est plus long. Ou alors il s'agit d'un choix "tous sélecteurs déroulants" ou "calendrier", en tout cas le mélange n'est pas convaincant...
Cela reste avis personnel, cela étant.
@+
Philippe
Gnagnagna monsieur Grands Chevaux.
Lors de ta remarque tu ne préconisais point de revenir à un truc plus simple, mais que les <select> aient un impact sur le choix de la date, ce qui à mon avis est justement une mauvaise idée ergonomique, du fait des questions en plus que ça pose pour résoudre les problèmes de date inexistante.
Pour qu'il n'y ait plus ces <select> confus MAIS que l'on puisse quand même naviguer rapidement dans tous les cas possibles, je pense que :
1) il ne faut que des *liens* de navigation
2) mais qu'il y en ait plus : pour les mois et pour les années séparément
Autrement dit :
< Février > < 2012 >
Avec des titles *explicites* sur les liens de navigation : "Mois précédent/suivant" et "Année précédent/suivante"
Ainsi, on pourrait naviguer de mois en mois comme actuellement, mais aussi d'année en année. Et ce sans rien changer au champ tant qu'on a pas cliqué sur une date.
Qu'en penses-tu ?
SPIP 3 est assez nouveau pour nos traducteurs/auteurs. J'ai déjà dû aider un auteur qui voulait changer la date, a écrit un chiffre pour l'année qui ne va pas (0012) et s'est retrouvé devant une page blanche. C'est sûr que ce sélecteur n'est pas le plus commode que j'ai jamais vu.
Ceci dit, je pense que cela suffit de s'y habituer. (Je suis bcp. plus touché par le changement de config de langue dont j'ai écrit hier.)
Paolo
Gnagnagna,
Oui. Enfin peut-être
@+
Philippe
* marcel tapuscrivait, le 05/08/2012 15:39:
Je viens de tomber sur un datepicker qui a une interface très pratique pour changer de mois ou d'année :
http://stefangabos.ro/jquery/zebra-datepicker/
Un clic sur August, 2012 affiche 2012 et la liste des 12 mois
Un clic au même endroit (donc sur 2012) affiche 2005-2016 et la liste des 12 années en question.
J'ai trouvé ça très ergonomique et intuitif.
Hop,