Enquête sur l'usage de la clause non commerciale de Creative commons

le 04/12/2008 à 1h09

La fondation Creative Commons lance une grande enquête sur la manière dont est comprise la clause non commerciale de sa licence. Celle-ci s’adresse à l’ensemble de la communauté Creative Commons élargie à tous ceux que la problématique des licences publiques intéresse. L’enquête est parfaitement anonyme, et aucune information permettant de découvrir votre identité de près ou de loin ne sera demandée.

Afin de toucher un maximum de monde, cette enquête est ouverte à tous. Aussi, n’hésitez pas à la relayer autour de vous, plus ils auront de données, et plus les résultats seront fiables. Le questionnaire sera en ligne jusqu’au 7 décembre, donc ne traînez pas.

Article original écrit par Frederic de Villamil et publié sur Ergonomie, Rails et Architecture de l'information web (2.0) | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie, Rails et Architecture de l'information web (2.0), c'est qu'il a été reproduit illégalement et sans autorisation.

Changement de serveur, encore une fois

le 29/11/2008 à 11h35

Je n’ai pas trop eu le temps de communiquer dessus, mais ce site a (encore une fois) déménagé. J’ai quitté mon beau serveur dédié OVH surdimensionné pour une petite Kimsufi, bien suffisante pour mes besoins, surtout depuis que la majorité du trafic vers Typo se fait maintenant vers Github.

Pourquoi avoir changé une fois de plus ?

Avant tout pour des raisons financières. Mon dédié OVH me coûtait 82€ TTC par mois, la Kimsufi ne m’en coute que 37. Or, si vous passez par ici de temps en temps, vous aurez pu constater que les publicités ont disparu. Je ne rentabilise donc même plus mon hébergement, et une économie de 45€ par mois n’est pas à négliger.

Ensuite pour des raisons techniques. J’avais besoin d’une plate-forme en 32 bits, l’allocateur de Ruby Enterprise Edition n’étant pas fait du tout pour le 64 bits, pas plus que ne l’est d’ailleurs Passenger. Il en résultait une consommation de mémoire terrifiante, un CPU à 100% en permanence, et un load de 15 malgré un redémarrage quotidien d’Apache.

Je réfléchis encore à la manière de monétiser ce site. Il ne s’agit pas pour moi de gagner de l’argent avec, mais simplement d’arriver à l’équilibre financier. J’héberge gratuitement pas mal de sites d’amis, ainsi que plusieurs projets open source, et ceci depuis maintenant 6 ans. Ce site est celui attirant le plus fort trafic, il est donc également le plus à même de rentabiliser cette machine sans avoir à demander le moindre centime à mes hébergés. Éventuellement une bière, mais ça n’ira jamais plus loin.

Article original écrit par Frédéric de Villamil et publié sur Ergonomie, Rails et Architecture de l'information web (2.0) | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie, Rails et Architecture de l'information web (2.0), c'est qu'il a été reproduit illégalement et sans autorisation.

Revue de presse du vendredi 28 novembre 2008

le 29/11/2008 à 1h11

Les revues de presse mettent chaque vendredi en lumière les 3 meilleurs articles sur lesquels a porté ma veille quotidienne. Ils peuvent être récents, ou particulièrement vieux, et rentrent dans cette catégorie pour leur qualité ou leur intérêt. N?hésitez-pas à proposer les vôtres.

Alléluia, pour la première fois depuis bien longtemps, la revue de presse arrive à l’heure. C’est une excellente occasion de se réjouir en cette fin de semaine qui devrait marquer un soulagement pour les millions de dindes américaines encore en vie, et la présentation du nouveau Typo à la Rails Party de dimanche soir à laquelle vous êtes évidemment tous invités.

Cette semaine, nous allons parler monétisation, un sujet brûlant alors que de nombreuses startups sont encore à la recherche d’un hypothétique business modèle, de référencement, et plus particulièrement de son intégration au sein de la culture des entreprises web, et enfin, nous verrons quelques astuces afin d’accroître votre productivité sous Textmate, mon éditeur de textes préféré.

7 bons (et 7 mauvais) stratégies de monétisation de Twitter, randfish.

Je connais peu de services qui déchaînent autant les passions que Twitter, entre ses inconditionnels pour lesquels il est quasiment devenu une religion il suffit simplement d’attendre que quelqu’un tue en son nom, et ses détracteurs, dont je fais partie malgré une utilisation intensive, qui lui reprochent son inutilité, sa futilité et son absence de business modèle. En parlant de business modèle, puisque tout ou presque a été dit sur la monétisation de blogs, il était temps de se pencher sur celle de Twitter, histoire de lui donner un semblant de rentabilité. Randfish explore pas moins de 14 manières de le faire, et donne son avis sur l’opportunité de chacun d’entre eux.

Le modèle des tweets publicitaires est déjà utilisé par certains clients Tweeter, comme Twitterific, et il me semble le plus intelligent, couplé à des comptes payants sans publicité. La publicité géo localisée est également très intéressante, surtout pour ceux qui utilisent Twitter pour la discussion et non pour la veille, auquel cas ce modèle n’aurait aucun intérêt.

Ramener le SEO dans la culture d’entreprise, Peter Da Vanzo

Le référencement naturel, est très souvent considéré comme une pratique à part dans le développement de sites web. Les experts sont externalisés, et appelés à la rescousse quand tout va mal, et les bonnes pratiques sont découplées du processus de développement et de mise en place des sites. Les missions d’optimisation du référencement sont relèvent de l’intervention chirurgicale quand elles devraient accompagner tout le cycle de vie d’un site web, de la conception au design en passant par à la rédaction des contenus.

Il est nécessaire, pour cela, de former chaque maillon de la chaîne aux bonnes pratiques du référencement, chacune selon sa spécialité. Poste après poste, Peter Da Vanzo étudie comment faire rentrer le SEO à tous les échelons de la culture de l’entreprise, et passe en revue les différents freins qui pourraient ralentir ce processus.

Astuces pour augmenter votre productivité sous Textmate, Roger Johansson

Textmate est devenu depuis bientôt 3 ans mon principal outil de développement, blogging et j’en oublie, au point de m’avoir fait changer d’architecture et de système d’exploitation. Outre un très grand nombre de bundles particulièrement pratiques pour toutes les choses de la vie, l’ensemble de ses raccourcis clavier ont été particulièrement bien pensés, loin des horreurs que j’ai connues ? avec plaisir pourtant ? sous emacs ou vi.

