Soluo, mise en place de plateformes de blogs WordPress MU et intranets métier » Web design

Faire varier le format d’une date avec CSS et les media-queries

raphaelle — Thu, 11 Aug 2011 13:01:26 +0000

Nous allons voir comment dans un blog « responsive » on peut afficher un format de date différent, comme par exemple avoir tantôt le mois en toutes lettres (ex : Septembre), tantôt l’abréviation du mois (ex : SEP), le tout en gardant une syntaxe HTML propre.

Voir l’exemple

Rappel sur le design « responsive » (ou « réactif ») : il s’agit d’utiliser les media-queries pour s’adapter à la taille du device et/ou du navigateur de manière intelligente et ergonomique. Pour plus d’infos, voir cet article sur les media-queries par Alsacréations.

Nouveau site, nouveaux challenges

Cet été nous préparons la refonte du site de soluo.fr. En fait, plus qu’une refonte, nous refaisons tout !

Notre nouveau site sera « responsive » (ou réactif), comme le site de Secri Gestion dont nous avons parlé dans des articles antérieurs.

Pour le nouveau site, nous avons choisi de séparer le blog. Il reprendra la charte graphique du site mais aura une structure et un design différent.

Tout blog qui se respecte contient des articles, auxquels certaines données « meta » sont associées. En général il y a au moins une date de publication et un auteur. L’article peut aussi être catégorisé et taggué par exemple.

Concentrons nous sur la date de publication d’un article. Notre blog sera lui aussi réactif, c’est à dire que son interface va s’adapter à la taille du navigateur et de l’appareil utilisé pour le visualiser.

Dans mon design « grand format », c’est à dire pour écrans d’ordinateurs classiques, j’ai choisi de montrer la date comme sur un petit bloc-calendrier. Je veux que l’abréviation du mois en 3 lettres s’affiche en haut, au dessous duquel on verra le jour en gros, puis l’année en plus petit, comme sur cette image :

Facile, sauf que dans le design pour petits formats (pour les smartphones par exemple) je veux montrer la date d’une autre manière. Le tout s’afficherait sur une ligne avec jour, mois, année, comme ceci :

Positionner les mêmes éléments de manières différentes ne me fait pas peur. Avec les media-queries, c’est facile. Dans le premier cas on peut se servir des positions absolute / relative, et dans le second cas, on laisse les éléments inline se positionner les uns après les autres naturellement.

Le problème : le format de la date

Je ne suis pas développeuse, mais je me doute que si je demande à mon collègue développeur de me fournir 2 formats de date différents selon que certaines media-queries sont déclenchées ou pas, il va me regarder de travers.

Une solution serait d’avoir la date 2 fois dans le code, dans 2 formats différents. Dans un cas on masque l’un, ou l’autre.

Cette solution ne me satisfait pas car j’aime que mon code reste propre.

J’ai posé la question sur Twitter et on m’a suggeré le pseudo-element :after et la propriété content de CSS.

Même si je n’ai pas tout à fait compris la suggestion car je ne souhaitais pas utiliser de lien, cela m’a donné une bonne piste.

J’ai aussi demandé l’avis de la communauté de Sitepoint sur leur forum, et j’y ai posté ma solution (English)

La solution : utiliser l’attribut TITLE

La solution qui me parait la meilleure est de générer la date dans 2 formats différents, du moins pour le mois, qui est l’élément problématique ici.

La balise contiendra le nom entier du mois, et l’attribut TITLE contiendra l’abréviation en 3 lettres.

Après il suffit d’un peu de CSS avec des media-queries pour afficher l’un ou l’autre.

Voici le code que j’ai écrit assez rapidement. Je ne suis pas contente de la manière dont je cache le mot « juillet », je pense qu’on peut mieux faire. Mais ça marche !









	12
	juillet
	2011

Pour voir comment ça marche, redimmensionnez la fenêtre de votre navigateur.

Voir l’exemple

N’hésitez pas à me faire part d’améliorations éventuelles, notamment pour la manière de cacher le contenu de la balise « month ».

Note sur la compatibilité

Cet exemple ne fonctionnera que sur les navigateurs modernes, qui comprennent les media-queries. C’est un petit essai que j’ai fait rapidement, sans me soucier de la compatibilité avec mon très cher Internet Explorer (6, 7 et 8). Cependant il est tout à fait possible de faire fonctionner tout ça sur IE en utilisant un outil tel que 320 and up qui inclut des fichiers javascript.

Credits : merci à IconSweets pour l’icône Calendrier.

