Opinion

Les cartouches d’encre sont-elles trop chères ? Oui.

9 Dec

Imaginons que je veuille acheter une imprimante couleur (parce que j’en ai pas).
Imaginons que j’aille sur le très peu ergonomique Fnac.com (clic du milieu inactif sur les listes produits, colonnes non triables, version flash à pleurer… bref).
Je tombe sur l’imprimante Canon Pixma IP 2600 à 39,90€ (livrée avec une cartouche noire et une cartouche couleur).

Ok cool. J’ai mon imprimante. Puis quelques mois plus tard, je n’ai plus d’encre noire, ni couleur. Alors je veux en acheter sur Fnac.com (parce que je suis maso). Il me faut (selon le site Canon) :

Encre noire Canon PG-40 à 21,90€
Encre couleur Canon CL-41 à 26,90€

Vous avez fait le calcul ? 2 cartouches d’encre, c’est plus cher qu’une nouvelle imprimante.

Les cartouches livrées avec la nouvelle imprimante ne sont sans doute pas remplies en entier, mais quand même…

6 commentaires »

La refonte perpétuelle

15 Nov

Le web est un média en mouvement continu. Comme chaque web designer qui se respecte, je fais ma veille régulière et relativement abondante, qu’il s’agisse de graphisme, de connaissances, d’astuces de code, de design, de tendances, d’outils, d’acteurs du web. Avec toute cette masse d’information, textuelle et visuelle, j’ai sans cesse envie d’intégrer de nouvelles idées graphiques et techniques dans ce blog, et je commence souvent des thèmes wordpress sans les terminer au final.

Le dernier en date, débuté il y a 2 mois déjà, s’appelle bbxjulie (en référence au morceau “Julie with…” de Brian Eno). J’y ai beaucoup bossé, je l’ai fignolé et je l’ai même intégré en thème wordpress. La seule qui manque est la page portfolio (une Page WP custom que j’ai pas pris le temps de faire). D’ailleurs, vous pouvez voir sur ce blog le thème bbxjulie.

Lorsque je l’ai commencé, j’étais très enthousiaste et plutôt content du rendu. C’est un des rares thèmes que je n’ai pas laissé tomber au bout de 3 jours, et je me disais qu’il allait être très complet et surtout : qu’il allait durer. Mais au final, même en y ayant passé beaucoup de temps, il ne me plaît pas. Je sais pas pourquoi. Plusieurs éléments me plaisent, notamment la sidebar avec les vignettes du portfolio et le champ de recherche. Mais c’est tout.

Pourquoi une refonte ?

La réponse que je me donne à cette question est très simple : je n’aime plus mon thème actuel. Il est ennuyeux et loin d’être ce que je voulais qu’il soit. Et l’intégration de nouveaux outils implique selon moi une refonte graphique.

Pourquoi ça bloque ?

Le manque d’inspiration, c’est évident. Mais surtout, le flou dans l’identité que je veux donner à ce blog. Ca doit être lié au rôle de ce blog.
Mais d’ailleurs, il me sert à quoi ce blog ? A parler, réponse évidente.
Mais de quoi ? De web design, de jeux vidéo, d’humour, de musique, de multimédia, de technologie, de code.
De moi ? Oui et non. Oui parce que l’intérêt principal d’un blog et la subjectivité affichée de l’auteur. Non parce que je ne parle pas de moi directement.
Quoiqu’il en soit, je me suis toujours refusé à essayer d’établir une charte éditoriale. Sans doute parce qu’il n’y en avait pas au départ et qu’il est compliqué d’en définir une en cours de route.

Résultat : ce blog est en roue libre depuis quelques temps, une sorte de hérisson à la dérive qui s’affiche et se manifeste lorsqu’il ne s’amuse pas à traverser des tunnels.

5 commentaires »

Mais arrêtez avec IE6!

20 Jul

Je le dis et je le répète : il faut arrêter de s’acharner à faire fonctionner parfaitement son site sous IE6. Chaque semaine, il y a un nouvel article qui prône cette idée, et c’est très bien.

Est-ce qu’un site doit apparaître exactement pareil sous chaque navigateur ?

Pour ceux qui ne le sauraient pas encore : la réponse est non.

Notez l’adverbe “exactement”. Parce que d’un côté, il faut que l’utilisateur puisse reconnaître un site, quel que soit le navigateur utilisé. Mais des différences (plus ou moins) légères dans le graphisme sont non seulement tolérées mais parfaitement admises. Ne pas avoir de coins arrondis (par CSS ou PNG), de dégradés complexes (par PNG), des ombres portées… sous IE6 n’est pas un problème.

C’est surtout qu’un utilisateur d’IE6 ne verra aucune dégradation dans sa version vu qu’il ne verra pas la “bonne version”!

Et puis d’abord, tout le monde n’a pas toutes les polices utilisées sur un site (Arial inexistant sous Linux ?), donc il y a déjà obligatoirement des différences, et des grosses différences : la typographie c’est au moins la moitié du design.
Lire la suite »

16 commentaires »

Le XHTML 2 c’est fini. Le HTML 5 s’en trouve renforcé.

5 Jul

Vous êtes sans doute au courant que le groupe travaillant sur le XHTML 2 va s’arrêter à la fin de l’année, pour notamment rejoindre le groupe du HTML 5. C’est moins laisser tomber quelque chose que se concentrer sur un seul standard.

Différence XHTML / HTML