Roger Johansson a rassemblé pour vous 12 astuces peu ou pas connues destinées à faciliter la vie du développeur en général, et du développeur web en particulier, toutes accessibles via des raccourcis clavier. Un régal et on en redemande.

Article original écrit par Frédéric de Villamil et publié sur Ergonomie, Rails et Architecture de l'information web (2.0) | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie, Rails et Architecture de l'information web (2.0), c'est qu'il a été reproduit illégalement et sans autorisation.

7 éditeurs riches au banc d'essai

le 28/11/2008 à 1h10

Mon article Recherche éditeur HTML désespérément a été visiblement mal compris, sauf peut-être de Xavier Borderie, et notamment la spécification non visuel. À croire que a) mes lecteurs ne savent pas lire, b) mon français n’est plus compréhensible par le génération skyrock, c) mes lecteurs ne lisent que les titres et se foutent du contenu, d) la réponse d.
Quoi qu’il en soit, mon appel au lazyweb n’aura été vain, puisqu’il m’a permis de découvrir un grand nombre d’éditeurs riche qu’il aurait été dommage de ne pas regrouper dans un billet, d’abord pour la ressource, ensuite pour le linkbait. Parce qu’il faut toujours dire ce que l’on pense, surtout si on a la réputation d’être retors.

1. TinyMCE

TinyMCE est probablement le plus ancien et le plus complet des éditeurs riches. Il dispose d’une API de plugins, du support d’AJAX, et il passe parfaitement sous Safari. La dernière version permet de générer du code propre et accessible, ce qui n’est pas gâché.

Meta données :

• Licence : LGPL
• Bibliothèques liées : aucune
• Plus : hyper complet, multilingue
• Moins : usine à gaz

2. FCK Editor

Grand concurrent de TinyMCE, FCK editor est l’autre éditeur de texte riche à utiliser si vous cherchez un substitut web à votre traitement de textes favori. Il embarque une API de plugins, support les skins, l’AJAX, et il pase également très bien sous Safari. Les copier / coller depuis Word sont en revanche hasardeux, à moins de passer par la fonction dédiée qui supprime le formatage.

FCK Editor est l’éditeur riche utilisé dans Typo, car il dispose d’un plugin pour Ruby on Rails particulièrement complet.

Meta données :

• Licence : LGPL
• Bibliothèques liées : aucune
• Plus : support des skins, plugin Rails
• Moins : usine à gaz, markup pas top

3. Mark it up

Mark it up n’est pas un éditeur WYSIWYG, mais il permet d’éditer avec de nombreuses syntaxes : html, bbcodes, markdown, textile, syntaxe wiki… Il se rapproche le plus de ce que je recherchais, mais il repose malheureusement sur la librairie JQuery. Il supporte l’envoi des informations via XMLHttpRequest, les skins, ainsi qu’un système de macros. Et surtout, il est beau.

Meta données :

• Licence : GPL, MIT
• Bibliothèques liées : JQuery 1.2.3
• Plus : léger, multiples syntaxes supportées, support des raccourcis clavier
• Moins : pas de WYSIWYG, pas d’upload d’images, lié à JQuery

4. WYMEditor

WYMEditor ? prononcez Why me est un éditeur de textes riche qui se veut simple, complet, et qui produit du code XHTML valide et sémantiquement correct. Il dispose également d’une API de plugins, et toute la mise en forme passe par des feuilles de style CSS facilement personnalisables.

Très léger, on lui reprochera cependant la limitation des fonctionnalités si on cherche une alternative aux fonctions avancées d’un FCK ou d’un TinyMCE, et surtout, le fait qu’il soit très moche.

Meta données :

• Licence : GPL, MIT
• Bibliothèques liées : aucune
• Plus : léger, XHTML sémantiquement correct, simple
• Moins : pas d’upload d’images, très laid

5. NICEdit

NiceEdit est un éditeur HTML riche simple, léger, et qui produit du code XHTML relativement propre. Il dispose d’une API javascript, AJAX, et est entièrement configurable.

Meta données :

• Licence : MIT
• Bibliothèques liées : aucune
• Plus : léger, XHTML à peu près correct, simple
• Moins : pas d’upload d’images, pas d’internationalisation

6. YUI editor

YUI Editor est l’éditeur riche développé par Yahoo et placé au sein de sa librairie Yahoo! UI Library. Il est léger, très bien pensé et facile à utiliser. La documentation est excellente, et fournit de nombreux exemples de personnalisation et d’extension. Et en plus, il est beau.

Meta données :

• Licence : BSD
• Bibliothèques liées : YUI
• Plus : léger, code propre, simple, beau, extensible
• Moins : pas d’upload d’images (mais un lien vers Flickr)

7. WMD

WMD est un éditeur markdown, une syntaxe de mise en forme simple destinée à être transformée en XHTML sémantiquement correct. Il est léger, très simple d’emploi, et autorise la majorité des tags HTML. Il ne s’agit donc pas d’un éditeur riche au sens WYSIWYG, et il ne permet notamment pas d’agir sur le style des balises.

Meta données :

• Licence : MIT
• Bibliothèques liées : aucune
• Plus : léger, code propre, simple
• Moins : pas d’upload d’images, pas de WYSIWYG, moche

J’ai volontairement passé sous silence les JS Quicktags (en fait ce que je cherchais à l’origine) BB Composer, une extension Firefox qui transforme les textarea en éditeurs riches, car il n’est pas basé sur le web. Si vous en connaissez d’autres, signalez-vous dans les commentaires, je compléterai l’article au fur et à mesure.

Article original écrit par Frédéric de Villamil et publié sur Ergonomie, Rails et Architecture de l'information web (2.0) | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie, Rails et Architecture de l'information web (2.0), c'est qu'il a été reproduit illégalement et sans autorisation.

Les 10 (+ 1) plus grosses erreurs du consultant web

le 26/11/2008 à 1h11

