Pas de budget ? Pas de site !

le 18/03/2010 à 11h50

Qui d’entre-nous n’a jamais entendu un prospect ? qui, généralement, avait initié le contact ? répondre à la fatidique question du budget prévu pour une prestation :

Je ne souhaite pas vous donner de budget afin de ne pas vous influencer.

Ou encore :

Je ne peux pas vous donner de budget car je vous ai mis en compétition avec une autre société, et je choisirai en fonction du prix.

Je ne remettrai pas en cause le fait de mettre ? ou non ? des agences en compétition sur un projet, même s’il me semble que le choix devrait se faire sur la stratégie proposée plus que sur les tarifs. Jouer à tirer les prix vers le bas se fait toujours au détriment de la qualité, quoique puisse vous en dire certaines agences low costs ou autres adeptes du petit neveu de 15 ans qui fait des sites Internet. Mais sans un budget en face, il est difficile, voire impossible d’élaborer une offre satisfaisant vraiment les besoins du client, qui est finalement le grand perdant de l’histoire. C’est un débat sans fin presque aussi vieux que la première bulle Internet qu’il serait stupide et vain de relancer une énième fois.

Une de mes amies, qui tient une petite agence Web me confiait récemment qu’à un client qui avait refusé de lui donner un budget, elle avait répondu :

D’accord, je vous fais votre site pour 200.000 euros, signez ici. Mais je ne vous dis pas ce que vous aurez pour ce prix là.

L’histoire ne dit pas si elle a eu le contrat.

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

Une bonne expérience client est indispensable à une bonne expérience utilisateur globale

le 13/03/2010 à 13h06

Si vous croyez que l’expérience utilisateur se limite à votre seul produit, vous êtes complètement à côté de la plaque. Une bonne expérience utilisateur commence le jour où vous entrez dans un magasin pour acheter un produit et se termine le jour où vous vous en débarrassez, voire après. C’est la raison pour laquelle il est indispensable de faire entrer l’expérience client dans votre expérience produit.

J’en discutais lundi soir autour d’un verre avec un vieil ami qui me parlait de son projet de délégation du support client auprès d’une entreprise spécialisée à la fois pour faire industrialiser son processus par d’autres et pour des raisons financières. Si ça démarche semble compréhensible, elle laisse de côté l’expérience client.

D’après vous, qu’est-ce qui satisfera le plus votre client ? Un anonyme qui lui posera mécaniquement une série de questions pré établies en fonction d’un plan écrit à l’avance, ou une personne au fait de son produit et capable d’établir un dialogue avec eux ? Quand le prix n’est pas votre principal argument de vente, la fidélisation passe avant tout par la relation établie avec le client. Tout comme Nul ne peut servir deux maîtres car, ou il haïra l’un et aimera l’autre, ou il s’attachera à l’un et méprisera l’autre (Mt 6, 24), il est impossible d’avoir un véritable sens du client si l’on n’a pas avant tout le sens du produit et de la marque, et vice versa diront certains.

Quand vous entrez dans un Apple Store, vous pouvez librement utiliser à tous les produits de la gamme afin de vous faire une idée avant d’acheter. Les vendeurs connaissent parfaitement leurs produits et véhiculent leur passion de la marque dans leur manière de vous conseiller quand d’autres magasins cherchent simplement à alourdir la facture. Il n’y a pas de rupture entre l’expérience client et l’expérience produit.

Le distributeur d’électroménager Darty a, sur le papier, un très grand sens du client que la marque a su mettre en avant année après année avec le premier vrai service après-vente industriel. Le service livraison arrive le jour dit à l’heure prévue, installe les nouveaux appareils, emporte les anciens, et les techniciens sont toujours prodigues en conseils de mise en route ou d’utilisation, y compris sur des produits que vous n’avez pas acheté chez eux. L’expérience en magasin est, en revanche, catastrophique, et j’en ai fait une bonne dizaine… Personnel peu ou pas aimable, aucune connaissance des produits vendus, et conseil visiblement plus motivé par la commission que par la recherche de la satisfaction client. Il y a six ans, ils m’ont même vendu un aspirateur “spécial parquet” pour un appartement entièrement recouvert de moquette ; et je me demandais pourquoi il n’aspirait rien. L’expérience client, pourtant au coeur de l’image de la marque est ici gâchée avant même d’avoir commencé.