La différence principale entre le XHTML et le HTML est la rigueur du code. Un document XHTML nécessite de n’inclure aucune erreur de syntaxe pour être bien rendu, alors qu’un document HTML peut se permettre de contenir certaines erreurs. Ca vient du moteur de rendu du navigateur qui gère les deux documents différemment. Ca ne veut pas dire qu’il faut être négligeant dans l’écriture du code pour autant. Mais c’est plus propre d’avoir à se tenir à une syntaxe rigoureuse.

Le HTML a l’avantage d’être davantage rétro-compatible. Les navigateurs plus anciens arrivent à mieux lire un document HTML récent qu’un document XHTML récent. Ca vient sans doute du côté “léger” de sa rigueur.

Concrètement, ça change quoi cette fin du XHTML 2 ?

A vrai dire, pas grand chose car c’est dans la logique des choses. Depuis quelques mois, le HTML 5 n’arrête pas de faire parler de lui. Les navigateurs commencent à bien l’implémenter (Safari 4, Opera et le tout récent Firefox 3.5). Et il a un gros potentiel. Pour en savoir plus, vous pouvez lire ma petite introduction au HTML 5.

Etant un adepte du XHTML 1.0 (pour des raisons de rigueur de code et pour éviter le Quirks Mode), je n’aurais pas à choisir entre le HTML 5 et le XHTML 2. Il n’y en aura plus qu’un. Et puis le HTML 5 aura aussi sa “version XML“. Donc je pourrais toujours imposer au document d’être totalement propre.

Je pense que cette fin du XHTML 2 est une bonne chose (même si ce n’est pas la fin du XHTML). Pas de casse-tête avec plusieurs standards à suivre, et un renforcement du HTML 5, ce qui va amener les navigateurs à être encore plus plongé dans le HTML 5 et va faciliter cette tâche.

3 commentaires »

Proposition de refonte du site d’American Airlines

19 Jun

Dustin Curtis, un designer d’interfaces, devait réserver un billet sur le site (horrible) d’American Airlines. J’ai déjà eu à le faire aussi lorsque je suis allé à New York. Son expérience en tant qu’utilisateur n’ayant pas été très plaisante, il s’est dit qu’il allait proposer sa propre refonte du site.

american-airlines-refonte

Je suis personnellement très fan de cette refonte du bloc le plus important du site : la réservation. Il y a un côté aéré, léger (pour une compagnie aérienne, que demander de mieux ?) et efficace dans sa refonte. Je me rappelle que je voulais proposer une refonte du site l’Equipe.fr (un tout autre domaine, un tout autre rôle) mais j’ai pas pris le temps de le faire et entre-temps, leur refonte est plutôt réussie.

La réponse d’American Airlines

Ok, Dustin Curtis ne connaissait sans doute pas les raisons qui amènent American Airlines à garder leur site tel quel. Mais il a reçu une réponse de la part du User Experience Architect. Un extrait (repris sur Words on Design – “shameless self promotion…”) :

We could even redesign the AA.com home page without having to slog through endless review and approval cycles with their requisite revisions and re-reviews.

En résumé, dans sa lettre de réponse, il dit qu’American Airlines est une boîte trop grosse avec beaucoup trop de gens impliqués dans le design pour que l’équipe de design puisse faire son boulot correctement, ou devrais-je dire, puisse faire son boulot tout court.

Je sais exactement ce qu’il veut dire.

American Airlines a les compétences en interne pour avoir un site intéressant, mais ne les utilise pas. Un problème politique ? Je pense aussi.

La peur du vide ?

C’est sans doute la crainte des grosses entreprises d’avoir un site aussi aéré et léger, avec peu de contenu. Ils se disent peut-être qu’avec tout leur argent et la taille du trafic du site, ils doivent forcément avoir un site avec beaucoup de fonctionnalités, de contenu, des liens partout, des promos par ci par là…

Je sais pas. Le peur d’innover ? De faire confiance aux plus jeunes ? A ceux qui savent ? A ceux dont c’est le boulot ?

Je pense sincèrement que la qualité d’un design est (quasiment) inversement proportionnelle au nombre de personnes (ignares?) qui donnent leur avis dessus. Avoir une équipe de plusieurs designers, OK. Mais lorsque les services commercial ou technique y mettent leur nez, ça commence à sentir le roussis. Chacun son taf et tout ira bien!

13 commentaires »

Un h1 pour le logo ou pas ?

12 May

A la question “Est-ce que je mets un <h1> pour mon logo ?”, je répondais oui avant. Maintenant, je réponds non.

Le débat

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 :

h1 pour le logo
Etant donné que le logo porte le nom du site, c’est l’élément le plus important. Il doit donc être dans un <h1>, sur toutes les pages.
Exemple : http://wordpress.org/
h1 différent par page, un lien pour le logo
Le h1 doit représenter le contenu de la page. Ce dernier étant différent pour chaque page, il faut que le h1 change aussi.
Exemple : http://simplebits.com/

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.

Le h1, le plus important et l’unique (?)

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.

Paradoxal le h1 ?

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 ?

Title et h1 : amis intimes

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 :

<title>Un h1 pour le logo ou pas ? < Blog < bbxdesign</title>
<h1>Un h1 pour le logo ou pas ?</h1>

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.

Un h1 est-il unique ?

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.

La solution optimale : un h1 différent par page, un lien pour le logo

Si je résume, le h1 :

décrit la section qui le suit
reprend une partie du title, qui lui-même décrit la page
est unique (selon moi)

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 ?

Les titres : une question d’ordre ou de poids ?

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.