Je discutais l’autre soir avec un ami qui passait brusquement du poste de chef de projets chez un éditeur de logiciels au dur mais passionnant métier de consultant spécialisé dans la refonte de sites et applications web auprès de grands comptes. N’ayant jamais eu à intervenir directement en clientèle, il me faisait part de ses craintes à l’approche de sa première mission, et me demandait mon retour d’expérience sur le sujet.
Je lui ai promis de réfléchir, et afin de lui donner le feedback le plus pertinent possible. Entre temps, Bertrand Duperrin m’a transmit un article plus généraliste sur les erreurs habituelles des consultants, qui contenait quelques pistes supplémentaires et m’a permis d’étayer un peu plus ma réflexion.

1. Prendre la description du problème donnée par votre client pour parole d’Évangile

Vous êtes là afin de résoudre un problème ou un ensemble de problèmes détectés par votre client, lequel n’a pas les ressources, les compétences, le recul ou les trois à la fois pour y arriver correctement. Cela implique que vous deviez dans un premier temps comprendre et circonvenir le ou les problèmes qu’a réellement votre client, dans le périmètre de la mission sur laquelle vous avez été envoyé.

En confrontant l’exposé de votre client à votre analyse de la situation, vous pourrez (éventuellement) :

• Recadrer le scope de la mission afin de répondre vraiment à la problématique du client.
• Éviter une catastrophe en passant à coté des problèmes réels ou en les voyant trop tard.
• Facturer des jours en plus (eh oui, ça arrive).

2. Oublier les objectifs business ou stratégiques de votre client

N’oubliez pas que votre intervention s’inscrit dans le cadre plus large de la stratégie ou du business d’une entreprise. Cela signifie qu’elle peut avoir des impacts collatéraux non négligeables, qui peuvent rendre vos préconisations irrecevables, ou votre travail bloquant. Avec au bout la certitude au choix de l’échec et l’annulation de la mission ou d’une explosion des coûts pour votre client.

3. Ne pas poser les questions qui fâchent

Je ne le répéterai probablement jamais assez, mais vous êtes là pour résoudre des problèmes. Cela signifie que non seulement vous avez le droit de poser des questions gênantes, mais qu’en plus cela fait partie de votre travail, alors profitez-en.

Concentrez-vous principalement sur ce qu’on “oublie” de vous dire, car c’est là que se trouvent les plus gros pièges, et notamment :

• Les faits et causes : pourquoi en est-on arrivé à cette situation. Que s’est-il passé ? Quand ? Quelles mesures ont été prises pour en limiter les effets ?
• Les risques : quels sont les risques micro et macro liés à la situation présente. Quels risques menacent d’apparaître dans le cadre de votre mission ? Et que peut-on faire pour les limiter ou les annuler ?
• Les coûts : quels ont été les coûts engendrés par le problème sur lequel vous intervenez ? Quels sont les coûts et les budgets prévus pour leur solution ? Quel que soit votre niveau d’intervention, il est important que vous connaissiez votre marge de manoeuvre, et les coûts y sont pour une grande part.

4. Ne pas oser dire les choses qui fâchent

Que vous interveniez dans le cadre d’un audit ou pour conduire l’exécution des préconisations d’un audit, vous n’êtes pas là pour faire plaisir à votre client, mais pour l’aider à résoudre ses problèmes. Les choses allant toujours mieux en les disant, dites les, mais en y mettant les formes. Si le prestataire embauché par votre client a fait du travail de cochon, ou pire, n’a pas fait son travail, dites le. Étayez vos conclusions de faits incontestables, et soyez force de proposition pour chaque problème soulevé. Évitez juste de faire virer le beau frère de votre commanditaire, ça pourrait vous attirer des ennuis.

Un des sujets qui fâchent souvent touche à la technologie, et plus particulièrement aux technologies utilisées pour l’existant, ou, plus généralement, dans le système d’information de votre client. L’adoption de telle ou telle technologie dans un système d’informations relève souvent de la guerre de religion. Proposer ou imposer une alternative, parce que l’existant est obsolète, trop gourmand, ou incapable de s’adapter à la situation de votre client risque bien, sans les appuis nécessaires, de mener votre projet au placard d’un simple Désolé, mais nous ne supportons pas cette technologie à ce jour. Nous pouvons étudier la faisabilité de son intégration dans notre système d’informations, mais cela va demander 6 mois d’études préalables pour un coût de 10 millions d’euros. Et l’externalisation n’est malheureusement pas toujours possible.

Il ne faut pourtant pas hésiter à amener le problème sur la table, tout refusant tout jugement partisan quant à la technologie de remplacement.

5. Omettre de poser des questions sur les ressources, les délais, les résultats attendus et les metrics

Qui ? Quoi ? Quand ? Comment ? Et combien ? Je sais bien que rentrer dans le vif du sujet est très tentant, après tout, vous êtes là pour ça. Mais le faire sans connaître la réponse à ces 5 questions est proprement suicidaire.

D’abord parce que vous ne connaissez pas les attentes de votre client, et que sans cela il vous est impossible de le satisfaire, puisque vous ne saurez même pas à quelle aune vos résultats seront jugés.

Ensuite, parce que vous ne pouvez pas commencer à travailler sans définir auparavant votre marge de manoeuvre. Et que vous ne pouvez pas la définir sans avoir au préalable répondu à minima à ces questions

6. Vous jeter sur des solutions micro avant de penser à leur impact macro

C’est très bien d’avoir la solution immédiate à tel ou tel problème qui handicape lourdement votre client, et la tentation est souvent forte de proposer une rustine sans voir la forêt cachée par l’arbre. Chaque fois que vous voyez la réponse à un problème précis et ciblé, étudiez les impacts collatéraux en mode macro. Oui, on peut réduire les dépenses et augmenter les performances en échangeant cette usine à gaz en Sharepoint contre quelque chose de beaucoup plus léger avec SPIP (mouahahahaha pardon aux familles, tout ça), pas de bol, on perd les connecteurs Exchange indispensables pour récupérer les informations sur les calendriers partagés des employés de la société.

7. Ne pas demander (ou l’admettre) quand vous ne savez pas

Quand il vous manque un élément, demandez le, mais ne restez surtout pas dans l’ignorance, au risque de passer pour un imbécile le moment venu. Et si vous ne savez pas quelque chose, dites le, personne ne vous reprochera de ne pas avoir la science infuse.

