Archive pour le mot-clef ‘design’

Utiliser la police de son choix sur son site internet

ArobaseL’intégration de polices de caractères sur un site web a longtemps été un casse tête pour les intégrateurs. On avait diverses solutions à portée de main : du flash, du javascript et quelques bidouilles assez incompatibles entres-elles pour lier directement une police dans le CSS.

Techniquement, si le W3C recommande depuis longtemps l’utilisation de Font-Face, celle-ci n’a pas toujours été implémentée comme il le faut dans les navigateurs. Aujourd’hui, l’horizon s’éclaircit progressivement même s’il faut encore fourber avec plusieurs formats pour arriver à un résultat efficace sur l’ensemble de la gamme des navigateurs. Dans l’ensemble on y arrive assez bien. Démonstration.

Tu l’a acheté ? Chuuuut ! Faut pas le dire sur internet…

Ah ! Un détail avant de vous lancer dans le code : une police de caractère est une oeuvre assimilable à un logiciel sur le plan juridique. Donc on touche au copyright (normal), aux droits d’auteur (un peu) et aux droits de diffusion (surtout). Si vous avez acheté une police, relisez bien les conditions d’utilisation, il est fort à craindre que vous n’ayez pas le droit de la proposer en téléchargement sur votre site web. Logique à priori, vous n’allez pas donner un truc qui se vend…

Sauf que… Les règles de Gutenberg ont un peu de mal avec le monde moderne. Si vous utilisez votre police sur votre site, il faudra bien que la machine de l’internaute la télécharge pour l’afficher. Même si l’utilisateur ne pourra pas (à priori, j’vous connais) s’en resservir dans un autre logiciel, vous placez cette police en téléchargement. C’est un fait. C’est stupide, mais c’est comme ça, sed lex.

L’idéal reste (once more) les polices gratuites ou sous Creative Commons. Perso, j’ai pris l’habitude de me fournir chez Google ou sur DaFont. Quitte à faire un petit don à l’auteur au passage (bah, au prix des polices payantes, ça reste tout bénef’ et vous assurez la pérennité du truc…).

Fourrer tout ça, proprement, dans son CSS…

Aller, une police libre dans une main, un ordi dans l’autre, comme l’ensemble des navigateurs ne comprennent pas tous la même chose, il faudra prendre soin de satisfaire chacun avec son ou ses formats de police préférés :

  • de l’Embedded OpenType (eot) pour Internet Explorer 4+
  • du Web Open Font Format (woff) pour Firefox 3.6+, Internet Explorer 9+ et Chrome 6+
  • et du Scalable Vector Graphics (svg) pour Chrome 3+, Opéra 9+
  • du TrueType (ttf) supporté par Firefox 3.5+, Opéra 10+, Safari 3.1+, Chrome 4+

Attention, l’ordre d’appel des différents formats dans le CSS compte et évitera à un navigateur qui comprend à la fois le SVG et le WOFF de charger le SVG à la place du WOFF. Au passage, ça vous évitera aussi quelques bugs sur certains navigateurs qui se mélangent un peu les pinceaux quand l’ordre ne leur convient pas (tatillons ?).

Pour convertir votre police dans les différents formats nécessaires à la pleine satisfaction les différents navigateurs Font Squirrel sera votre sauveur. Attention, ce dernier vous renverra à la loi si vous lui proposez une police handicapée d’un vilain copyright (et toc !).

Assez bavardé, voici le code magique à placer en tête de votre CSS.

@font-face {
    font-family: 'maPolice';
    src: url('fonts/maPolice.eot?')format('eot'),
         url('fonts/maPolice.woff')format('woff'),
         url('fonts/maPolice.svg#IdMaPolice')format('svg'),
         url('fonts/maPolice.ttf')format('truetype');
}

