pompage.net

La cryptographie et le Web : hachage, salage et autres recettes

Blandine Proust — 2012-02-28T00:52:46Z

L'un des outils de sécurité les plus puissants à disposition des développeurs web est la cryptographie, une opération consistant à transformer des informations porteuses de sens en bruit aléatoire, illisible sauf là où elles ont besoin d'être lues. Nombre de gouvernements ont strictement réglementé les logiciels de cryptographie jusqu'à une période relativement récente. Mais la cryptographie étant simplement des mathématiques appliquées, elle s'est avérée impossible à éliminer. Un développeur web qui travaille dans son garage sur son petit netbook a aujourd'hui accès à des cryptosystèmes majeurs dont les gouvernements rêvaient seulement il y a encore quelques décennies.

Il est tentant de croire qu'une simple application web n'a pas besoin d'une sécurité de niveau industriel parce qu'elle n'est pas censée contenir d'informations qui vaillent la peine d'être dérobées, telles que des numéros de carte de crédit. Malheureusement, les gens ont tendance à réutiliser les mêmes mots de passe sur les différents systèmes qu'ils emploient. Si le plus vulnérable de ces systèmes est compromis, l'accès aux autres sera généralement possible. En 2009, un pirate a ainsi fait parler de lui en réussissant à pénétrer dans plusieurs systèmes internes à Twitter après avoir piraté le compte e-mail d'un seul assistant administratif.

Tout artisan doit connaître ses outils et les matériaux pour atteindre l'excellence. Les développeurs web doivent quant à eux savoir quel type de cryptographie convient à quel contexte, même s'ils ne comprennent pas les opérations mathématiques utilisées dans leur moindre détail. Des méthodes de cryptographie mal appliquées n'apportent aucun avantage et peuvent même s'avérer dangereuses en procurant un faux sentiment de sécurité. Il existe de nombreux types de cryptosystèmes, mais trois grandes catégories concernent habituellement les applications web.

Fonctions à sens unique

Il est impossible de partir d'une saucisse pour produire les ingrédients de base qui la composent. De même, une fonction de hachage cryptographique est conçue pour prendre des données et les mélanger afin que le résultat à l'autre bout soit irréversiblement méconnaissable. Décrite ainsi, cette opération ne semble pas particulièrement difficile ni utile. Mais les fonctions de hachage bien conçues présentent deux propriétés qui les rendent à la fois complexes et utiles.

Primo, une légère modification des données en entrée doit entraîner un changement drastique des données en sortie. Autrement dit, modifier un caractère des données hachées changera bien plus qu'un simple caractère en sortie. En règle générale, le hachage produit une empreinte de longueur définie (et relativement faible), quelle que soit la taille des données en entrée. Cela signifie qu'en théorie, plusieurs entrées peuvent donner le même résultat. Un pirate qui ne posséderait que l'empreinte cryptographique n'aurait donc pas la possibilité de remonter jusqu'aux données d'origine.

Secundo, une fonction de hachage produira toujours la même empreinte à partir de données identiques en entrée. L'application la plus évidente du hachage est le stockage des mots de passe. Une application web n'a pas besoin de réellement « connaitre » le mot de passe d'un utilisateur ; il lui suffit de vérifier que la personne demandant l'accès le connait. Si la même méthode de hachage est utilisée au moment de la création du mot de passe et au moment de l'identification, il suffit de stocker et de comparer uniquement le résultat des opérations de hachage pour savoir que les mots de passe originaux sont identiques. Ainsi, même si un pirate parvient à accéder à une base de données utilisateur, il n'obtient aucune information vraiment utile. En tout cas, c'est l'opinion la plus répandue.

