Ok, je viens de rentrer une sortie sur PC et un point de passage sur téléphone. Pour moi, ça me convient. Merci pour le boulot effectué.
Concernant les images, on va être clair : je ne vais sans doute plus les taguer…
Projet UI - Ergonomie de saisie d'une sortie
Tu veux dire mettre la catégorie ?
C’est sûr qu’on va perdre sur les catégories des photos (certains vont avoir la flemme de cliquer sur le bouton), mais je trouve qu’on gagne en efficacité pour tout remplir (légende, licence, catégorie) avec le nouvel outil (enfin quand on pourra charger plus de 2 photos d’un coup ;-))
C’est exactement ça. Je suis d’accord : plus confortable mais on va perdre là-dessus. Bah, c’est un compromis à faire.
Et c’est vrai que Google photo commence à catégoriser plus ou moins correctement les photos … Sans tag.
Je ne comprends pas : j’ai tout chargé d’un coup sûr cette sortie. C’est quoi le bug ?
Bug pas stable, un que je vais adorer 
Ici :
J’ai bien envie de répondre ça (bon en fait je vais quand même préciser un truc).
Est-ce que la proposition ci-dessous convient à une majorité ? A défaut, quelles améliorations proposez-vous ?
Là c’est plus une question (je n’ai pas d’avis tranché) : peut-être faudrait-il remonter les champs calculés automatiquement (déniv, longueur, cotation), en début de l’onglet « Détails » ? En particulier les déniv ne sont pas forcément ceux de l’iti de base (je me suis fait avoir plusieurs fois : j’ai oublié de changé le D+).
Globalement, oui.
Pour ma part, j’aurais mis durée/horaire sur la même ligne que date de début
Sinon, j’aurais mis le bloc carto plus encadré, avec le bouton ajouter une trace gps plus en évidence et au dessus de la carte. à cote, le texte en rajoutant : « Sinon, Vous pouvez dessiner, éditer ou faire glisser la trace GPS sur la carte. »
Pourquoi pas, mais j’ai une préférence sur la même ligne que le champ Météo, car c’est bien d’avoir qq lignes pour ce champ horaires, et ça va décaler pas mal vers le bas la carte et autres infos importantes de cet onglet.
Oui bonne idée. Et on pourrait mettre longitude et latitude sous la carte, vu que ça se remplit tout seul avec la trace.
OK fait dans V6 comme dans Main. Cependant, je n’ai que les droits de suggestion.
@Miko, tu pourrais m’augmenter mes droits dans Transifex ? Merci !
Peux-tu me le rappeler ce we à mon retour?
1 Like
- A l’édition d’un document, c’est dommage de ne pas utiliser plus de largeur sur un grand écran (sans forcément tout utiliser). Sur la V6, la largeur d’un champ texte est de 1220 px sur un écran de 1920px de large, alors que sur la maquette c’est 824 px (moins de la moitié de la largeur restante une fois enlevé le menu de gauche).
- Les champs texte vides pourraient ne faire que 2 lignes de haut, et les autres s’adapter +/- à la longueur du texte avec un max de 6 ou 8 lignes par exemple.
- Pour l’enneigement par zone, la largeur des colonnes est identique pour toutes les colonnes, alors qu’il y a 2 colonnes avec juste des chiffres. La dernière colonne doit être la plus large. Voir la V6 pour un exemple de largeurs plus adaptées.
2 Likes
Ce choix m’a permis de simplifier énormément la mise en page. Sur la V6, sur écran large, cela donne :
Cette largeur des champs numérique n’a pas de sens. Et en fait, j’ai rien inventé, j’ai juste suivi la logique de Discourse Cela dit, j’ai mis une largeur max de 840px de large pour le formulaire (j’ai repris la valeur du site sur lequel je me suis inspiré pour les section repliable). Ca peut en effet etre poussé à 1000px sans avoir des champ ridiculement large. Je te livre ca pour la prochaine, tu medira ce que tu en penses.
Bon pour la prochaine
Je peux les raccourcir (3 ou 4 lignes). Pour la taille adaptable, c’est plutôt hors projet. Et mon avis perso : complexité de code peu justifiée, tu peux changer la taille du textearea, ou te mettre en plein écran
Cette remarque est aussi valable pour le feed de la page d’accueil, ou utilisateur. D’ailleurs sur mon écran large, cela ne passe plus en deux card par ligne (ce qui densifie l’info, un retour v6 fort)
Oui, c’est un des défauts de la V6.
Mais avec une class sur les champs cotations et sur les champs numériques (qu’il faudrait d’ailleurs indiquer comme tel dans le html pour imposer le clavier numérique sur mobile et éviter les faute de frappe sur desktop), on peut réduire la largeur de ces champs sans toucher aux autres champs.
Il faut aussi ajouter une padding sur les champs 'conditions de l’accès TC" et autres champs à l’intérieur d’un div column.
En fait il faut enlever le padding sur le « .column » et le mettre sur « . column > div » (ou s’il y a des effets de bords, ajouter une class sur les div de champ placés à l’intérieur du div.column).
On peut aussi mettre l’unité des champs numériques en gris foncé au lieu de gris clair.
Et un truc qui permet d’identifier facilement les champs modifiables par rapport au reste du formulaire, c’est de mettre un fond gris.
Je n’ai pas réussi à mettre les checkbox en blanc, mais vous voyez l’idée.
Voici ce que ça donne :
La bordure de l’unité des champs num a sauté, mais ce n’est pas voulu.
L’original :
1 Like