Responsive web design : Comment optimiser son site pour mobiles et tablettes (3ème partie)

raphaelle — Tue, 12 Jul 2011 08:14:08 +0000

Après les phases initiales de recherche et de design que nous avons abordé dans deux articles précédents, vient le temps de l’intégration HTML et CSS.

En principe ce n’est pas très compliqué : il suffit de suivre la méthode de 320 and up qui consiste à intégrer d’abord pour la taille de fenêtre la plus petite.

Je dis « en principe », car nous avons rencontré un certain nombre de difficultés, notamment avec Internet Explorer 7 et 8, malgré les outils javascript fournis dans le template.

Note : Comme pour la majorité des sites que nous réalisons, nous avons décidé de ne pas supporter IE6 pour ce projet.

L’intégration pour 320px et 480px de large

Note : Pour tester j’ai utilisé un iPhone 3GS ainsi que Firefox 3.6, Chrome, Safari, IE7 et IE8 sur desktop. J’aurais voulu pouvoir tester sur d’autres smartphones mais je n’avais pas cette possibilité.

Andy Clarke propose deux versions du template : la première avec une feuille de style unique et la seconde avec de multiples feuilles de styles. J’ai préféré travailler avec plusieurs feuilles de styles car cela me paraissait plus « propre », mais c’est un choix très personnel.

On commence donc par style.css qui est la feuille de style de base. Elle correspond à une largeur de fenêtre de 320px au maximum.

La méthode de 320 and up consiste à intégrer d’abord pour les plus petits formats, et de rajouter des feuilles de styles les unes au dessus des autres en allant vers le format le plus large.
Cela signifie que les règles CSS contenues dans style.css seront prises en compte par toutes les tailles écrans. Certaines devront être écrasées par la suite afin de positionner les éléments d’une nouvelle manière pour une taille de fenêtre supérieure.

Pour les écrans allant jusqu’à 480px de large, on doit penser aux appareils mobiles de type smartphone. Les zones cliquables doivent être suffisamment larges pour effectuer un « clic » avec le doigt. On peut faire le choix de masquer certains éléments s’ils sont superflus et si leur absence peut rendre l’interface plus claire et intuitive.

Dans une logique d’optimisation et de performance, on évitera l’utilisation d’images de fond volumineuses, et on limitera les effets graphiques d’une manière générale.

L’utilisateur d’un appareil mobile a très peu de patience – encore moins que sur un ordinateur classique – c’est pourquoi il est si important de peaufiner l’ergonomie de l’interface pour les petits formats.

Une fois satisfaite du résultat sur mon iPhone en mode portrait, je suis passée à l’intégration du mode paysage, c’est à dire en 480px de large. Rien ne nous oblige à tout changer pour chaque taille d’écran. Je pense que le passage de 320px à 480px demande un petit travail d’adaptation qui n’est pas radical dans un le cas d’un site comme celui-ci.

En l’occurrence j’ai principalement changé la présentation des biens sur la page d’accueil et sur les pages « A louer » et « A vendre » pour que la fiche du bien passe en mode horizontal. L’image est plus petite qu’en mode portrait mais au moins on voit toutes les informations en un clin d’oeil.

Si j’avais laissé exactement les même styles qu’en 320px de large, la photo du lieu aurait paru énorme et il aurait fallu scroller pour voir les information relatives à un lieu.

Annonce immobilière sur la page d’accueil en 320px de large (iPhone)

Annonce immobilière sur la page d’accueil en 480px de large (iPhone)

L’intégration pour 728px et 992px de large

Le passage entre les versions 728px et 992px de large était un petit peu plus complexe, notamment à cause du header et de la navigation que je devais adapter. Je m’en suis souvent sortie en ajoutant plus de markup (généralement des DIVs), chose qui n’est pas idéale.

En effet, si le site avait été de largeur statique, j’aurais utilisé beaucoup moins de balises mais puisque la disposition de certains éléments doit pouvoir changer, il faut de quoi les positionner de différentes manières : tantôt avec un positionnement absolu ou relatif, tantôt avec un float.

Il faut jongler avec les différents éléments du HTML et de CSS pour arriver à ses fins et ne pas oublier de tester le site sur différentes tailles d’écran et sur tous les navigateurs à supporter lorsque l’on apporte des changements à une feuille de style.