Ce n'est pas si simple en réalité. Tout d'abord, tous les algorithmes de hachage ne naissent pas égaux. L'algorithme MD5 par exemple a connu son heure de gloire, mais est réputé aujourd'hui pour son manque de fiabilité général sur le plan cryptographique (bien qu'il puisse toujours être utilisé pour les mots de passe). Ensuite, nous savons que de nombreuses personnes choisissent les mêmes mots de passe courants. Un pirate qui connaîtrait la valeur de l'empreinte pour « 123456 » produite par quelques algorithmes couramment utilisés n'aurait aucun mal à la retrouver dans une base de données. Des listes d'empreintes précalculées, appelées tables arc-en-ciel (rainbow tables) par les professionnels de la sécurité, sont disponibles très facilement.

Afin de pallier ce point faible, une fonction de hachage peut être « salée ». Étant données les deux propriétés des bons algorithmes de hachage décrits précédemment, il suffit d'ajouter au mot de passe quelques données à notre sauce et de stocker l'empreinte de cette combinaison de textes plutôt que celle du mot de passe seul. Cette opération génère un résultat complètement différent, mais toujours facile à vérifier.

Comparez les deux exemples suivants :

sha1('mot_de_passe')
=> 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 sha1('x5T1mot_de_passe')
=> e1f9530af9bde38db0eef386c4d22ec2ba10d2fe

Ici, ajouter quatre caractères aléatoires au début du mot change 95 % de l'empreinte. Parmi les fonctions de hachage disponibles dans la plupart des langages de programmation, l'algorithme SHA-1, développé par la NSA [1], est à ce jour le plus efficace.

Chiffrement symétrique

Bien entendu, les fonctions à sens unique trouvent un usage assez restreint. La plupart du temps, les informations sont cryptées uniquement pour s'assurer qu'elles ne puissent pas être lues hors de leur contexte. Mais dans un contexte donné (une console d'administration, par exemple), le cryptage doit être réversible.

Toutefois, un développeur d'applications devrait toujours commencer par se poser la même question : « Ai-je vraiment besoin de recueillir et de stocker ces informations ? » Maintenir la collecte des données à un strict minimum simplifie le développement et contribue généralement à améliorer l'expérience utilisateur et bien entendu la sécurité. Après tout, les données qui n'existent pas ne peuvent être ni volées ni exploitées.

Mais si ces informations sensibles sont absolument indispensables à la fonctionnalité d'une application, il faut réfléchir à comment les manipuler en toute sécurité. Le cryptage réversible se divise en deux catégories. Dans la première, une seule « clé » secrète est utilisée pour chiffrer et déchiffrer les données. Les clés constituent une sorte de mot de passe, mais puisqu'elles sont utilisées plutôt par des programmes que par des humains, elles peuvent (et doivent) être plus longues et complètement aléatoires.

Avec les algorithmes modernes, le cryptage symétrique a l'avantage d'être extrêmement rapide. Le puissant algorithme AES (ou Rijndael) a été spécialement conçu pour être rapide et compatible, avec des implémentations à la fois dans les serveurs de bases de données et dans les frameworks applicatifs. Par exemple, crypter et décrypter des données dans MySQL est un jeu d'enfant :

INSERT INTO gens (nom_animal) VALUES (AES_ENCRYPT('Snoopy','ma-cle-secrete')); SELECT AES_DECRYPT(nom_animal, 'ma-cle-secrete') AS nom_animal FROM gens;

Cette méthode n'empêche pas les informations d'être exposées si un utilisateur mal intentionné accède à l'application web, car elle sait comment décrypter les données. Cependant, elle empêche de divulguer accidentellement les données dans d'autres contextes, comme des fichiers de sauvegarde ou une attaque sur la base de données même. Le cryptage symétrique fonctionne bien lorsque l'on accède toujours aux informations depuis le même contexte. Toutefois, sa force réside toute entière dans la clé secrète. Cela devient un problème lorsque les données ont besoin d'être transférées. La clé n'est plus secrète dès lors qu'elle est partagée, surtout avec plusieurs destinataires.

Chiffrement asymétrique

Pour répondre à ce besoin, les algorithmes asymétriques se basent sur une paire de clés générées avec certaines propriétés spécifiques. Lorsqu'un message est crypté avec une clé, seule l'autre clé correspondante peut le déchiffrer. Ce type de chiffrement est également appelé « cryptographie à clé publique », car il arrive souvent (mais pas toujours) que l'une des clés soit rendue publique et l'autre tenue secrète.

Il est intéressant de connaître les opérations mathématiques à la base de cette méthode, mais les développeurs web ont surtout besoin de comprendre quand utiliser ce type de chiffrement et la protection qu'il offre. Cette technologie est le plus fréquemment utilisée pour les connexions SSL (appelées TLS aujourd'hui). Le serveur web envoie sa clé publique au navigateur, qui l'utilise pour chiffrer les données que seul le serveur est capable de déchiffrer. Elle peut également servir à envoyer des e-mails chiffrés.

Comparées aux fonctions symétriques, les fonctions asymétriques sont lentes et nécessitent des clés beaucoup plus longues pour être efficaces. Dans le cadre de connexions TLS, le navigateur et le serveur utilisent simplement un système cryptographique à clé publique pour établir une clé symétrique temporaire afin de chiffrer les communications ultérieures.

Ces fonctions remplissent toutefois un rôle crucial dans la navigation web moderne. Elles nous permettent en effet de protéger les données qui transitent entre une application et les utilisateurs. La forte présence des réseaux Wi-Fi ouverts est une réelle source de préoccupation à ce sujet. Sur ces réseaux, les utilisateurs diffusent tout ce qu'ils font dans un rayon de 360° et sur une distance considérable. Non chiffrées, ces données peuvent être consultées facilement par n'importe qui équipé d'un ordinateur portable. En 2010, deux incidents très médiatisés ont mis ce risque en lumière. Tout d'abord, Google s'est trouvé aux prises avec les autorités chargées de la protection de la vie privée après avoir stocké accidentellement le trafic de réseaux Wi-Fi non chiffré capté par ses véhicules Street View. Ce que Google a fait accidentellement, d'autres peuvent le faire volontairement. Quelques mois plus tard, le plug-in Firesheep a fait les gros titres en montrant à quel point il est simple (et dangereux) d'espionner un réseau ouvert.

Les applications web devraient exiger au minimum des connexions TLS pour la transmission des informations d'identification. Il est encore mieux de les utiliser pour l'ensemble du trafic.

Comprendre le risque

Étant donnée l'utilisation que nous faisons des ordinateurs aujourd'hui, il est certain que toutes ces technologies seront de plus en plus importantes pour les développeurs web. Les événements de ces dernières années ont montré que ce risque n'était pas que théorique. Se dire que son application n'est pas assez réputée pour être ciblée ne suffit pas. Les attaques sont souvent automatisées, pas ciblées. Dans le même temps, nous devons comprendre et informer les gens des risques spécifiques qui existent et sur la manière d'utiliser la technologie pour les contrer. Sans cette démarche éducative, les clients peuvent considérer qu'un site ou une application est « sûre » tout simplement parce qu'elle accepte les connexions HTTPS. Sans comprendre pourquoi il est impossible de leur envoyer un mot de passe en clair dans un e-mail.

La sécurité n'est jamais absolue. Mais utilisée correctement, la cryptographie moderne nous fournit des outils pour éliminer les principales menaces. À nous de les mettre à profit.

[1] National Security Agency, agence de sécurité nationale américaine

La discipline de la stratégie du contenu

Evren Kiefer — 2011-12-15T12:00:00Z

Nous, les personnes qui faisons des sites web, parlons depuis quinze ans d'expérience utilisateur, d'architecture de l'information, de systèmes de gestion de contenu, de programmation, de métadonnées, de design visuel, de recherche utilisateur et de toutes les autres disciplines qui permettent à nos utilisateurs de trouver et de consommer du contenu.

Mais bizarrement, nous ne parlons jamais de l'essentiel : le contenu lui-même.

Oh oui, on le sait : écrire pour le web, c'est mettre des listes à puces partout.

Mais qui parmi nous pose les questions qui fâchent à propos du contenu telles que « Quel est l'intérêt ? » ou « Qui s'en occupe ? ». Qui parle du processus chronophage, compliqué, désordonné de développement du contenu ? Qui supervise le soin et l'alimentation du contenu une fois mis en ligne, bouchant les tuyaux et mettant à mal nos moteurs de recherches ?

En tant que communauté, nous restons assez discrets sur la question du contenu. En fait, il semble que chacun de notre côté, nous soyons silencieusement arrivés à la conclusion que le contenu n'est vraiment pas notre problème — « le client peut le faire », « les utilisateurs vont le générer » — ainsi, nous, les personnes qui faisons des sites web, n'avons pas à nous en soucier du tout.

Pensez-vous qu'il s'agisse d'une coïncidence, donc, si une grosse partie du contenu web est minable ?

S'occuper de contenu, c'est un sale boulot. C'est compliqué, c'est pénible et c'est cher.

Et pourtant, le web est contenu. Le contenu, c'est le web. Il mérite que l'on y consacre du temps et de l'attention.

Et c'est là que la stratégie du contenu entre en jeu.

Qu'est-ce que la stratégie du contenu ?

La stratégie du contenu planifie la création, la publication, et la gouvernance de contenus utiles et utilisables.

Le stratège du contenu doit obligatoirement s'efforcer de définir non seulement quel contenu sera publié, mais aussi pourquoi nous le publions en premier lieu.

Dans le cas contraire, la stratégie du contenu n'est pas du tout de la stratégie : elle n'est guère plus qu'une chaîne de production pour du contenu dont personne n'a réellement besoin ou envie. (Référez-vous au système de gestion de contenu de votre entreprise.)

La stratégie du contenu est aussi - surprise - un livrable clé dont le stratège du contenu est responsable. Son développement est nécessairement précédé par un audit et une analyse détaillée du contenu existant - un processus d'une importance capitale qui est souvent survolé ou même sauté par les équipes de projet.

À son meilleur niveau, une stratégie du contenu définit :

les thèmes clés et les messages,
les sujets recommandés,
la raison d'être du contenu (c'est-à-dire comment le contenu fera la jonction entre les besoins du public et les objectifs d'affaires),
l'analyse des écarts en matière de contenu,
un guide de rédaction des métadonnées et autres attributs de contenu associés
l'optimisation pour les moteurs de recherche et
les répercussions des recommandations stratégiques sur la création, la publication et la gouvernance du contenu.

Mais attendez... il y a plus.

Dans son article pionnier, « Content Strategy : the Philosophy of Data » (Stratégie du contenu : la philosophie des données), Rachel Lovinger dit :

Le principal objectif de la stratégie du contenu est d'utiliser des mots et des données pour créer du contenu sans ambiguïté et épauler des expériences interactives pleines de sens. Nous devons être des experts dans tous les aspects de la communication pour faire cela efficacement.

C'est beaucoup demander. Pour ma part, je pense qu'il y a trop d'aspects de la communication pour qu'un stratège du contenu seul puisse se proclamer expert de chacun d'eux.

À la place, admettons qu'il y ait un certain nombre de disciplines relatives au contenu qui méritent leur propre définition, tour à tour :

La stratégie éditoriale définit les lignes directrices qui gouvernent tout contenu en ligne : les valeurs, la voix, le ton, les considérations légales et réglementaires, les contenus générés par les utilisateurs, et ainsi de suite. Cette pratique définit aussi le calendrier éditorial en ligne d'une organisation, y compris les cycles de vie du contenu.
L'écriture web est la pratique qui consiste à écrire des contenus utiles et utilisables spécifiquement pour la publication en ligne. Elle va bien au-delà de la rédaction intelligente. Un rédacteur web efficace doit comprendre les bases du design d'expérience utilisateur, être capable de se référer à la documentation de l'architecture de l'information, écrire des métadonnées efficaces et gérer un inventaire de contenus en constante évolution.
La stratégie des métadonnées identifie le type et la structure des métadonnées, aussi appelées « données à propos des données » (ou contenu). Des métadonnées intelligentes et bien structurées aident les éditeurs à identifier, organiser, utiliser et réutiliser du contenu de manière sensée pour leurs publics cibles.
L'optimisation pour les moteurs de recherche est le processus qui consiste à éditer et organiser le contenu sur une page ou sur tout un site (y compris les métadonnées) pour augmenter la pertinence potentielle pour certains mots clés.
La stratégie de gestion du contenu définit les technologies nécessaires pour capturer, stocker, livrer et préserver le contenu d'une organisation. Les infrastructures de publication, les cycles de vie du contenu et les « workflows » sont des considérations essentielles de cette stratégie.
La stratégie des canaux de distribution définit comment et où le contenu sera mis à la disposition des utilisateurs. (Bref aparté : considérez le marketing par e-mail dans le contexte de cette pratique ; il s'agit d'une façon de distribuer du contenu et d'inciter les gens à venir sur votre site pour y trouver des informations, et pas seulement une tactique de marketing séparée.)

Au final, cette distinction n'implique en aucun cas que le stratège du contenu ne peut ou ne doit pas être capable de jouer ces rôles et créer les livrables associés. En fait, dans mon expérience, le stratège du contenu fait partie d'une espèce rare, il est souvent désireux et capable de se fondre dans ces rôles si cela est nécessaire afin de livrer du contenu utile et utilisable.

MAIS. Et c'est un grand « mais ». Si notre communauté ne parvient pas à reconnaître, diviser et conquérir les multiples rôles associés à la planification, à la création, à la publication et à la gouvernance du contenu, nous continuerons de sous-estimer le temps, le budget et l'expertise nécessaires pour faire du bon contenu. Nous ne définirons et ne défendrons pas clairement le processus auprès de nos clients et de nos entreprises. Nous continuerons de nous laisser enfermer avec des directives de dernière minute, des brouillons de copie à-corriger-plus-tard - et nous continuerons à publier n'importe quoi.

Nous pouvons faire mieux. Nos clients et nos employeurs le méritent. Notre public le mérite. Nous le méritons en tant qu'utilisateurs.

Reprenez le flambeau.

C'est David Campbell, fondateur de Saks Fifth Avenue, qui a dit, « La discipline, c'est se rappeler ce que l'on veut ».

Lorsqu'il s'agit de créer et de gouverner du contenu, il est facile d'oublier ce que l'on veut, ou encore pire, de se contenter du minimum.

Jusqu'à ce que nous nous engagions à traiter le contenu comme un actif important digne d'une planification stratégique et comme un investissement sensé, nous continuerons à mouliner du contenu sans valeur en réaction à des demandes démesurées. Nous continuerons d'essayer de faire entrer des mots, des sons, des images et de la vidéo dans des gabarits qui n'ont pas été conçus conformément aux spécifications du contenu réel de notre entreprise. Nos consommateurs ne trouveront toujours pas ce qu'ils cherchent. Et nous n'arriverons jamais à publier du contenu utile et utilisable qui intéressera les gens.

Arrêtez de prétendre que le contenu n'est pas votre problème. Reprenez le flambeau de la stratégie du contenu. Apprenez-la. Pratiquez-la. Faites-en la promotion. C'est le moment de faire du contenu une chose importante.

Comment bien placer des labels dans leur zone de texte

Blandine Proust — 2011-10-03T01:23:37Z

Il existe plusieurs manières de disposer les labels sur les formulaires. En général, les designers web les placent soit au‑dessus, soit à gauche des zones de texte. Mais jusqu'à récemment, personne ne pensait à les insérer à l'intérieur. On commence à rencontrer de plus en plus fréquemment des formulaires de ce genre. Plus ils gagnent en popularité, plus les designers web auront tendance à les utiliser. Mais avant d'opter pour cette méthode, quelques points sont à connaître.

En plaçant vos labels à l'intérieur des zones de texte, vous apportez à votre formulaire de nombreux avantages. Pour commencer, vous réduisez la longueur et la largeur du formulaire. Puisque le label se trouve à l'intérieur, vous disposez de davantage d'espace à l'extérieur de la zone de texte pour réaliser un agencement plus compact. D'autre part, le nombre de fixations visuelles nécessaires entre le label et la zone de texte diminue. Les deux éléments étant superposés, une seule fixation suffit pour trouver le label et la zone à laquelle il appartient. Le formulaire devient alors plus lisible et plus rapide à remplir, tout en donnant une impression générale de sobriété et de simplicité. Il ne semble pas surchargé, ce qui le rend plus attrayant pour les utilisateurs.

Reconnaissance visuelle contre mémoire

Placer les labels à l'intérieur des zones de texte apporte autant d'avantages que de défis. La principale difficulté est de permettre la reconnaissance visuelle plutôt que l'usage de la mémoire. Lorsque l'utilisateur commence à remplir une zone de texte, le label qui se trouve à l'intérieur disparaît. Lorsqu'il revient sur le formulaire, il est difficile pour lui de reconnaître les informations qu'il a entrées. Sans aucun indice sur le type d'information figurant sur le formulaire, l'utilisateur est obligé de se rappeler les labels correspondant aux données qu'il a saisies, ce qui augmente la charge cognitive de sa mémoire.

Groupes et intitulés

Afin que l'utilisateur puisse reconnaître facilement le type d'information qu'il saisit, vous devez regrouper vos zones de texte en fonction des informations qu'elles contiennent et attribuer un intitulé clair à chaque rubrique. Par exemple, les informations de livraison et de paiement sont différentes. Il est donc important de ne pas réunir ces zones de texte. Répartissez‑les plutôt dans deux rubriques séparées ayant chacune un titre. L'utilisateur pourra ainsi plus facilement identifier la zone correspondant aux informations de livraison et celle correspondant aux informations de paiement.

Des rubriques secondaires sont également nécessaires si vous créez un grand nombre de zones de texte. Par exemple, les informations de livraison contiennent généralement des données concernant la personne et d'autres concernant l'adresse. En regroupant les zones correspondant à ces deux catégories dans deux rubriques secondaires, vous aidez l'utilisateur à les distinguer une fois le formulaire rempli.

Messages d'erreur

La plupart des messages d'erreur sur les formulaires indiquent à l'utilisateur qu'il a laissé un champ vide ou saisi des informations non valides. Si les labels sont placés à l'intérieur des zones de texte, ces messages d'erreur standards ne suffisent pas. Lorsqu'un utilisateur rencontre un message d'erreur indiquant qu'une information n'est pas valide dans la zone de texte qu'il a remplie, cela ne lui est pas très utile puisque le label correspondant a disparu. Résultat : ne sachant pas à quoi s'applique l'information située dans la zone de texte, l'utilisateur a plus de difficultés à corriger sa saisie. C'est pourquoi le message d'erreur doit mentionner l'information saisie pour chaque zone de texte. Indiquer simplement qu'une zone de texte n'est pas valide n'aide pas l'utilisateur à reconnaître et à corriger l'information. Vous devez adapter chaque message d'erreur à chaque zone de texte. L'utilisateur sera ainsi capable de la corriger sans voir le label.

Feed‑back visuel

Placer les labels à l'intérieur des zones de texte représente un autre défi : le feed‑back visuel reçu par l'utilisateur. Ce feed‑back doit se déclencher lors de la sélection et de la saisie d'informations dans la zone de texte, mais également lors de la suppression d'informations et de la désélection de la zone. Si vos zones de texte sont bien conçues, les utilisateurs pourront remplir votre formulaire sans aucun problème.

Sélection d'une zone de texte et saisie

La première fois qu'un utilisateur pose les yeux sur votre formulaire, les labels doivent être gris afin de se différencier du texte noir qui s'affiche lors de la saisie. Ils doivent disparaître au moment où l'utilisateur commence à taper, mais pas lorsqu'il sélectionne la zone de texte à l'aide de la souris. La zone de texte doit plutôt être mise en évidence et le label doit s'estomper, indiquant ainsi qu'il va disparaître au moment de la saisie. Le label ne doit pas disparaître complètement avant que l'utilisateur ne commence à taper : certains utilisateurs risquent de sélectionner une zone de texte et d'oublier quelles informations ils doivent y entrer. En laissant le label visible jusqu'à la première frappe, vous évitez à l'utilisateur de faire appel à sa mémoire pour se souvenir du label.

Suppression d'informations et désélection de la zone de texte

Lors de la suppression d'informations et de la désélection de la zone de texte, celle‑ci doit revenir à son état d'origine. Le label doit donc réapparaître. Dans certaines zones de texte, le label ne réapparaît pas, même si la zone est revenue à son état d'origine. Le label doit réapparaître lorsque l'utilisateur supprime les informations et désélectionne la zone de texte afin qu'il puisse le lire à nouveau si nécessaire.

Placer les labels à l'intérieur des zones de texte apporte son lot d'avantages et de difficultés. Si vous y parvenez, votre formulaire aura l'air plus propre, plus simple et plus léger que la plupart de ceux rencontrés sur le web. Les utilisateurs seront impressionnés par la vitesse et la facilité avec laquelle il se remplit. Mais parvenir à ce résultat demande du travail. Cet article ne le fera pas pour vous, mais il peut vous mettre sur la bonne voie afin qu'au bout du compte, vous n'ayez plus à vous inquiéter de rien.

À vous de jouer

Dimensionner ses fontes avec rem

Fabien Basmaison — 2011-09-01T02:00:00Z

Déterminer quelle unité de mesure choisir pour la taille de notre texte peut mener à un débat houleux, même de nos jours. Malheureusement, il existe toujours des avantages et inconvénients qui rendent ces différentes techniques peu désirables. La question est alors de savoir quelle solution est la «  moins pire  ».

Les deux techniques suivantes sont le plus souvent utilisées :

taille en px ;
taille en em.

Analysons ces deux approches avant que je ne révèle mon troisième atout.

Dimensionnement avec px

Au tout début du Web, nous utilisions les pixels pour dimensionner notre texte. Cette solution est fiable et cohérente. Malheureusement, les utilisateurs d'Internet Explorer (même IE9) ne peuvent pas changer la taille du texte en utilisant la fonction native de redimensionnement du texte de leur navigateur. Pour ceux d'entre nous qui se soucient de la convivialité de leur site web, cela peut poser un gros problème. Les versions récentes d'IE incluent une fonction de zoom, mais elle augmente la taille de tout le contenu de la page (une fonctionnalité également présente dans la plupart des autres navigateurs courants). Cela a permis de limiter le problème jusqu'à un certain point.

Pour ma part, je suis du côté de ceux qui pensent que les mises en page en pixels apportent la cohérence nécessaire, et que les utilisateurs possèdent suffisamment d'outils dédiés à l'affichage pour arrêter de penser que l'accessibilité est si préoccupante. Mais je digresse. Que pouvons‑nous faire d'autre ?

Dimensionnement avec em

L'impossibilité totale de redimensionner le texte avec IE est une frustration permanente. Pour contourner le problème, nous pouvons utiliser les unités en em. L'article de Richard Rutter « How to size text using ems » [1] est probablement le premier que j'ai lu à propos de cette approche ; c'était en 2004. (Wow, bientôt sept ans.)

Cette technique modifie la taille du texte de base du body grâce à des pourcentages. L'ensemble est ajusté de telle sorte qu'1em est égal à 10px, au lieu des 16px par défaut. Pour définir une taille de fonte équivalente à 14px, réglez‑la à 1.4em.

body { font-size: 62.5%; }
h1 { font-size: 2.4em; } /* =24px */
p { font-size: 1.4em; } /* =14px */
li { font-size: 1.4em; } /* =14px? */

Le problème avec le dimensionnement par em est que les tailles agissent en cascade : une liste dans une liste ne fait pas 14px, elle fait 20px. Un niveau plus loin, et elle fera 27px ! Ce problème peut être contourné en définissant une taille de 1em pour chacun des éléments enfants, annulant ainsi l'effet de cascade.

body { font-size: 62.5%; }
h1 { font-size: 2.4em; } /* =24px */
p { font-size: 1.4em; } /* =14px */
li { font-size: 1.4em; } /* =14px? */
li li, li p /* etc */ { font-size: 1em; }

La nature combinatoire du dimensionnement par em peut être frustrante, que pouvons‑nous donc faire d'autre ?

Dimensionnement avec rem

CSS3 introduit un certain nombre de nouvelles unités, dont le rem, qui signifie « root em » [2]. Si vous n'êtes pas encore profondément endormis, regardons un peu comment fonctionne rem.

L'unité em est relative à la taille de la fonte du parent, ce qui crée un effet de cascade problématique. L'unité rem est relative à l'élément racine : la balise html. Cela signifie que nous pouvons ne définir qu'une seule taille de police sur l'élément html, puis composer toutes les tailles en rem comme pourcentages de cette valeur initiale.

html { font-size: 62.5%; } body { font-size: 1.4rem; } /* =14px */
h1 { font-size: 2.4rem; } /* =24px */

Je définis une taille de police initiale de 62.5% pour bénéficier des mêmes avantages qu'un dimensionnement en px.

Mais à quel piètre support devons‑nous nous attendre du côté des navigateurs ?

Vous serez surpris d'apprendre que le support des navigateurs est tout à fait honnête : Safari 5, Chrome, Firefox 3.6+, et même Internet Explorer 9 supportent cette unité. Le plus beau est qu'IE9 permet de redimensionner le texte s'il est défini en rem. (Hélas, Opera (jusqu'à 11.10, au moins) n'a pas encore implémenté l'unité rem.)