Lors de l’épluchage des conclusions du dernier audit sur lequel j’ai eu le plaisir d’intervenir, j’avais certaines questions particulièrement pressantes de mon client, qui voulait du concret, immédiatement sur des points qui demandaient réflexion. Ce genre de pression est particulièrement désagréable, car une absence de réponse de votre part peut être vue comme du travail bâclé ou pas assez approfondi.

8. Trop la ramener

Soyez HUMBLE. Vous avez peut-être codé l’intranet du Pentagone sous Vi en une nuit, ou fait Normal Sup et l’ENA façon marionnette d’Alain Jupée dans les Guignols, ce n’est pas la peine de la ramener. Si vous le faites, votre client sera systématiquement déçu par votre travail, aussi bon soit-il car il aura l’impression que vous pouvez faire mieux. Il vous faut au contraire sous promettre pour sur délivrer.

9. Accepter des délais impossibles

Ça me semble évident, mais ça vaut, à mon avis, la peine d’être redit. Rome ne s’est pas fait en un jour, et votre client doit comprendre que ses problématiques stratégiques ne vont pas se résoudre d’un claquement de doigts, même s’il faut également être capable de travailler dans l’urgence, et sous pressions.

Il m’est arrivé à plusieurs reprises de refuser des missions dont les délais me semblaient trop courts pour faire un travail correct. Les effets de bord sont trop importants pour être négligés :

• Contractuellement, un retard même d’une journée peut vous être particulièrement préjudiciable.
• On ne fait rien de bien dans la précipitation, et votre client ne sera pas satisfait.
• Vous allez détester cette mission qui s’annonçait pourtant super intéressante, ce serait dommage non ?

10. Évangéliser vos clients à l’accessibilité, aux standards du web, aux Microformats…

Je déteste ce paragraphe, il est pourtant important, bien qu’il ne s’applique pas à 100% des cas.

À moins que cela fasse partie de votre feuille de route, votre mission n’est pas d’évangéliser vos clients à l’accessibilité, aux standards du web, aux Microformats et j’en oublie. Même si c’est tentant, même si c’est important, même si c’est quelque chose que vous avez à coeur. Parce que ce n’est pas ce que l’on vous demande.

Cela ne veut pas dire que vous ne devez pas en mettre, mais que, tout comme le validateur W3C, ce n’est pas une fin en soi.

Que vous préconisiez un abandon de la solution full flash car cela va permettre de toucher 10% de public en plus, OK. Que vous recommandiez l’abandon du développement en tableaux et du mélange structure / présentation pour des raisons évidentes de maintenabilité, OK. Que vous préconisiez la mise en place de HTML sémantique tout beau tout propre afin d’optimiser le site de votre client pour les moteurs de recherche, et ainsi accroître son trafic, et donc ses revenus, OK. Mais surtout, si vous voulez être pris au sérieux, ne recommandez les bonnes pratiques que lorsqu’elle vont dans le sens des impératifs business et stratégiques de votre client.

Dans le cas contraire, vous risquez de tomber sur deux types d’interlocuteurs :

• Celui qui est déjà sensibilisé à ces problématiques, pour qui cela va de soi, et pour qui vous passez à coté de choses importantes.
• Celui qui, pour une raison ou pour une autre n’en a rien à faire (ce n’est pas son travail, il fait du marketing, pas de la technique…), et vous prendra pour un gentil illuminé, donc pas crédible.

11. Oublier que dans une entreprise, tout ou presque est politique

Celui là, c’est mon bonus à moi en forme de conclusion. L’entreprise, le service dans lequel vous intervenez existaient avant votre arrivée, et existeront certainement après votre départ. Et dans cet univers, tout est politique, et vous n’avez absolument pas la moindre idée de ce à quoi vous allez vous heurter, généralement avant de vous prendre le mur, entre ceux qui refusent d’investir un centime de budget sous prétexte que le projet va profiter au service comptable qui, lui, n’a pas mis un sous, ou ceux qui veulent devenir calife à la place du calife, et qui ne veulent surtout pas que le meneur de ce projet stratégique leur passe devant. Voire, tout simplement, les jalousies personnelles et histoires de cul dont on ne vous parlera pas.

Mais surtout, que cela ne vous décourage pas !

Article original écrit par Frédéric de Villamil et publié sur Ergonomie, Rails et Architecture de l'information web (2.0) | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie, Rails et Architecture de l'information web (2.0), c'est qu'il a été reproduit illégalement et sans autorisation.

Recherche éditeur HTML désespérément

le 25/11/2008 à 9h51

Cher lazyweb, tu me trouves aujourd’hui dans une situation grave, si ce n’est désespérée. Je suis à la recherche d’un éditeur HTML simple, non visuel, comme celui que l’on trouve par exemple sur Wordpress. Je le voudrais très léger, facilement extensible, et si possible bien documenté.

Évidemment, les choses seraient plus simple s’il n’y avait pas un piège dans ma demande. Il faut impérativement que cet éditeur soit placé sous licence BSD ou MIT, mais SURTOUT pas sous (cette saloperie virale de) GPL.

Voilà, si vous avez des idées, je suis preneur, sinon, je sens que je vais être obligé de le coder moi-même, et cette idée ne m’enchante pas vraiment.

Article original écrit par Frédéric de Villamil et publié sur Ergonomie, Rails et Architecture de l'information web (2.0) | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie, Rails et Architecture de l'information web (2.0), c'est qu'il a été reproduit illégalement et sans autorisation.

Créez des thèmes pour Typo partie 1 sur 3 : les thèmes standards

le 24/11/2008 à 1h11

Typo, le principal outil de publication en Ruby on Rails dispose d’un système de template poussé extrêmement souple, et probablement un des plus avancés qui soit. Il permet de créer aussi bien des thèmes rapides utilisant le balisage par défaut de l’application que des thèmes extrêmement complexes totalement personnalisés.
La majorité des thèmes disponibles sur Typogarden ayant été développés après l’introduction de ce second mode, ses possibilités ? et sa simplicité ? sont assez peu connues, laissant penser, à tort, que Typo ne dispose pas d’un système de templates avancé.

Vite fait, bien fait, la méthode pour les feignants

Un template Typo se compose à minima de trois fichiers :

• Un squelette, appelé layout.
• Une feuille de style CSS.
• Un fichier à propos au format markdown.
• Éventuellement des images, et une capture d’écran.

L’arborescence minimum est donc :