Pour les pages « A louer » et « A vendre » j’ai souhaité utiliser des selectors CSS3 grâce à Selectivizr et à un plugin pour jQuery qui étend le support des pseudo-class et selectors CSS3. J’aurais voulu pouvoir utiliser des selectors tels que nth-of-type(2n+4) sur tous les navigateurs, mais après quelques échecs nous avons abandonné cette belle idée car cela ne fonctionnait pas sur Internet Explorer.

Nous comptons revenir sur ce problème prochainement afin de comprendre d’où est venu cet échec.

Page d’annonces en 768px de large

Page listing des annonces en 960px de large

Adaptation de 320 and up

Sur la page d’accueil j’avais prévu deux colonnes à hauteur égale pour « Syndic » et « Gestion locative ». Dans ce cas de figure j’étais obligée de recourir à un petit peu de javascript pour calculer la hauteur de la colonne la plus haute et forcer la hauteur de l’autre colonne. C’est très facile à implémenter, cependant le problème est que si la fenêtre est redimensionnée, la hauteur des colonnes ne change pas.

Pour résoudre ce problème j’ai « triché » en ajoutant suffisamment de padding-bottom pour que le texte ne déborde pas lorsque la largeur d’écran est réduite.

Cependant, le vrai problème était pour les versions 320px et 480px car étant très étroites, j’ai voulu positionner les colonnes l’une au dessus de l’autre. Comme je ne souhaitais plus qu’elles aient la même hauteur, j’ai ajouté une media-query et une feuille de style pour viser toutes les largeurs de fenêtre en dessous de 768px.

Le seul style que cette feuille de css contient est :
section.homeMainContent article { height: auto !important; }

Ainsi, la j’écrase la hauteur générée par le javascript afin que les deux colonnes prennent une hauteur « naturelle », en fonction de leur contenu.

Internet Explorer…

En théorie 320 and up contient je javascript nécessaire au bon fonctionnement des media-queries sur Internet Explorer.

Lors de la phase d’intégration j’étais assez contente du résultat sur IE7 et IE8 sur XP et Windows 7, même si ce n’était pas parfait à 100% ; certains éléments de l’interface ne se positionnaient pas tout à fait comme ils auraient dû lors du redimensionnement de la fenêtre. Néanmoins, ces légers « bugs » me paraissaient suffisamment discrets pour que le site soit mis en ligne tel quel.

Après la mise en ligne du site, le client nous a signalé un problème que nous n’avons pas réussi à reproduire à ce jour : sur 2 de leurs ordinateurs, seule style.css était prise en compte, ce qui donnait un résultat catastrophique sur un écran classique.

Nous avons l’intention d’investiguer mais pour l’instant nous préférons fournir une version statique en 960px de large aux utilisateurs d’Internet Explorer 7 et 8. A suivre…

Dans le prochain article je ferai le bilan de cette expérience : je vous donnerai quelques astuces pour réussir votre site réactif, et je vous ferai part des leçons apprises grâce à cette aventure, dans l’espoir de vous éviter de vous confronter aux mêmes problèmes.

Responsive web design : Comment optimiser son site pour mobiles et tablettes (2ème partie)

raphaelle — Wed, 06 Jul 2011 08:09:57 +0000

Dans un article précédent nous avons parlé des outils que nous avons choisi pour la réalisation du site secri.fr, afin d’en faire un site « responsive » (ou en français, « réactif »).

Cependant, avant de passer à l’intégration du site il nous a fallu repenser le design. En effet, le visuel du site en 960px de large avait déjà été validé par le client, avant que nous décidions d’en faire un site réactif.

Note : en principe une telle décision devrait se faire en amont et avec l’accord du client car cela représente plus de travail qu’un site statique (et donc un coût un peu plus important) mais nous avions envie d’expérimenter sur ce projet qui s’y prêtait bien.

Le design initial

Le design de départ, qui avait déjà été validé par le client, prenait la largeur classique de 960px.

Page d’accueil en 960px de large

Page listing des annonces en 960px de large

J’ai estimé qu’il faudrait prévoir 4 « versions » du site réactif.

La plus petite irait jusqu’à 320px de large (ce qui correspond au mode portrait de l’iPhone)
La suivante serait utilisée pour les largeurs entre 320px et 480px (480px étant la largeur de l’iPhone en mode paysage)
La suivante pour les largeurs entre 480px et 768px (768px est la largeur de l’iPad en mode portrait)
La dernière correspondrait au design conçu pour le site statique en 960px, et irait de 768px à 1000px de large.

Étant donné que le site secri.fr contient relativement peu de contenu, je n’ai pas vu l’intérêt de prévoir une largeur supérieure car l’interface aurait perdu en ergonomie et en esthétique.

