Re: bug date publication
Cédric Morin <cedric.morin <at> yterium.com>
2012-08-05 21:38:27 GMT
Le 5 août 2012 à 23:01, marcel a écrit :
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.
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
- pourquoi ce mode de saisie conventionnel ne fonctionne-t-il pas bien ici (ou induit-il en erreur) ?
- doit-on changer ce fonctionnement par défaut et l'adapter à ce que l'utilisateur attend (pour le moment je crois que tu es le seul à faire ce retour, mais peut-être d'autres ont-ils eu la même impression sans en faire part 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 :
- doit-on les supprimer et revenir à une navigation plus conventionnelle dans ce type d'aide à la saisie (mois precedent/suivant via fleches) ?
- doit-on profiter de leur présence pour, comme tu attendais en les voyant, faciliter la saisie par changement de mois/année au moyen de ces select.
Mais dans ce dernier cas la question qui se pose est de savoir si ces select doivent rester synchronisés avec le champ de saisie, ou avec le déplacement dans le mini-calendrier (ie si je me déplace au mois précédent via la petite flèche, est-ce que ça change aussi la valeur dans le select, et donc dans la saisie ou ça ne change pas sa valeur) ? Cela veut dire aussi qu'on ne peut se déplacer rapidement dans les dates sans que cela modifie aussi la valeur du champ de saisie. On perd cette séparation entre la valeur du champ de saisie et l'aide à la selection qu'est le mini-calendrier, mais peut-être celle-ci n'a-t-elle aucun sens en fait ?
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
<div>
<br><div>
<div>Le 5 août 2012 à 23:01, marcel a écrit :</div>
<br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span">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.<br>Cela me semble assez parlant.</span></blockquote>
</div>
<br><div>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.</div>
<div>Réaction de développeur, que l'on doit constamment surveiller. Mais chassez le naturel...</div>
<div>Tu fais donc très bien de souligner ce point.</div>
<div><br></div>
<div>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.</div>
<div>Donc les questions qui se posent sont ici</div>
<div>- pourquoi ce mode de saisie conventionnel ne fonctionne-t-il pas bien ici (ou induit-il en erreur) ?</div>
<div>- doit-on changer ce fonctionnement par défaut et l'adapter à ce que l'utilisateur attend (pour le moment je crois que tu es le seul à faire ce retour, mais peut-être d'autres ont-ils eu la même impression sans en faire part ici) ?</div>
<div><br></div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>Du coup je me demande :</div>
<div>- doit-on les supprimer et revenir à une navigation plus conventionnelle dans ce type d'aide à la saisie (mois precedent/suivant via fleches) ?</div>
<div>- doit-on profiter de leur présence pour, comme tu attendais en les voyant, faciliter la saisie par changement de mois/année au moyen de ces select. </div>
<div>Mais dans ce dernier cas la question qui se pose est de savoir si ces select doivent rester synchronisés avec le champ de saisie, ou avec le déplacement dans le mini-calendrier (ie si je me déplace au mois précédent via la petite flèche, est-ce que ça change aussi la valeur dans le select, et donc dans la saisie ou ça ne change pas sa valeur) ? Cela veut dire aussi qu'on ne peut se déplacer rapidement dans les dates sans que cela modifie aussi la valeur du champ de saisie. On perd cette séparation entre la valeur du champ de saisie et l'aide à la selection qu'est le mini-calendrier, mais peut-être celle-ci n'a-t-elle aucun sens en fait ?</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>Comme quoi une petite question peut en entraîner beaucoup d'autres...</div>
<div><br></div>
<div>Cédric</div>
</div>
RSS Feed