Le principal fichier est le fichier default.html.erb, qui va servir de squelette à votre thème. Il s’agit d’un simple fichier en HTML dans lequel nous allons placer quelques directives Ruby permettant d’afficher les informations venues de l’application.

En-tête du fichier

L’en-tête du fichier va contenir les informations standards pour un document HTML.

Les directives importantes sont :

• h(page_title), qui va contenir le titre du document en cours. Ce titre est généré automatiquement par Typo, et la traduction est assurée dans les langues supportées.
• stylesheet_link_tag contiendra le nom de votre feuille de style, amputé (ou non) du suffixe .css.
• page_header va afficher l’en-tête de page généré par Typo. Il contient les informations et directives suivantes :
  • Le tag ICBM pour la localisation géographique de votre blog Typo.
  • Le champ meta description du document.
  • Le champ meta keyword du document.
  • Le champ RSD du site.
  • Les URL des flux RSS et Atom pour le document en cours, pour la découverte automatique.
  • Les feuilles de style utilisées par les plugins inclus dans Typo.
  • Les fichiers Javascript nécessaires à votre blog Typo.
  • L’appel à Google Analytics si vous avec renseigné ce champ dans l’administration.

Corps du fichier

Toutes les div incluses dans le corps de ce fichier ne sont pas indispensables, seuls les appels aux méthodes Ruby ont leur importance.

Ici, les directives importantes sont :

• this_blog.base_url : l’URL de votre site, renseignée dans les settings.
• this_blog.name : le titre du site, indiqué dans la configuration.
• this_blog.blog_subtitle : la tagline de votre site, renseignée dans les settings.
• content_for_layout est l’appel le plus important, puisque c’est lui qui va afficher le contenu de la page en fonction du contrôleur invoqué : liste de billets, liste de tags, billet seul…
• render_sidebars permet d’afficher le contenu des plugins que vous aurez auparavant choisis dans l’administration.

Et voilà, vous savez faire un thème Typo standard. Dans la seconde partie de cet article vous apprendrez comment faire un thème avancé en utilisant toutes les ressources offertes par Typo.

Article original écrit par Frédéric de Villamil et publié sur Ergonomie, Rails et Architecture de l'information web (2.0) | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie, Rails et Architecture de l'information web (2.0), c'est qu'il a été reproduit illégalement et sans autorisation.

Fuzz 1, Olivier Martinez 0 / Blogosphère 0, Monde réel 1

le 23/11/2008 à 1h11

Éric Dupin a donc gagné en appel dans le procès qui opposait Fuzz, son Digg like à l’acteur Olivier Martinez. Je suis très satisfait de la manière dont cette affaire s’est déroulée, et ceci pour deux raisons.

N’allez surtout pas croire que j’en ai quoi que ce soit à foutre de Fuzz, je m’en tamponne au contraire le coquillart avec un tibia de langouste, comme avait coutume de dire feu mon père. La valeur de l’information qu’on y trouve est à peu près nulle. Les utilisateurs relaient tous les mêmes dépêches ad nauseam dans un français souvent douteux, à croire qu’il ne se passe pas grand chose sur terre. L’ayant utilisé quelques fois à l’époque où je cherchais des concentrés d’informations relativement intéressants, j’y ai trouvé le rapport signal / bruit plus faible qu’une louve qui aurait mis bas 12 petits. Je me suis depuis rabattu sur les flux Diigo de 2 ou 3 personnes dont l’exigence en matière de qualité de l’information ne fait aucun doute. Il faut bien que je profite moi de la mode de l’UGC n’est-ce pas ?
Là où la non défaite de Fuzz me rassure, avec simple une application de la si décriée Loi de Confiance dans l’Économie Numérique ? laquelle donne pourtant un sérieux coup de pouce à Éric ? si j’en crois ce que j’ai lu ici et là, c’est que cette affaire était sur le point de créer un fâcheux précédent dans un web français qui n’a déjà pas vraiment de raisons de faire le fier. Il n’est pas dit que d’autres affaires du genre n’éclatent pas, avec des résultats tout à fait différents, mais, depuis l’affaire Estelle Halliday contre Altern.org, je soupire de soulagement chaque fois qu’un tel cas veut bien se produire. Voilà pour la première raison.

La seconde raison de ma satisfaction tient au déroulement en deux temps de cette affaire, et plus particulièrement à sa première partie. Ceux qui s’intéressaient de près ou de loin à cette affaire se souviendront très probablement de sa conclusion, la défaite d’Éric Dupin malgré la très forte mobilisation de la blogosphère. Cette défaite de la vox populi à qui l’on a fait miroiter qu’elle était un énième pouvoir ? n tendant à mon humble avis plus vers 0 que vers l’infini ? lui peut être fait retrouver, pour un instant, le sens des réalités. Sa soi disant influence ne tient finalement qu’à sa capacité à relayer sans cesses la même information, au grand bonheur d’équipes marketing qui n’y voient qu’un excellent moyen de relayer un produit ou un slogan à fort peu de frais, et c’est la raison qui me pousse à vous resservir la si cynique Annabelle, 26 ans, blogueuse influente.

J’aurais aimé que la si bien nommée blogosphère se réveille et comprenne qu’elle n’a finalement que l’influence qu’on veut bien lui accorder, et qu’elle se rappelle surtout que, quelle que soit la taille de la sphère, on finit toujours par y tourner en rond. Au point d’ailleurs que les blogueurs belges n’en aient toujours pas trouvé le coin dans lequel on leur a promis qu’ils trouveraient un plat de frites.

Article original écrit par Frédéric de Villamil et publié sur Ergonomie, Rails et Architecture de l'information web (2.0) | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie, Rails et Architecture de l'information web (2.0), c'est qu'il a été reproduit illégalement et sans autorisation.

Revue de presse du vendredi 21 novembre 2008

le 22/11/2008 à 1h12

Les revues de presse mettent chaque vendredi en lumière les 3 meilleurs articles sur lesquels a porté ma veille quotidienne. Ils peuvent être récents, ou particulièrement vieux, et rentrent dans cette catégorie pour leur qualité ou leur intérêt. N?hésitez-pas à proposer les vôtres.