Pour d’autres types de projet on peut tout à fait envisager des largeurs de fenêtre supérieures, comme le fait le site de 320 and up.

Adaptations du design

Page d’accueil en 768px de large

Je suis brièvement repassée par la case Photoshop pour visualiser la page d’accueil en largeur 768px. Il fallait surtout revoir la navigation car les éléments risquaient de ne pas tous rentrer à droite du logo. J’ai donc choisi de sortir le logo de la barre de navigation et de le centrer, ainsi que de centrer la liste des liens.

La liste des biens passe en mode horizontal, ce qui fonctionnera aussi très bien pour la version d’en dessous qui est de 480px de large, avec quelques adaptations.

Page d’accueil en 768px de large

Liste des annonces en 768px de large

Pour les pages « A louer » et « A vendre », il n’y a plus assez de place pour 4 annonces par ligne, on passe donc à 3 annonces seulement. Le reste ne change pas.

Page d’annonces en 768px de large

Pour les deux versions les plus petites (320px et 480px), je n’ai pas eu besoin de travailler dans Photoshop car le travail effectué sur la version de largeur 768px m’a permis de les visualiser dans ma tête pour ensuite les implémenter directement pendant la phase d’intégration.

Ce que je ferai différemment à l’avenir

Je travaillerai probablement sur 2 ou 3 tailles du site en parallèle, sans forcément décliner tous les gabarits pour chacune d’entre elles. Il est très possible que je continue à me baser sur un design en 960px de large, tout en réfléchissant à chaque étape à mes choix graphiques et à la manière dont ils vont affecter la syntaxe HTML.
Je réfléchirai un peu plus aux conséquences de mes choix ergonomiques sur la phase d’intégration, notamment pour éviter l’ajout de scripts supplémentaires.

Dans un prochain article je parlerai de la phase d’intégration. Celle-ci s’est déroulée relativement bien grâce à l’outil 320 and up mais il y a eu quelques petits soucis liés à javascript et à certains navigateurs, pour ne pas citer de noms…

Responsive web design : Comment optimiser son site pour mobiles et tablettes (1ère partie)

raphaelle — Tue, 28 Jun 2011 16:43:33 +0000

Nous avons récemment mis en ligne le site secri.fr, pour une agence immobilière située en région parisienne. Nous l’avons intégré de sorte qu’il soit « réactif ». En anglais on parle de « responsive web design« .

En pratique, cela signifie qu’on utilise les media-queries (CSS3) pour appliquer des styles différents selon la taille de l’écran, de la fenêtre, ou encore de l’orientation d’un appareil mobile (smartphones et tablettes).

Cela permet donc de présenter à l’utilisateur un design et une ergonomie optimisés pour chaque type d’appareil qu’il utilise ainsi que pour la taille de la fenêtre de son navigateur.

Pour voir de quoi il s’agit, amusez-vous à redimensionner la fenêtre de votre navigateur lorsque vous êtes sur secri.fr.

Notons que selon les projets, il peut être préférable de créer un site ou une application mobile séparés. Cependant, dans la plupart des cas, l’utilisation des media-queries est la meilleure option car elle est relativement facile à implémenter et reste peu coûteuse.

Les problèmes liés à la création d’un site réactif

Lorsqu’on approche le sujet pour la première fois, cela peut paraître très complexe car très vite, on comprend qu’il va falloir changer ses méthodes de travail.

Quelques questions peuvent venir à l’esprit :

Dois-je créer une maquette graphique pour chacune des différentes apparences du site ? Cela représente beaucoup de travail et d’échanges avec le client !
CSS3 ne fonctionne que sur les navigateurs récents ; que faire des navigateurs plus anciens ?
Comment aborder la phase d’intégration ?
Est-ce compliqué d’obtenir différentes « versions » d’un site en gardant la même syntaxe HTML ?

Lors de la réalisation du site de Secri Gestion, notre premier site réactif, je me suis confrontée à ces problématiques. Je vais vous faire part du cheminement que nous avons suivi en espérant que cela vous aidera à réaliser vos sites.

L’idée de départ

Peu avant de commencer l’intégration de secri.fr, j’ai trouvé le template 320 and up, créé par le talentueux Andy Clarke. C’est une extension de HTML5 Boilerplate (par le tout aussi talentueux Paul Irish) que nous utilisions déjà pour tous nos sites.

