Recherche avancée

Sur d’autres sites (9645)

• Anomalie #4623 : Styles des fieldset dans l’espace privé

  18 avril 2021

  Bon stop (ou pas) !

  Il semble que les blocs fieldset ne peuvent pas parfaitement se styler seuls. Manifestement c’est assez récent que les navigateurs acceptent un display:flex; dessus par exemple.

  J’ai fait quelques tests en partant du formulaire de préférences des menus (tiens d’ailleurs ce formulaire a des div.editer sans div.editer-groupe parent (à corriger !)
  Il contient un fieldset + .editer-groupe.deux_colonnes (columns : 2)

  Ce que j’ai testé (sous macOS avec FF, Safari, Chrome & Opéra) : la formule suivante (enlever le .editer-groupe interne et le monter sur le fieldset)
  

  <span class="CodeRay"><span class="tag">fieldset</span><span class="class">.editer-groupe</span>
      <span class="tag">legend</span>
      <span class="tag">div</span><span class="class">.editer</span>
      <span class="tag">div</span><span class="class">.editer</span>
      ...
  </span>
  Télécharger

  1) Si on applique un columns: 2 sur ce fieldset,
  - Firefox & Safari : conservent le legend, passent le reste en 2 colonnes
  - Chrome & Opéra : ignorent et conservent donc un affichage 1 colonne.

  2) Si on applique un display: flex; flex-wrap: wrap sur ce fieldset
  - Tous : le legend est conservé comme tel
  - le reste passe effectivement en flex (permettant donc de mettre plusieurs .editer sur la même ligne)

  Déjà je suis étonné que Flex semble fonctionner, contrairement à ce que dit https://caniuse.com/mdn-html_elements_fieldset pour tous les Gecko. Et Edge aussi est indiqué en non fonctionnel.

  Donc du coup… je me dis que le .editer-groupe dans le fieldset à encore du sens stylistique.
  Ce qui pour le coup ne nous arrange pas forcément, mais ça évite aussi de casser un truc de plus dans cette structure html en le laissant.

  Donc du coup, on en reviendrait peut être à "fieldset.editer-section" ou "fieldset.editer-fieldset" ou "fieldset.fieldset" ou "fieldset" (sans rien)…
  J’utilise .editer-section ensuite (mais peut importe)

  A) fieldset.editer-section > div.editer-groupe¶

  (le plus proche de l’actuel je pense)

  <span class="CodeRay">  <span class="tag">div</span><span class="class">.editer-groupe</span>
        <span class="tag">div</span><span class="class">.editer</span>
        ...
    <span class="tag">fieldset</span><span class="class">.editer-section</span>
      <span class="tag">legend</span>
      <span class="tag">div</span><span class="class">.editer-groupe</span>
          <span class="tag">div</span><span class="class">.editer</span>
          ...
  </span>
  Télécharger

  B) fieldset.editer-groupe > div.editer-section¶

  L’autre possibilité si ça facilite vraiment le css, c’est d’inverser les classes (avec l’ennui principal de du coup devoir reprendre l’existant)

  <span class="CodeRay">  <span class="tag">div</span><span class="class">.editer-groupe</span>
        <span class="tag">div</span><span class="class">.editer</span>
        ...
    <span class="tag">fieldset</span><span class="class">.editer-groupe</span>
      <span class="tag">legend</span>
      <span class="tag">div</span><span class="class">.editer-fieldset</span>
          <span class="tag">div</span><span class="class">.editer</span>
          ...
  </span>
  Télécharger

  B) fieldset.editer-groupe.editer-section > div.editer-groupe¶

  Ou du doubler d’une autre classe

  <span class="CodeRay">  <span class="tag">div</span><span class="class">.editer-groupe</span>
        <span class="tag">div</span><span class="class">.editer</span>
        ...
    <span class="tag">fieldset</span><span class="class">.editer-groupe</span><span class="class">.editer-section</span>
      <span class="tag">legend</span>
      <span class="tag">div</span><span class="class">.editer-groupe</span>
          <span class="tag">div</span><span class="class">.editer</span>
          ...
  </span>
  Télécharger

  Mais dans ce cas là je trouve cela redondant (fieldset.editer-section me parait suffisant, si on doit effectivement mettre un classe css dessus)
  Le plus ennuyant est peut être de devoir annuler des styles CSS du .editer-groupe dans .editer-section > .editer-groupe ;