C’est d’ailleurs une des problématiques à laquelle doit répondre une société cherchant à donner une expérience utilisateur globale. Chacun de ses employés est devenu de facto un porte-parole de la marque auprès des clients. Le marketing de votre société passe par la manière dont vos employés répondent au téléphone, parlent de vous et de vos produits, et se comportent face à tous ceux auxquels ils s’adressent dans et en dehors de l’exercice de leurs fonctions.

Évidemment, encore faut-il en comprendre l’importance, et cela passe par deux choses indissociables. La première, est de cesser de se reposer sur la seule communication institutionnelle comme vecteur de l’image de l’entreprise. La seconde est d’inculquer à tous ses employés sans exception, l’amour du client, qu’ils soient ou non en relation avec lui. Le reste, et notamment l’image viendra avec. D’ailleurs, depuis combien de temps n’avez-vous pas répondu vous-même à une demande d’information sur votre produit ?

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

Si vous trouvez votre interface trop complexe, cherchez du côté fonctionnel

le 12/03/2010 à 17h37

Il y a quelques jours, je travaillais sur une interface dotée d’une section assez complexe, réagissant de manière radicalement différente en fonction des choix des utilisateurs. Le genre de formulaires insupportables à tiroirs offrant tellement de cas possible que je finissais par ne plus m’y retrouver. Au bout d’un moment, j’ai commencé à réfléchir à un modèle sur deux pages malgré des spécifications me contraignant à une seule.

Au bout d’un moment, j’ai fini par poser ma souris pour aller déjeuner, dans l’espoir que cette pause me permette de prendre du recul. Plus je réfléchissais, et plus la solution sur deux pages me semblait la marche à suivre. Mon formulaire se prêtait largement à une division en deux étapes, la première consacrée aux informations fondamentales, la seconde aux options. Je pouvais même subdiviser chaque page en deux sections distinctes qui offriraient à l’utilisateur un chemin balisé d’un bout à l’autre du formulaire. Renvoyée en page deux, ma section si complexe en serait largement simplifiée grâce aux choix effectués précédemment. J’ai donc relancé Balsamiq Mockups, mon outil de prototypage favori et commencé à designer mon interface. Tout allait pour le mieux dans le meilleur des mondes possibles.

Quelque chose, pourtant, me turlupinait. Deux petites heures plus tard, je sirotais une tasse de Lapsang Souchong tout en m’assurant que je validais bien tous les cas d’usage possibles. Je contemplais mon travail, satisfait du résultat obtenu malgré la complexité fonctionnelle sous-jacente. C’est là que je m’arrêtais net, percé jusqu’au fond du coeur d’une atteinte imprévue aussi bien que mortelle.

… malgré la complexité fonctionnelle sous-jacente.

Je venais de mettre le doigt sur mon problème. La complexité de mon interface n’était que le reflet de ma complexité fonctionnelle. J’aurais probablement du le comprendre immédiatement, mais plongé dans la résolution d’un problème local, j’avais oublié de chercher une solution globale. Une petite heure et une consultation plus tard, tout le fonctionnel superflu disparaissait au profit d’une grande simplification du projet. La voie que nous n’aurions jamais du quitter.

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

Rework, et si vous changiez votre manière de travailler ?

le 12/03/2010 à 17h37

