Les faux contrôles de formulaires

Complètement d’accord !

Amen !
A faire passer aux webdesigner and co.

La même, j’approuve totalement.

D’accord également, mais quand le graphiste inculte en met un peu partout, et quand le client les veut absolument, parce que selon lui, c’est indispensable.
On se retrouve avec un code alourdi à cause d’incompétents…

Je l’ai fait récemment pour un site et c’est vrai que c’est galère.
D’ailleurs comme contre je rajouterai le temps d’intégration et de tests qui peuvent être assez long pour une utilité plus que discutable…

Je suis totalement d’accord. C’est galère et long à faire et au final on obtient pas forcément (au pixel près) ce que veut le client et on est obligé de lui expliquer pourquoi !
A faire passer au webdesigner ^^

Par extension, j’ai aussi un peu de mal avec les fausses alert, pour exactement les même raisons… Pourquoi remplacer une alert js qui est certes moche mais intégrée au système ?

QUOI ??? MAIS TU BRIDE MA CREATIVITE !!!!

Ceci est, j’en suis certain à 95%, le type de réactions des créas si on leur dit de ne pas les customiser !

Je suis graphiste et je suis d’accord !!

95% du temps les internautes voient un formulaire avec les éléments systèmes, il n’y a donc aucun intérêt à modifier un code visuel évident pour chaque internaute.

C’est surtout que ça fait chier royalement les intégrateurs :-)
Parce que les « contres » que tu as cité peuvent très bien s’appliquer aussi aux boutons et input de formulaires, comme le bouton de ce formulaire de commentaire par exemple :-)

Si on va dans votre logique, on fait des sites a la Jakob Nielsen (http://www.useit.com).

et donc dans POUR tu rajouterais quoi : ?

La plus part du temps une liste déroulante comme celle si est mal conçu.
Ne répondant pas de la même façon que celle du système :
– contrôlable au clavier
– orienté le déroulement en fonction de la place disponible
– auto sélection quand on tape au clavier
– gestion d’une liste trop longue
– z-index

à chaque fois un de ces points est bâclé ou en tout cas pas compatible avec certains navigateur. Tous les respecter représente une bonne couche de javascript (lourde)

Ce petit élément nécessite effectivement énormément de travail pour y gagner un peu en ergonomie. À moins que vous ayez un ergonome très compétant pour assurer vos désirs graphiques, s’il vous plais ne prenez pas le risque d’utiliser ce genre de fantaisie.

Et dans le pire des cas, on demande à l’intégrateur de faire un mix entre uniform et PIECss…parce que le truc doit être réalisé en CSS, sans image bitmap, et en même temps compatible avec les IE qui ne gèrent pas les border-radius et autres box-shadow…sisi…ça peut arriver !

@Minvielle Le cas des alert() est totalement différent: il y a bien des manières dont on peut vouloir notifier l’utilisateur. On peut vouloir une modale, ou pas. On peut vouloir que ce soit discret, ou en plein milieu de la page (selon la gravité de la notification par exemple). Bref, il y a tout un tas de vraies bonnes raisons et notamment ergonomiques, pour ne pas garder l’alerte système :)

Bonjour,

ça me fait penser aux webdesigner qui font leurs maquettes sur mac et qui maquette les formulaire avec les éléments de Safari.
Une fois livré le client gueule parce qu’il est sur Windows/IE (forcement) parce que les formulaires sont « dégueux ».

En matière d’accessibilité, il y a des solutions, comme celle présentée par Roger Johansson dans un billet intitulé An accessible, keyboard friendly custom select menu (http://www.456bereastreet.com/archive/201111/an_accessible_keyboard_friendly_custom_select_menu/). Il n’empêche que c’est, effectivement, toujours plus simple et plus pratique de lâcher prise en matière de design.

Alléluia, voila un article qui fait plaisir à lire, je me sens moins seul.

Et pourquoi ce serait un « select » ? S’il est entouré d’autres éléments de formulaire, ok, on évite les design impossible.
Mais si c’est un item d’une toolBar pour basculer vers un autre site (genre canon France vers Canon Espagne, cet élément graphique n’est pas nécessairement un select. Une ul – li -a peut faire l’affaire et avoir ce design.

Autre point à soulever. Les navigateurs et OS imposant une partie du design et de l’ergonomie des éléments de formulaire. Comme l’introduit Rob. Quel design doit être utilisé pour les éléments de formulaire sur une maquette ?

Je ne vois personne parler de WAI-ARIA et de jQuery Mobile.

>> Parce que les « contres » que tu as cité peuvent très bien s’appliquer aussi aux boutons et input de formulaires, comme le bouton de ce formulaire de commentaire par exemple <<

Styliser un bouton ou un input, c'est 3 lignes de CSS.

Styliser un select, c'est 50 lignes de jQuery, 4 ou 5 div inutiles, 20 lignes de CSS.

Merci de ne pas désinformer le lecteur.

@monsieur au dessus qui se prend pour dieu le père avec son « noob spotted », t’es pas sur le forum de World Of Warcraft ou sur Jeuxvideo.com, merci de rester courtois :-)

Je parlais surtout de l’ergonomie. Parce que les points qui concernent le chargement, on peut les appliquer a un tas de trucs, comme les webfonts par exemple … ah ué mais la ça prend 1min30 pour l’appliquer du coup y a personne qui râle :-D Et pourtant 90% des webfonts ont un rendu complètement dégueulasse digne de windows 3.1, et personne dis rien :-)

Pour ceux qui parlent de petit détail pour pas grand chose au final : « C’est avec des petits détails qu’on fait de grande chose » :-)