• Evolution #4749 (Nouveau) : [UX] Comportement des labels : quoi par défaut, quoi ponctuel ?

  27 avril 2021, par RastaPopoulos ♥

  Ce ticket sert à réfléchir et possiblement reconcevoir les choix par défaut pour les labels des formulaires.

  État des lieux¶

  On le sait, l’ergo c’est normalement beaucoup d’objectif : certains placements, certaines tailles, épaisseurs, etc fonctionnent mieux que d’autres, et ceci est prouvable par tests utilisateurs.

  Or cela fait des années que les tests par eye-tracking montrent que les formulaires sont
  1) lu plus rapidement
  2) avec une meilleure compréhension
  lorsque les labels sont au-dessus des champs.

  Ça ne veut pas dire qu’il faut totalement interdire autrement mais : ça veut clairement dire que ça devrait être le comportement par défaut. Et seulement ponctuellement, par choix explicite, pouvoir mettre les labels sur le côté.

  Par ailleurs les pros de l’ergo (sur base des mêmes tests) préconisent tou⋅tes : dans les rares cas où on met les labels sur le côté, ça devrait être calé à droite sur le champ, pour les mêmes raisons de compréhension.

  Les avantages des labels au-dessus :
  - prouvé que c’est bien mieux compris par tout le monde
  - lecture plus rapide
  - fonctionne de base sur tous les écrans, pas d’adaptation à faire
  - polyvalent et générique sur le contenu des labels : marche mieux quelque soit la longueur, et donc à prioriser dans un contexte multilingue
  => cela correspond bien au maximum de notre utilisation : un CMS multi-lingue, allant enfin vers le responsive, se souciant d’accessibilité.

  Le seul désavantage : allonge la hauteur des formulaires, mais ça n’a un impact surtout que pour les formulaires ayant vraiment vraiment beaucoup de champs, ce qui est rare !
  Quand un formulaire est extrêmement long, il y a même plusieurs méthodes qui peuvent être utilisées sans pour autant passer les labels sur le côté :
  1) placer certains champs sur le même ligne (prénom + nom, etc)
  2) découper le formulaire en plusieurs étapes.

  Proposition pour le futur¶

  - tous les labels doivent être au-dessus comme comportement par défaut
  - pour certains cas, une classe permet de mettre sur le côté : valable uniquement en grand écran, ça reste au-dessus en mobile first
  - si sur le côté : c’est mieux si aligné sur le champ (donc à droite en LTR)
  - ex de rare formulaire candidat : changement des dates

  Quelques sources¶

  Tests utilisateurs
  https://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php

  Placing a label above an input field works better in most cases
  Placing labels above input fields is preferable
  In most cases, when placing labels to the left of input fields, using left-aligned labels imposes a heavy cognitive workload on users
  if you choose to place them to the left of input fields, at least make them right aligned

  Chez le très connu cabinet d’ergo Nielsen Group
  https://www.nngroup.com/articles/form-design-white-space/

  We recommend placing field labels above the corresponding text fields [en gras chez eux !]
  it makes the form easier to scan, because users can see the text field in the same fixation as the label. Top placement also allows for longer field labels
  If the labels are too far to the left, it can be difficult to associate the correct label with its corresponding field

  Chez Adobe, ils préconisent de suivre les recommandations de la première source
  https://xd.adobe.com/ideas/principles/web-design/best-practices-form-design/

  Matteo Penzo’s 2006 article on label placement suggests that forms are completed faster if labels are on top of the fields. Top-aligned labels are good if you want users to scan the form as quickly as possible.
  The biggest advantage of top-aligned labels is that different-sized labels and localized versions can more easily fit the UI.
  Takeaway : If you want users to scan a form quickly, put labels above the fields. The layout will be easier to scan because the eye will move straight down the page. However, if you want users to read carefully, put labels to the left of the fields. This layout will slow down the reader and make them scan in a Z-shaped motion.

  Chez une appli de conception d’interface
  https://phase.com/magazine/usability-of-forms/

  from a cognitive point of view, the association is powerful
  Also, the eyes move only in one direction since the scanning is top down as compared to Z shape (left-right and top-bottom) for inline labels
  Design is space efficient and hence adaptable to all resolutions ; in short, responsive in nature
  We also get flexibility regarding the length of labels. This proves useful while working with variable label lengths like multilingual support for applications
  One drawback of this approach is the increased height of the form. However, it can be solved with alternate designs like a grouping of fields or stepper forms