Véritable plaidoyer pour un travailler autrement, Rework, le dernier opus de 37Signals pourrait fortement ressembler à une accumulation de lieux communs ressemblant à s’y méprendre à une overdose de méthode Coué. S’il est est d’ailleurs un lieu commun qui semble avoir la vie dure, c’est que ce qui marche pour 37Signals ne vaut que pour 37Signals. Nombreux sont ceux qui tentent de les copier sans parvenir à les égaler, à se demander si ce qu’ils professent a le moindre fond de vérité. Car c’est bien de la méthode 37Signals dont nous parlons, décrite à grands renforts d’exemples tout au long des 288 pages que comptent ce livre que j’ai fiévreusement dévoré en deux jours.

Martelés avec un enthousiasme tout américain, Planifier c’est deviner, virez les workaholics, les réunions sont l’ennemi, vous avez certainement besoin de bien moins que vous ne l’imaginez, banissez ASAP, ces dizaines d’un chapelet récité au dieu entrepreneuriat passeraient pour le pire bullshit depuis l’invention du marketing s’ils n’étaient ponctués d’une longue argumentation tirée du monde réel. Tout est bon pour expliquer la méthode 37Signals, du pétrolier Exxon à la sandwicherie du coin, et ces exemples permettent de sortir d’une vision de l’entreprise au pays des Bisounours, les fondamentaux étant rappelés aussi souvent que nécessaire : travailler, gagner de l’argent (et non emprunter), ne pas chercher à grandir trop vite… et ne pas copier vos concurrents.

C’est d’ailleurs en filigrane l’avertissement donné Jason Fried tout le long de l’ouvrage à tous les wannabe 37Signals : soyez vous-même, ne (nous) copiez pas, vous n’arriverez à rien. L’une de mes citations favorites concerne d’ailleurs la culture d’entreprise imposée, pour tout ceux qui voudraient reproduire artificiellement leur modèle :

Dans une jeune société, la culture d’entreprise ressemble à un mauvais maquillage, mais dans une société plus mure, c’est de la patine

Fan du réalisme de la doctrine 37Signals depuis le jour de l’annonce de Ruby On Rails sur la mailing list Rails Talks ? ça ne date pas d’hier ? j’attendais Rework avec l’impatience de la groupie de Roch Voisine pour l’album come back de son idole ; je n’ai tout simplement pas été déçu de la première à la dernière page, pas tant par les recommandations dont une bonne partie m’étaient déjà familières, mais par l’énorme bouffée de motivation qui s’en dégage. À lire absolument pour ne pas mourir idiot.

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

La conception agile de vos services avec le Community Driven Design

le 09/03/2010 à 13h52

Avez-vous déjà essayé le Community Driven Design ? Ce modèle consiste à soumettre les prochaines fonctionnalités de votre produit à vos utilisateurs, tous vos utilisateurs, dès l’écriture d’un premier mockup afin d’intégrer leurs retours dès la phase de conception. Inscrit dans un développement itératif, cette méthode vous permet de gagner du temps par rapport à la conception traditionnelle. Au lieu de sortir une fonctionnalité, collecter les feedbacks, modifier l’existant, puis sortir une nouvelle version, vous passez une itération à récupérer les feedbacks et une à les développer.

Quand (ne pas) utiliser le Community Driven Design ?

Sa nature même ne rend pas le Community Driven Design utilisable partout. Il se limite en fait à des fonctionnalités ciblées, n’ayant pas un impact sur de multiples endroits de votre application sous peine de générer des retours inutilisables. Il faut au contraire proposer des problèmes simples et compréhensibles.

Balsamiq, une excellente application de prototypage basée sur Adobe AIR utilise ainsi le Community Driven Design pour sa fonctionnalité de mise à jour automatisée. Marco Botton a soumis un premier prototype à la communauté, qui donne son feedback. La fonctionnalité est alors développée, puis mise à la disposition des clients.