Ces templates, composés de HTML, de CSS et de Javascript, sont une très bonne base pour créer un site réactif en bénéficiant des meilleures pratiques. Grâce au Javascript fourni, même Internet Explorer 6 se comportera comme un navigateur moderne. Enfin presque.

Plus qu’un template, 320 and up est une méthode de travail. C’était ça la vraie nouveauté pour moi car j’ai dû repenser ma manière de travailler. En effet, pour un site statique on passe généralement du design à l’intégration d’une façon assez linéaire.

Dans le cas d’un site réactif ayant 4 apparences différentes (la première pour les fenêtres allant jusqu’à 320px de largeur, puis jusqu’à 480px, 768px, et supérieure à 992px), il va falloir travailler autrement. La méthode d’Andy Clarke consiste à intégrer d’abord la version la plus petite, puis à passer au cran au dessus et ainsi de suite, jusqu’à l’intégration de la version la plus large en dernier. Ayant tenté le procédé inverse par le passé, je ne suis pas prête de revenir en arrière car c’était laborieux !

A noter que nous souhaitions réaliser un site à la fois réactif et flexible, c’est à dire qu’au lieu de « sauter » d’une apparence à l’autre lors du redimensionnement de la fenêtre, les éléments devaient s’adapter à la largeur de la fenêtre avec souplesse. Il fallait donc utiliser des pourcentages pour les largeurs des différents éléments.

Nous verrons dans un prochain article comment je m’en suis sortie au niveau du design, puisque la maquette graphique faisant 960px de large avait déjà été validée par le client.

Deuxième partie de cet article : la phase de design

Débats à Paris Web 2010

raphaelle — Mon, 18 Oct 2010 17:59:33 +0000

Paris Web 2010 s’est déroulé du 14 au 16 octobre et a rassemblé des centaines de professionnels du web : des développeurs, des intégrateurs, des web designers, et d’autres profils du web, du marketing à l’accessibilité.

Les sujets abordés étaient tantôt méthodologiques, techniques ou quasi philosophiques. D’après ce que j’ai pu voir, les conférences qui ont généré le plus de réactions du publics étaient celles de Francis Chouquet, CSS3/Photoshop : quel avenir pour le métier de web designer ? et d’Eric Daspet Le web, un métier de valeur.

J’ai eu l’impression qu’il y avait un certain malaise dans une industrie jeune et dynamique où beaucoup cherchent leur place.

Le designer et le code

Il y a le débat (j’ai envie de dire “vieux comme le monde” mais ça me paraît un peu prématuré) : le web designer doit-il savoir coder ? Les opinions divergent fortement :

Ne pas savoir coder peut brider la créativité car on ne comprend pas les possibilités liés à la technologie et on peut passer à côté de certaines choses.
Savoir coder peut aussi brider la créativité car on pense aux contraintes (ou “spécificités”) du web au lieu de donner libre cours à son imagination.

Pour moi, les deux arguments sont valides mais est-ce que ça ne dépend pas de l’individu, de sa sensibilité et de ses méthodes de travail ? Je trouve que c’est tant mieux s’il y a plusieurs approches et outils possibles à la création Web.

Dans des petites structures, les profils hybrides seront appréciés tandis que dans les grosses agences, on cherchera des personnes plus spécialisées. Ce n’est peut-être pas toujours vrai mais dans l’ensembe ça résume bien la situation.

Des experts en mal de reconnaissance

Lors de la conférence d’Eric Daspet sur la valeur des métiers du web, plusieurs membres du public ont parlé du problème de manque de reconnaissance de leur expertise. Dans beaucoup de leurs entreprises, le Web, c’est pour les stagiaires.

Les experts sont donc peu reconnus et leurs intitulés de postes reflètent ce problème, tout comme leurs minces salaires qui ne correspondent pas aux nombreuses compétences qu’on exige d’eux. Eric Daspet nous a parlé d’offres de stages non payés qu’il voit toujours passer et qui demandent des compétences solides dans des langages de programmation complexes et très spécifiques, ainsi que de nombreuses années d’expériences !

Des solutions ?

Certains proposent de s’accorder sur une nomenclature pour nos métiers. Je trouve dommage qu’on veuille à tout prix s’étiqueter comme dans d’autres industries. Ne peut-on pas tirer parti du légér flou qui règne quand on parle de “web designer” ? Chacun peut se façonner une casquette à sa taille en quelque sorte. D’autant plus que nos métiers évoluent tellement vite ; comment définir ce qui est en constante mutation ?

