30 novembre 2007
Pour un premier tutoriel je vais reprendre celui que j’ai fait pour un autre site ( CSS Only Design ). C’est un menu totalement en CSS, histoire de montrer ce dont les CSS sont capables. Evidemment, il fonctionne sur les 5 principaux navigateurs, à savoir : IE6, IE7, FF, Opera et Safari. Vous pouvez l’utiliser pour votre site si vous le voulez, j’apprécierais cependant un lien vers l’auteur. Voici le résultat obtenu.
Lire la suite
22 janvier 2008
Ca faisait quelques temps que je voulais en parler. Cela fait suite à cet article de « A List Apart » : A Preview of HTML 5, dont ce post est entièrement inspiré.
Voici donc des infos sur le HTML 5. Cela correspond aussi au XHTML 5 (à la différence que ce dernier est exprimé en XML, ce qui apporte son lots de variations), qui passerait de la version 1.1 à la version 5 (et coller à celle du HTML). Bien évidemment, tout ceci n’est pas encore clairement défini, ce sont juste des versions alpha (et encore) développées par le W3C et le WHATWG.
Pour l’instant, les balises existantes définissent des titres, des paragraphes, des liens, des emphases, des abbréviations… Mais lorsqu’il est question d’établir les grandes parties d’une page, on doit se tourner vers l’inévitable balise générique : <div> (qui amènera l’horrible expression « coder en div »), balise qui ne signifie et ne représente rien. Que ce soit le header, le footer ou la sidebar, n’ayant pas autre chose sous la main, on utilise des <div> par défaut, auxquelles on applique des id spécifiques.
Le HTML 5 corrigera tout ça. On aura droit à des nouvelles balises très utiles :
La structure d’une page pourra ressembler à ceci :
<body>
<header>Bienvenue</header>
<nav>Accueil - A Propos - Contact</nav>
<article>
<section>
Prémices du HTML 5
</section>
</article>
<aside>Catégories</aside>
<footer>bbxdesign 2008</footer>
</body>
Plus léger et plus lisible. Il faut noter que dans sa syntaxe, une balise <article> pourra regrouper plusieurs balises <section>, ces dernières correspondants à des sous-parties d’un article.
L’intérêt n’est pas seulement pour l’intégrateur du site, mais aussi au niveau des moteurs de recherches. A l’heure actuelle, un moteur ne peut en aucun cas savoir que différentes parties existent dans une page. Il ne peut pas hiérarchiser ou utiliser ces parties.
Ces véritables balises de page pourront le permettre. Ensuite, libre alors aux moteurs de les interpréter à leur façon.
Question accessibilité, ces balises seront très utiles. La page étant bien hiérarchisée, on pourra facilement naviguer et sauter des parties, aller d’une section à une autre… Il suffira d’adapter les outils à cette nouvelle structure.
Lorsqu’il s’agit d’audio ou de vidéo dans les pages web, on pense tout de suite et exclusivement au lecteur Flash. Il s’est imposé par sa légèreté, ses fonctionnalités (streaming, multimédia…), son design. C’est tout simplement le seul moyen de partager de l’audio et de la vidéo facilement, avec des unités de contrôle, et une grande rapidité.
HTML 5 proposera une alternative grâce à ses balises <video> et <audio>. Par exemple, pour la vidéo on pourra définir :
Bref, ça sera le strict minimum, histoire d’avoir la possibilité de lire des fichiers multimédia sans passer par Flash (surtout lorsqu’on ne le maîtrise pas).
Un petit tour sur le site du W3C permet de connaître quelques autres nouvelles balises qui vont venir enrichir le panel :
La liste des balises (et des attributs) s’agrandit pour mieux nous aider en tant que développeurs (facilité, flexibilité, lisibilité) mais aussi en tant qu’utilisateurs (accessibilité, intéraction, simplicité).
Sources : A Preview of HTML 5 , HTML 5 differences from HTML 4
31 janvier 2008
En attendant le prochain bdbx (déjà prêt), je vous propose 5 bonnes pratiques en CSS. A force de bosser des feuilles de style, il m’arrive de ne plus faire quelques erreurs même si je n’arrive pas encore à toujours trouver la solution optimale directement. Ici, je ne parlerai pas de pratiques basiques plutôt évidentes (comme par exemple d’utiliser un maximum les notations raccourcies), mais d’autres plus subtiles auxquelles je ne pensais pas auparavant.
8 avril 2008
La bataille très fructueuse des navigateurs continue. Un nouveau comparatif de performances JavaScript de Firefox 3.0 Beta 5 et Safari 3.1 sur Mac OS X nous montre que Firefox est plus rapide (de peu). Il est intéressant de noter que Firefox est encore en beta tandis que Safari est dans sa version stable. Ces deux là ne cessent de se battre au coude à coude. Une chose est sûre : nous (utilisateurs et web designers) sommes les grands gagnants de cette course vers la performance et le respect des standards.
5 mai 2008
Sur les pages web, nous sommes limités à 9 polices de caractères (Arial, Verdana, Times…). Cela semble peu (et ça l’est). Mais même avec ce faible nombre de polices, on peut jouer sur la taille, l’alignement, les couleurs, le type, l’espacement… pour apporter de la variété et du dynamisme à une page web. Il faut pour cela tester, et cela prend pas mal de temps, de taper une à une les propriétés CSS puis observer les changements, et comparer avec d’autres possibilités. Si vous voulez gagner du temps, je vous propose un outil très pratique (et très bien foutu) : Typetester.
Il s’agit d’un outil pour comparer des polices, sur la base de 3 colonnes (pratique pour voir les différences au premier coup d’oeil). Les modifications se font en « live » et tous les types (gras, italique, small-caps…) sont disponibles. On peut aussi copier-coller les propriétés d’une colonne vers une autre. Cerise sur le gâteau : on peut choisir dans la liste déroulante les polices installées sur son ordinateur, pour ainsi tester d’éventuelles créations d’images.
9 mai 2008
Les web designers sont confrontés au problème du nombre de polices disponibles lorsqu’il s’agit de texte html. 9 polices (dont Arial, Verdana, Times…), ça semble peu. Et pourtant, il existe des solutions pour habiller une page rien qu’en jouant sur les variations d’une même police.
Un exemple : la page du Seed Conference.
1 police (Times) et de nombreuses variations (taille, couleur, type…) créent une page relativement jolie.
Encore plus intéressant : Phineas Jones a réalisé exactement la même page mais en utilisant des em (cadratin). Le résultat est excellent. Changez la taille de la police (Ctrl + et Ctrl – sous Firefox) : le redimensionnement est parfait. On croirait un pdf! Comparez avec la page originale, vous verrez la différence.
Via Simple Bits
23 mai 2008
Une chose que l’on nous apprend en CSS c’est d’utiliser les web-safe fonts. Ce sont en fait une dizaine de polices qui sont a priori existantes sur tous les ordinateurs. Ca permet à l’utilisateur de voir le site correctement, tel qu’il était prévu. Parmi ces polices il y a Arial, Verdana, Times…
Par conséquent, les intégrateurs se sont naturellement limités à utiliser les polices de cette liste. Mais en réalité, rien n’empêche d’en utiliser d’autres. C’est juste qu’en général, on ne prend pas ce risque là, parce qu’on ne connait pas la disponibilité des autres polices.
C’est pour ça que 3.7 Designs a établi une liste de 8 polices qu’on n’utilise pas en CSS mais qu’on devrait. Tahoma, Century Gothic, Palatino… Ce sont des polices qui sont très répandues, que ce soit sur Mac ou PC. On peut donc aisément les utiliser, en songeant bien sûr à spécifier des polices alternatives au cas où elles viendrait à manquer.
10 juin 2008
Avis + Best Of + Bien développer + Design + XHTML / CSS
Après une année (ou presque) passée dans le monde professionnel du web design en tant que novice encore en rodage, je me pose encore la question : c’est quoi être web designer ? J’utilise cette dénomination parce que c’était celle de la formation que j’ai suivie, et qu’elle correspond aux 2 principaux aspects de mon travail : intégration et graphisme.
Intégration : l’écriture du code (X)HTML et des feuilles de styles (CSS) associées.
Graphisme : création de visuels, animés ou non, sous Photoshop, Illustrator, Flash…
A ce stade, j’ai d’ores et déjà inclus autre chose que du graphisme dans la notion de « web design » : l’intégration. En effet, coder c’est du web design aussi, et correspond en l’occurrence à la moitié de mon travail.
Cela peut prêter à confusion. On se dit « design = graphisme » et donc que le « web design » se résumerait au « graphisme sur le web ». Mais « to design », c’est concevoir, penser, réaliser les sites web. Comme le résume très bien l’article Wikipedia :
Le web design désigne la conception de l’interface web : l’architecture interactionnelle, l’organisation des pages, l’arborescence et la navigation d’un site web.
24 juin 2008
Je suis tombé sur un post de Positive Space qui recense 30 Essential PDF Documents Every Designer Should Download. Cette liste très bien fournie aborde des thèmes aussi variés que WordPress, la notion de design, les CSS dans les newsletter, le Web 2.0, la typographie, le statut de freelancer… On peut utiliser ces documents comme des guides, car leur avantage est d’adopter une vision très générale et synthétique d’un thème. Voici quelques-uns de mes préférés.
Yahoo! possède déjà de très bonnes ressources pour les développeurs en tout genre. Le pdf de Design Pattern Library est quant à lui un résumé des différents éléments graphiques que l’on peut être amené à implémenter dans un site, que ce soit des onglets, des calendriers, des formulaires… Il y a aussi des informations utiles pour créer un site selon un système de grille, ainsi que des informations sur les supports mobiles (dont l’iPhone).
Ce mémo pour WordPress est indispensable à tous ceux qui comme moi aiment créer des thèmes WordPress à partir de rien. Il recense toutes les fonctions que l’on peut appeler, en y juxtaposant une description concise et précise. Il existe bien sûr le Codex WordPress, la source principale, mais ce mémo a pour avantage de donner une vision globale de ce que l’on peut faire, et de trouver facilement une solution face à un problème donné. Si vous voulez aller plus loin, il existe aussi le Advanced WordPress Help Sheet, qui lui se focalise sur des cas particuliers faisant appels à plusieurs fonctions.
Ce qui me plaît dans cette charge contre le look Web 2.0 c’est que l’auteur (Elliot Jay Stocks) évalue exactement les raisons de la prolifération du soi-disant style « Web 2.0 » et caricature les gens qui ne comprennent pas ce que c’est, que ce soit les clients ou bien (et c’est pire) les designers eux-même. Le Web 2.0 n’est pas un design mais un concept. Malheureusement, ce terme a généré une vague sur laquelle bon nombre de gens surfent allègrement en se posant comme des designers 2.0 et considérant que l’Ajax est une technologie 2.0 (alors que ce n’est pas la technologie qui a changé entre le 1.0 et le 2.0, mais l’utilisation que l’on en fait). Le document fait bien remarquer que bon nombre de web designers n’ont pas suivi cette tendance de « look 2.0 », voyant bien que ce n’est qu’un feu de paille bien superficiel.
4 juillet 2008
Ce matin en ouvrant mon navigateur préféré, une mise à jour de Colorzilla était disponible. Vous connaissez sans doute cette extension Firefox qui permet d’avoir un outil « pipette » dans votre navigateur. Ainsi, en naviguant sur un site, il suffit de cliquer sur l’icône Colorzilla et de placer le curseur sur un pixel d’un élément de la page pour connaître ses codes couleurs (RVB et Hexadécimal).
Souvent, lors d’une mise à jour, une page du site de l’extension s’ouvre pour vous décrire les maj installées. En général, je zappe rapidement cette page, pensant qu’il n’y a qu’une liste de bugfix sans intérêt pour ma part. Mais là, j’ai bien fait de lire les nouveautés.
Aujourd’hui, la version 2.0 de Colorilla est sortie. Quoi de neuf ? Et bien 2 fonctions bien pratiques :
La version 2.0 porte plutôt bien son nom, avec son lot de fonctionnalités de partage très intéressantes, sans oublier la simplicité et l’efficacité du générateur de palettes.
1 août 2008
N’ayant actuellement pas internet chez moi mais voulant tout de même finir mon futur thème WordPress, j’ai cherché à obtenir une version complète et transportable du Codex WordPress. J’ai finalement trouvé par hasard ce guide complet des template tags de WP.
En désactivant le JavaScript (merci Web Developer), on obtient la même page avec tous les blocs entièrement déroulé. Ensuite, un screenshot de la page entière (merci Pearl Crescent) permet d’obtenir tout le codex WordPress en une seule image.
11 août 2008
Si vous suivez ce blog depuis quelques temps, vous aurez remarqué que j’aime changer de thème WordPress assez fréquemment. Non seulement, je m’ennuie en général assez vite d’un nouveau design mais le thème en lui-même n’est pas bien construit. D’un côté, j’aime varier l’aspect purement graphique de mon site et je construis par conséquent le thème derrière. Mais ce dernier est rarement optimisé. Par exemple, le dernier contenait uniquement un fichier index.php (mis à part les fichiers d’inclusion du type header,footer, comments…). Vous aviez donc la même page selon que vous naviguiez sur la page d’accueil, la page d’un post ou la page des archives. Une grossière erreur d’ergonomie.
Mon objectif était avant tout de réaliser un thème long terme, que je ne modifierais pas dans quelques mois. Il fallait donc qu’il soit déjà très fonctionnel.
Chaque type de page a sa structure personnelle :
Le plus grand challenge a été de réaliser ce thème avec un design élastique. Il n’est pas fixe (largeur définie en pixels), ni fluide (largeurqui s’adapte à la taille de la fenêtre). Il est élastique : la largeur des blocs dépend de la taille du texte, car définie en em. Il est rare de voir ce genre de design parce qu’il est plus compliqué à mettre en place que les autres. Parmi les sites qui l’utilisent, il faut citer l’excellent SimpleBits, le très typographique site de Jon Tan ou bien l’incontournable blog de Fred Cavazza.
A quoi ça sert ?
En modifiant la taille du texte (Ctrl+molette vers le haut ou le bas), les blocs s’adaptent à la taille du texte. Ca permet à ceux qui veulent agrandir le texte de le faire tout en gardant une structure correcte. On a l’impression que c’est un véritable zoom, mais il n’en est rien. Cette méthode marche même sous Internet Explorer.
J’aurais pu refaire un design fixe, comme d’habitude. Mais j’ai profité ce nouveau thème pour apprendre à utiliser les em. Je l’ai fait en lisant (et relisant) cet excellent post : The Incredible Em & Elastic Layouts with CSS.
En supplément de l’utilisation des em pour la typographie et pour la largeur des blocs, je me suis intéressé à adopter une structure verticale, que l’on appelle en anglais vertical motion (ou vertical rhythm).
Vertical space is metered in a different way [to horizontal space]. You must choose not only the overall measure – the depth of the column or page – but also a basic rhythmical unit. This unit is the leading, which is the distance from one baseline to the next.
Que ce soit les titres, les paragraphes, les listes, les citations… tous ces éléments ont une hauteur multiple de 24. Cela se voit surtout sur la page d’un seul post, où il y a 2 colonnes.
Il y a donc pas mal de changements dans ce dernier thème. J’en ai profité pour mettre à jour mon tutoriel de menu 100% css et je compte prochainement rajouter un theme switcher, ainsi qu’un footer (à l’occasion 😉 ).
19 novembre 2008
Hier je suis tombé sur un post très surprenant : une librairie JavaScript qui fait fonctionner IE6 comme IE7.
Il s’agit d’un JS à implanter sur son site et qui (si le JS est actif chez le client) fixe les divers problèmes HTML et CSS de IE6. En gros, plus de problème de :
Je l’ai implanté sur mon site, mais n’ayant pas d’IE6 sous la main, je n’ai pas pu vérifier la performance du JS. Si un passant encore sous IE6 pouvait me le dire, ça serait sympa. Comment vérifier ? C’est simple : mon site est cassé sous IE6 (parce qu’il est bien codé 😉 ) et ne le serait pas a priori avec ce JS.
Comme le dit le site lui-même, ça semble trop étonnant pour être vrai. Les heures passées à régler les innombrables bugs d’IE6 seraient de l’histoire ancienne ? Cela voudrait dire aussi que l’excellent Position Is Everything ne serait plus indispensable ?
La réponse est : attendons de voir. Ce JS est relativement passé inaperçu donc je ne sais pas ce qu’il vaut exactement. Mais ça reste un grand espoir pour les web designers hostiles à ce fossile qu’est IE6.
8 janvier 2009
Si l’on considère que le web design, c’est à 95% de la typographie (et c’est sans doute grandement vrai), le moteur de rendu du texte d’un navigateur devient un élément primordial dans le choix de ce dernier. Dans les navigateurs les plus répandus, il en existe un qui se démarque particulièrement dans ce domaine : Safari (que ce soit sous Windows ou Mac).
Lire la suite
17 février 2009
Si vous désirez créer un menu avec des <ul> et des CSS, voici le site qu’il vous faut : CSS Menus. Il regorge de plusieurs types de menus (horizontal, vertical, déroulant…) et les proposent même en téléchargement gratuit. Accessoirement, ce site constitue un bon moyen d’apprendre à créer des menus soi-même.
8 mars 2009
En regardant la liste des plus vieux sites en .com, on remarque que peu d’entre eux sont connus. A part IBM, Intel ou Apple, beaucoup sont inconnus. Comme le premier de la liste : Symbolics.
Ce qui m’étonne, c’est de voir dans le code, du vieux HTML Transitional (avec ses majuscules, ses <font> et autre <BR>) mélangé à quelques <DIV>, <SPAN> et des CSS inline… Curieux mix.
20 mars 2009
Si vous n’avez pas eu la chance de tester la compatibilité de votre site avec le tout récent Internet Explorer 8, ne vous inquiétez pas! Rajoutez cette ligne de code sur tout votre site et il sera compatible IE7:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
Merci à David Walsh pour cette astuce.
29 mars 2009
Astuces + Design + XHTML / CSS
Je suis tombé sur ce post qui recense des sites d’applications iPhone, où le téléphone en lui-même s’avère être un élément de design redoutable. Mais au-delà du contenu de ce billet, ce qui m’a beaucoup plu c’est la manière dont un lien visité est marqué. Pour ceux qui ne le sauraient pas, il est possible de styler différemment les liens qui ont déjà été visités. Par défaut, les liens nouveaux sont bleus, les liens visités sont violets.
Bref, voici comment ils apparaissent sur ce site :
J’ai trouvé ça très sympa et très pratique : rajouter une image par-dessus les liens visités grâce à la CSS.
3 avril 2009
Je ne connaissais pas cette astuce et j’en avais besoin pour mon tout récent blog 29minparjour.com où je poste beaucoup de code dans des balises <pre>.
Au début, je voulais utiliser le syntaxhighlighter (très connu et très utilisé) mais je n’aimais pas avoir à spécifier à chaque fois dans le html que tel bloc devait être stylé, et dans quel language. De plus, le code à insérer (name= »code ») n’est pas valide…
J’avoue que le rendu est élégant (sauf avec la version 2.0, la dernière en date). D’ailleurs, Viget Labs avait amélioré le JS en permettant d’agrandir la fenêtre au survol. Une belle amélioration.
Malgré tout, c’était au niveau HTML que je trouvais ça laborieux. Je voulais quelque chose de tout simple.
Je voulais juste un simple retour à la ligne pour éviter que les balises <pre> ne dépassent en largeur. J’ai trouvé ça sur le site de Tyler Longren :
pre {
white-space: pre-wrap; /* css-3 */
white-space: -moz-pre-wrap; /* Mozilla, since 1999 */
white-space: -pre-wrap; /* Opera 4-6 */
white-space: -o-pre-wrap; /* Opera 7 */
word-wrap: break-word; /* Internet Explorer 5.5+ */
}
Ca fonctionne sous FF 3 et IE6. Le comble étant que le reste du site est un encore un peu cassé sous IE6… (soupir)…
16 avril 2009
Art + Humour + Logiciels + XHTML / CSS
Rappelez-vous cette scène culte de Pulp Fiction où Samuel L. Jackson s’emporte un peu… Remplacez les protagonistes par des navigateurs et vous obtenez Pulp Browsers. Ou comment IE7 se fait remonter les bretelles par Firefox et Safari.
PS : la version typographique de cette scène est superbe.
21 avril 2009
Depuis longtemps, je suis le passionant travail de Luke Wrobleski, le Senior Director of Product Ideation & Design chez Yahoo. En gros, il design des interfaces web, et notamment les formulaires. Ca n’a l’air de rien, mais cet élément fondamental du web est souvent négligé. Il a sorti un livre : Web Form Design: Filling in the Blanks que j’aurais acheté si je bossais encore dans le e-commerce.
Luke a fait une conférence le mois dernier au MIX 09. Elle est disponible en vidéo et c’est à partir de celle là que je rédige ce post.
Les formulaires, c’est chiant. C’est une barrière entre l’internaute et le site, entre l’utilisateur et l’outil, entre le client et l’entreprise. Il y en a pour tout : pour acheter en ligne, pour participer à des forums, pour utiliser une appli web… C’est pourquoi il faut en tenir compte pour les rendre plus agréable à remplir.
Je livre ici un résumé de la vidéo précédemment citée.
Avant de remplir un formulaire, l’internaute doit avoir un aperçu de ce qui l’attend. Visuellement, la page doit pouvoir être scannée rapidement. Si il y a plusieurs pages, il faut notifier des différentes étapes (présent, passé, futur). Il faut qu’à tout moment, l’internaute sache où il en est et ce qui lui reste à faire.
Mauvais exemple :
Bon exemple :
Il y a 3 manières d’aligner les labels :
3 manières d'aligner les labels pour 3 situations différentes
Si on met le label à l’intérieur de l’input, il faut bien notifier que le contenu actuel ne fait pas partie de la réponse à donner. Si il y a marqué « Mettez votre nom ici… », il faut éviter que ce contenu soit validé.
Aussi, en remplissant l’input, le label disparaît. Donc à utiliser avec précaution.
L’aide est utile :
Il faut faire attention à ne pas surcharger l’utilisateur d’informations.
Plusieurs manières d’aider l’utilisateur :
Le formulaire de Digg offre une aide au fur et à mesure que l'on remplit les inputs.
Avec de l’Ajax et des notifications visuelles, on peut aider l’utilisateur à remplir correctement le formulaire, et du mieux possible.
La validation en « live » permet :
La barre de progression pour le mot de passe s'est très répandue.
Luke avait posté un excellent post sur la manière de placer et distinguer les actions primaires (« Valider », « Confirmer », « Suivant »…) des actions secondaires (« Annuler », « Effacer », « Retour »…). Il avait réalisé des tests utilisateurs en leur proposant 6 mises en forme différentes.
La meilleure solution est :
La meilleure solution est de distinguer visuellement les deux actions possibles et d'aligner l'action principale à gauche.
Il y a parfois des actions qui demandent du temps, par exemple, lorsqu’on rentre un numéro de carte de crédit et que le formulaire demande à la banque si les informations données sont correctes.
Dans ce cas, pour éviter les erreurs, la meilleure solution est de désactiver temporairement la validation du formulaire, parce que justement, on ne peut pas valider tant que la réponse de la banque n’a pas été fournie. Si l’internaute clique par malheure sur le bouton, il risque de compromettre la validation du formulaire et d’avoir à tout recommencer.
C’est le cas typique de la case à cocher « J’accepte les condtions de service », qui est généralement décochée. L’internaute clique sur « valider » mais ça ne marche pas.
Les erreurs de formulaire dûes à des informations erronées données par l’internaute sont le principal obstacle à la validation du formulaire. Tant qu’il y a des erreurs, on ne peut terminer la validation. L’important est de notifier ces erreurs, et d’informer l’internaute.
Pour bien notifier l’erreur, il faut :
N'oubliez pas les déficients visuels : il faut non seulement une différence de couleur mais aussi une différence dans la police. Une icône est un plus.
Il y a souvent des inputs inutiles dans un formulaire. Par exemple, il arrive souvent à l’inscription d’un site que ce dernier vous demande toutes vos informations : nom, prénom, adresse, sites préférés, hobbies, comment avez-vous connu le site, votre revenu annuel… alors que l’essentiel pour utiliser le site ne réside que dans le nom et l’email.
On voit ça souvent dans les sites communautaires (un forum par exemple) où on demande implicitement à l’inscription de remplir la page de profil alors qu’il est parfaitement possible de s’en occuper plus tard. « Pour l’instant, je veux juste poster ma question sur le forum. Je remplirai mes informations personnelles après ».
Si il est possible de retirer des inputs, il faut le faire.
Avant de s’attaquer à la création d’un formulaire, il faut se focaliser sur ces points :
Ecrire "Day/Year" plutôt que "dd/yyyy" est bien plus naturel et compréhensible.
Le site Huffduffer propose un formulaire imbriqué dans une phrase.
Le but ultime d’un formulaire est de pouvoir s’en passer. Si un internaute peut commencer à utiliser un service web sans avoir à s’inscrire, alors il sera beaucoup moins réticent à s’inscrire par la suite. « Tiens, je n’ai pas besoin de m’inscrire pour tester cette appli. » Et quelques minutes de test plus tard : « Ah c’est vraiment super! Je m’inscris tout de suite! »
En arrivant sur netvibes, on peut déjà customiser sa page sans avoir à s'inscrire au préalable.
Si une inscription est inévitable, il faut faire en sorte de la rendre la moins laborieuse possible.
Par exemple, si je veux créer un blog :
Je veux juste créer un blog. Pourquoi remplir 3 pages alors que je n'ai que besoin de remplir 3 champs ?
Les formulaires resteront toujours un obstacle entre un site et l’internaute. Il faut à tout prix les raccourcir, jusqu’à les supprimer! Le plus gratifiant dans l’expérience que l’on a d’un service web c’est lorsque l’utilisation est instantanée. Il n’y a pas délai entre le moment où l’on arrive sur un site et le moment où l’on commence à s’en servir. L’inscription s’avère alors une formalité.
Est-ce qu’un bon formulaire peut faire gagner de l’argent ? Oui! Rappelez-vous le bouton à 300 millions de dollars : l’internaute n’était plus invité à « S’inscrire » mais plutôt à « Continuer » ses achats. Ce formulaire avait été redesigné par Luke Wroblewski lui-même.
Je vous invite donc fortement à regarder cette passionante et sympathique vidéo remplie d’exemples intéressants et drôles.
27 avril 2009
Avis + Humour + Logiciels + XHTML / CSS
J’avais lu un article sympa il y a quelques jours : « 10 cool things we’ll be able to do once IE6 is dead« . Je me suis dit que j’allais me faire une petite liste perso.
Si IE6 n’existait plus :
En attendant, je galère encore.
4 mai 2009
The do’s and don’ts of modern web design regroupe les bonnes pratiques (do’s) et les mauvaises pratiques (don’ts) en web design. A chaque fois, un lien est fourni vers un article expliquant pourquoi c’est une bonne ou mauvaise pratique.
Dans les do’s on trouve par exemple :
Il faut dire qu’en l’occurence le conseil « Mix and match Classes » contredit un peu le « Write good class and id names » parce qu’il crée une classe « bordered » (bouh pas bien). Mais dans l’ensemble ça reste cohérent.
Dans les don’ts (à éviter donc) on a par exemple :
Le site aurait du rajouter « oublier de faire un lien sur le logo du site »!
6 mai 2009
Je me suis posé la question de savoir combien était divisé mon temps pendant que j’intégrais. J’ai divisé en 5 parties ce temps (peut-être en oubliant des parties) et évalué grossièrement leur répartition. Je suis arrivé à ce graphique :
Je code toujours en XHTML 1.0 Strict, et ça m’a évité pas mal de problème de Quirksmode je me rends compte. J’utilise au maximum les balises sémantiques <p>,<ul>,<label>,<hn>,<strong>… mais je suis de moins en moins réticent à multiplier les <div> et <span>. D’un côté, c’est cool d’éviter la divite, c’est joli, c’est léger. Mais en pratique, et surtout pour les gros sites, il faut être très spécifique quant aux styles à appliquer à certains éléments. Donc je rajoute une ou deux div par ci par là pour améliorer ma productivité et surtout la flexibilité du code. Ca facilite grandement la différenciation. Et ça permet surtout de prévoir d’eventuelles évolutions de fonctionnalités, et avoir une approche plus modulaire.
A force de prôner la séparation HTML (contenu) / CSS (mise en page), on a peur de modifier le HTML, comme si c’était devenu interdit voire impossible. Je me dis que les développeurs ne sont pas bien méchants et que l’on peut leur demander des modifs HTML, avoir plusieurs classes sur un même élément au lieu de répéter son code CSS pour pas grand chose (voir plus bas).
C’est évidemment très lié au HTML utilisé. Depuis quelques temps, je me suis fait un fichier reset.css qui utilise le Reset CSS de Yahoo! . Par contre, ce n’est pas un fichier que j’importe à chaque fois mais un code que je copie-colle en créant ma CSS. Parce que oui, je préfère garder une seule CSS pour tout le site. Niveau lisibilité, je n’ai pas trop de problème à utiliser un seul fichier parce que j’écris chaque sélecteur CSS sur une seule ligne. Niveau productivité, répartir des propriétés sur plusieurs CSS c’est passer beaucoup de temps de l’une à l’autre, trouver où se trouve ce sélecteur, éviter les conflits… J’évite. Et le seul vrai avantage d’avoir plusieurs CSS, c’est d’en appeler certaines dans certains cas, et d’autres dans les autres cas. Je préfère mettre une class au body pour différencier les pages, c’est beaucoup mieux.
Les exceptions pour utiliser plusieurs CSS sont : un fichier pour ie6, un fichier par couleur (si il y a des thèmes par couleur) et un fichier pour le print.
Je fais encore pas mal de contextualisation (ex: .bloc table tbody td.direction ) parce que ça permet d’éviter les conflits. + de contextualisation = – de classes à créer
Il y aussi le cas où vous voulez que plusieurs éléments HTML aient les mêmes propriétés CSS Dans ce cas, il y 3 choix :
La première méthode est à éviter : si on veut changer une propriété (ex: la couleur d’une bordure), il faut le changer autant de fois que l’on a copié-collé.
La deuxième méthode est la plus propre : le HTML reste relativement léger (= non alourdi de classes) mais la CSS est plus longue à maintenir. C’est ce que je faisais avant.
La troisième méthode est plus « modulaire » je dirais. Un élément HTML aura par exemple : class= ».maclasse .manouvelleclasse ». On rajoute donc une classe aux éléments qui ont le même style. Mmmh. Est-ce que c’est bien ? Est-ce que l’on sépare bien la mise en page du contenu ? Plus ou moins je dirais. En fait, dans le HTML, on ajoute la classe à tous les éléments qui doivent appraître de la même façon. Et si on veut plus qu’un élément n’aie plus ces propriétés ? Il faut supprimer la classe dans le code HTML. Ah. C’est pas bien. On ne devrait plus avoir à toucher au code HTML. En théorie, c’est vrai. Mais en pratique, c’est, d’une part, très rare de vouloir changer le style d’un seul élément, et d’autre part, pourquoi n’aurait pas-t-on le droit de modifier le HTML ? Une fois livré, on ne peut plus rien faire (voir § sur le HTML) ?
Je dois préciser une chose importante : cette méthode modulaire, je l’utilise surtout pour les blocs et les gros éléments, pour les éléments qui structurent et divisent l’affichage. Il faudrait que j’envisage de faire un article avec des exemples plus éloquents. 🙂
J’ai déjà parlé de ce que l’on pourrait faire si IE6 n’existait plus. En fait, rendre un site compatible IE6, c’est du débuggage pur et simple. On doit utiliser des overflow:hidden, position:relative, display:inline… pour aucune raison valable si ce n’est faire plaisir aux internautes du siècle dernier (ou presque). Sans compter tout ce que l’on est privé de faire. Bref, une calamité.
Dans mon souci d’avoir un code lisible, pour moi et ceux qui retoucheront aux CSS, j’essaye d’avoir des noms de class/id simples mais efficaces. Simple, ça veut dire court. Avec 4 lettres, on peut faire pas mal de choses : .bloc, .nav, .main, .side… J’ai par exemple remplacé .pagination par .page. Ou mettre .srv au lieu de .service. C’est pas très méchant et ça permet d’avoir une CSS bien plus lisible (surtout si l’on contextualise ET que l’on met tout sur une ligne).
Et si je passe autant de temps, c’est aussi pour éviter d’appeler un élément « grillade » par exemple (alors que ça n’a rien à voir avec un barbecue). J’ai vérifié, elle y est encore.
Dernier point : découper le PSD. On voit directement si un PSD est fait par quelqu’un qui sait intégrer ou pas. J’ai de la chance, c’est souvent le cas. Mais lorsque ça ne l’est pas, il faut voir les effets de dégradés, les superpositions, les ombres qui dépassent… qui n’ont l’air de rien graphiquement, mais qui sont une calamité à intégrer. D’ailleurs, c’est une calamité à cause d’IE6! Parce que pour IE6, il faut tout aplatir! L’ombre doit aller avec l’élement qui la fait ET avec l’élément où elle se projette. N’est-ce pas logique ? Et bien non. Vive les PNG. C’est tout.
J’ai essayé de faire un rapide panorama de ce que doit faire un intégrateur. On se rend compte que le grand ennemi reste IE6. Les 40% cités correspondent au temps de débuggage, mais je suis sûr qu’on peut gagner du temps dans les autres domaines (découpage, css, html) si il n’y avait pas IE6. J’ai peut-être oublié des éléments, je ne sais pas. Vous avez des idées ? Des remarques ? Des critiques ?
12 mai 2009
A la question « Est-ce que je mets un <h1> pour mon logo ? », je répondais oui avant. Maintenant, je réponds non.
Il existe un débat assez récurrent sur l’élément de la page qui portera le h1. Que ce soit dans un post ou deux, ou dans des commentaires, la question reste ouverte. Il y a 2 écoles :
Cas particulier : il arrive d’avoir un h1 pour le logo uniquement sur la page d’accueil, les autres pages ayant un h1 différent. Je classe ces sites dans la deuxième catégorie.
C’est quoi un h1 d’abord ? Selon le W3C, ça donne :
A heading element briefly describes the topic of the section it introduces. Heading information may be used by user agents, for example, to construct a table of contents for a document automatically.
Le h1 est le titre de premier niveau et doit introduire la section qui le suit.
Si le h1 est sur le logo, alors il est tout en haut. Il doit donc décrire tout ce qui le suit, c’est à dire, le reste de la page. Il ne faut pas le mettre sur le logo alors ?
Le titre de la page (balise <title>) est défini ainsi par le W3C :
The TITLE element is not considered part of the flow of text. It should be displayed, for example as the page header or window title. Exactly one title is required per document.
Le titre est unique et doit décrire le contenu de la page. C’est à peu près de cette façon que j’utilise mon h1 : il est unique et décrit la page. Il est pour moi différent pour chaque page, comme l’est le titre.
Par contre, le titre doit être davantage fourni que le h1. L’idéal pour ce post serait :
Mon titre décrit le contenu du document et d’où il provient.
Mon h1 décrit la section qu’il introduit : mon post.
Les deux sont complémentaires parce que l’un fait partie du flux du document, l’autre non. Ils ont donc un rôle légèrement différent.
Je viens de remarquer que Digg et A List Apart ont deux h1 dans la même page (lorsque l’on va dans les commentaires ou sur un article). Ca m’a surpris parce que j’ai toujours cru que le h1 était unique, comme l’est la balise title. Le W3C ne spécifie rien sur l’unicité des headings (h1,h2,h3…) mais étant donné qu’elle préconise d’utiliser une partie de la balise title pour son contenu, je présume qu’il faut que le h1 soit unique.
Si je résume, le h1 :
Cette équation a une seule solution : il y a un h1 différent par page, un lien pour le logo (à part éventuellement pour la page d’accueil, qui est un cas particulier).
Si le h1 doit décrire ce qui le suit et que je le mets sur le logo « bbxdesign » sur toutes les pages (il l’est actuellement uniquement sur ma page d’accueil), alors toutes mes pages auront comme contenu « bbxdesign » ? C’est très léger comme description de ma page, et très redondant, surtout pour les moteurs de recherche. Toutes mes pages ne parlent pas de « bbxdesign ». C’est juste le nom du site (qui est par ailleurs dans l’url). Mes pages ont toutes un contenu différent et je veux que mon h1 reflète ceci. C’est pour ça que ma page d’accueil a le logo comme h1, mais tous mes posts ont leur titre comme h1 (et le logo devient h2).
Le logo décrit le site, pas la page que l’on consulte actuellement. Après, il est possible de mettre deux h1, un pour le logo, un pour le titre du post par exemple. Mais cela voudrait dire que le premier h1 (celui du logo) affiche « bbxdesign », et l’autre affiche « Un h1 pour le logo ou pas ? ». Pourquoi pas, mais je trouve que le second a davantage de poids et de légitimité que le premier. Et étant donné que l’on jusqu’à 6 niveaux hiérarchiques, pourquoi ne pas en tirer profit ?
Si le h1 n’est pas le logo, il se peut (et c’est mon cas) que le h1 ne soit pas le premier élément de la page, mais arrive après le header et la navigation. Est-ce que c’est problématique ? Je ne pense pas. Le W3C ne précise rien à ce sujet. Il faudrait plutôt se poser la question si les titres (h1,h2,h3…) sont davantage une question d’ordre ou de poids ?
A première vue, c’est surtout une question d’ordre. On a d’abord un h1, puis un h2, puis un ou plusieurs h3, puis peut-être un autre h2 suivi d’autres h3… A ce propos, il est interdit de « sauter » un niveau hiérarchique. On ne passe pas d’un h1 à un h3 sans avoir de h2. Il faut voir les h1-h6 comme des chapitres d’un livre.
Users should order heading elements properly. For example, in HTML, H2 elements should follow H1 elements, H3 elements should follow H2 elements, etc. Content developers should not « skip » levels (e.g., H1 directly to H3).
Pour le W3C c’est une question d’ordre. Mais il m’arrive de ne pas suivre cette règle à la lettre. Par exemple, dans une sidebar structurée, je mets des <h3> et des <ul> parce que c’est le poids que je leur donne par rapport au contenu de la page. Et mon post a lui aussi des h3-h6. Par conséquent, l’ordre de mes titres dans mon code peut passer du h6 au h3. Et ce n’est pas spécifique à la sidebar. Ca peut arriver lorsqu’il y a plusieurs zones dans la page avec un contenu différent.
Les titres h1-h6 restent des éléments assez mal utilisés (par moi d’abord), sans doute par manque de précisions de la part du W3C. En même temps, c’est peut-être têtu de s’obstiner autant. Parce qu’en ayant d’un côté le W3C (avec les soucis de standardisation et d’accessibilité) et de l’autre les moteurs de recherche (qui analysent minitieusement notre code), couplés à un flou autour de la définition de l’utilisation des titres, on se demande parfois si la solution est unique.