Je vous avais recommandé il y a quelques mois d’impliquer vos utilisateurs dans l’évolution de votre produit, et non vos clients, afin d’éviter le développement à façon pour l’un d’entre eux. Le Community Driven Design ne rentre pas dans cette problématique. D’abord parce qu’il ne s’agit pas de concevoir votre produit au niveau macro avec vos clients, mais de leur soumettre au contraire des points micro là où une série de tests A/B pourrait également jouer. Il ne s’agit pas tant du quoi que du comment. Ensuite, parce qu’en vous adressant à une communauté (de clients) plutôt qu’à des clients ciblés, vous dissolvez les risques de pression dans le nombre.

Ce qui me fait venir à un point intéressant de cette méthodologie qui s’étend bien au delà du simple processus d’amélioration continue. En faisant participer vos clients à la conception de votre produit, vous créez une communauté d’utilisateurs fidèles, et générez un fort engagement chez ces derniers, faisant d’eux vos meilleurs évangélistes, donc rapporteurs d’affaires.

En revanche, si vous ne souhaitez pas communiquer tout ou partie de votre roadmap produit à vos concurrents, cette méthode est évidemment à proscrire, puisqu’elle vous fait perdre l’effet de surprise, et donc une possible avance produit. Elle découle d’une certaine philosophie qui consiste à mettre de côté l’obsession de la concurrence ? et ses corolaires la course à la fonctionnalité et la stratégie girouette ? au profit de l’obsession de la satisfaction des utilisateurs.

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

Alfred, le meilleur lanceur d'applications pour Mac OS X ?

le 09/03/2010 à 13h52

Inconditionnel de Quicksilver pour lancer mes applications et retrouver mes documents sans me prendre la tête ni utiliser la souris, je n’aurais probablement jamais essayé Alfred si je n’avais pas découvert au hasard de Twitter que mon amie Vero Pepperrel ne faisait partie de l’équipe qui développe cette petite merveille. Après Doris la soubrette (perverse comme il se doit), Alfred le bien nommé est donc mon nouveau compagnon de productivité.

Encore en alpha publique, quoique parfaitement utilisable, Alfred est un lanceur d’application pour Mac OS X, qui couvre également les documents, les pages web, et les recherches verticales comme IMDB ou Amazon. Particulièrement léger, il se déclenche exactement de la même manière que Quicksilver, ce qui permet de ne pas perdre ses habitudes et la frappe est beaucoup moins hasardeuse qu’avec son grand frère qui remonte souvent un peu tout et n’importe quoi sans que l’on comprenne vraiment pourquoi. Ajoutons à cela la possibilité d’utiliser également les raccourcis clavier pour atteindre les résultats secondaire. Il est en revanche clairement optimisé pour les claviers US, mais ce n’est pas un problème pour moi, bien au contraire. Alors comme disait la pub : Alfred est probablement le meilleur lanceur d’applications pour Mac OS X, mais c’est à vous de décider.

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

2010 L'Odyssée du Marketing Interactif

le 09/03/2010 à 13h52

Je ne sais pas si ça vient de l’ambiance 1984 qui règne depuis quelques mois entre LOOPSI et ACTA, mais ce bon vieux HAL 9000, l’ordinateur dérangé de 2001 connaît un regain de popularité qui confine à l’obsession. Anyway, ça n’empêche pas la version 2010 de l’Internet Marketing, opus annuel que l’EBG a eu la gentillesse de m’envoyer d’être un excellent cru malgré un site douteux. Les cordonniers sont toujours les plus mal chaussés.

Si vous ne connaissez pas encore les parutions de l’EBG, mais que le marketing interactif vous intéresse de près ou de loin, courrez vous jeter sur L’Odyssée du Marketing Interactif. Dans une première partie, il décortique l’univers du marketing interactif et ses métiers, donnant un aperçu assez complet des diverses disciplines qui s’y côtoient. Dans la seconde partie, il décortique 62 campagnes significatives de l’année dernière, en fonction des buts à atteindre ? vente, image, fidélisation avec à chaque fois un récapitulatif des retombées de la campagne. Chaque campagne est accompagnée d’une problématique qui permet d’en comprendre l’orientation et en facilite l’étude.

À qui s’adresse ce livre ?

