Produits Entr'ouvert » Intégrations graphiques Publik

• La mode Material Design : http://materializecss.com/forms.html
• la source de beaucoup, Bootstrap : http://getbootstrap.com/css/#forms

Beaucoup de ces formulaires amènent l'utilisation d'un placeholder (le texte grisé à l'intérieur du champ avant qu'on ne tape); cela appelle-t-il un nouveau champ pour renseigner du texte à mettre dedans, ou bien on y duplique le titre du champ, ou ce qui est mis en remarque "quand pas trop long" ?

Frédéric Péters a écrit :

Beaucoup de ces formulaires amènent l'utilisation d'un placeholder (le texte grisé à l'intérieur du champ avant qu'on ne tape); cela appelle-t-il un nouveau champ pour renseigner du texte à mettre dedans, ou bien on y duplique le titre du champ, ou ce qui est mis en remarque "quand pas trop long" ?

Un nouveau champ, nommé "Exemple", ça m'irait bien.

Un nouveau champ ça m'embête un peu (alourdir l'interface pour des
raisons cosmétiques bof), par contre la proposition de Fred me plaît
bien : les gens pour qui la cosmétique compte soigneront le champ
remarque.

Pierre

Pierre Cros a écrit :

Un nouveau champ ça m'embête un peu (alourdir l'interface pour des
raisons cosmétiques bof), par contre la proposition de Fred me plaît
bien : les gens pour qui la cosmétique compte soigneront le champ
remarque.

Mélanger des trucs qui n'ont rien à voir, bof : le champ "remarque" ne fourni pas un "exemple" (le placeholder c'est destiné à être un exemple). Surtout que le placeholder est effacé dès que la personne commence à faire sa saisie sur le champ. Mais bon, hé, allez, c'est pas bien grave. L'avantage de ne pas ajouter un champ, c'est qu'on pourra l'ajouter plus tard :)