Explication de texte

  • La directive font-family permet de nommer la police pour les appels dans le CSS.
  • Dans les sources, on refile l’ensemble des formats aux navigateurs. Le navigateur s’arrêtera à la première qui lui convient.
  • Le point d’interrogation après l’extension eot permet de forcer le téléchargement sur IE afin qu’il n’interprète pas ce qui se trouve après ce caractère (ce qui permet d’ajouter les autres sources).
  • Le format eot s’appelle en fait embedded-opentype, l’utilisation d’eot leurre IE9 qui du coup ne connaît pas ce format et chargera le Web Open Font Format plus léger.
  • Dans le format SVG on notera une chaine louche après l’ancre. Il s’agit de l’identifiant du SVG. Vous le trouverez directement dans les premières lignes du fichier, dans une ligne qui ressemble à ça : <font id="IdMaPolice" horiz-adv-x="786" >.

Une fois la police incluse, elle sera utilisable comme les autres directement dans une directive font-family :

body { font-family: maPolice,sans-serif; } 

Optimiser une police de caractère…

En fonction de vos besoins, il est tout à fait envisageable d’épurer une police pour un usage web. Souvent les polices de caractères contiennent des caractères que l’on n’utilise jamais (symboles, autres langues, etc…) et que l’on peut retirer du package.
Pour ça, il existe deux solutions. Les plus courageux passeront par Font Forge, les plus pressés se concentrerons sur Font Squirrel. Dans le mode « Expert » de ce dernier, on trouve une option « Custom Subsetting » qui vous permettra de sélectionner très finement la gamme de caractères ou uniquement les caractères dont vous aurez besoin. On peut facilement imaginer faire passer le poids d’une police de 150ko à 6ko pour un titre de site par exemple. On est alors très proche du temps de chargement d’une image équivalente, et tellement plus accessible !

L’intégration en mode feignasse by Google

Parallèlement à cette technique qui peut paraître un peu longue à première vue, Google vient de lancer une bibliothèque de polices de caractères librement utilisables. On peut chercher, voir, et surtout, on peut intégrer ça dans son site en une seule ligne de CSS. Google fera le reste (et enverra le bon CSS au bon navigateur).

Google web font previewer

La bibliothèque n’est pas encore très fournie et cette API est encore en version Beta, mais c’est particulièrement prometteur.

Si le sujet vous intéresse, je vous conseille cette lecture ou encore celle-ci, et si vous avez vous aussi des petits conseils sur l’utilisation des polices sur le web, je suis preneur !!


De l’optimisation d’un site web

La question est vaste et c’est un travail quotidien : compression, réduction du nombre des requêtes, mise en cache, progression non obstrusive, parallélisation… Quelques points qui me paraissent essentiels et qui sont encore trop souvent délaissés.

L’optimisation d’un site web joue à chaque fois sur quelques millièmes de secondes. Ça peut paraître complètement dérisoire, ceci étant, je suis passé un affichage en 6 secondes pour la page d’accueil de ce blog à moins d’une seconde et demi. L’expérience utilisateur n’est plus tout la même !

Pour info Google prend officiellement en compte le temps de chargement d’une page web dans le classement des résultats de Google depuis le moins d’Avril. Lire le reste de cet article »


HTML5 : le nouveau souffle des app’s standardisées ?

Avec l’arrivée du HTML5, on sent bien qu’une petite révolution ergonomique se prépare, dans la lignée de celle que fut l’AJAX en son temps. Les premières pages du web commencent à être loin derrière nous maintenant.

Je viens de découvrir Sencha Touch, un kit de développement encore en phase Beta mais qui propose déjà des outils assez bluffants pour créer des site web mobiles avec des interfaces proches de celles que l’on connait aujourd’hui sur les applications smartphones. Pour l’heure, le poids du fichier Javascript laisse à désirer pour un usage mobile (230ko en version compressée), mais c’est parce qu’il prend en charge tous les effets, espérons que ça évolue…

L’avantage de passer par le web pour des applis, c’est de retomber sur ses pattes en utilisant les standards : une seule appli pour couvrir l’ensemble des plate-formes mobiles.

Je vous laisse découvrir, ça fait 20 Mo, et le résultat est visible n’importe quel navigateur, vous m’en direz des nouvelles !


De l’accessibilité des sites web en mobilité

