J’ai commencé à bosser sur https://framagit.org/kresusapp/kresus/issues/776 et j’en ai profité pour tester plusieurs nouveaux affichages pour les opérations et voulais vous en parler pour voir ce que vous en pensez, et éventuellement revoir + globalement l’organisation de cette liste :
La version basique (vis à vis du ticket), mais j’ai déplacé la colonne « Type » à droite :
Pareil mais avec le type sous le montant, non éditable (la modale suffirait peut-être, on modifie rarement le type ?). C’est juste un essai rapide donc le texte est tronqué, faites appel à votre imagination :
Salut ! Merci d’avoir commencé ce travail très utile.
Dans les deux premières vues, je suis un peu décontenancé par le jour affiché à côté de chaque opération ; on se demande à première vue ce qu’indique ce nombre, ce n’est pas évident du premier coup d’œil. Par élimination c’est forcément le jour, mais si on doit réfléchir par élimination, c’est qu’on a déjà un peu perdu, nan ?
La vue sur deux lignes avec le jour de la semaine et le numéro de jour me plaît pas mal, vu qu’on gagne en information (quel jour de la semaine). Il y a encore une certaine forme de redondance à avoir le même jour / numéro plusieurs fois à la suite (par exemple « Vir nuage douillet » / « vir mr jean claude dusse » / « merbnb » ont le même jour / numéro dans la capture d’écran). Ce n’est pas choquant après réflexion, je pense qu’on pourrait même remettre le nom du mois pour éviter que l’oeil ne doive faire un aller-retour haut/bas (en particulier s’il y a beaucoup de transactions le mois en question).
J’aime bien l’idée de cacher un peu le type, et de ne pas lui mettre un sélecteur dans la vue par défaut. Comme tu le fais remarquer, c’est rare qu’on doive le changer. Par ailleurs la plupart des sites que j’utilise n’affiche pas cette information dans la ligne de base, il faut toujours aller dans les détails pour voir le type de transaction. Ça me paraîtrait cohérent de le cacher nous aussi par défaut, ou de l’afficher en plus petit comme tu le fais, ou de n’afficher qu’un pictogramme, unique par type (dur dur de les différencier par contre).
Une autre idée de vue, qui prendrait encore plus de place, consisterait à regrouper les opérations par jour plutôt que par mois (je crois que N26 le faisait à une époque, ils sont repassés à un regroupement par mois). Cela fait sens, parce qu’en pratique, sauf simulation de « banking temps réel » comme font les nouvelles banques / apps, les opérations ne sont validées que les jours ouvrés des banques (donc du mardi au samedi, par exemple pour ma banque). À tester pour voir, peut-être ?
C’est ce qu’il y a chez ING, donc ça ne me choque pas.
Oui mais regrouper par jour ou autre est assez chiant à faire (à ce niveau là on a uniquement les ids des opérations et chaque composant n’a pas connaissance de la date du précédent) :p.
Et sur deux lignes ça ne me choque plus. On pourrait remettre le mois oui.
Avec ces deux lignes je me demande même si on ne pourrait pas garder le bouton pour ouvrir la modale sur mobile (voire le renommer « Détails » carrément) et virer le long press !
Ça ferait énormément de « groupes » et de perte de place en hauteur du coup, ça me tente pas trop…
Comme @bnjbvr l’a dit, le numéro du jour seul est un peut perturbant dans la vue mobile car on n’a aucune infor sur ce qu’est ce nombre (pour la valeur, on a l’unité). En superposant avec l’icône calendar-o, on devrait pouvoir faire comprendre qu’il s’agit d’un jour. Par contre, ça rendrait incompréhensible l’icône disant que l’opération est budgetisée pour le mois précédent ou suivant.
Et je valide que faire disparaitre le type de la liste n’est en soit pas très grave, voire ajoute en lisibilité.
J’aime pas trop de rajouter du gras sur le libellé, j’aurai plus tendance à augmenter la taille de police pour les informations très importantes: libellé / solde et éventuellement catégorie, et maintenir une police plus petite pour la date et le type.
Pour l’affichage sur 2 lignes, je suis partagé :
d’un part, ça permettrait de faire des colonnes plus étroites (et donc rapprocher l’information pour avoir tout sous les yeux sans devoir traverser l’écran avec les yeux
d’autre part ça réduit la quantité d’information verticale, alors qu’on ne manque pas de place horizontale (en gros, on pourrait montrer plus sur la même surface d’écran)
Est-ce que sur desktop tu ressens un manque d’infos justement ?
Sur mobile perso je suis assez regardant car j’ai moins d’espace, mais étant donné que le label est tronqué la plupart du temps et que c’est un peu gênant, je serais prêt à perdre un peu en vertical pour gagner en lisibilité sur le libellé.
Sur mobile, utiliser deux lignes ne me gène pas car on n’a pas de place horizontale. Sur desktop, par contre, j’ai du mal à voir la valeur ajoutée de tout mettre sur deux lignes. A part à réduire la largeur du tableau (et donc réduire les allez-retour des yeux).
Sur desktop, par contre, j’ai du mal à voir la valeur ajoutée de tout mettre sur deux lignes. A part à réduire la largeur du tableau (et donc réduire les allez-retour des yeux).
Eh bien tu dis un des avantages Et un autre serait d’avoir une interface qui ressemble moins à un tableur excel et serait plus aéré, moins suffoquant.
Je suis pour qu’on le fasse dés que possible, pour ma part. Tentons d’atteindre un consensus : si quelqu’un a des objections majeures justifiées (pas possible de vivre avec un tel changement ; les petits « meh j’aime pas trop » ne sont pas majeurs ni justifiés), qu’iel se fasse entendre d’ici le 12 mars, ou se taise à jamais
Si on choisit de mettre les dates et libellés dans une même colonne, ça impacte l’ordre.
Je ne vois pas d’utilité à ré-ordonner par libellé, est-ce qu’on pourrait donc dire que si on réordonne la première colonne ça se base sur la date et non le libellé ?
Pour les infos secondaires, j’ai vu sur RefactoringUI qu’il était conseillé de plutôt choisir une police + légère que + petite pour les infos secondaires. Et on peut jouer sur la couleur.
Mais on y reviendra, j’expliquerai les choix faits sur les nouvelles maquettes (enfin je ferai peut-être une WIP, c’est aussi simple à prototyper pour moi).
Pour être très clair, ce que je voudrais qu’on implémente serait le regroupement par mois (avec une ligne de « header » pour le mois), et ensuite chaque transaction aurait sa ligne (ou ses deux lignes), pour au moins éviter la répétition du mois et de l’année qui n’apportent que très peu de valeur à la lecture globale.
Pourquoi pas, mais ça me semble encore condenser l’information énormément.
On avait mentionné l’idée de cacher le type de la liste des transactions, ou de ne le faire apparaître que discrètement (avec une icône par ex.), où en-est on de cette idée ?
Si on retire le type, je pense qu’on pourrait garder tout sur une ligne, avec « jeudi 26 [espace] café moxka [etc] » et que ce soit encore assez lisible, quitte à ce que ce soit sur 2 lignes sur mobile.
Idéalement, on retirerait aussi les lignes séparatrices grises entre les transactions, ça rajoute du cloisonnement et de l’espacement vertical pourrait jouer le même rôle de séparation entre les transactions.
Ah oui j’avais juste du mal à comprendre donc je faisais référence à l’image du premier post pour le bloc par mois.
Par contre dans une recherche ça va pas forcément rendre bien (ça va probablement beaucoup répéter le bloc).
Et si on donne la possibilité de ré-ordonner les opérations par autre chose que la date, ça va être un sacré bordel.
Je n’utilise pas les types à vrai dire, mais peut-être que ceux qui utilisent des cartes à débit différé préféreraient le garder ? Ou est-ce que la date future suffit ?
Si on utilise 1 seule ligne, et le jour en textuel (ex: « jeudi ») on va avoir une largeur de colonne variable ou au moins égale au texte le + long (et c’est un peu chiant potentiellement si on ajoute des langues) si on garde une colonne pour la date (si on colle le libellé à la date ce sera très bizarre). Mais sinon ça me va, mais je pense préférer les 2 lignes dans tous les cas (sur mobile ce serait en effet obligatoire)
J’apprécie vraiment les lignes lors de la lecture. On pourrait éventuellement les estomper encore un peu mais les supprimer totalement ça me dérange
Ex. avec une hauteur de ligne de 70px au lieu de 54 et pas de bordure :
Je suis d’accord qu’en gardant l’espacement horizontal tel qu’il est, les lignes de séparation ont leur importance ; mais on aurait aussi ici l’occasion de concentrer un peu ces données, parce que tout afficher avec une largeur énorme n’apporte pas vraiment de valeur supplémentaire (en particulier puisqu’on pense aussi réduire le nombre d’éléments à afficher par défauts). Du coup ça pourrait valoir le coup de tester comme ça aussi ?
pour avancer sur le sujet commençons par lever les questions restantes !
C’est pour moi incompatible avec [Client] UX improvement: select operations table sorting key (#944) · Issues · kresusapp / kresus · GitLab.
Lorsque les opérations sont affichées telles qu’actuellement dans l’ordre chronologique, ça a un sens.
Mais si maintenant on choisit d’implémenter #944 et de réordonner par exemple par montant,
on va avoir une ligne de header possiblement pour chaque opération, et ça portera à confusion d’avoir des lignes de header complétement désordonnées.
Donc :
soit on implémente pas les lignes de header
soit on implémente pas le tri (#944)
soit on désactive les lignes de header lorsque les opérations sont triées par autre chose que la date, mais ça signifie qu’on doit dans ce cas s’assurer que la date complète est affichée pour chaque transaction.
Merci d’avoir pris le temps de relancer la conversation. Une autre possibilité serait d’avoir deux affichages possibles de cette liste : un affichage très tabulaire comme ce qu’on a maintenant, avec colonnes triables, et encore plus de colonnes pour montrer vraiment toutes les informations par opération ; une affichage plus aéré, avec opérations regroupées par mois, pour la vue principale de la liste des opérations.
Notre principal souci est qu’il est difficile d’estimer ce qui est important pour les utilisateurices sans lancer des expériences utilisateur avec des interfaces wireframes ; si on demande juste dans des sondages, on va biaiser les réponses en créant potentiellement des besoins qui n’existaient pas avant le sondage. Par exemple, si on demande « préférez-vous un affichage avec opérations regroupées par date (mais pas triable), ou affichage tabulaire (triable), ou les deux », je suis quasiment certain que tout le monde va répondre « les deux », en se donnant des bonnes raisons pour l’un ou pour l’autre.
La seule mesure réelle qu’on ait, c’est la fréquence et récence des demandes d’un des deux affichages. De tout ce qui ressort des tickets, et conversations que j’ai pues avoir avec des gens en face à face, le tri par colonnes n’a été mentionné qu’une seule fois en tout et pour tout. Moi-même j’ai encore pensé à fermer le ticket récemment en me disant que je ne voyais pas de cas d’utilisation, et je ne l’ai pas fait parce que la relecture du ticket en montrant quelques-uns qui étaient valides. Mais cela me semble tout de même marginal.
Un affichage plus aéré des opérations est quelque chose dont on parlait depuis un moment, qui me semble standard (en comparant avec d’autres applications bancaires), et dont d’autres gens m’ont parlé.
Par conséquent, au vu du « peu de moyens » que l’on a (étant bénévoles, etc.), je prends le parti que l’on devrait se lancer dans un affichage aéré, et mettre de côté l’idée d’un affichage alternatif, tabulaire, qui permettrait d’afficher et trier toutes les colonnes, pour plus tard, si le besoin se fait ressentir de nouveau.
Par contre, ça rendrait incompréhensible l’icône disant que l’opération est budgetisée pour le mois précédent ou suivant.
Et un autre serait d’avoir une interface qui ressemble moins à un tableur excel et serait plus aéré, moins suffoquant.