Ce livre s’adresse aussi bien à ceux que le marketing interactif intéresse, qu’ils baignent directement dedans ou non, qu’à ceux qui se posent encore la question de lancer une campagne online (y en a-t-il ?), ou qui recherchent des exemples de ce qui a pu se faire par le passé.

Bien que ne m’intéressant pas directement au marketing, j’ai dévoré les 62 cas étudiés afin de voir comment les marques avaient choisi de se positionner ou de positionner leur produit, histoire d’accroitre un peu ma culture générale. J’y ai retrouvé quelques campagnes qui m’avaient bien plu, notamment le joueur de tennis du futur de Lacoste, ou la campagne Prototype menée pour Activision par les belges de 1md et notamment l’ami Vincent.

Metz Angkor ?

Côté présentation, je regrette un peu le coté sympa de la version 2009 qui se lisait dans les deux sens. Le cahier central bourré de chiffres utiles est en revanche une mine d’or pour qui s’intéresse aux usages en ligne. Sur la forme, une unification du retour sur investissement des campagnes abordées offrirait une grille de lecture simplifiée beaucoup plus pratique. Enfin, si j’ai pris beaucoup de plaisir à lire L’Odyssée du Marketing Interactif, certaines campagnes m’ont en revanche laissé un arrière goût de remplissage ou de copinage. L’intérêt de présenter les campagnes Etam ou Viadeo notamment me semble encore douteux, mais je suis peut-être trop exigeant. Que cela ne vous empêche cependant pas de vous jeter sur ce très bon cru en attendant la version 2011.

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

Vos utilisateurs ne se servent jamais votre produit comme vous l'avez conçu mais comme ils l'ont compris

le 25/02/2010 à 10h06

Inutile de créer de beaux didacticiels pour vos produits, seuls vos power users les consulteront. Comme évoqué dans le compte-rendu de Designer L’Invisible, tout ce que nous faisons avec un média digital fait intervenir bien plus de connaissance acquise que l’action originale effectuée avec nos outils quotidiens [1].

Écrire avec un crayon sur une feuille de papier ne fait entrer en jeu que la connaissance écriture. Écrire avec un traitement de texte implique des connaissances en dactylographie, typographie, archivage… dont l’acquisition relève plus pour la grande majorité d’entre-nous de l’intuition, du tâtonnement et de l’à peu près que d’un véritable apprentissage conscient. Je me rappelle très bien de mon premier contact avec un traitement de textes graphique ? Word Junior sous DOS ne comptant pas. Grâce à Microsoft Works premier du nom sous Windows 3.0, ce qui ne nous rajeunit pas, j’effleurais l’édition et la mise en page à grands coups de titres en 48px ombrés et avec des effets 3D. Presque 20 ans plus tard, j’en frémis encore d’horreur.

Une partie non négligeable de la conception logicielle consiste à anticiper tous les cas limites d’utilisation que pourraient rencontrer nos utilisateur en ne suivant pas précisément le schémas d’utilisation théorique tracé lors de la conception du produit. Plus votre application grossit et gagne en complexité, et plus ces cas limites sont nombreux et tordus. Ils n’en deviennent que plus imprévisibles, et le temps nécessaire afin de corriger une fausse manipulation s’accroit parfois de façon exponentielle.

Si vous vivez avec des enfants en bas-âge, vous voyez certainement de quoi je veux parler. Garder une maison fonctionnelle, agréable et résistante aux bêtises ? et accessoirement s’assurer que les enfants ne courent aucun risque ? est un défi perpétuel. Avant d’en avoir, j’ai eu la chance ? si l’on peut dire ? d’encadrer des camps d’enfants et d’adolescents dont une partie venait contre leur gré. J’y ai acquis un certain “nez” pour détecter les bêtises à venir, mais rien n’y fait, et mon ainé de six ans me dame régulièrement le pion à ce petit jeu. Si celles des adolescents relèvent d’une volonté de transgresser les interdits, les bêtises des petits enfants, elles, sont le plus souvent innocentes.