On ne m’ôtera pas de l’idée que ce débat fait des remous parce que c’est le truc le plus chiant a thémer dans une page web :-)

T’facon, j’veux pas vous déprimer, mais les webdesigners qui arrêtent de themer les formulaires au complet, ça risque par d’arriver :-)

PS : C’est moi ou le bouton d’ajout de commentaire est plus themé ? :D

Cela résume assez bien ma pensée. J’ajouterais dans la liste des causes, les 150 UI packs qu’on nous sert tous les jours à toutes les sauces avec des super drop down custom etc et les shots sur dribbble avec des UI customisées à l’extrême. Je me suis toujours demandée comment on passe de Photoshop à CSS quand on voit la complexité visuelle de certaines éléments. C’est joli. Point.
Hélas de plus en plus de clients prennent ces packs pour modèles, et il devient de plus en plus compliqué, même avec toutes la volonté et les bons arguments du monde, de leur faire comprendre pourquoi on ne peut pas leur faire la super drop-down comme ils l’ont vu sur le shot de superawesome designer sur dribbble (true story)

Grizouw > Les boutons, c’est un mauvais exemple je pense, ceux-ci ne demandent justement pas trop de fioritures pour être stylés, et donner à un quelconque élément une fonctionnalité de bouton n’est pas non plus très couteux ni handicapant.

Par contre, en ce qui concerne l’accessibilité et l’interropérabilité, il est indéniable qu’un pseudo-contrôle sera toujours plus gênant que le contrôle d’origine…
Il est vrai cependant que résumer les « pour » à un « c’est joli » est un peu casse gueule, car c’est bien souvent également le seul « pour » des autres effet graphiques, et dans cette optique on ne ferait effectivement plus que des sites fonctionnels, qui chargent vite, portables et accessibles, sans se soucier de ce « détail » qu’est le design.

mmmh assez subjectif comme article :) vous me direz « c’est normal pour sur un blog ». Bien qu’étant développeur je pense qu’attribuer tous les contres à tous les types constituant un formulaire et résumer le pour au simple « c’est joli » revient à créer des amalgames et surtout c’est un peu facile ;)

– L’ergonomie est un faux « contre » rien n’empêche d’avoir un formulaire design et ergonomique, et par définition ergonomique veut dire que c’est intuitif et facile d’utilisation donc si ça l’est véritablement, aucun temps supplémentaires pour l’utilisateur.

Personnellement je trouve que le seul vrai point contre, c’est l’accessibilité, le reste ça peut encore se maitriser ou se négocier lol…

@malak: Rien n’empêche de faire un select en Js qui soit accessible. Seulement dans les faits, c’est toujours une bouze immonde car l’intégrateur a les nerfs de devoir travailler sur des faux contrôles pourris.

Par contre, pour le temps de chargement, l’ergonomie et pour la pérennité : 100% d’accord. Combien de sites avec faux contrôles sont utilisables avec un mobile sans zoomer/dé-zoomer frénétiquement ?

Hum, je suis pas tout à fait d’accord.

je trouve que c’est désormais TRÈS facile d’implémenter ça (http://ivaynberg.github.com/select2/select2-latest.html), parfois c’est même plus pratique qu’un SELECT normal. Pour le mobile ? Une condition pour les désactiver en JS, et voilà.

Après oui, c’est plus lourd, ça prends plus de temps à faire. Personnellement, à l’utilisation j’ai tendance à préféré les SELECT modifiés (quand ils sont bien fait).

Travaillant dans une petite agence je cumule conception graphique et intégration (ce qui à mon sens devrait être le cas pour tout le monde car j’ai du mal à imaginer qu’on puisse concevoir l’aspect de quelque chose sans connaître le code sous-jacent mais c’est un autre débat). La guéguerre graphistes vs intégrateurs m’est donc étrangère. Cependant plus je lis ce blog et plus la lecture des commentaires quasi-haineux des intégrateurs m’inspirent deux conclusions : #1 les graphistes doivent impérativement savoir intégrer (en plus d’être experts en ergonomie et accessibilité) et #2 les intégrateurs doivent impérativement être tenus éloignés du design car ce concept leur échappe visiblement complètement.

Le html a été initialement conçu pour afficher du texte indépendamment de la machine qui le lit. On avait donc du texte à police, à taille et à mise en page à géométrie variable.

Et puis le web commercial est arrivé, et là, tout le monde s’est mis à faire des pages où tout doit être contrôlé pour des raisons d’image de marque, comme s’il s’agissait de quelque chose d’imprimé. Le métier d’intégrateur web est apparu, condamnant des milliers de gens à s’arracher les cheveux, car devant faire quelque chose avec des technologies conçues pour faire le contraire.

Ce post critique à juste titre une démarche qui va dans le sens de l’esthétique, pourtant il est présent sur une page dont le contenu est verrouillé dans un cadre d’un millier de pixels de large, alors que j’ai un écran qui en affiche près de 2000, ce qui laisse deux énormes espaces blancs, ce qui en plus me force à scroller pour lire la totalité du contenu.

Cher HTeuMeuLeu, je suis d’accord avec vous, et vous encourage d’aller au bout de votre démarche et de définir la largeur du contenu de votre blog relativement à la largeur de l’écran qui l’affiche, et non pas en px (oui, je sais, c’est une unité relative).

Je n’ai qu’une question. Quand le formulaire est le seul et unique intérêt de la page, n’est-ce pas un peu dommage. Je ne parle pas des formulaires à rallongent d’un tunnel d’achat par exemple, mais sur un petit jeu-concours il est intéressant de savoir comment le faire sans sortir l’utilisateur de l’univers qu’on lui propose.