Que faire pour les navigateurs qui ne supportent pas l'unité rem ? Nous pouvons spécifier une solution de secours en px, si cela ne vous ennuie pas que les utilisateurs d'anciennes versions d'Internet Explorer soient toujours incapables de redimensionner le texte (enfin, il existe toujours le zoom pleine page sur IE7 & IE8). Pour ce faire, nous spécifions la taille en px, puis nous la définissons une seconde fois en utilisant l'unité rem.

html { font-size: 62.5%; } body { /* =14px */ font-size: 14px; font-size: 1.4rem;
}
h1 { /* =24px */ font-size: 24px; font-size: 2.4rem;
}

Et voilà ! Nous avons maintenant un dimensionnement du texte cohérent et prévisible dans tous les navigateurs, et du texte redimensionnable dans la dernière version des navigateurs principaux.

[1] Comment dimensionner du texte en utilisant les em

[2] em à l'origine (racine)

Pourquoi les menus affichés au survol font plus de mal que de bien aux utilisateurs

Evren Kiefer — 2011-08-09T05:48:02Z

Avez-vous déjà pensé à la façon dont vos menus affectent les utilisateurs ? Les menus sont un moyen populaire de permettre aux utilisateurs de naviguer sur un site web. Mais quand ils s'ouvrent lors du survol, ils peuvent causer de nombreux problèmes d'ergonomie que la plupart des concepteurs ignorent.

Le mythe du survol

De nombreux designers semblent croire que les menus affichés au survol sont plus rapides et plus simples pour la plupart des utilisateurs. Cela semble être le cas au premier abord, mais en y regardant de plus près vous remarquerez que ce n'est pas vrai. Ces menus sont en réalité plus lents et plus difficiles à utiliser pour une majorité d'utilisateurs. Les menus affichés au survol économisent un clic, pourtant ce clic est nécessaire pour faire savoir au site que l'utilisateur souhaite et s'attend à l'ouverture du menu. Cela confirme également à l'utilisateur que quelque chose se passe en réponse à son clic. Ce comportement correspond à son modèle mental du fonctionnement de la plupart des sites web. Cliquer pour obtenir ce qu'il veut n'a jamais été un problème pour l'utilisateur. En revanche, un problème se pose quand le simple fait de survoler un élément provoque un résultat non désiré et inattendu.

Sur un site web, les utilisateurs survoleront souvent de nombreux éléments à la souris. La plupart des utilisateurs le fait pour déterminer quels éléments sont cliquables. C'est quand il indique aux utilisateurs qu'un élément est cliquable que le survol est le plus utile. Mais lorsqu'il ouvre quelque chose avant que l'utilisateur ne l'ait demandé, il peut surprendre et désorienter les utilisateurs. Il n'y a aucun intérêt à obtenir très rapidement quelque chose qu'on ne désire pas. Quand cela se produit, cela devient plus une nuisance qu'un bienfait.

Même si les utilisateurs cherchent à ouvrir un menu, le survol ne le rend pas plus rapide si le menu est difficile à utiliser. Les menus affichés au survol sont connus pour être difficiles à utiliser pour plusieurs raisons. Cliquer l'item d'un menu affiché au survol n'est pas toujours aussi facile qu'il y paraît.

Les menus affichés au survol obligent à emprunter des tunnels invisibles