Après 15 jours d’absence pour cause de travail intensif, week-end trop chargé et de calendrier à faire pâlir un ministre sarkozien made in France qui se lève tôt, la revue de presse est enfin de retour. Au programme cette semaine nous verrons quelques conseils pour écrire sur le web sans perdre ses lecteurs ; nous continuerons avec quelques conseils à un ami qui voudrait se mettre à l’entreprise 2.0, avant de voir comment concevoir des sites permettant aux dyslexiques d’avoir more fnu.

Exposez votre point de vue sans égarer vos lecteurs, Dina Giolitto

Se faire comprendre de ses interlocuteurs, tous ses interlocuteurs, nonobstant leur niveau de connaissance n’est pas toujours facile en soi. Cela devient même une véritable gageure quand on s’attaque à la vulgarisation de données très pointus ou à des domaines relativement spécifiques. Dina Giolitto à qui l’on doit déjà d’autres articles cités dans cette revue de presse s’attaque au problème, et a réuni quelques bonnes pratiques à mettre en oeuvre dans le but de mieux faire passer le message en facilitant la compréhension du lectorat :

1. Soyez clair.
2. Évitez le vocabulaire technique.
3. Allez droit au but.
4. Ne vous égarez pas et restez pertinent.
5. Ciblez vos destinataires.
6. Faites que l’on retienne ce que vous venez de dire.

Ce que j’aime bien avec Dina, c’est qu’elle va à l’essentiel, et met généralement ses conseils en application dans ses billets. Elle n’hésite pas à aborder l’écriture sur le web sur un mode micro et macro à la fois, et c’est ce qu’elle fait encore une fois dans cet article.

11 conseils à un ami qui voudrait se mettre à l’entreprise 2.0, Bertrand Duperrin

Bien que j’entende déjà déjà des gens s’écrier bingo ! dans la salle au simple terme d’entreprise 2.0, j’ai tout de même à coeur d’expliquer ce que c’est. Bertrand me corrigera si besoin. L’entreprise 2.0 est la mutation des méthodes de management, d’une gestion verticale dans laquelle tout vient d’en haut ? top down management ? vers un mode de gestion dans lequel l’initiative vient également de la base ? on parle alors de bottom up ? articulée autour de la mise en place d’outils collaboratifs. Il s’agit donc moins de l’introduction du web social dans l’entreprise que d’un changement de nos manières de travailler.

Bertrand réunit dans ce billet 11 conseils “à un ami” qui voudrait lancer le processus de transition vers le management 2.0, afin d’éviter les écueils des chimères d’un buzzword déjà galvaudé.

1. Pense entreprise au lieu de penser 2.0 et surtout ne te trompe pas de projet.
   Autrement dit, get real or go home
2. Déresponsabilise tes équipes.
3. Ne rend pas tes collaborateurs schizophrènes.
4. Apprenez le solfège avant de faire un b?uf.
5. Cherche la valeur dans le travail et pas ailleurs.
   Travailler plus pour plus de ROI ?
6. Affiche les gains, même les plus petits en permanence.
7. Soit clair et terre à terre.
   Au risque de me répéter, get real or go home.
8. Ne te prend pas pour le chef.
9. Cherche à travailler horizontalement plutôt que verticalement.
10. Laisse quand même une petite chance au hasard.
11. IRL avant tout !
    Get real or go home, t’as pas encore compris ?

Design de sites web pour les dyslexiques, Mel Pedley

Si les mal et non voyants font souvent bonne presse dans les articles sur l’accessibilité ? et pour cause, le matériel qu’ils utilisent et les solutions pour leur rendre les sites accessibles sont les plus voyants ? on oublie un peu trop souvent les handicaps cognitifs au sein desquels la dyslexie tient une place non négligeable.

Dans une série de trois articles un peu anciens et pourtant toujours d’actualité, Mel Pedley nous dévoile tout ce dont nous avons besoin de savoir afin de concevoir et développer des sites accessibles aux dyslexiques. Le premier volet traite de la dyslexie en elle même : qui, quoi et combien. Le second aborde les problématiques de background et de contraste entre fond et police, lesquels ne s’appliquent visiblement pas uniquement aux déficients visuels. Enfin, le troisième adresse plus précisément les problématiques de la mise en forme de l’écriture sur le web : polices, hauteur de ligne, utilisation des fonts… sont passés au crible de l’expérience de l’auteur.

Avec environ 10% de la population atteinte par la dyslexie de manière plus ou moins grave, la dyslexie représente une part importante des visiteurs d’un site web. Si pour une fois, les amélioration apportées en termes d’accessibilité n’apportent pas grand chose au niveau du référencement naturel, et pour cause, elles peuvent en revanche apporter un sérieux plus au niveau du taux de transformation, et ce seul élément ne doit pas être négligé.

Et voilà, c’est tout pour ce soir, pour une fois que je rends cette revue de presse dans les temps, je vais m’autoriser une bonne nuit de sommeil.

Article original écrit par Frédéric de Villamil et publié sur Ergonomie, Rails et Architecture de l'information web (2.0) | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie, Rails et Architecture de l'information web (2.0), c'est qu'il a été reproduit illégalement et sans autorisation.

Wordpress, code et poésie

le 22/11/2008 à 1h12

Entendu sur le Twitter d’Eric Meyer

If code is poetry, then blogging software must be written by Vogons.

Selon Wikipedia, les Vogons…

sont des créatures stupides et sans c?ur qui ne vivent que pour l’administration. Ils sont notamment responsables de la destruction de la Terre. Ils écrivent des poèmes qui sont classés comme la troisième exécrabilité dans tout l’univers selon le Guide du voyageur galactique ! En effet, il est dit que la dernière représentation d’un poème Vogon en public engendra trois hémorragies internes dans le public, et le président du comité n’avait alors réussi à survivre qu’en mangeant sa propre jambe. Le poème qui devait suivre n’eut pas lieu car l’intestin du Vogon poète avait décidé d’étrangler son hôte dans un geste de générosité.

Quand on voit certaines parties du code de Wordpress, on se dit que l’analogie n’est pas totalement fausse.

Article original écrit par Frédéric de Villamil et publié sur Ergonomie, Rails et Architecture de l'information web (2.0) | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie, Rails et Architecture de l'information web (2.0), c'est qu'il a été reproduit illégalement et sans autorisation.

Mes conventions de développement en XHTML et CSS

le 21/11/2008 à 1h12

