planet #openweb

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.

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.

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.

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.

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.

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.

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.