Complètement au pif, j’avoue. Tu penses qu’il y a bcp de monde qui va utiliser le formulaire complètement déplié ?
Projet UI - Ergonomie
S’ils trouvent comment faire, je pense qu’il y a beaucoup de monde qui va le faire. Les onglets, c’est pénible à l’usage.
4 Likes
Dans la prévisualisation d’un itinéraire, il ne faut pas mettre la liste des dernières sorties ni le bouton « Ajouter une sortie », car après avoir passer 30s à relire, éventuellement en passant à un autre onglets, et quand on tombe sur la liste des sorties, on croit que c’est l’itinéraire enregistré, en ayant oublié qu’on l’a juste prévisualisé. On risque de perdre toute ses modifs…
Il faudrait aussi ajouter un warning comme sur la V6 :
Ceci est une prévisualisation du document que vous modifiez. Les changements ne seront pris en compte qu’après avoir cliqué sur le bouton Enregistrer.
Le coup des champs pliés individuellement, je trouve ça pour ma part génial sur smartphone. Surtout pour reprendre un travail en cours, on ne déplie que ce qui est utile.
1 Like
Yop, encore de l’ergonomie. J’ai à nouveau mes deux mains, je peux mieux jouer avec un ordi, et c’est bon pour la rééduc.
Les menus qui s’ouvrent sur mobile ne désactivent pas le reste de l’écran et ne sont donc pas intuitifs, ni faciles à refermer. Voici à mon sens les aspects ergonomiques et non ergo du comportement des différents menus :
##Menu de gauche (menu général) :
Les liens non désactivés de la zone principale une fois le menu ouvert sont gênants. D’autant que certians liens sont bien désactivés. Le défilement n’est pas bloqué, tout devrait être bloqué sur la zone en arrière du menu. Quelques exemples de pages sur lesquelles s’ouvre ce menu. En vert, ce qui est selon moi, un comportement correct, en rouge, incorrect.
##Menu de droite (menu préférences)
Le bouton ayant servi à l’ouverture ne fonctionne plus à la fermeture du menu. Aucune zone inactive une fois le menu ouvert. Le défilement n’est pas bloqué, tout devrait être bloqué sur la zone en arrière du menu. Un exemple de page sur laquelle s’ouvre ce menu. En vert, ce qui est selon moi, un comportement correct, en rouge, incorrect.
Suivant comment est chargé de liens l’écran sous-jacent, ça peut être très compliqué d’arriver à fermer ce menu …
##Comportement inter-menus
Il n’est pas normal de pouvoir ouvrir deux menus en même temps (gauche, puis droite). Si menu droite en premier, l’ouverture du gauche le referme.
##Menus de recherche dans le topoguide
Idem précédement
1 Like
Pour le menu de gauche qui se déplie, regarder ce qui a été fait sur la v6, ça marchait très bien (normal c’est moi qui l’ai fait 
)
Pour les autres menus, certains points relevés sont ok,d’autres plus discutables pour moi.
1 Like
PI, Sur la V6, quand un menu déroulant est ouvert, les liens ailleurs sur la page ne sont pas désactivés. je ne sais pas trop quel est le fonctionnement logique dans ce cas…
Je reglerai ca après la fin du sondage, il va falloir que je rebosse dessus
Pour la désactivations du reste de la page quand on ouvre un menu déroulant, je sais pas trop quoi en penser. J’ai deja au moins rajouté le fait de pouvoir le fermer en rappuyant sur le bouron qui l’a ouvert.
Le reste est ok dans peu de temps
Edit c’est bon.
On peut avoir l’habitude de cliquer à côté du menu pour le fermer (c’est mon cas sur la v6 sur mobile, car sur la flèche en haut à gauche il y a un risque de cliquer sur le logo, qu’il faut laisser actif pour pouvoir accéder à la home).
Du coup, on clique n’importe où à côté du menu. Si c’est sur un lien, ça change de page pour rien, et c’est déroutant. Sur la home avec les card active sur toute leur surface, 90% de la surface à côté du menu est active.
C’est pour éviter ça que sur la V6 toute la page en arrière plan est désactivée lorsque le menu est ouvert.
En effet. Mais pour discourse sur mobile en portrait, le menu de droite prend presque toute la largeur, du coup c’est plus pratique de recliquer sur l’avatar.
Sur la maquette, pour le menu de droite c’est aussi facile de recliquer sur le pseudo. Mais bon sur la v6 le menu sous le pseudo semble quand même bloquer l’arrière plan.
Sur la page des filtres le sélecteur carte/liste est masqué pour les point de passage sur les écrans mobiles trop petit
1 Like
Sur mobile, sur le filtre de sortie ou itinéraire, je n’ai pas trouvé le champ pour filtrer sur des docs associés.
Je ne l’ai pas affiché, j’ai pas encore réussi à trouver une bonne façon de le mettre 
C’est un vrai défi de tout faire tenir sur les mobiles avec peu de largeur d’écran…
J’ai pas.trop.pris le temps de regarder le design. Mais on pourrait envisager de mettre des boutons hamburger pour les cas où il y a beaucoup d’icône et peu de choix.
Tu peux le mettre sous le titre.
Sous le titre dans le 1er onglet de filtre, pas visible en permanence.
Ou à la fin de cet onglet.
On aurait tendance à le chercher sous l’onglet avec le picto « sommet », mais en fait cet onglet contient des filtres qui n’ont rien à voir avec les sommets.
Par ailleurs, sur mobile ce serait mieux de mettre les cards en pleine largeur, et le titre du doc sur plusieurs lignes dans la card.
Il faut éliminer le défaut de la v6 qui coupe les titres, c’est vraiment rédhibitoire. C’est quand même l’info principale d’une card, si on ne l’a pas en entier, on se retrouve régulièrement avec plein de cards avec le même début de titre et impossible de choisir.
Exemple : Camptocamp.org developement builds
(Même défaut sur la v6 et la maquette).
1 Like
Complètement, surtout sur mobile avec une seule colonne de card, c’est un non sens.
Sur la maquette, en mode paysage on peut avoir des titres plus longs. Mais ce n’est pas pratique de passer en paysage juste pour avoir des titres plus longs.
Sur la V6, en mode paysage ça passe en double colonne, donc la largeur d’une card reste quasi identique et le problème subsiste.
Sur mobile, l’ensemble des cards est dans une boite .section qui a un padding de 1.5rem.
Ca fait une marge de 20px de chaque côté.
Sur la V6 il n’y a pas cette marge, ça laisse plus de place pour la card.