C’est pour cette raison d’ailleurs que vous auriez tort de blâmer vos utilisateurs quand ils ne font qu’utiliser le produit que vous leur avez vendu. On se retrouve alors dans une de ces quatre situations :

• Le produit est bien trop complexe pour être compris intuitivement de ses utilisateurs. Une phase d’expérimentation est nécessaire afin de pouvoir l’utiliser sans se référer à la documentation.
• Votre produit ne fait pas ce que souhaite l’utilisateur qui cherche toutefois à l’y contraindre. Vous avez déjà vu ces enfants forcer sur leurs jouets pour faire rentrer le cylindre dans le trou prévu pour le prisme ? Pareil.
• Vous n’avez pas posé de garde-fous à votre produit, ce qui rend les actions de vos utilisateurs hasardeuses, voir dangereuses. Le risque que vous ayez laissé des failles de sécurité n’en est que plus grand.
• Vous connaissez le problème mais avez décidé qu’il était suffisamment mineur et bénin pour ne pas justifier une résolution en amont, plus coûteuse en temps ou en ressources. C’est un choix, celui de la solution de facilité, mais il est compréhensible. Jusqu’au moment où….

Une des raisons pour lesquelles je déteste Perl, en dehors de sa syntaxe imbitable, est son crédo there is more than one way to do it, qui ouvre la porte à toutes les fenêtres de l’abus. Je préfère des produits simples, qui font moins de choses que leurs concurrents, et qui ne me laissent qu’une manière évidente de le faire à des produits qui exigeront de moi de me demander si la meilleure manière d’aller d’un point A à un point B passe par C, D, E, ou tous à la fois.

À l’époque lointaine où j’enseignais la sécurité des systèmes d’information, je commençais tous mes cours par : la chose la plus importante que vous deviez savoir, c’est que 65% des dommages et des attaques affectant un système d’informations viennent de l’intérieur. Si je devais aujourd’hui animer un atelier sur l’utilisabilité, je crois que je commencerais par 65% des problèmes que rencontreront vos utilisateurs viennent de ce que vous avez pensé votre produit d’une manière, et qu’ils ont compris comment s’en servir d’une autre.

[1] Dont l’usage est beaucoup moins inné qu’on veut bien nous le faire croire. Le principe du marteau ou de la roue ont nécessité des milliers d’années d’expérimentation.

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

Le spam est un état d'esprit !

le 25/02/2010 à 10h06

Lors de la séance de questions / réponses à propos de Rework, le prochain livre de 37Signals, Jason Fried a du répondre à Pourquoi dites-vous que le spam n’est pas le problème du seul e-mail ?

Le spam est un état d’esprit. Il s’agit d’une méthode d’approche imprécise, inexacte et impersonnelle. Cela revient à lancer quelque-chose contre un mur pour voir si ça va accrocher. Vous harcelez des milliers de gens en espérant une réponse de quelques-uns.

Les communiqués de presse sont du spam. Chacun d’entre-eux n’est qu’un pitch générique envoyé à des centaines de journalistes que vous ne connaissez pas dans l’espoir que l’un d’entre eux finira par parler de vous.

Les CVs sont du spam quand vous envoyez le même à des dizaines, des centaines d’employeurs potentiels. Ceux là n’en ont rien à faire du boulot que vous offrez, ils cherchent juste le premier emploi qu’on voudra bien leur donner.

Le spam n’est rien d’autre qu’une méthode simpliste d’attirer l’attention de quelqu’un. C’est vraiment insultant.

Si vous voulez un conseil: soyez personnel. Appelez directement la personne avec laquelle vous voulez entrer en contact. Publiez une note. Si vous lisez un article sur une société ou un produit similaire, contactez le journaliste qui l’a écrit et pitchez le avec passion. Si vous cherchez du travail, écrivez une lettre de motivation qui sorte de l’ordinaire et explique vraiment pourquoi vous voulez travailler dans cette société.