Un des plus grands désavantages des menus affichés au survol est qu'ils forcent les utilisateurs à déplacer habilement leur curseur au travers de tunnels de survol. Les tunnels de survol sont des parcours au travers desquels les utilisateurs doivent manœuvrer dans le but de cliquer sur un élément de menu. Les utilisateurs plus âgés qui sont moins à l'aise avec la technologie auront des problèmes à le faire. Même les utilisateurs les plus habitués à la technologie trouvent désagréable de devoir exécuter un parcours difficile pour cliquer sur un élément de menu.

Non seulement cela rend le menu plus difficile à utiliser mais aussi moins efficace en empêchant les utilisateurs d'atteindre leur objectif de navigation rapidement. Parce que lorsque le menu s'ouvre, les utilisateurs ne peuvent pas déplacer le pointeur de la souris directement vers l'élément sur lequel ils désirent cliquer. S'ils le font, le menu se fermera accidentellement. Au lieu de cela, ils doivent manœuvrer la souris à travers le tunnel de survol à chaque fois qu'ils souhaitent cliquer sur un élément de menu. Il n'y a pas de raison pour que les utilisateurs peinent autant pour naviguer à travers un site web.

Les menus affichés au survol rendent les éléments périphériques lents et difficiles à cliquer

Les menus affichés au survol se ferment dès que le pointeur de la souris sort du menu. Cela rend les éléments périphériques plus difficiles à activer car ils se trouvent au plus près du bord du menu. Les utilisateurs ne peuvent pas bouger la souris rapidement pour cliquer sur un élément. Ils doivent ralentir le mouvement à mesure qu'ils s'approchent des éléments périphériques qui sont plus éloignés. De plus, comme la plupart des éléments de menu sont des liens textuels en petits caractères, la cible est d'autant plus petite et cela ajoute à la lenteur de l'action. La loi de Fitts confirme cet effet : « les cibles les plus petites ou éloignées nécessitent plus de temps pour être atteintes ».

Si les utilisateurs ne ralentissent pas le mouvement de la souris pour arriver précisément sur un élément périphérique du menu, le menu se ferme et ils n'ont plus qu'à recommencer. Dans certains menus, les éléments sont séparés du bord par des marges internes (padding) de façon à ce que le menu reste ouvert si les utilisateurs manquent de peu leur cible. Cependant, même l'ajout de marge interne ne constitue pas une solution idéale car le menu peut toujours se fermer si les utilisateurs bougent leur souris trop loin. Ce n'est pas normal que les utilisateurs commettent des erreurs à cause de leur façon de bouger la souris.

Les menus affichés au survol rendent les pages d'index plus difficiles à trouver

De nombreux sites utilisant les menus affichés survol ont souvent des pages d'index. Ces pages donnent aux utilisateurs des informations détaillées à propos des éléments de menus pour qu'ils puissent faire un meilleur choix. Ces pages d'index ne peuvent pas aider les utilisateurs s'ils ne peuvent pas les trouver. Des pages d'index sont souvent cachées dans l'élément principal que les utilisateurs survolent avec leur souris. La plupart des utilisateurs ne sauront pas cliquer sur l'élément principal du menu pour se rendre sur la page d'index car le surlignement montre que l'élément est déjà sélectionné. Cela nuit aux nouveaux utilisateurs qui ont souvent besoin des informations détaillées fournies par les pages d'index pour choisir leur destination. Si vous avez une page d'index, vous devriez rendre sa position sur le menu claire de façon à ce que les utilisateurs qui en ont besoin puissent l'utiliser.

Les menus s'ouvrant par clic

Les menus affichés au clic plutôt que par survol à la souris règlent chacun de ces problèmes. Avec des menus affichés au clic, les utilisateurs seront libérés des tunnels de survol, des éléments périphériques difficiles à atteindre et des pages d'index cachées.

Il existe trois approches utilisables pour les menus affichés au clic. La première approche est la plus simple et la plus normale. Quand l'utilisateur clique l'élément général, le menu s'ouvre. Il se ferme seulement quand l'utilisateur clique en dehors du menu. Cette approche permet aux utilisateurs de déplacer la souris de la façon désirée sans affecter le menu. La fermeture du menu est aussi aisée que l'ouverture.

Le menu affiché au clic vous force également à mettre le lien vers la page d'index dans le menu plutôt que de le cacher dans l'élément général du menu. Si les utilisateurs cliquent l'élément général du menu, le menu se ferme. Ainsi, faire de l'élément général un lien vers la page d'index n'est plus une option. Il faut faire de l'index un élément du menu. Les utilisateurs verront clairement comment se rendre sur les pages d'index.

Un autre type de menu affiché au clic qui rendra vos pages d'index claires et visibles est le menu à index développable. Avec un menu à index développable, les utilisateurs peuvent accéder à la page d'index aisément en cliquant sur l'élément général. Par contre, les utilisateurs qui souhaitent accéder au menu peuvent cliquer sur la flèche de développement de l'index. Cette approche sépare les pages d'index du menu de façon à ce que les utilisateurs puissent accéder aux pages d'index plus facilement sans avoir à les chercher dans le menu. Cette approche prend en compte à la fois les utilisateurs nouveaux qui souhaitent utiliser les pages d'index, et les utilisateurs habitués qui souhaitent probablement utiliser le menu.

La dernière approche pour le menu affiché au clic est le menu accordéon. Ce menu a l'avantage de ne pas cacher le contenu qui se situe en dessous. À la place, il pousse le contenu de la page vers le bas en s'ouvrant. Cette approche est magnifique pour les énormes menus qui prennent beaucoup de place. Un menu accordéon permet d'afficher votre méga menu sans cacher le haut de la page. Les menus accordéons se referment lorsque les utilisateurs cliquent l'élément général une nouvelle fois. La flèche change d'orientation et pointe alors vers le bas pour informer les utilisateurs de ce qui s'est passé.

Ces trois approches de menus affichés au clic règlent tous les problèmes posés par les menus affichés au survol. Ils sont tellement plus rapides et faciles à utiliser que les menus à survol qu'on se demande pourquoi plus de sites ne les utilisent pas. Ils sont aussi plus faciles à comprendre pour les utilisateurs car ils s'ouvrent par clic, lorsque les utilisateurs le souhaitent alors que les menus affichés au survol s'ouvrent parfois sans que les utilisateurs ne le souhaitent ou ne s'y attendent. Les bénéfices de l'utilisation d'un menu affiché au clic sont clairs. Un menu permettant aux utilisateurs de naviguer rapidement et facilement est meilleur qu'un menu apparemment sympathique qui empêche les utilisateurs de naviguer convenablement.

Désacraliser les tests d'utilisabilité

Goulven Champenois — 2011-06-30T01:00:00Z

Un certain nombre de personnes semble penser que les tests d'utilisabilité sont mauvais, que ce n'est plus à la mode, ou que les designers n'ont plus besoin d'en faire. Et si je vous disais qu'au contraire, il n'y a rien de plus branché dans l'étude de l'expérience utilisateur ?

Chaque fois que quelqu'un vit une expérience de qualité en interagissant avec un site ou une application web, un gadget ou un service, c'est parce qu'une équipe de designers a pris d'excellentes décisions, décisions nourries par des données sur comment les gens interagissent avec un design. Comment ont‑ils obtenu ces données ? Par des tests d'utilisabilité.

Jared Spool [1] ne se fait jamais prier pour expliquer que toutes les mauvaises décisions qui vouent un design à l'échec viennent d'un manque d'information, d'après une étude de sa compagnie. Observer les utilisateurs permet de prendre de bonnes décisions en toute confiance et certitude. Et pourquoi cette technique plutôt qu'une autre ? Parce que selon moi, 80% de la valeur ajoutée de ces tests vient de la magie qui opère quand on observe et qu'on écoute les gens pendant qu'ils se servent d'un design. Ce qu'on voit et entend est souvent surprenant, parfois éclairant, et par‑dessus tout imprévisible. Et cette imprévisibilité est difficile à capturer autrement.

Les 20% restants viennent des discussions préliminaires durant lesquelles les membres de l'équipe choisissent leurs « Grandes questions », ainsi que des discussions récapitulatives au cours desquelles ils décident quoi faire de ce qu'ils ont constaté durant les tests.

Différents objectifs, différents types de tests

Quand je vous parle de « Test d'utilisabilité », vous imaginez probablement une sorte d'expérience psychologique : un « Sujet » est enfermé avec des cartes d'actions, peut‑être même branché à des capteurs biométriques, pendant que « l'Observateur » se tient dans une pièce séparée, enregistrant les moindres faits et gestes tout en dictant ses instructions via un intercom, telle une présence divine.

Cette image correspond aux « tests formels », qui sont le plus souvent sommatifs. Ils servent à vérifier que le design fonctionne bien tel que prévu.

Ce type de tests se réalise plutôt en fin de cycle de conception. Ce qui m'intéresse davantage (comme la plupart d'entre vous) concerne surtout l'exploration et l'évaluation, en début de cycle.

Le processus classique

Dans le Manuel des tests d'utilisabilité (Handbook of usability testing, 2^nd edition), Jeff Rubin et moi‑même présentions ce qui peut servir à mener des tests formels, aussi bien que des tests plus décontractés qui permettent d'explorer des idées et de former des concepts et des designs. Quel que soit le type de test, les étapes restent grosso modo les mêmes.

Concevoir un plan de test ;
Choisir les conditions du test ;
Trouver et sélectionner les participants ;
Préparer le guide de test ;
Diriger les sessions ;
Noter les remarques des participants et observateurs ;
Analyser les données et observations ;
Tirer des conclusions et proposer des recommandations.

Passons en revue chaque étape.

Concevoir un plan de test

Installez‑vous avec l'équipe et accordez‑vous sur un objectif de test (ne vous contentez pas de « Déterminer si c'est utilisable »), la formulation des questions, et les caractéristiques des personnes à interroger (on préfère les appeler « Participants » que « Cobayes »). Le plan de test inclut aussi les méthodes et mesures qui seront utilisées pour obtenir les réponses aux questions du test. Il est entièrement possible de boucler ces points en moins d'une heure. Notez bien tout et choisissez le membre de l'équipe qui sera modérateur des sessions de test.

Choisir les conditions du test

Utiliserez‑vous un laboratoire ? Sinon, quel type d'équipement ? Les sessions seront‑elles enregistrées ? Ici encore, l'équipe devrait décider de ces choses‑là ensemble. Il est bon d'inclure ces questions logistiques dans le plan de test.

Trouver et sélectionner les participants