Sur la représentation des pages j'ai ajouté dans le wiki une page "Multipages" qui reprend toutes les successions de page des formulaires de prod, pour voir si c'était disposable horizontalement. (où l'on découvre un formulaire comportant 27 pages…)

http://help.wufoo.com/articles/en_US/SurveyMonkeyArticleType/Multi-Page-Forms
http://patternry.com/p=multiple-page-wizard/
http://www.smashingmagazine.com/2010/01/15/progress-trackers-in-web-design-examples-and-best-design-practices/

J'aime vraiment l'idée de la barre de progression avec un pourcentage. Parfois un peu futile, ça permettrait cependant de bien faire ressortir l'étape de validation, en montrant qu'on n'est pas encore à 100%.

https://spiral-project.github.io/formbuilder/#/new des idées à prendre peut-être (mais ça ne concerne plus l'affichage des formulaires, juste leur conception)

pcros:  Le carré rouge fait un peu daté aussi (mais j'ai pas d'alternative encore)
fpeters:  oui, l'icône pour les champs obligatoires qu'on oublie de compléter aussi.

À le noter quelque part pourquoi pas ici, pour materialize (mais c'était pareil pour bootstrap), mon rejet véhément, c'est parce qu'il s'agit de définir l'apparence via le code HTML et non plus via le code CSS, c'est-à-dire, plutôt qu'affecter une valeur sémantique à un élément (genre "footer") puis ensuite dire dans la CSS que le footer doit faire 80% de large, ce qui se passe avec des frameworks c'est que ça demande à définir dans l'HTML le rendu souhaité, par exemple <div class="m10"> pour dire que ce div doit faire 80% de large. Je me dis que ça peut encore marcher pour du backoffice (en acceptant l'idée de devoir modifier tout un tas d'éléments le jour où c'est autre chose qui est hype, mais ça se tient encore), ça n'est pas adapté à notre travail d'intégration graphique de sites tiers, où nos éléments sémantiques sont bien plus utiles.

Cela n'est en rien un commentaire sur les rendus de ces frameworks, ni sur les métaphores qu'ils appellent, qui peuvent très bien être adaptés dans nos applications. (mais comme il ne s'agit pas de tout prendre on télécharge ça tourne, c'est utile de pointer ce qu'on y trouve chouette).

Évidemment je comprend pas pourquoi les modifs devraient se faire dans le HTML et pas dans la CSS avec les frameworks (et c'est pas grave) mais je crois que tout le monde est ok pour dire que c'est pas l'utilisation des frameworks qui est intéressante mais le résultat qu'ils donnent à l'écran. Si on peut avoir quelque chose d'approchant en passant par les CSS et sans les utiliser c'est très bien.

Les choses concrètes :

• Victor pointait des détails d'alignement dans un jabber avec moi hier :
  VictorVictor 18:35:51
  nous on fait des trucs qui "volent" un graphiste aura tendance à faire des trucs propres bien alignés
  PierrePierre 18:37:09
  C'est quand même sans doute lié au côté dynamique des formulaire aussi, non ?
  Je pense que c'est beaucoup plus difficile de caler les choses quand tu connais pas la longueur d'un libellé, la longueur d'un input ou la hauteur d'un text area, la longueur du champ remarque, etc. Mais de toute façon ce sera bien d'en parler à Fred

• Je pointais le fait d'améliorer, comme Fred l'a fait pour les input ici https://wcs.imio.entrouvert.org/maison/demande-d-emplacement-de-stationnement-pour-vehicules-de-personnes-handicapees/ , les boutons radio, les cases à cocher, la police.

Après on peut discuter autours des effets, des icônes, du placeholder lors de l'EO day du 4 juin. J'ai rajouté ça au programme.

Moi qui ne suis pas très fan des effets, je trouve quand même très bien le halo que prend un champs actif ici (cliquer sur s'inscrire pour voir le formulaire) :
http://www.openmap-numeriques.fr/sinscrire-aux-pitch/
Et l'astérisque plutôt que le carré rouge et la police un peu graissée et bien noire avec le violet, et les champs sur 2 colonnes et la longueur identique de tous les champs qui ne sont pas sur deux colonnes. Bref un mélange de choses qui sont parfois uniquement de la responsabilité de celui qui conçoit le formulaire mais dont on devrait essayer de se rapprocher par défaut (genre que la longeur des input et des texte area par défaut soit la même et soit sur toute la largeur quand ils sont sur une seule colonne).

bon ça apporte sans doute pas grand chose au débat ou y a peut être des idées à prendre niveau graphisme j'en sais rien.
J'ai bossé sur ça : https://victor.au-quotidien.com/contacts/demande-d-intervention-des-services-municipaux/

C'est pas finalisé, c'est pas encore responsive, et tous les éléments de formulaires sont pas intégrés.

Victor Claudet a écrit :

bon ça apporte sans doute pas grand chose au débat ou y a peut être des idées à prendre niveau graphisme j'en sais rien.
J'ai bossé sur ça : https://victor.au-quotidien.com/contacts/demande-d-intervention-des-services-municipaux/

C'est pas finalisé, c'est pas encore responsive, et tous les éléments de formulaires sont pas intégrés.

J'aime bien.

Formulaire fait avec typeform https://sfermigier.typeform.com/to/RyaOID que je pointais à Fred :
[09:59:11] ‎Pierre‎: oui et les choix sous forme de bouton avec un truc (moche ici) qui apparaît àcôté du chois sélectionné, la barre de progression, le pied de page de manière générale, les boutons ok et envoyer, les champs grisés tant qu'ils ont pas le focus, le petit numéro à côté des questions, etc.
‎[10:00:19] ‎Pierre‎: Je trouve que c'est pas parfaitement réussi vu la débauche d'énergie, mais on est pile dans les idées dont on a besoin pour faire du hype

Pour la pagination, http://fezvrasta.github.io/bootstrap-material-design/bootstrap-elements.html#pagination

Un truc que je viens de voir sur un formulaire (achat en ligne) et que j'ai trouvé top : tant que les champs obligatoire sont pas correctement remplis le bouton valider est grisé. Je sais bien que ça totalement à l'encontre de ce qu'on fait aujourd'hui.

Mais si on se met, à un moment, à foutre du JS pour vérifier la validité des champs "à la volée" (et pas à la soumission), faudra mettre en œuvre ce détail, c'est vraiment très très chouette, on ne peut plus avoir d'erreur à la soumission.