Même si certains motifs se détachent parfois du lot, les conventions de développement ou d’intégration restent quelque chose de très personnel. La majorité des langages, et même des framework ont des méthodes gravées dans la pierre que chacun est fortement invité à respecter. Ce n’est pourtant pas le cas pour le couple HTML/CSS, et c’est la raison pour laquelle Florent Verschelde et l’équipe d’Alsacréations ont entrepris de mettre en place un guide stylistique de l’intégration HTML. Ils ont pour cela proposé un appel à contribution sous la forme d’un questionnaire en deux parties auquel je réponds à mon tour.

Questions relatives à HTML

1. Quelle versions de HTML ou XHTML utilisez-vous? Quelle version priviligiez-vous?

J’utilise quasiment exclusivement XHTML 1.0 stricte sur mes nouveaux projets. Quand je reprends un existant, ou que je dois utiliser des balises supprimées en XHTML 1.0 stricte, je me cantonne au transitionnel.

2. Respectez-vous des règles strictes pour l?écriture des balises et attributs HTML même en HTML 4.01 (balises systématiquement en majuscules ou systématiquement en minuscules, pas de guillemets ou single quotes ou double quotes pour tous les attributs, etc.)?

J’utilise des conventions assez strictes : balises et attributs en lowercase. J’utilise des guillemets pour les chaînes de caractères (attribut alt ou title par exemple) et des single quotes pour les noms de classes, d’ID, ou pour les URL dans les liens et les images.

3. Quel usage faites-vous de la validation du code HTML?

J’utilise le validateur à la fin du montage d’une page, par acquit de conscience, mais de toutes manières, mon markup est toujours naturellement impeccable ;-).

Je considère la validation comme un indicateur de qualité parmi d’autres, pas comme une fin en soi. Je peux avoir une mise en page en tableaux ou une soupe de balises imbitable parfaitement valides, mais totalement inaccessibles ou pas sémantique du tout.

4. Quel usage faites vous des commentaires HTML?

J’en utilise le moins possible. Comme avait coutume de le dire mon prof de TDD, un bon code n’a pas besoin de commentaires (et les tests sont le meilleur moyen d’expliquer le code). En fait, je ne les utilise que pour marquer la fermeture des blocs principaux, et encore je préfère compter sur l’indentation et les fonctionnalités de dissimulation des blocs de mon éditeur favori pour obtenir cette information.

5. Quels sont les éléments HTML que vous utilisez le plus? Y a-t-il une logique précise pour l’utilisation de tel ou tel élément (un P plutôt qu?un DIV, par exemple)?

J’essaie d’utiliser un maximum d’éléments en fonction de leur valeur sémantique. J’abuse clairement des listes non ordonnées ou du triplet dl, dt, dd dans mes menus quand le cas se présente. Il y a en revanche certaines balises que j’évite au maximum, comme frame ou iframe par exemple.

J’utilise div pour marquer les grands blocs de la structure de mon site, et le p afin de placer du texte qui n’a pas sa place dans une balise de titre, un address…

5. Quel usage faites-vous des éléments génériques DIV et SPAN?

Pour l’usage que j’ai de la div, cf. paragraphe précédent. J’utilise le span de deux manières différentes :

• Soit quand je veux appliquer un display: block; (généralement avec un float) dans un élément inline contenu dans un bloc sans casser la logique du flux d’informations. Un bon exemple est celui des boites à bords arrondis extensibles décrites par Dan Cederholm dans son livre Bulletproof Webdesign
• Soit quand je veux appliquer du style a un élément significatif au sein d’un bloc textuel (titre, paragraphe).

6. Avez-vous une convention de nommage pour les classes et identifiants (ou une convention différente pour chaque)? Choix des mots, minuscules, majuscules alternées, tirets, traits de soulignement, etc.

A la première question, je répondrai oui sans hésiter, et je répondrai même oui, sans les avoir consultés, pour mes coreligionnaires en subversions radiophoniques, Luis Rego et Claude Villers.

Pour les id, j’utilise bêtement les noms qui me semblent les plus appropriés en fonction de leur utilisation dans la page : search, wrapper, page, sidebar, menu… Pour les classes, je les désigne par ce qu’elles font : align-left, align-right… ou aux éléments auxquels elles s’appliquent : submit, cancel…

Dans tous les cas, j’utilise de l’anglais en minuscules, et je sépare les mots par un “-“.

7. Dans quels cas utilisez vous plutôt les classes ou plutôt les identifiants?

J’utilise les identifiants quand le style s’applique à l’ensemble du contenu HTML inclus dans l’élément nommé, et les classes quand je dois appliquer un même style à un même élément réparti un peu partout dans la page.

Questions relatives à CSS

1. Quel usage faites-vous de la validation CSS ?

Je ne l’utilise pas. Peut-être à tort, mais j’ai suffisamment confiance dans mon code pour m’en passer.

2. Comment utilisez-vous les commentaires en CSS? Avez-vous des «styles» précis pour différents types de commentaires (capitales, étoiles ou autres symboles dans le commentaire, etc.) ?

Je les utilise afin de séparer les principaux blocs du site, mais globalement assez peu. Je viens en revanche de découvrir le modus operandi d’Hélène dans le thème qu’elle avait fait pour Typo, et je pense que je vais l’utiliser sur les grosses feuilles de style :

• Une table des matières en tête de feuille.
• Un commentaire pour chaque titre de partie ou de sous partie

3. Utilisez-vous des sélecteurs « verbeux » (le plus précis possibles et reprenant le contexte d?utilisation de l?élément), ou au contraire les plus courts possibles? Ou bien une solution intermédiaire ?

Je ne fais pas tellement attention à la verbosité de mes sélecteurs, mais plus au sens qu’ils ont et à leur clarté, histoire que le code reste bien lisible et compréhensible.

4. Comment utilisez-vous les espaces, retours à la ligne, lignes vides et indentations? Pouvez-vous fournir un exemple-type ?

Je saute une ligne entre chaque classe ou identifiant, et deux lignes entre la dernière classe d’une partie et la partie suivante. Et sinon j’indente à 2 avec des espaces et non des tabulations. Je mets toujours un espace entre les deux points et l’attribut.

5. Regroupez-vous les blocs de déclarations (sélecteurs + leurs propriétés) de manière logique ou prévisible? Quelle est la logique utilisée, et dans quel ordre les placez-vous?