Ne faites pas confiance à la méthode de mitraillage qu’est le spam. Si vous ne vous investissez pas dans vos interactions, vous ne retirerez probablement rien en retour.

Que l’on soit d’accord ou non, les propos de Jason ont de quoi faire réagir, Mon premier réflex fut une certaine empathie envers tous les forçats du CV et de la lettre de motivation qui prennent leur bâton de pèlerin à la recherche d’un entretien d’embauche souvent humiliant. Avant de réaliser combien j’étais d’accord avec lui.

Avant toute chose, il est bon de se rappeler que ce qui est bon pour 37Signals ne marche généralement que pour 37Signals. Il est difficile de demander à tout le monde la même passion dans son métier et le même engagement envers son emploi et son employeur. 37Signals est avant tout un regroupement de passionnés partageant une même philosophie du travail, mais le modèle est difficile à reproduire ailleurs.

Je discutais l’autre jour avec un ami qui sortait d’entretien d’embauche, et me disait ceci : je suis tombé sur une nana des RH qui a passé une demi heure à me vendre la boite, le salaire, l’ambiance et conditions de travail, mais rien ni sur le poste, ni sur les raisons pour lesquelles ils m’ont appelé. Alors, le recrutement serait-il aussi du spam ? Possible si l’on en croit les méthodes shotgun de beaucoup, simplement à la recherche d’un profil ou de ressources qui conviennent.

J’ai reçu pas mal de propositions d’embauche ces derniers temps. Certaines plus ou moins personnalisées, d’autres envoyées aux quatre vents dans l’espoir d’hameçonner quelque-chose. Les premières donnent toujours plus envie de répondre que les secondes, et j’y réponds d’ailleurs, tandis que les emails lancés au hasard partent directement dans ma corbeille. Le pire étant probablement ces emails me proposant le job de mes rêves (sic) et me demandant de transmettre l’offre à mes amis si je n’étais pas intéressé. Wesh, fais tourner gros ! Le ton et la manière me donnent régulièrement envie de leur répondre de manière pas forcément gentille… et puis non. Allez expliquer ce qu’est la passion à ces gens là.

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

Google Chrome a une gestion du cache pour le moins contestable

le 25/02/2010 à 10h06

Google Chrome semble avoir une gestion du cache quelque peu discutable, notamment lorsqu’il s’agit des téléchargements. Une fois un fichier téléchargé, le navigateur ne se connecte plus au serveur afin de savoir s’il a ou non été modifié, mais utilise une version en cache et la télécharge localement comme si de rien n’était.

Je m’en suis rendu compte en travaillant sur un de mes sites. Je venais de remplacer une ressource par une autre, et son nom ayant changé, il me fallait faire une redirection 301 afin de prévenir les navigateurs et les crawlers de son nouvel emplacement.

Je fais donc très classiquement la redirection côté serveur, puis je redémarre.

rewrite ^/ancien/fichier$ /nouveau/fichier permanent;

Il semble, au passage, que Nginx fasse par défaut des redirections 302, et qu’il faille indiquer la directive permanent afin d’obtenir une 301. Dommage qu’ils n’aient pas implémenté un RedirectPermanent comme Apache, mais je m’égare.

Je relance le téléchargement afin de tester ma règle, et Chrome télécharge l’ancien fichier. Je teste avec Webkit, pas de soucis, la règle de réécriture est bien prise en compte. Je relance Chrome, le comportement ne change pas. Un coup d’oeil dans mes logs me confirme qu’aucune requête n’est reçue côté serveur.

Il a fallu que je vide explicitement le cache pour voir enfin une requête arriver à mon serveur. Je ne sais pas trop comment Chromium gère son cache, mais je m’attendais, dans le pire des cas, à un code de retour HTTP 304 en cas de règle incorrecte, mais certainement pas à ça.

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

Sortie de Typo 5.4.3 "Willy Ronis"

le 25/02/2010 à 10h06