• Evolution #4753 (Nouveau) : Styles du privé : listes d’objets (suite des boîtes et des formulaires)

  30 avril 2021

  Les boîtes et les formulaires ont été visuellement « raccordés » ensembles.
  Je pense que logiquement les listes d’objets devraient suivre.
  En fait ce sont 3 variations d’un même composant : une boîte avec entête, corps et pied.

  Pour les listes on peut séparer la question en 2 aspects :

  1) L’emballage extérieur¶

  Là il s’agirait de reprendre les choix graphiques propres à « l’emballage extérieur » des boîtes et formulaires : bordure, arrondi, espacements.
  Exemple sur l’image suivant où les 3 sont visibles (nb : ceux en colonne sont automatiquement « ressérés », d’où la différence de padding etc.)

  

  Après en fonction de l’un ou de l’autre, il y aura peut-être lieu d’ajuster le padding ou la taille du titre. Mais pour l’instant ce sont ceux en place.

  2) L’intérieur¶

  Ensuite je propose de procéder à quelques ajustements à l’intérieur de ces listes.
  Je pense que certains choix ont été faits pour s’accommoder du manque de place en largeur à l’époque, et ne sont plus nécessaires maintenant.

  Pour me faire un idée de ce qui fonctionnerait le mieux, et comprendre les détails visuels qui me gênaient un peu, j’ai parcouru quelques articles de recommandations sur l’ergonomie des data tables.
  Alors ils traitent plutot des fonctionnalités de ces tables dans leur ensemble, mais il y a aussi quelques guidelines visuelles intéressantes.

  • https://uxdesign.cc/data-table-for-enterprise-ux-cb48fb9fdf1e
  • https://medium.com/nextux/design-better-data-tables-4ecc99d23356
  • https://www.uxbooth.com/articles/designing-user-friendly-data-tables/
  • https://uxdesign.cc/lets-design-data-tables-bf065a60e588

  Je retiens quelques règles simples :

  • Des espacements suffisants et consistants (le padding quoi)
  • Une taille de police identique partout (au moins dans le tbody). C’est fatiguant pour l’oeil et moins lisible quand on passe sans arrêt d’un taille de police à l’autre sur une même ligne. Et je ne suis pas sûr qu’il y ait forcément besoin de gras pour certains éléments comme les titres ou autres.
  • À quelques exceptions près (id, picto), pas de largeur fixes sur les colonnes, laisser faire le navigateur.

  Donc voilà, c’est pas grand chose à ajuster non plus.
  Les colonnes des tables ont des classes .importante et .secondaire.
  À mon avis elle ne devraient plus avoir d’incidence en vue « normale », mais juste décider quelles colonnes afficher et masquer en vue réduite, dans les colonnes ou ailleurs.

  Donc dans les grandes lignes ça donnerait quelques chose comme ça (juste une maquette) :

  

  3) Détails¶

  Enfin pour ces 3 composants, je propose qu’il y ait une classe modificatrice commune pour produire un affichage compact, c’est à dire ressérer tout le contenu.
  Cette classe serait automatiquement appliquée dans les colonnes.

  Ça pourrait être « compact », mais sur d’autres composants pour varier les tailles je suis parti sur mini / large. Donc mini aussi ?