Il est beaucoup plus simple de choisir en fonction de la tâche à observer que de chercher à coller à la segmentation du marché ou à la démographie. Si vous étudiez un système de téléconférence par Internet, prenez des gens qui donnent ou suivent des téléconférences. Si vous testez le processus de réservation d'hôtel sur un site web, faites appel à des gens qui réservent des chambres d'hôtel. Si vous étudiez un guichet aiguillant des personnes intégrant ou quittant un programme d'étude, recrutez des gens qui suivent ces programmes. Vous voyez le topo ? Pas la peine de se compliquer la vie pour le recrutement.

Préparer le guide de test

Vous aurez besoin d'une sorte de guide ou de check‑list pour vous assurer que le modérateur fait bien le tour des questions du test. Il ne doit pas les poser directement aux participants ; elles doivent être transformées en scénarios de tâches représentant des objectifs utilisateurs réalistes.

Ce document doit également contenir les questions que vous souhaitez poser à tous les participants, des débuts de phrase pour les inciter à élaborer, ainsi que les questions à poser en conclusion du test.

Diriger les sessions

Le modérateur devient maître de cérémonie durant chaque session. Il doit être garant de la sécurité et du confort des participants, s'assurer que les observateurs parmi l'équipe sont attentifs et ne perturbent pas le déroulement, et vérifier que les données sont collectées.

Il ne doit y avoir qu'un seul modérateur par session, mais un maximum de membres de l'équipe doit assister aux tests. Si vous choisissez de réaliser plusieurs sessions de tests individuels, chaque membre de l'équipe doit assister à deux de ces sessions au moins.

Noter les remarques des participants et observateurs

À la fin de chaque session, pensez bien à prendre du recul avec le participant, et à lui demander son ressenti. Invitez également les observateurs à faire passer leurs questions au modérateur, ou à les poser eux‑mêmes. Remerciez le participant, rémunérez‑le, et dites‑lui au revoir.

Vient ensuite le moment où les observateurs doivent résumer ce qu'ils ont vu et entendu, sans pour autant commencer à chercher à analyser et à trouver des solutions.

Analyser les données et observations

À la fin d'un test d'utilisabilité, vous savez ce que vous avez observé, ce que votre équipe a vu et entendu. En étudiant ensemble les observations effectuées, un schéma se dessine et vous permet de réfléchir à ce qui provoque certains comportements particuliers. De ces comportements, vous pouvez commencer à imaginer ce qui frustre vos utilisateurs et leur pose des problèmes. Grâce à ces hypothèses, votre équipe pourra utiliser son expertise pour proposer des solutions aux problèmes détectés dans le design. Il est ensuite possible de modifier le produit et de confronter ces hypothèses à une deuxième session de test.

Ce que vous obtenez

En suivant ce processus pas à pas, vous obtenez un planning impeccable, respecté au millimètre, des tonnes de données, des analyses rigoureuses, et le plus important : des résultats. Au passage, vous obtiendrez également de la documentation. Ça peut paraître beaucoup, et parfois c'est nécessaire.

En fait, la plupart des tests d'utilisabilité doivent être plus simples et plus rapides. Certaines des meilleures équipes d'expérience utilisateur ne font que quelques heures de tests par mois, sinon moins, et sans forcément les concevoir comme telles. Pour eux, cela s'appelle simplement « rassembler des idées », ou « obtenir des retours utilisateurs ».

Peu importe le nom, pourvu que vous observiez des gens utilisant votre design, c'est un test d'utilisabilité.

Quelqu'un, quelque chose, quelque part

Je vous assure, tout ce dont vous avez besoin pour un test d'utilisabilité, c'est d'un utilisateur de votre design (ou de quelqu'un qui joue son rôle), quelque chose à tester (un design, achevé ou non), et quelque part où confronter l'utilisateur et le design et où vous puissiez observer cette rencontre. Cet endroit peut même être éloigné, cela dépend surtout de l'état d'achèvement du design. Vous n'êtes même pas obligés d'utiliser un laboratoire et tout l'équipement qui va avec.

Une fois que vous serez habitué à faire ce genre de tests, vous trouverez des moyens d'aller plus vite et de réduire le processus aux seules étapes qui vous aident vraiment. En général, les étapes essentielles à une étude d'utilisabilité sont les suivantes :

Préparer le guide de test

Le processus classique implique un guide de test qui peut faire plusieurs pages. Une équipe bien rodée peut se contenter d'une structure minimale d'une ou deux lignes spécifiques aux éléments du test.

Trouver des participants

Je le répète, tout est question de comportement. Il faut viser ici l'attitude qu'ont les parents qui poussent leurs enfants dans des études post‑bac. Assurez‑vous surtout de :

Connaître vos utilisateurs ;
Leur laisser le temps ;
Être flexible ;
Vous souvenir qu'ils sont humains ;
Récompenser généreusement.

Diriger les sessions

Si vous êtes le modérateur, faites le maximum pour être impartial et dénué de préjugés. Essayez d'être simplement présent et de voir ce qui se passe. Le concepteur de l'interface peut assumer ce rôle lui‑même, ce qui vous permet de prendre du recul et de considérer l'exercice objectivement.

Rappelez‑vous que le but n'est pas d'apprendre au participant à se servir du design. Demandez‑lui d'effectuer une tâche réaliste et laissez les choses se passer, en ayant les yeux et les oreilles grands ouverts. Bien sûr, s'il s'agit d'une tâche courante et que le participant n'y arrive pas pendant la session, indiquez‑lui comment faire une fois que vous aurez obtenu vos informations.

Au cours de la session, posez des questions ouvertes : Pourquoi… ? Comment… ? Qu'est‑ce qui… ?

Tirer des conclusions et proposer des recommandations

Parlez. Considérez toutes les idées sans vous censurer. Mettez‑vous d'accord. À moins que le design ait été parfait au moment où le test a été effectué (c'est extrêmement rare), et même si l'équipe n'a fait qu'une ou deux sessions, analysez vos observations et tirez‑en des théories expliquant pourquoi les choses se sont passées de cette manière. Modifiez quelques éléments et recommencez le cycle.

Comment naissent les designs proposant une expérience particulièrement agréable ? De l'observation des utilisateurs

Obtenir des retours utilisateurs est fantastique, et connaître leurs contraintes est important. Les retours des plates‑formes téléphoniques et du personnel de support technique sont également d'une grande aide pour créer et améliorer les designs. Peu importe le terme employé dans votre équipe (tests d'utilisabilité, tests d'ergonomie, retours utilisateur), pour justifier les décisions prises concernant le design, les meilleures données sont celles obtenues en étudiant le comportement et les performances de personnes utilisant un design afin d'atteindre leurs propres buts.

Les équipes disposant de beaucoup de données prennent de meilleures décisions. Et neuf fois sur dix, ces données viennent de tests d'utilisabilité.

Si cela vous intéresse, vous pouvez télécharger gratuitement des exemples et modèles de plans de tests, formulaires de consentement et guides de sessions depuis le site compagnon du Manuel des tests d'utilisabilité : www.wiley.com/go/usabilitytesting.

[1] NdT : Fondateur d'une société de recherche, formation et consulting en utilisabilité

Introduction au positionnement CSS

Frédéric Chotard — 2011-05-31T01:00:00Z

Si vous êtes un développeur ou un designer qui aime le code, les mises en page basées sur les CSS représentent le cœur même de votre travail. Histoire de rafraîchir la mémoire de certains, ou d'en aider d'autres à découvrir le sujet, jetons un coup d'œil à la propriété CSS position pour voir comment construire des thèmes CSS conformes aux standards et garantis sans tableaux.

Tout est dans la position

Le positionnement CSS est souvent mal compris. Parfois, enragé par un bug, nous appliquons différentes valeurs à la position d'un sélecteur quelconque, jusqu'à en trouver une qui fonctionne. C'est un processus pénible qui peut faire l'affaire un certain temps, mais il serait mieux de savoir pourquoi indiquer position: relative parvient à régler notre bug d'affichage. Mon but est que nous puissions aprendre les valeurs et les comportements de la propriété position, et surtout comprendre comment une valeur peut affecter notre mise en page. La spécification CSS nous offre cinq valeurs pour la propriété position : static, relative, absolute, fixed et inherit. Chaque valeur correspond à un objectif précis. C'est en comprenant cet objectif que l'on pourra maîtriser les mises en page en CSS.

Suivez le flot

Commençons par prendre un peu de recul pour reconnaître le terrain sur lequel nous travaillons. Tout comme dans la vraie vie, en CSS nous travaillons au sein de limites. En CSS, cette limite s'appelle le flux normal. On lit dans la spécification CSS 2.1 que :

Les boîtes dans un flux normal appartiennent à un contexte de mise en forme, bloc ou en-ligne, mais pas les deux en même temps. Les boîtes de bloc participent à un contexte de mise en forme bloc, les boîtes en-ligne à un contexte de mise en forme en-ligne.

(NDT : traduction française de la recommandation CSS 2 du W3C)

Il faut voir les « boîtes » décrites dans ce texte comme des cubes en bois, du même genre que ceux avec lesquels vous jouiez quand vous étiez gamin impétueux. Il vous faut maintenant voir le flux normal comme une loi semblable à la loi de la gravitation. Le flux normal du document, c'est la façon dont vos éléments s'empilent les uns sur les autres, de haut en bas, suivant l'ordre où ils apparaissent dans votre code. Souvenez‑vous quand vous construisiez des tours géantes avec vos cubes : le flux normal, c'est le même principe que ces cubes de bois liés entre eux par la loi de la gravitation. Dans votre jeu d'enfant, vous placiez les cubes les uns sur les autres ; dans votre balisage, vous obtenez un élément après l'autre. Une chose que vous ne pouviez pas faire quand vous étiez enfant, en revanche, était de donner à ces cubes des propriétés qui défieraient la loi de la gravitation. Tout d'un coup, les CSS paraissent nettement plus sympa que vos cubes.

`Static` et `relative` : rien de nouveau jusqu'ici

Les valeurs static et relative attribuées à position se comportent comme vos cubes en bois — ils se superposent les uns les autres. Notez que static constitue la valeur par défaut de tout élément, faute d'y appliquer une autre. Si vous mettez trois éléments positionnés en static dans votre code, ils vont se placer les uns sur les autres, sans surprise. Voyons cet exemple avec trois éléments, chacun recevant la valeur static pour la propriété position :

#box_1 { position: static; width: 200px; height: 200px; background: #ee3e64;
} #box_2 { position: static; width: 200px; height: 200px; background: #44accf;
} #box_3 { position: static; width: 200px; height: 200px; background: #b7d84b;
}

Dans l'exemple A, vous pouvez voir trois éléments superposés comme une simple tour. Merveilleux, n'est‑ce pas ? Vous venez de passer votre premier niveau de positionnement CSS. Félicitations !

