Recherche avancée

Sur d’autres sites (12619)

• 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 ?

• Nomenclature #4626 : Renommer le menu "Squelettes"

  3 mai 2021, par RastaPopoulos ♥

  Pfiou voilà, je suis allé voir chaque page de chacun des plugins qui s’insère actuellement pour faire le point !

  Mise en page¶

  - ACS : comme le noizetier, mise en page à partir de blocs
  - Campagnes : pour la gestion de encarts à insérer ensuite dans la mise en page (ensuite dans chaque encart on gère les campagnes de bandeaux, mais le menu lui c’est pour aller à la gestion des encarts), pourrait éventuellement virer ailleurs en reformulant des choses
  - Comments : config du mode de mise en page des commentaires (threads ou pas, etc)
  - Compositions : liste les variantes de mise en page pour chaque type de contenu
  - Eléments : de la mise en page sur les contenus (comme le noizetier, et n’a d’ailleurs plus trop d’intérêt depuis plusieurs années que le noizetier sait aussi configurer des blocs pour tel contenu précis, pas que en global)
  - eva-web-bonus eva-web-habillage eva-web-install eva-web-mentions : configuration de la mise en page ou des styles du squelette Eva
  - Kaye : pour configurer la mise en page du cahier de texte
  - menu_langues_liens : configurer la manière d’afficher le changement de langue
  - noizetier : mettre en page le site entier par petits blocs
  - porte_plume_enluminures_typographiques : configure la mise en page des textes de contenus suivant les nouvelles syntaxes
  - seminaire : configuration de mise en page je crois, mais sinon ça devrait aller juste dans SVP
  - sociaux : configure quels liens et leur affichage
  - spip_visuels : configurer les rôles de visuels (pourrait peut-être aller ailleurs, et surtout remplacé par Rôles de documents bien plus pérenne car basé sur les documents existants)
  - squelettes_par_mots_cle : un peu un ancêtre de Compositions, mettre en page des contenus avec un autre squelette suivant un mot-clé
  - switcher : très vieille contrib, configure si on affiche le switcher de squelette (donc de mise en page !), mais c’est juste une config globale une unique fois, donc pourrait parfaitement être dans SVP uniquement

  Navigation¶

  - Court-circuit : change le comportement des liens pour certaines rubriques pour aller à un article interne directement
  - exclure_secteur : masque des secteurs entiers, mais pourrait aller dans Publication, je crois, puisque ça dépublie par défaut littéralement des branches
  - menus : créer et remplir les menus de navigation

  Styles et comportement d’affichage¶

  - Adaptive images : taille des images, lazyload ou pas, styles des previews
  - cloudzoom : un peu comme modalbox, configurer les images zoomables
  - fontawesome5 : sert juste à voir les icones existantes
  - forkawesome : pareil
  - Links : configure le style des liens externes et comment les afficher quand on clique
  - mediaspip_player : configurer l’apparence du lecteur
  - picto : comme fontawesome, sert juste à voir les icones existantes
  - player : choix du lecteur audio (conditionnant essentiellement son affichage)
  - rainette : configure l’affichage de la zone météo
  - recherche_mots_cles : pour configurer comment s’affiche (mais ce plugin n’est plus vraiment maintenu pour l’instant et cette page toujours en vieux exec PHP)
  - refbase : configure la manière d’afficher les bibliographies
  - sjcycle : configure l’affichage du carrousel
  - slick : configure l’affichage du carrousel
  - timecircles : configure l’affichage des timers
  - tooltip : configure l’affichage des infobulles
  - videos : configure l’affichage des vidéos (mais de nos jours on utilise plutôt oEmbed)
  - w3css : configurer l’apparence graphique en choisissant le thème du framework

  À virer ailleurs¶

  - champs_extras_synchronisation
  - Chosen : devrait virer complètement et être juste dans SVP, ou à la limite dans Configuration : c’est un truc qu’on configure une unique fois en gros, ce n’est pas à retrouver en permanence
  - comarquage : la dernière version du plugin ne s’insère plus donc sans objet
  - dublin_core : il s’agit de SEO/indexation/meta infos dans les métas du site et c’est juste la page de config général du plugin : soit juste SVP soit Configurer (soit Publication ? trouver où regrouper tous les trucs SEO, métas infos ?)
  - mathjax : aucun rapport ni squelette ni mise en page, c’est pour configurer comment le script JS est appelé CDN ou en local. En plus cette page ne devrait même pas exister, car CDN tierce on n’en veut pas normalement dans SPIP par défaut, le JS devrait toujours être interne au site
  - select2 : exactement comme Chosen, n’a pas à être retrouvé en permanence dans les menus, ça se configure une fois à l’installation
  - seo : trouver un autre endroit Publication ou Configuration, c’est de la méta information, voire juste SVP si c’est que la config générale à faire une fois
  - skeleditor : menu Développement !
  - xray : menu Développement !
  - zinit : j’ai pas tout compris mais j’ai l’impression que c’est pour aider les intégrateurices donc du dev donc Développement
  - xiti : statistiques, mais si config globale une unique fois : dans SVP uniquement, à la limite dans Configuration