Je suis structure du document HTML autant que faire se peut.

6. Utilisez-vous des indentations multiples (jusqu?à plusieurs niveaux d?indentation) pour, par exemple, refléter la structure du code HTML ?

Non.

7. Utilisez-vous les propriétés de raccourci ? Si oui, les utilisez-vous systématiquement et en priorité, ou seulement lorsque cela permet de gagner quelques déclarations (propriété + valeur) ?

J’utilise un maximum de raccourcis, dès lors que cela reste compréhensible, notamment pour les propriétés background, border, font, margin et padding.

8. Respectez-vous un ordre précis pour les propriétés CSS (ordre alphabétique, ordre «logique», etc.) ? Si besoin, pouvez-vous le détailler ?

Pas consciemment en tout cas, mais je viens d’aller jeter un oeil, et en fait, je mets visiblement toujours les propriétés CSS dans le même ordre :

• Font
• Structure
• Couleurs

9. Dans une feuille de styles relativement longue (plus de quelques dizaines de ligne, et jusqu?à des centaines ou milliers de lignes), comment organisez-vous les différents styles ?

Je sépare en plusieurs feuilles, que je concatène ensuite selon les besoins afin d’économiser des téléchargements :

• Structure générale, commune à toutes les pages.
• Fonts et couleurs générales communes à toutes les pages.
• Structure spécifiques aux pages ou aux “univers”.
• Fonts et couleurs spécifiques aux pages ou aux “univers”.

10. Utilisez-vous plusieurs feuilles de styles pour un projet de «petit» site (moins de dix pages-type). Utilisez-vous plusieurs feuilles de styles pour des projets plus conséquents? Comment séparez-vous les différents styles: par type de propriétés CSS, par type de page, etc. ?

Cf. paragraphe précédent.

11. Utilisez-vous des hacks CSS ?

Le moins possible, je préfère à la limite passer par les commentaires conditionnels quand je n’ai vraiment pas le choix.

12. Utilisez-vous les commentaires conditionnels pour Internet Explorer? Si oui, comment procédez-vous?

J’inclus des fichiers spécifiques à IE6 ou IE7 en fonction des besoins, mais dans la mesure du possible, j’essaie de contourner. Ne faisant pas d’intégration en agence, ou en freelance, à titre professionnel, je suis assez peu lié par les sociétés de design qui vendent le reflet exact d’un site, en oubliant parfois les réalités du web. Je me permets au contraire un peu de dégradation si ça m’évite de commettre des horreurs.

Article original écrit par Frédéric de Villamil et publié sur Ergonomie, Rails et Architecture de l'information web (2.0) | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie, Rails et Architecture de l'information web (2.0), c'est qu'il a été reproduit illégalement et sans autorisation.

En e-commerce comme dans la vie, la première impression est souvent la bonne

le 20/11/2008 à 1h12

Vous avez lu et appliqué à la lettre le e-commerce pour les nuls, et vous vous préparez à dévoiler votre bébé à la face du monde. Tout est prêt et rien n’a été laissé au hasard. La charte graphique révèle parfaitement l’esprit de votre plate-forme, joyeux bazar pour le hard discount ou chic et exubérance classique pour une marque de luxe. Le parcours utilisateur a été calculé au clic près et tous les chemins mènent à la transformation. Les éléments de cross selling sont parfaitement placés, à droite de l’écran, à portée du pointeur de souris, et mis en avant de telle sorte que le client potentiel ne puisse rien faire d’autre que cliquer. Les photos sont alléchantes tout en étant précises, et les mises en scène parfaitement adaptées. Bref, vous tenez là le site de e-commerce idéal, mélange parfait entre la cash machine et l’émanation exacte de l’image de votre marque.

Mais avez-vous pensé à ce que vos visiteurs allaient ressentir en arrivant chez vous ?

Ceux qui me connaissent le savent bien, je suis un inconditionnel des pulls marins officier de la marque Saint James (prononcer Saint Jâme à la française et non Saint James à moins de vouloir passer pour un plouc auprès des connaisseurs) au point de ne porter que cela. Ils ne sont certes pas vraiment donnés ? même s’il existe beaucoup plus cher ? mais ils sont beaux, très chauds, d’excellente facture et chacun d’entre eux me dure entre 6 et 8 ans.

Étant sérieusement en rade de pull, je suis passé l’autre jour à la boutique située pas très loin de la place de la Madeleine, à Paris en sachant très bien quel article je voulais, et combien j’allais en prendre. Quand je suis entré dans le magasin, j’ai senti une chape de mépris assez extraordinaire s’abattre sur moi comme la chaudepisse sur le pauvre peuple. Il faut dire que je ne paye pas de mine, généralement pas rasé, l’air hagard du type qui ne dort pas assez et qui passe le plus clair de son temps à habiller ses enfants le matin au lieu de se préparer pour un rendez-vous mondain. Ça n’a pas fait un pli, je suis parti en moins de 15 secondes en jetant à peine un oeil à la marchandise proposée. Vu la morosité ambiante, c’est un peu dommage de perdre une vente sûre comme ça.

Ce genre d’expérience m’arrive également parfois sur le web, quand je me rends sur certains sites de vente en ligne, et curieusement pas sur ceux dont on pourrait attendre une quelconque hauteur vis à vis de leurs clients. Le site d’Hermes, entre autres, est un modèle de clarté, de calme et de tranquillité ? tout en étant une horreur à bien des points de vue, mais cela n’est pas mon propos du soir.

Depuis la révolution Amazon, les sites de e-commerce ont fait pas mal de progrès question utilisabilité, parcours utilisateur, et expérience d’achat. C’était indispensable car, contrairement à l’achat en boutique, le visiteur n’a pas la possibilité de flâner dans les rayons, et de toucher directement les articles en vente. Le processus devait donc être optimisé afin de l’aider à trouver ce qu’il cherche, avant de le pousser à acheter. De gros progrès restent pourtant à faire dans l’impression générale ressentie par l’utilisateur, sous peine de les voir fermer leur navigateur pour une bête question de feeling qui ne passe pas.

Article original écrit par Frédéric de Villamil et publié sur Ergonomie, Rails et Architecture de l'information web (2.0) | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie, Rails et Architecture de l'information web (2.0), c'est qu'il a été reproduit illégalement et sans autorisation.