Selon Eric Daspet, les professionnels du Web ont tendance à se positionner en executants car ils disent trop souvent « oui » aux demandes déraisonnables des moins experts. C’est une piste.

Quelqu’un a évoqué l’artisanat pour parler de nos métiers. L’idée m’a plu instantanément. Quand on cherche une définition du mot “artisan” sur Google on trouve trois définitions dont deux qui me paraissent les plus pertinentes :

Celui ou celle qui exerce un métier mécanique ou manuel, qui suit les règles d’un art établi, par opposition aux métiers dits industriels où la production est fournie par des automates; Celui qui est l’auteur, l’origine de quelque chose.

C’est un travailleur manuel. Il travaille pour des particuliers. L’artisan travaille seul, en famille ou avec des compagnons.

On trouve ici l’idée d’un savoir-faire très humain, même s’il utilise la technologie. L’artisan est à la fois concepteur et executant : il est auteur de son oeuvre. L’autre notion qui me parait importante est que l’artisan travaille soit seul soit en groupe. Il peut donc être très polyvalent ou assez spécialisé, ce qui n’enlève rien à son savoir-faire.

Conclusion

En somme, ces débats confirment mes impressions à mon retour en France l’année dernière, après des années passées au Royaume Uni où les diplomes et les étiquettes ont une moindre importance : les métiers du Web et en particulier du Design Web sont peu valorisés notre pays. Les intitulés de postes sont nombreux et fourre-tout mais qu’importe, tout cela est en pleine mutation. Il y a un an j’avais l’impression que tout le monde ne jurait que par Flash ici, mais déjà j’entends un autre son de cloche. Je garde donc espoir pour l’avenir des Artisans du Web.

Suivez moi sur Twitter

Suivez Francis Chouquet sur Twitter

Suivez Eric Daspet sur Twitter

5 types de notifications pour applications web

raphaelle — Wed, 12 May 2010 15:26:37 +0000

Chez Soluo nous travaillons actuellement sur un projet d’application web. C’est dans ce cadre que je me suis penchée sur les différentes manières d’afficher des messages d’erreur, d’avertissement, d’information et de confirmation.

Les messages d’erreur sont probablement les plus connus, mais les autres types de notifications peuvent aussi être utiles. Parfois, on veut signaler à l’utilisateur que l’action qu’il a déclenché s’est déroulée comme prévue, car si rien ne se passe à l’écran, il peut croire qu’une erreur s’est produite et c’est très frustrant. D’autres fois, une partie des actions ont réussi tandis que d’autres ont échoué. Il faut donc en informer l’utilisateur.

J’ai identifié 5 manières de présenter de telles informations au sein d’une interface web. Le souci est de savoir laquelle utiliser et dans quel cas. De plus, dans une application comme sur un site web, il faut faire preuve de cohérence : on évitera d’utiliser ces 5 styles de notifications sur une même interface, on risquerait de désorienter l’utilisateur.

1ère méthode : la zone unique de notification

C’est un emplacement, souvent situé en haut de l’interface, qui sert à afficher les notifications de tous types à travers l’application. Cette zone vient toujours se positionner à la même place. Si on décide de la situer dans le header, cela implique de la laisser vide en l’absence de notification. On peut aussi choisir de l’afficher sous le header de manière à ce qu’elle pousse le contenu vers le bas lorsqu’elle apparaît.
Exemple de zone unique de notification

Avantages : Participe à la cohérence de l’application car les messages sont toujours au même endroit. Il n’y a donc pas de surprise, et c’est une bonne chose. De plus, rien ne nous empêche d’utiliser cette approche et de la combiner avec la suivante dans certains cas.

Inconvénients : Quand l’utilisateur est descendu en bas d’une page longue, cette zone est alors masquée. Si on ne voit pas le message, on peut avoir l’impression que rien ne s’est passé. Si la page revient brusquement tout en haut afin que le message soit visible, cela peut être frustrant pour l’utilisateur que l’on a presque redirigé, sans lui demander son avis.

2ème méthode : les messages contextuels

Ce sont les messages que l’on positionne au sein même de la zone concernée. Le meilleur exemple est celui des formulaires. Si le formulaire ne valide pas car un champ comporte une erreur, on préférera mettre en valeur ce champ – en rouge par exemple – plutôt que de mettre un message générique en haut du formulaire. De cette manière l’utilisateur n’a pas trop d’effort à faire : il sait tout de suite ce qui s’est passé et comment rectifier le problème.