Tel-mobile J’entends souvent dire qu’il faut une version mobile pour un site internet (soyons francs, quand on m’en parle, on appelle ça une version iPhone, ça fait mieux) et je dois dire que je suis assez d’accord. On ne recherche pas la même chose en situation de mobilité que derrière l’écran de son ordinateur confortablement, vautré dans le sofa. Une version bien épurée, pratique et ergonomique permet à l’internaute de gagner du temps et offre une bien meilleure expérience utilisateur. On ne s’adresse pas à l’internaute de la même manière quand il est sur un ordinateur ou sur un téléphone.

Ceci étant, proposer une version optimisée pour les téléphones ne doit pas dispenser de proposer une version générale « compatible » mobile…

Lire le reste de cet article »


Développement web durable ?

Ca fait plusieurs fois ces derniers temps que j’ai l’occasion de me demander « mais pour combien de temps ces gens développent-ils leur site internet ???« . Et chaque fois, l’horizon est de 3 à 5 ans. Le web évolue vite, donc il faut refaire régulièrement. Ils en ont conscience, c’est normal, c’est une dépense lourde, mais Internet est un impératif, ça permet d’avoir une bonne vitrine et de soigner son image, il faut dépenser.

Je ne suis pas totalement contre cette idée. Le web évolue vite. Il faut donc faire évoluer les sites en même temps. Mais en revanche, une grosse refonte de profondeur est-elle vraiment nécessaire si le projet est bien pensé au départ ? A mon gout, le seul risque, c’est le changement radical de technologie (genre ASP => PHP => ROR), pour le reste, des améliorations régulières suffisent amplement.

Sauf quand un site n’est pas prévu pour durer : de très gros développements Flash, absence de séparation entre le fond et la forme, code incompréhensible pondu par une machine sans intelligence, aucune orientation objet dans le développement (ou pensé à peu près comme tel), etc…

Ce qui m’étonne le plus, c’est que l’on soit encore actuellement dans une démarche de vendre ce type de produits. Qu’à-t-on à y gagner ? Refaire le travail tous les 3 ans ? Les changements de chartes graphiques, les évolutions régulières, les nouveaux services, devraient fournir largement autant de travail… et surtout, surtout, permettre d’aboutir à un résultat plus concluant puisque pas repris régulièrement à zéro !

Ah ! Si 2008 pouvait correspondre avec une prise de conscience de l’intérêt d’un développement propre et de celui du respect des standards, ce serait une bonne année
à tous ! (Ben quoi ? Je ne vous l’avais pas encore souhaité !)


Infographie 2.0 et Ajax

infographie 2.0 Je ne suis pas particulièrement versé sur le design en règle générale (la tête de ce blog en dit long sur le sujet). Mais j’ai quand même décidé de me remettre un peu au gout du jour. J’ai donc consulté quelques billets sur l’infographie à la mode 2.0 :

Je me dis au final que l’infographie présente sur le Web 2.0 est composée d’ombrages, de dégradés, de reflets… Il n’y a rien de magique dans tout ça. Rien de bien difficile non plus me direz-vous. Tous les outils dont on se sert pour réaliser ces jolies illustrations sont présents depuis longtemps au sein des logiciels d’infographie.
Mais alors pourquoi diable tout cela n’a-t-il pas vu le jour plus tôt ?

C’est exactement le même cas que pour l’ajax. Les divers langages nécessaires étaient là depuis belle lurette, et ce n’est apparu que bien plus tard, du jour au lendemain, sans que l’on sache vraiment pourquoi…

Après, du côté infographie, la mode doit certainement jouer un rôle (qu’elle ne peut avoir eu pour l’ajax).


Oh oui CSS

Je craque… je ne voulais pas faire de suivisme là dessus, mais je finis par me résigner  ! Un pur truc de Geek !
CSS oh oui à écouter en ligne avec les paroles à côté !
Là je ne pourrais plus rien dire quand je verrais un de mes stagiaire en train de développer avec un casque scotché dans une oreille. ;-)


Mise en forme de flux RSS.