Vous pouvez utiliser la valeur static pour des mises en page simples, à colonne unique, où chaque élément vient se poser sur le suivant. Si vous voulez commencer à déplacer ces éléments à l'aide de propriétés de décalage comme top, right, bottom et left, vous êtes coincé. Ces valeurs ne sont pas disponibles pour un élément static. En fait, un élément statique ne peut même pas créer un nouveau système de coordonnées pour des éléments descendants. Hein ? Quoi ? C'est quoi, cette histoire de « système de coordonnées » ? Ne bougez pas, j'ai compris le message. Je vais vous expliquer à l'aide de la valeur relative.

Les éléments qui reçoivent un positionnement relatif se comportent de la même façon que ceux qui sont statiques : ils s'entendent bien avec leurs voisins, s'empilent gentiment et ne mettent pas le bazar. À peine croyable, non ? Souvenez‑vous de notre exemple précédent. Cette fois, nous avons appliqué la valeur relative :

#box_1 { position: relative; width: 200px; height: 200px; background: #ee3e64;
} #box_2 { position: relative; width: 200px; height: 200px; background: #44accf;
} #box_3 { position: relative; width: 200px; height: 200px; background: #b7d84b;
}

L'exemple B montre que les éléments positionnés en relatif se comportent de façon tout à fait identique à ceux positionnés en statique. Mais ce que vous ne savez peut‑être pas, c'est que les éléments qui ont la valeur relative sont comme Clark Kent : ils dissimulent de bien plus grands pouvoirs que leurs congénères statiques…

Pour débuter, nous pouvons attribuer l'une de ces décalages à un élément relatif : top, right, bottom ou left. À l'aide du balisage tiré de notre exemple précédent, appliquons un décalage à #box_2 :

#box_2 { position: relative; left: 200px; width: 200px; height: 200px; background: #44accf;
}

L'exemple C montre ce que donne ce positionnement avec relative. Nos trois blocs s'empilent gentiment, mais cette fois le bloc bleu (#box_2) s'écarte de 200 pixels du bord gauche. C'est ici que nous commençons à modifier la loi de la gravitation à notre guise. Le bloc bleu est toujours dans le flux du document (puisque les éléments s'empilent les uns sur les autres), mais observez le bloc vert en bas (#box_3) : il est placé sous le bloc bleu, alors même que celui‑ci n'est pas directement au‑dessus de lui. Quand nous utilisons un décalage pour déplacer un élément positionné en relatif, cela n'affecte pas les éléments qui le suivent. Le bloc vert reste placé comme si le bleu n'était pas décalé. Essayez ça avec des cubes en bois…

Autre super‑pouvoir de la valeur relative : la possibilité de créer un système de coordonnées pour ses éléments enfants. Un système de coordonnées est un point de référence pour les décalages. Souvenez‑vous de l'exemple C, notre bloc bleu (#box_2) n'est situé à l'intérieur d'aucun autre élément, donc le système de coordonnées qu'il utilise pour se décaler à 200 pixels de la gauche du document est le document lui‑même. Si nous plaçons l'élément #box_2 à l'intérieur de #box_1, nous obtiendrons un autre résultat, car #box_2 va se positionner relativement au système de coordonnées de #box_1. Pour l'exemple suivant, nous ne modifierons rien au CSS, mais nous allons retoucher notre code HTML pour déplacer #box_2 à l'intérieur de #box_1 :

L'exemple D montre ce que donne notre nouveau balisage. À cause du nouveau système de coordonnées, le bloc bleu calcule son décalage de 200 pixels à partir de la gauche du bloc rouge (#box_1) et non plus à partir du document. Cette pratique est plus courante quand les éléments se voient attribuer position: absolute — tel que vous auriez aimé construire vos tours.

`Absolute` : n'inporte où, n'inporte quand

Si la valeur relative se comporte comme Superman, alors la valeur absolute renvoie à Inception — un lieu où vous pouvez concevoir votre propre univers. Contrairement aux valeurs static et relative, un élément positionné de façon absolue est retiré du flux normal. Cela veut dire que vous pouvez le mettre où vous voulez, car il n'affectera ou ne sera affecté par aucun autre élément dans le flux. Voyez‑le comme un élément doté d'un grand morceau de velcro dans le dos. Il suffit de lui dire où se coller, et il va y rester. De la même façon que pour la valeur relative, les éléments positionnés en absolu vont répondre aux décalages. Vous pouvez placer un élément à top: 100px et left: 200px, et cet élément se mettra exactement à 100px du haut du document, et à 200px de son bord gauche. Voyons un exemple en utilisant quatre éléments :

#box_1 { position: absolute; top: 0; left: 0; width: 200px; height: 200px; background: #ee3e64;
}
#box_2 { position: absolute; top: 0; right: 0; width: 200px; height: 200px; background: #44accf;
}
#box_3 { position: absolute; bottom: 0; left: 0; width: 200px; height: 200px; background: #b7d84b;
}
#box_4 { position: absolute; bottom: 0; right: 0; width: 200px; height: 200px; background: #ebde52;
}

L'exemple E nous montre quatre boîtes, chacune située dans un coin de la fenêtre du navigateur. Comme nous avons fixé en absolute la position de chaque boîte, c'est comme si nous avions collé une boîte au velcro dans chaque coin de la fenêtre du navigateur. Si nous redimensionnons cette fenêtre, les boîtes resteront dans leurs coins respectifs. Si vous réduisez le navigateur de telle sorte que les boîtes se recouvrent, vous remarquerez qu'il n'existe aucune interaction : c'est parce qu'elles sont exclues du flux normal du document.

Tout comme les éléments placés de façon relative, ceux qui le sont de manière absolute créent un nouveau système de coordonnées pour les éléments enfants. L'exemple F modifie l'exemple E en plaçant un élément orange à l'intérieur de chaque boîte. Remarquez que les coordonnées de décalage fonctionnent par rapport à chaque élément parent.

Histoire de ne pas se faire doubler par d'autres valeurs de positionnement, la valeur absolute offre certaines fonctionnalités vraiment très pratiques en utilisant les propriétés de décalage. Si vous prenez deux de ces propriétés, voire toutes les quatre, vous pouvez étirer un élément sans lui définir de largeur ni de hauteur : il n'est limité que par son élément-parent, ou bien par le document lui‑même. Voyons cela en action. Si vous prenez le code suivant :

#box_1 { position: absolute; top: 10px; right: 10px; bottom: 10px; left: 10px; background: #44accf;
}
#box_2 { position: absolute; top: 20px; right: 20px; bottom: 20px; left: 20px; background: #ff9c34;
}

Dans l'exemple G, nous avons créé une bordure décalée de dix pixels par rapport au bord du document, et cela reste parfaitement fluide si on redimensionne la fenêtre : le tout est réalisé avec un positionnement et des décalages en absolute. Dans un autre exemple, nous pouvons créer une mise en page en deux colonnes qui occupe toute la hauteur du document. Voici la CSS :

#box_1 { position: absolute; top: 0; right: 20%; bottom: 0; left: 0; background: #ee3e64;
} #box_2 { position: absolute; top: 0; right: 0; bottom: 0; left: 80%; background: #b7d84b;
}

L'exemple H montre une mise en page en deux colonnes occupant tout l'écran. Même s'il ne s'agit sans doute pas de la meilleure façon de concevoir une mise en page en deux colonnes, cela montre quand même toute la puissance de la valeur absolute. En réfléchissant un peu au‑delà, vous pouvez trouver de nombreuses applications utiles à position: absolute. Des manipulations du même genre n'exploitent qu'une seule valeur de décalage. Par exemple :

#box_1 { width: 200px; height: 200px; background: #ee3e64;
}
#box_2 { position: absolute; left: 100px; width: 200px; height: 200px; background: #44accf;
}

Dans l'exemple H2, regardez bien le bloc bleu. Remarquez que je n'utilise qu'un seul décalage, left: 100px;. Cela permet à l'élément #box_2 de maintenir sa position verticale, tout en s'éloignant de la gauche de 100 pixels . Si nous appliquions un second décalage de zéro par rapport au bord supérieur, nous verrions que notre bloc bleu (#box_2) est tiré vers le haut du document. On peut le voir ici, dans l'exemple H3 :

#box_2 { position: absolute; top: 0; left: 100px; width: 200px; height: 200px; background: #44accf;
}

`Fixed` : personne ne bouge !

Un élément auquel on a attribué position: fixed partage les mêmes règles qu'un élément positionné en absolu, mise à part que c'est la zone d'affichage (fenêtre du navigateur ou du périphérique) qui détermine le placement de l'élément « fixé » (fixed), et non pas un élément parent. D'autre part, un élément fixed ne défile pas avec le document. Il reste… fixe, quoi ! Voyons un exemple :

#box_2 { position: fixed; bottom: 0; left: 0; right: 0; }

L'exemple I montre un pied de page (« footer ») avec à l'intérieur un texte de copyright. Ce pied de page constitue un élément fixe. Si vous faites défiler le document, vous verrez qu'il ne bouge pas. Remarquez que les propriétés de décalage left et right sont mises à zéro. Dans la mesure où la valeur fixed se comporte de la même façon que la valeur absolute, nous pouvons étirer la largeur de l'élément pour qu'il occupe toute la place du support de visualisation, tout en fixant cet élément en bas grâce à bottom: 0. Mais attention à fixed : son support dans les navigateurs anciens est plus mauvais qu'autre chose. Par exemple, d'anciennes versions d'Internet Explorer interprètent les éléments fixed comme des éléments avec static. Or vous savez maintenant que les éléments statiques ne se comportent pas comme les fixes, n'est‑ce pas ? Si vous voulez vraiment utiliser des éléments fixes dans une mise en page, il existe plusieurs solutions qui vous aideront à faire en sorte que votre élément se comporte comme prévu dans des navigateurs qui ne comprennent pas la valeur fixed.

`Inherit` : pour que rien ne change

Comme je l'ai évoqué au début de cet article, il y a cinq valeurs possibles pour la propriété position. La cinquième est inherit. Elle fonctionne comme l'indique son nom : l'élément hérite de la valeur de son élément parent. En principe, les éléments qui ont une valeur de positionnement n'héritent pas naturellement des valeurs de leurs parents, puisque la valeur static est assignée par défaut si aucune valeur de positionnement n'est indiquée. Mais vous pouvez saisir inherit ou bien la valeur de l'élément parent, et ainsi obtenir la même valeur.

Dans les faits

Assez de blabla et passons à l'action. Jetons un œil à un exemple de site web qui utiliserait toutes les valeurs de positionnement. L'exemple J montre la mise en page typique d'un site contenant un en-tête, la navigation, le contenu, et un pied de page. Voyons chaque élément l'un après l'autre pour parler de son positionnement et comprendre les choix qui ont été faits.