Pour faire encore mieux, on peut allier les méthodes 1 & 2 en mettant un message en haut de page avec les détails de l’erreur ET en faisant ressortir les champs à modifier.
Exemple de message contextuel

Avantages : Le message est positionné dans la zone de l’interface concernée, donc l’utilisateur a toutes les chances de le voir.

Inconvénients : Représente un peu plus de travail pour les développeurs et intégrateurs car chaque message est un peu « sur mesure ».

3ème méthode : la fenêtre modale

Elles sont très à la mode, surtout pour la présentation de galeries photo, mais aussi pour les notifications importantes. En général elles sont positionnées de manière centrale dans la fenêtre, avec un calque transparent en fond, signifiant ainsi que le reste de l’interface est désactivé.
Exemple de fenêtre modale (lui-même présenté dans une fenêtre modale)

Avantage : On peut être sûr que l’utilisateur va voir le message. Il y a une idée « d’urgence », ou du moins à une situation critique qu’il faut examiner de plus près.

Inconvénient : C’est une approche assez agressive car on empêche l’utilisateur d’interagir avec le reste de l’application. De plus, on l’oblige à prendre une décision, sans quoi il ne peut pas se débarrasser de la fenêtre. Bref, il ne faut pas abuser des fenêtres modales.

4ème méthode : la boite de dialogue

Par boite de dialogue, j’entends « l’alert box » du navigateur. Elle s’apparente à la fenêtre modale car elle requière une action de la part de l’utilisateur. Par contre le web designer n’a aucun contrôle sur son aspect visuel et son positionnement : cette boite appartient à l’interface du navigateur plutôt qu’à celle de l’application web ou site web.
Exemple de boite de dialogue

Avantages : Le sentiment d’urgence et de gravité qu’elle procure si utilisée avec parcimonie.

Inconvénient : C’est encore plus intrusif qu’une fenêtre modale : on l’associe plus à une « erreur fatale ». Son utilisation est troublante quand il s’agit de communiquer un message purement informatif ou de confirmation car on s’attend à un message d’une certaine gravité.
Contrairement à la fenêtre modale, la boite de dialogue peut passer inaperçue : le reste de l’interface est désactivé mais ce n’est pas mis en évidence visuellement.
Vous l’aurez compris, je n’ai pas beaucoup d’affection pour ce mode de notification et je ne vois pas très bien où il a sa place sur le web.

5ème méthode : les notifications de type « Growl »

Ce sont ces messages qui apparaissent assez discrètement dans un coin de l’écran ou de la fenêtre. Parfois ils disparaissent d’eux-même au bout de quelques secondes, d’autres fois il faut cliquer sur un bouton pour les fermer. Ces notifications se superposent donc à l’interface de manière plutôt subtile.
Voir la démo d’un plugin de type « Growl »

Avantages : Ce système permet d’afficher des messages dans une même zone de la fenêtre quelle que soit la longueur de la page. Cela résout donc le problème de la 1ère méthode où le message peut être masqué si on est en bas de page. Ce type de notification permet de discrètement afficher des messages informatifs et n’empêche pas l’utilisation du reste de l’interface.

Inconvénients : Si on utilise ce système pour des notifications importantes, on risque de ne pas les voir ou de ne pas comprendre l’urgence du message car leur positionnement dans la page n’est pas contextuel. De plus il y a des zones auxquelles nous faisons moins attention (en bas à gauche/droite).

Alternative aux notifications intrusives

Je suis arrivée à la conclusion que toutes ces méthodes – à part peut être la boite de dialogue – sont des solutions valides, mais qu’il faut savoir utiliser au bon moment.

Les solutions intrusives telles que les fenêtres modales et les boites de dialogue sont à utiliser le moins possible, car leur problème est justement… qu’elles sont intrusives.
Et si on pouvait s’en passer complètement ?

En lisant le chapitre « Notifying and Confirming » du livre About Face 2.0, The essentials of interaction design (Alan Cooper & Robert Reimann, Wiley Publishing, 2003), j’ai réalisé qu’il y avait presque toujours une alternative au message intrusif.

Par exemple, si l’utilisateur clique sur un bouton « supprimer » afin d’effacer un document de l’application, pourquoi afficher une fenêtre modale lui demandant de confirmer l’action à effectuer ? Dans 95% des cas, la personne veut vraiment effacer le document. Lui demander de confirmer cette action peut instiguer le doute et créer un certain stress. Par ailleurs, si la même fenêtre apparaît à chaque fois que l’utilisateur souhaite effacer quelque chose, il risque d’y être tellement habitué qu’il va machinalement cliquer sur « OK ».