Nous avons le plaisir de vous annoncer la sortie de Typo 5.4.3, le fameux blogware développé avec Ruby on Rails qui fait tourner ce blog, et bien d’autres. Cette troisième version de la branche Willy Ronis corrige un certain nombre de dysfonctionnements, dont un bug critique passé à travers notre couverture de tests. Utilisateurs de Typo 5.4.2, vous devez impérativement mettre à jour si vous souhaitez pouvoir utiliser nos pages statiques. Si vous utilisez une version plus ancienne, vous devriez également mettre votre instance de Typo à jour.

La liste exhaustive des changements :

• Correction d’un bug critique provoquant une erreur 500 sur l’éditeur de pages statiques.
• Correction du ticket 143 : publier un article dans le futur le fait remonter dans la liste des articles publiés.
• Les éditeurs ont été étendus en hauteur, facilitant leur utilisation.
• Correction d’un bug dans RDOC qui provoquait une erreur lors de l’installation.

Vous pouvez installer Typo depuis la gem, ou depuis les sources disponibles sur http://github.com/downloads/fdv/typo/typo-5.4.3.tgz.

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

Pourquoi choisir une application Web ? Étude d'un argumentaire très efficace

le 25/02/2010 à 10h06

Convaincre ses futurs clients d’opter pour une application web en mode hébergé n’est pas toujours chose aisée. Entre les réticences d’un modèle encore considéré par beaucoup comme peu sérieux et les DSI qui craignent de perdre leur pré carré, les arguments sont souvent difficiles à placer.
J’aime beaucoup 37Signals, pour leur pragmatisme, la simplicité de leurs applications, et une certaine philosophie du plus c’est simple, mieux ça marche. Plutôt qu’expliquer pendant des heures pourquoi opter pour des applications web en mode S.A.A.S (ou A.S.P), ils ont dédié une page de leur site au sujet. Page qui mérite largement un détour car elle représente un cas d’école en termes d’argumentaire.

La page se lit selon deux axes, délimités visuellement par les bordures verticales et horizontales.

La lecture se fait d’abord de 1 à 2, de gauche à droite :

1. Qu’est-ce qu’une application web ?
2. Pourquoi est-ce mieux pour mon business ?

L’argumentaire ne commence véritablement qu’en 3, avec la mise en avant d’un point fondamental propre à infléchir les décideurs : la sécurité. La lecture de ce troisième point se fait de haut en bas, argument par argument.

Pendant que le visiteur lit cet argumentaire, l’oeil est attiré par la colonne de gauche qui comprend les seuls éléments graphiques de la page. Il y a en fait une lecture parallèle des espaces 3 et 4, l’attention étant retenue par des logos de marques de grande notoriété, familières au lecteur, et synonymes de sérieux. La disposition des logos alterne volontairement les thématiques, en commençant par trois grands domaines :

1. L’agro-alimentaire
2. Les technologies de l’information
3. La santé

Les logos suivants enchainent toutes les thématiques possibles de manière à s’assurer qu’au moins une d’entre elles touchera le visiteur :

• Parce qu’elle fait partie de son domaine socio-professionnel (Sun, Mayo Clinic)
• Parce qu’elle fait partie intégrante de sa vie quotidienne (Kellogs, Adidas, Best Buy)
• Parce qu’elle l’atteint émotionnellement (Obama, WWWF, Amnesty International)
• Parce qu’elle dispose d’un trust rank important (USA Today, Continental Airlines, University of Chicago)
• Parce que c’est un truc de geek (Twitter, Happy Cog, Last.fm)

L’argumentaire de 37Signals lui-même est particulièrement orienté vers des clients américains, même si 3 des 6 premiers logos sont ceux de marques mondialement connues. Cependant, ce modèle d’argumentation peut être repris pour à peu près n’importe quelle offre, dès que la liste des clients permet d’accompagner l’argumentaire en touchant une cible de visiteurs quasi universelle. Du grand art.

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