Ca ne vous énerve pas vous de voir un vilain fichier incompréhensible quand vous cliquez sur un flux RSS, ou quand vous tombez dessus via Google ? Moi si, beaucoup même. Il y a pourtant moyen de mettre en forme ces flux RSS via des fichiers XSL.

Je me suis amusé à rendre mon fil RSS à peu près lisible. Le code n’est pas forcément très dur à comprendre :

  • d’un côté un fichier rss.xsl qui permet de remanier la sortie du flux pour un affichage épuré,
  • un fichier rss.css pour la mise en forme (à personnaliser, ou utiliser directement celui de votre thème Dotclear),
  • et un fichier rss.js. Là par contre, c’est une technique qui n’est pas tout à fait clean, j’utilise un remplacement en javascript des balises < et > pour contourner la commande disable-output-escaping= »yes » qui n’est pas implémentée dans Mozilla.

Ca donne un truc plus lisible, et il y a bien entendu moyen de faire bien mieux. Je me suis essentiellement basé sur le travail d’Adal Chiriliuc pour le fichier xsl, les conteneurs ont été ajoutés/renommés pour s’adapter à Dotclear.

Pour ceux que ça intéressent, vous pouvez télécharger les fichiers ici. A vous de compléter à votre sauce. Amusez vous bien…


Dessus de sous ?

Je viens de tomber sur la première page du site DébitCrédit via Eric. Un design sympa en effet ! D’entrée de jeu, je me suis dit « Aïe le référencement »… du texte en image, donc zou le référencement. Puis ça m’a quand même paru bizarre… Un look Web 2.0, ce n’est visiblement pas l’oeuvre d’un amateur… Je désactive les CSS et, oh stupeur ! Je retrouve le squelette exact de la page : tout le contenu en texte ! Parfaite séparation entre le fond et la forme. L’idée est bonne et astucieuse : le texte de base existe dans le code XHTML mais il est ensuite masqué dans la présentation gérée par le CSS. Résultat, visuellement on ne voit que le texte de l’image utilisée en fond, avec toutes les fioritures que cela permet (ombrages, relief, etc.) et un moteur de recherche voit le texte dans le code. Tout le monde est content, c’est joli et efficace ! Tout le monde ? Ben… presque… car à l’écran, on perd toutes possibilités de grossir les polices de caractères. L’accessibilité de premier niveau (juste besoin de grossir un peu le texte) est donc réduite à néant. En revanche, la page offre une accessibilité plus poussée (remplacement des feuilles de style par défaut, lecture du contenu textuel). Dans le cas précis de cette page, un autre petit hic fait son apparition : que se passe-t-il si on essaye de l’imprimer ? Le texte est masqué, or, le navigateur de monsieur tout le monde n’imprime pas les images de fond… l’angoisse de la page blanche (ou presque) ! Rien de dramatique (et je suis prêt à parier que ce sera corrigé d’ici peu), il aurait suffit de préciser au navigateur que le CSS ne doit agir que sur l’écran, ou qu’on lui en donne un autre pour l’imprimante.
Ma conclusion ? Une astuce astucieuse, du joli presque compatible, ça doit pouvoir dépatouiller bien des cas difficiles à mon avis, même si ce problème de polices me gène un peu…

EDIT : Apparemment, j’ai vexé Olivier, le webdesigner qui a créé le design de DébitCrédit. Oops ! Je tiens à m’en excuser platement ! Si j’ai écris ce billet, c’est tout simplement parce que je trouvais sa technique très intéressante ! Respect des standards et visuel au top ! Et cela me semble particulièrement approprié pour ce type de pages. Après, dans un second temps, j’ai élargi un peu pour voir jusqu’où pouvait aller cette astuce et trouvé une petite limite qui peut gêner en production sur des pages d’un type différent, là, une telle utilisation serait donc à étudier au cas par cas. Mais mon cher Olivier, je tiens à le préciser, cela n’enlève en rien toute la qualité de cette page (en espérant en voir plus bientôt) que je trouve particulièrement bien fignolée ! Ah… si j’avais un peu plus de crédits pour le site de l’assoc pour laquelle je bosse, je crois que je signerais.