Mieux vaut donc effacer le document sans rien demander, mais en donnant après coup la possibilité de le restaurer. Gmail fait ça très bien ; il m’arrive parfois de sélectionner un email et de cliquer sur « signaler comme spam » au lieu d’un autre bouton. Aussitôt l’action effectuée, la possibilité de l’annuler est bien visible dans la zone de header, sur fond jaune.

Cette manière de faire est beaucoup plus pertinente car elle traite des cas rares – ces 5% – où l’utilisateur s’est trompé, au lieu d’ajouter une étape pour les 95% des cas où tout se passe comme prévu.

Il faut tout de même savoir que la création d’une fonction « annuler » peut représenter une tonne de travail pour les développeurs. Il peut donc être plus rentable de s’en passer. Par exemple, permettre d’annuler la suppression d’un document est assez simple. En revanche, si l’élément à supprimer est relié à d’autres éléments, tout se complique.

Typographie, navigateurs et CSS

raphaelle — Fri, 19 Mar 2010 14:49:16 +0000

Récemment, alors que j’étais en phase d’intégration d’un site dont je venais de réaliser la maquette graphique, je me suis heurtée à quelques problèmes de rendu de typographie.

Il faut savoir que le site en question a un fond très foncé avec du texte clair, et que j’ai plus souvent conçu des sites clairs au texte foncé (meilleure lisibilité).

1er problème : rendu du texte plus gras sur mac

A ma grande surprise, mes titres en Palatino italisés apparaissaient en gras sur Mac. Je savais que sur Mac le texte était plus gras que sur Windows, ce que je ne savais pas c’est que l’écart est encore plus élevé quand le fond est foncé et le texte clair. En plus de ça chaque navigateur a un rendu un peu différent. Je n’étais pas prête à accepter une telle injustice donc je me suis lancée en quête d’une solution.

Je n’en ai pas trouvé à ce jour. Les différentes valeurs de font-weight (100, 200, … 900) ne servent à rien si la famille de police d’écriture ne contient pas suffisamment de variations, ce qui est souvent le cas. J’espérais trouver un moyen de tricher un peu avec de Javascript, sans succès.

Pour éviter ce genre de surprise, je vais peut-être essayer TypeKit sur le prochain projet. C’est une bibliothèque de polices d’écritures qui ne coûte pas cher (gratuit jusqu’à 2 polices pour un site) et qui est censée avoir un impact négligeable sur la performance du site. Cela me permettra de jouer sur les différentes variations d’une même police (extra light, light, roman, etc.).

2ème problème : rendu du letter-spacing

Dans Photoshop j’avais choisi de réduire l’espacement entre les lettres par -5 pour les titres. Dans ma feuille de style j’ai donc joué avec différentes valeurs de letter-spacing afin d’arriver à un résultat similaire. J’étais plutôt satisfaite de la valeur -0.02em. Sauf que ça ne marchait ni dans IE6 ni dans IE7, mais ce qui me dérangeait le plus était que ça ne marchait pas bien dans Chrome alors que le rendu devrait être le même que sur Safari (en théorie).

Je n’ai pas trouvé d’explication valable mais sur un forum on m’a proposé d’utiliser la valeur -1px au lieu d’une valeur relative en EMs et c’est l’option que j’ai choisie. J’utilise toujours des valeurs relatives pour le texte mais dans ce cas particulier j’estime que ça n’enlève rien à l’accessibilité du site.

Par contre sur la dernière version de Firefox pour Mac (3.6), les lettres de mes titres sont un peu trop serrées. A propos de Firefox, voici un article qui révèle quelques bugs qui varient d’une version de Firefox à l’autre. Mon problème pourrait en être un de plus.

Au final j’ai donc choisi la valeur -1px car elle rend bien sur la plupart des navigateurs. Après tout, peu de gens sont sur Firefox pour Mac et quand bien même ils utiliseraient ce navigateur, c’est tout à fait lisible.

Conclusion

Il faut accepter que les rendus seront un peu différents d’un navigateur à l’autre et que ça fait partie du jeu. En tant que designer web avec des qualités d’intégrateur, j’ai toujours envie que le site soit la réplique exacte de mon PSD, puisque c’est ce que le client a validé, cependant certains détails échapperont toujours à notre contrôle.

Quand on pense au temps que le designer passe à rendre son site « joli » dans tous les navigateurs, l’idée de travailler directement dans celui-ci fait sens. Nous explorerons cette idée dans le prochain article.