Commençons par notre élément #container. Il s'agit simplement de l'élément conteneur que j'utilise pour centrer notre contenu dans la fenêtre de visualisation. L'élément de navigation #nav est le premier élément inclus dans notre élément #container. Cet élément #nav ne reçoit aucune propriété de positionnement, donc par défaut, sa valeur sera static. Ça nous va très bien : nous n'avons aucun besoin de décaler cet élément, ni de créer par son biais de nouveau système de coordonnées. En revanche, c'est ce dont nous aurons besoin avec #content, notre prochain élément. C'est pourquoi nous lui avons appliqué une position relative.

Comme nous ne mettons ici en œuvre aucun décalage, la valeur de position n'a pas de réelle influence sur l'élément #content, mais nous l'avons placé là pour créer un nouveau système de coordonnées pour l'élément #callout (l'encadré latéral). Nous assignons position: absolute à notre élément #callout, et puisque son élément parent (#content) est placé en relative, les propriétés de décalage que nous appliquons à #callout se basent sur les coordonnées créées par #content. L'élément #callout utilise un décalage négatif de 80 pixels à droite pour tirer cet élément vers l'extérieur de l'élément parent qui le contient. De plus, j'ai employé sur l'élément #callout l'une des possibilités les plus cool que nous offre la valeur absolute : en situant les décalages en haut et en bas à 100px, j'ai étiré l'élément #callout qui prend maintenant toute la hauteur du document, moins un décalage de 100 pixels en haut et en bas.

Comme l'élément #callout a une valeur absolue, cela n'affecte aucun autre élément. Il va donc falloir ajouter un espacement (« padding ») à l'élément #content pour éviter que nos paragraphes ne disparaissent en‑dessous. Le fixer à 250px à droite maintient notre contenu bien visible pour nos lecteurs. Pour conclure, nous avons ajouté un pied de page avec une position fixed pour bien le garder en bas de la page. Au fur et à mesure que nous faisons défiler la page, le pied de page reste bien en place. Tout comme nous avons ajouté un espacement à #content pour éviter que nos paragraphes ne soient masqués, nous allons faire de même pour l'élément #footer car son comportement est similaire à un élément positionné avec absolute. En ajoutant 60px d'espacement inférieur à l'élément #content, nous nous assurons qu'il est possible de faire dérouler l'intégralité du document sans qu'aucun texte ne puisse se cacher sous l'élément #footer, comme ce devrait normalement être le cas.

Nous voilà maintenant avec une belle mise en page toute simple, composée d'un menu de navigation, d'un espace de contenu, d'une zone d'encadré et d'un pied de page, tout en ayant placé des éléments en static, relative, absolute et fixed. Dans la mesure où nous avons utilisé la valeur fixed dans cette mise en page, il faudra appliquer certaines techniques pour s'assurer que les navigateurs les plus anciens respecteront notre design.

Conclusion

Grâce à la puissance de la propriété position, vous allez pouvoir créer des mises en page en toute confiance. Fort heureusement, 80% des valeurs de la propriété position sont très bien interprétées dans les navigateurs récents comme dans les plus anciens. Seule la valeur fixed doit vous tenir en alerte. C'est en comprenant intimement le fonctionnement de ces valeurs que vous poserez votre CSS sur des bases solides, en n'ayant plus pour limite que votre imagination. Si tout va bien, l'époque où vous vous arrachiez les cheveux à tenter de régler des problèmes de positionnement à coups de devinettes est bel et bien révolue.

Note de la rédaction  : Attention  ! Dans l'exemple J, l'utilisation de position: absolute pose un problème d'ergonomie et d'accessibilité. Dans le code source, la div «  callout  » vient avant la suite de la div «  content  » alors qu'elle apparaît après visuellement.

Quand on navigue dans la page en tabulant au clavier ou avec une revue d'écran, le curseur se placera dans la zone «  callout  », avant la suite de la zone «  content  ». Pour éviter ce problème, il suffit de placer la div «  callout  » en fin de div «  content  », et de donner à cette dernière une hauteur minimum suffisante pour que toute la div «  callout  » soit visible quand la div «  content  » est courte.

Plus d'informations dans le guide Accessiweb, critère 10.4

Formulaires HTML5 : prenez la clé des champs

Frédéric Chotard — 2011-04-29T00:00:00Z

Les formulaires sont souvent considérés comme ces trucs pénibles qu'il faut baliser et styler. Désolée, mais je suis d'un tout autre avis : les formulaires, c'est ce que je préfère (tout comme les tableaux !).

Nous allons voir ici comment styler un beau formulaire HTML5, grâce aux CSS avancées et aux techniques CSS3 les plus récentes. Je vous promets qu'après avoir lu cet article, vous voudrez absolument fabriquer vos propres formulaires.

Voici ce que nous allons créer :

Le projet initial. Les icônes proviennent de Chalkwork Payments.

On donne du sens aux balises

Nous allons appliquer du style à un simple formulaire de paiement. Il y a trois grandes sections dans ce formulaire :

les informations sur la personne ;
les informations sur l'adresse ;
les informations sur la carte de crédit.

Nous allons aussi utiliser quelques-uns des nouveaux attributs et types d'entrée du HTML5 pour créer des champs qui aient du sens, et éviter d'utiliser trop de class et de id inutiles :

email, pour le champ email ;
tel, pour le champ téléphone ;
number, pour le numéro de carte et le code de sécurité ;
required, pour les champs à saisie obligatoire ;
placeholder, pour donner des indications à l'intérieur de certains champs ;
autofocus, pour permettre une focalisation sur le premier champ de saisie lorsque la page est chargée.

Il y a des milliers d'autres nouveaux attributs et types d'entrée en HTML5, et vous auriez tout intérêt à aller voir les nouveautés sur le site du W3C. J'espère que cela vous convaincra que le balisage des formulaires peut devenir beaucoup plus sympa qu'avant.

On pose des fondations solides

Chaque section du formulaire sera insérée dans son propre fieldset. En ce qui concerne les boutons radio qui permettent de choisir le type de carte de crédit, nous placerons ces options dans un autre fieldset imbriqué.

Nous allons également utiliser une liste ordonnée pour regrouper chaque couple label / input (étiquette du champ / données à y entrer). Cela nous fournira une sorte de point d'accroche pour appliquer un style de façon sémantique, tout en rendant le formulaire plus lisible s'il est affiché alors que les feuilles de styles ne sont pas appliquées :

Voici donc le balisage avec lequel nous allons travailler :

  Votre identité   Nom  
  Email  
  Téléphone  
 
 
  Adresse de livraison   Adresse  
  Code postal  
  Pays  
 
 
  informations CB    Type de carte bancaire    VISA 
   AmEx 
   Mastercard 
 
 
 
  N° de carte  
  Code sécurité  
  Nom du porteur

Code source de cet exemple

On améliore l'aspect

Commençons par le commencement : il faut d'abord donner un cadre par défaut, en remettant à zéro les marges et les espacements des éléments, et en indiquant une police par défaut pour la page :

html, body, h1, form, fieldset, legend, ol, li { margin: 0; padding: 0;
}
body { background: #ffffff; color: #111111; font-family: Georgia, "Times New Roman", Times, serif; padding: 20px;
}

Puis on va appliquer un style à l'élément form qui entoure nos champs de saisie :

form#paiement { background: #9cbc2c; -moz-border-radius: 5px; -webkit-border-radius: 5px; border-radius: 5px; padding: 20px; width: 400px;
}

Nous allons aussi enlever la bordure de l'élément fieldset, puis ajouter de la marge en bas. Grâce à la pseudo-classe :last-of-type, nous enlevons la marge en bas du dernier fieldset, car nous n'en avons pas besoin.

form#paiement fieldset { border: none; margin-bottom: 10px;
}
form#paiement fieldset:last-of-type { margin-bottom: 0;
}

Puis nous allons passer les legend en grand et en gras, et nous allons également appliquer un text-shadow vert clair pour obtenir un petit effet sympa supplémentaire :

form#paiement legend { color: #384313; font-size: 16px; font-weight: bold; padding-bottom: 10px; text-shadow: 0 1px 1px #c0d576;
}

Nos legend ont maintenant très bel aspect, mais ce serait encore mieux si elles indiquaient très clairement le nombre d'étapes à suivre dans notre formulaire. Au lieu de l'ajouter manuellement à chaque legend, nous pouvons utiliser des compteurs générés automatiquement.

Pour ajouter un compteur à un élément, il faut utiliser l'un des pseudo-éléments :before ou :after pour ajouter du contenu via les feuilles de style. Voici comment faire :

créer un compteur en utilisant la propriété counter-reset sur l'élément form ;
appeler le compteur avec la propriété content (en gardant le nom que nous avons créé auparavant) ;
avec la propriété counter-increment, indiquer qu'à chaque élément qui correspond à notre sélecteur, ce compteur sera augmenté de 1.

form#paiement > fieldset > legend:before { content: "Étape " counter(fieldsets) " : "; counter-increment: fieldsets;
}

Enfin, il faudra changer le style de la balise legend qui appartient au groupe de boutons radio, pour lui donner l'aspect d'un label :

form#paiement fieldset fieldset legend { color: #111111; font-size: 13px; font-weight: normal; padding-bottom: 0;
}

On donne du style aux listes

Pour nos éléments de liste, nous allons nous contenter d'ajouter de jolis coins arrondis, avec bordure et fond semi-transparents. Puisque nous utilisons des couleurs RGBa, il faut fournir une solution pour les navigateurs qui ne les gèrent pas (à placer avant la couleur RGBa). Pour les listes imbriquées, mieux vaut retirer ces propriétés pour éviter qu'elles se recoupent :

form#paiement ol li { background: #b9cf6a; background: rgba(255,255,255,.3); border-color: #e3ebc3; border-color: rgba(255,255,255,.6); border-style: solid; border-width: 2px; -moz-border-radius: 5px; -webkit-border-radius: 5px; border-radius: 5px; line-height: 30px; list-style: none; padding: 5px 10px; margin-bottom: 2px;
}
form#paiement ol ol li { background: none; border: none; float: left;
}

On contrôle les formulaires

Il ne nous reste plus qu'à styler nos label (étiquettes de champ de saisie), nos input (les entrées à saisir) et l'élément button. Tous nos label auront le même aspect, à l'exception de celui utilisé pour les éléments radio. Nous les laisserons flotter à gauche, et nous leur attribuerons une largeur.

Pour les label de la partie carte de crédit, nous allons ajouter une icône en image de fond, et éliminer certaines propriétés inutiles. Nous utiliserons le sélecteur d'attribut pour définir l'image de fond de chaque label ; dans le cas présent, c'est l'attribut for qui sera employé pour chaque label.

Encore un détail pour améliorer l'ergonomie : nous allons ajouter un curseur de type pointeur (cursor: pointer) aux label de type bouton radio lorsqu'ils sont survolés (état hover), afin que l'utilisateur sache qu'il n'a qu'à cliquer pour sélectionner cette option.

form#paiement label { float: left; font-size: 13px; width: 110px;
}
form#paiement fieldset fieldset label { background:none no-repeat left 50%; line-height: 20px; padding: 0 0 0 30px; width: auto;
}
form#paiement label[for=visa] { background-image: url(visa.gif);
}
form#paiement label[for=amex] { background-image: url(amex.gif);
}
form#paiement label[for=mastercard] { background-image: url(mastercard.gif);
}
form#paiement fieldset fieldset label:hover { cursor: pointer;
}

On touche à la fin ! Passons maintenant aux éléments input. Nous voulons que tous les champs input soient identiques, sauf pour les boutons radio et la zone de texte textarea. À cet effet, nous utiliserons la pseudo-classe de négation :not(). Grâce à elle, nous allons cibler tous les éléments input à l'exception de ceux qui possèdent le type radio.

Il ne faudra pas non plus oublier d'ajouter des styles de focus, ainsi que de styler correctement les input de type radio.

form#paiement input:not([type=radio]),
form#paiement textarea { background: #ffffff; border: none; -moz-border-radius: 3px; -webkit-border-radius: 3px; -khtml-border-radius: 3px; border-radius: 3px; font: italic 13px Georgia, "Times New Roman", Times, serif; outline: none; padding: 5px; width: 200px;
}
form#paiement input:not([type=submit]):focus,
form#paiement textarea:focus { background: #eaeaea;
}
form#paiement input[type=radio] { float: left; margin-right: 5px;
}

Pour finir, nous voici arrivés au button, le bouton permettant de soumettre le formulaire. Nous allons juste y ajouter une jolie police et un effet de text-shadow, puis l'aligner au centre du formulaire et lui donner différentes couleurs de fond pour chaque état possible :

form#paiement button { background: #384313; border: none; -moz-border-radius: 20px; -webkit-border-radius: 20px; -khtml-border-radius: 20px; border-radius: 20px; color: #ffffff; display: block; font: 18px Georgia, "Times New Roman", Times, serif; letter-spacing: 1px; margin: auto; padding: 7px 25px; text-shadow: 0 1px 1px #000000; text-transform: uppercase;
}
form#paiement button:hover { background: #1e2506; cursor: pointer;
}

Voilà, c'est fini ! Regardez le formulaire terminé.

Ce formulaire n'aura pas le même aspect dans tous les navigateurs, bien évidemment. ~~Internet Explorer et Opera n'interpètent pas border-radius (du moins pas aujourd'hui).~~ Les nouveaux types d'input sont simplement rendus comme des input ordinaires dans certains navigateurs ; et une partie des CSS les plus avancées comme le compteur ou bien :last-of-type ou encore text-shadow ne sont pas interprétées par certains navigateurs. Mais cela ne vous empêche pas de les utiliser dès maintenant afin de simplifier votre processus de développement. Voilà, j'espère que mon cadeau vous a plu !

Conférences Sudweb et WebUX

Pompage — 2011-01-21T14:10:00Z

Vous avez probablement entendu parler de Paris Web, le cycle de conférences et d'ateliers sur la conception, réalisation et maintenance de projets Web... Mais saviez‑vous que deux autres conférences viennent compléter le tableau en 2011 ?

SudWeb vous donne rendez‑vous le 27 mai 2011 à Nîmes pour une journée de conférences sur le développement, les méthodologies et valeurs métiers, sujets fréquemment traités sur ce site.

Et ce n'est pas tout ! Dès le 26 mai, dans les mêmes locaux, se tiendra WebUX : une journée de conférences à propos de l'expérience utilisateur sur le web.

La rédaction vous donne donc rendez‑vous à Nîmes au mois de mai !

Penser mobile d'abord aide pour les décisions critiques

Goulven Champenois — 2010-11-15T09:28:52Z

Durant notre entretien du Big Web Show, hier, Jeffrey Zeldman, Dan Benjamin et moi‑même discutions des raisons pour lesquelles concevoir d'abord pour les mobiles aide à éviter certains des problèmes qui enquiquinent les designers depuis des années.

Il fait même le café

Un des problèmes les plus tenaces sur le Web est de vouloir tout faire faire à son site Web. Il est relativement simple d'y ajouter des éléments, et c'est donc ce qui se produit, d'autant plus quand un grand nombre d'intervenants a voix au chapitre. Les différents services d'une société, les responsables de telle ou telle fonctionnalité… L'entreprise et ses clients ont tous des besoins différents. Les designers sont souvent forcés d'équilibrer de nombreuses promotions, interactions, zones de contenu et modes de navigation dans une seule et même mise en page. Dans un écran de 1024 × 768, il y a énormément de pixels à remplir !

Lorsque vous concevez d‘abord pour la version mobile, un ensemble de contraintes retient votre main, la plus importante étant probablement la place à l'écran. En effet, quand on passe à un écran de 320 × 480 (iPhone, Palm Pre, première génération d'Android), 80 % de la surface disponible disparaît. Cela signifie que 80 % du contenu, de la navigation, des promotions et des interactions doivent être supprimés. Et… c'est très bien ainsi.

Perdre 80 % de la place disponible oblige à se concentrer sur les éléments prioritaires. Vous devez être sûr que l'écran ne contient plus que les fonctionnalités les plus importantes pour votre client et vous‑même. Il n'y a tout simplement pas la place pour des éléments d'interface inutiles ou des contenus d'intérêt douteux. Il est crucial de savoir ce qui compte le plus. Et pour cela vous devez connaître parfaitement vos clients et votre entreprise. De toute façon c'est le B‑A‑BA du design, et concevoir pour les terminaux mobiles vous oblige à passer par là, que vous le vouliez ou non.

Observez les différences entre le site de Southwest Airlines et leur application iPhone. Les innombrables pixels disponibles à l'écran ont été couverts d'informations sans intérêt. Pourquoi ? Parce qu'on pouvait se le permettre. L'application mobile, en revanche, se concentre exclusivement sur ce dont les clients ont besoin et ce que propose Southwest : réserver un voyage, s'enregistrer, vérifier les horaires d'un vol, consulter ses points de fidélité, etc. Et rien d'autre que l'indispensable.

Si vous concevez d'abord pour les mobiles, vous créez un consensus sur ce qui est essentiel. Il n'y a plus qu'à le reprendre et à l'appliquer à la version classique du site. Une fois que tout le monde est d'accord sur les fonctionnalités et contenus les plus importants pour les clients et l'entreprise, pourquoi en changer même s'il y a plus de place ?

Le contexte d'utilisation est bien sûr différent d'une utilisation classique, mais le service de base et l'intérêt d'un site restent les mêmes.

Identique dans tous les navigateurs

Depuis des années, les designers et développeurs bataillent pour que les sites aient le même aspect et les mêmes fonctionnalités dans tous les navigateurs. Ils sont pourtant tous différents, chacun avec ses propres possibilités et limitations. Uniformiser l'expérience fait passer à côté de certaines opportunités, et oblige à contourner plus ou moins proprement les limites des navigateurs. Pas idéal.

L'avènement d'un très grand nombre d'appareils reliés à Internet, chacun ayant ses qualités et défauts, a prouvé que les sites ne devaient pas obligatoirement s'afficher et se comporter à l'identique dans tous les navigateurs. Penser mobile d'abord le montre immédiatement. La façon de présenter vos actions clés et l'information sur un mobile a de fortes chances de différer de la version classique. Et c'est très bien comme ça.

Si l'on compare un autre design du site de Southwest Airlines avec la version mobile, on constate que les deux se concentrent sur les mêmes points essentiels pour le client et l'entreprise, mais de manières distinctes, adaptées à la forme et à l'encombrement du moyen de consultation.

Les sites web doivent‑ils donc avoir le même aspect dans tous les navigateurs ? Non. Concevoir pour mobile en premier le montre bien.

Comment convaincre de commencer par la version mobile

Maintenant qu'il a été démontré que cette approche aide les designers à résoudre d'épineux problèmes, comment convaincre les clients et responsables de l'adopter eux aussi ? Avec des chiffres, tout simplement.

Le nombre d'utilisateurs réguliers d'appareils mobiles devrait tripler, pour atteindre le milliard d'ici 2013. (Source)
L'adoption d'Internet mobile progresse huit fois plus que la version filaire. (Source)
Les ventes de smartphones devraient dépasser les ventes mondiales de PC d'ici fin 2011. (Source)
Et plus encore…

pompage.net

La cryptographie et le Web : hachage, salage et autres recettes

Fonctions à sens unique

Chiffrement symétrique

Chiffrement asymétrique

Comprendre le risque

La discipline de la stratégie du contenu

Qu'est-ce que la stratégie du contenu ?

Mais attendez... il y a plus.

Reprenez le flambeau.

Comment bien placer des labels dans leur zone de texte

Reconnaissance visuelle contre mémoire

Groupes et intitulés

Messages d'erreur

Feed‑back visuel

Sélection d'une zone de texte et saisie

Suppression d'informations et désélection de la zone de texte

À vous de jouer

Dimensionner ses fontes avec rem

Dimensionnement avec px

Dimensionnement avec em

Dimensionnement avec rem

Pourquoi les menus affichés au survol font plus de mal que de bien aux utilisateurs

Le mythe du survol

Les menus affichés au survol obligent à emprunter des tunnels invisibles

Les menus affichés au survol rendent les éléments périphériques lents et difficiles à cliquer

Les menus affichés au survol rendent les pages d'index plus difficiles à trouver

Les menus s'ouvrant par clic

Désacraliser les tests d'utilisabilité

Différents objectifs, différents types de tests

Le processus classique

Concevoir un plan de test

Choisir les conditions du test

Trouver et sélectionner les participants

Préparer le guide de test

Diriger les sessions

Noter les remarques des participants et observateurs

Analyser les données et observations

Ce que vous obtenez

Quelqu'un, quelque chose, quelque part

Préparer le guide de test

Trouver des participants

Diriger les sessions

Tirer des conclusions et proposer des recommandations

Comment naissent les designs proposant une expérience particulièrement agréable ? De l'observation des utilisateurs

Introduction au positionnement CSS

Tout est dans la position

Suivez le flot

Static et relative : rien de nouveau jusqu'ici

Absolute : n'inporte où, n'inporte quand

Fixed : personne ne bouge !

Inherit : pour que rien ne change

Dans les faits

Conclusion

Formulaires HTML5 : prenez la clé des champs

On donne du sens aux balises

On pose des fondations solides

On améliore l'aspect

On donne du style aux listes

On contrôle les formulaires

Conférences Sudweb et WebUX

Penser mobile d'abord aide pour les décisions critiques

Il fait même le café

Identique dans tous les navigateurs

Comment convaincre de commencer par la version mobile

`Static` et `relative` : rien de nouveau jusqu'ici

`Absolute` : n'inporte où, n'inporte quand

`Fixed` : personne ne bouge !

`Inherit` : pour que rien ne change