Ergonomie, Rails et Architecture de l'information web (2.0)

Google Map ne cesse de me surprendre de jour en jours, aussi bien par sa richesse fonctionnelle que par la rapidité de ses algorithmes qu’une gigantesque ferme de calcul ne suffit pas à expliquer.

Dernière fonctionnalité de malade en date, le “click and drag” proposé sur leur outil de calcul des itinéraires.

Mettons que je veuille me rendre de Lisieux à Hermival les Vaux…

Mais que je m’aperçoive soudain que j’ai oublié d’acheter un pot de beurre au supermarché de Glatigny (et puis la route de Glatigny est bien meilleure pour remonter à Hermival). Il me suffit de cliquer sur un point de la route et de déplacer celui-ci à Glatigny pour que mon itinéraire soit automatiquement recalculé en temps réel.

Cette vidéo est d’ailleurs beaucoup plus parlante que ces captures d’écran.

Au delà de la prouesse technique qui n’est pas sans me rappeler le jeu Click and Play de l’éditeur Maxis (Sim City) en son temps, je me demande si, malgré son extrême simplicité – je clique, je déplace et ça marche – ce genre d’interface super intuitive est aujourd’hui réellement à la portée d’utilisateurs grand public habitués à des outils beaucoup plus austères, complexes et directifs.
Aujourd’hui, l’ensemble des applications de calcul d’itinéraires existantes nécessitent un nombre important d’étapes bien délimitées : adresse, code postal, ville, pays de départ, d’arrivée et pour chaque étape. Ces dernières sont à préciser en amont de la recherche, et ne peuvent pas être changées sans effectuer une nouvelle recherche, là où Google Map demande simplement une ligne de départ, une d’arrivée, et suggère des alternatives quand il ne trouve pas directement ce qu’il cherche.

Comme rien ne vaut les retours d’expériences, je viens de faire essayer le service de calculs d’itinéraires de Google à une habituée de Mappy. Elle devait se rendre de Rouffiac (17) à Saint Sauveur d’Aunis (17) en passant par Parançay (17). Sa première réaction fut : “c’est nul, on ne peut pas indiquer par où on veut passer”.

Le changement d’usages est là évident : à une habitude consistant à indiquer par où l’on souhaite transiter en amont de la recherche vient se substituer le calcul d’un itinéraire idéal (se prendre les embouteillages à Tonnay-Charente n’est clairement pas ce que j’appelle un itinéraire idéal) que l’utilisateur peut altérer de manière visuelle, simple et avec le calcul du nouvel itinéraire en temps réel, en fonction de ses goûts ou de ses besoins. Sauf qu’aujourd’hui, l’utilisateur ne le sait pas encore, et qu’il n’est pas forcément prêt à une telle mutation.

Et vous, qu’en pensez-vous ? Croyez-vous que ces nouveaux usages pourront facilement convertir une masse d’utilisateurs non geeks, ou sont-ils destinés pour un temps au moins à une communauté d’early adopters ?

Via Ogle Earth et Nicolas

Si comme moi, dans votre jeune temps, vous avez passé des nuits blanches et perdu toute notion de vie sociale sur aimé Sim City et son successeur Sim City 2000, jetez-vous immédiatement sur Miniville, le Sim City social sauce web 2.0.

Le principe est simple : vous créez votre ville, puis vous l’alimentez et la faites croître en organisant du buzz autour d’elle. Pour chaque visite sur la ville, celle-ci gagne un nouvel habitant. L’interactivité y est très limitée, mais le jeu, est, lui, particulièrement addictif.

Tout irait donc pour le mieux dans le meilleur des mondes possibles si le principe même du jeu ne risquait pas d’entraîner de nombreux abus et de se retourner contre lui-même. La croissance de votre ville dépendant des visites reçues, les moyens d’y amener du monde sont relativement limité :

• Faire un script (5 minutes en shell), permettant d’utiliser une liste de serveurs proxy ouverts afin de vous connecter sur votre ville depuis un grand nombre d’adresses différentes.
• Parler de votre ville sur votre blog, et laisser les robots des moteurs de recherche et autres spammeurs automatisés gonfler votre population sans rien faire.
• Ou encore spammer votre entourage pour les amener à vous rendre une petite visite. Et là, tout est bon : mail, MSN, Twitter…

Alors évidemment, encourager au spam – le principal problème du net – au travers d’un jeu sympathique, je trouve cela plus que limite, quelle que soit la manière dont l’incitation est présentée, et ça risque rapidement de très mal tourner.

Malgré l’arrivée des vacances, et, on peut l’espérer, du beau temps, l’actualité des rencontres autour du web reste chargée, très chargée même, à Paris comme en province.

Paris blog-t-il ? ouvre les hostilités dès mardi prochain à partir de 19h30. Ce qui se veut la soirée blogo-hype (hem) de la capitale consacre sa huitième édition au lancement de Blogbang, une plate-forme publicitaire 2.0 qui valorise la créativité et démultiplie votre pouvoir d’influence (re hem). Probablement beaucoup de flan, mais ça ne m’empêchera pas d’y faire un tour histoire de discuter autour de quelques verres.

Le Paris blog-t-il spécial Blogbang se déroulera le mardi 23 juin 2007 à partir de 19h30 à L’Entrepôt, 7/9, rue Francis de Pressensé - 75014 Paris.

On entame le mois de juillet avec le retour des Mobile Monday France, soirées organisées par la FING et Silicon Sentier autour du web sur les plates-formes mobiles. L’édition du 2 juillet traitera de la télévision sur mobile, avec 4 mini conférences qui tenteront de répondre à la grande question soulevée par l’échec actuel de la 3G : est-ce que ça peut vraiment marcher, et sous quelles conditions ?

Le Mobile Monday dédié à la télévision sur mobile se déroulera le 2 juillet 2007 à partir de 18h45 chez BETC - Euro RSCG, 85-87, rue du Faubourg Saint Martin, 75010 Paris.

Je profiterai du beau temps pour faire un saut à la quarante-huitième édition du Paris Carnet, la rencontre historique des blogueurs parisiens qui se tiendra le 4 juillet à partir de 19h30 à l’Assassin dans le onzième arrondissement. À essayer si l’ambiance du Paris blog-til ne vous tente pas.

Le 48ème Paris Carnet se déroulera mercredi 4 juillet à partir de 19h30 à l’Assassin 99, rue Jean-Pierre Timbaud - 75011 Paris.

Pas le temps de souffler, puisque le second Yulbiz Paris se déroulera dès le lendemain, à partir de 19h chez Urbi et Orbi. Importés du Quebec, les Yulbiz sont des rencontres épisodiques rassemblant toute la communauté des professionnels du web autour d’un verre et d’un buffet d’antipasti. J’avais vraiment apprécié l’ambiance du premier Yulbiz où j’avais pu échanger avec des gens parfois improbables, et j’espère bien que cette seconde édition saura se montrer aussi riche.

Le second Yulbiz Paris, aura lieu le jeudi 5 juillet 2007 à partir de 19h chez Urbi et Orbi, 93 rue Montmartre - 75002 Paris.

N’hésitez pas à me faire part de votre venue, je serai ravi de vous rencontrer autour d’un verre… non alcoolisé évidemment.

Edit : après une bonne nuit de sommeil, j’ai refait une passe sur les photos et mis une nouvelle sélection plus réussie.

<mode “3615 ma vie”>

Rien à voir avec le web, qu’il soit 1, 2 ou 3.0, mais je ne pouvais pas m’empêcher de vous faire partager mon nouveau jouet, une optique des plus sympathiques, laquelle, une fois posé le pare-soleil, est aussi longue que mon avant bras plus la main. J’ai profité du beau temps pour aller tester la bête au parc de La Villette à l’occasion du Qashqai Urban Challenge, la finale d’un championnat européen de VTT freestyle. Je ne connais rien à cette discipline, mais elle me semblait à même de mettre mon nouvel objectif à l’épreuve.

Les photos ont été prises avec un boîtier Canon EOS 20D sur lequel était monté un téléobjectif Canon 70-200 2.8 L USM IS.

Et pour ceux qui souhaiteraient voir le reste, ou celles-ci en plus grand, j’en ai mis une sélection sur mon Flickr.

Quant à moi, je vais me coucher après un excellent concert des Fatals Picards en excellente compagnie.

</mode>

Un peu surpris ce matin, je découvre que le site officiel du premier ministre, en plus d’une newsletter personnalisable, dispose d’une page RSS et une page de podcasts permettant de suivre les divers communiqués émis par Matignon. Et pour ne rien gâcher, cette page est un modèle du genre comme j’aimerais en rencontrer plus souvent.

La page commence par une excellente définition du RSS, loin de tout effet marketing : précise, scientifique, mais accessible et efficace à la fois.

La syndication permet d’établir des échanges d’informations (textes, liens, images) entre sites internet, qui sont automatiquement mis à jour.

Ce dispositif permet notamment d’afficher sur un site des informations issues d’un autre site tout en conservant sa propre mise en page et sa propre charte graphique (on parle de publication en marque blanche)

S’ensuivent une description du contenu global proposé par les flux, ainsi qu’une liste de flux pertinents : types de documents et grandes thématiques : emploi, éducation, santé…

Par défaut, l’ensemble des fils RSS disponibles proposent les 10 derniers documents recherchés, classés du plus récent au plus ancien. Chaque lien proposé précise le jour et l’heure de publication, le titre du document ainsi qu’un court résumé (lorsqu’il est disponible).

Le meilleur reste évidemment pour la fin : la génération de flux entièrement paramétrables. En trois clics, je peux décider de ce que je vais suivre de l’actualité du premier ministre avec une remarquable granularité :

1. Type de document désiré (actualités, communiqués de presse, discours, compte-rendu du conseil des ministres…)
2. Thématique, parmi les 70 grands thèmes proposés, ou tous à la fois.
3. On valide, et voilà !

Je ne sais pas vraiment qui a mis cela en place, ni quand, mais la présence de flux RSS efficaces, pertinents et bien pensés sur le site officiel du premier ministre montre définitivement que la syndication a largement dépassé l’effet de mode – s’il restait des sceptiques – pour rentrer dans l’ère de la grande production.

La préparation de la phase de recette est un des moments clé de la conception du projet en ce qu’il donne l’assurance de vérifier dans les meilleures conditions possibles l’adéquation du produit fini avec les spécifications. Il s’agit aussi de la phase la plus fastidieuse et rébarbative d’un projet, et, si jamais vous rencontrez quelqu’un qui vous prétend le contraire et tente de vous démontrer par tous les moyens possibles que la qualité est un domaine absolument passionnant, engagez le, et ne le laissez jamais repartir : ces gens là sont trop rares pour qu’on les laisse échapper.

Quand rédiger les plans de test ?

Idéalement, vous rédigerez vos plans de tests dès que le client aura validé la conception, histoire de ne pas les changer du tout au tout trois fois par semaine. La tentation à éviter est d’attendre la fin des développements afin de pouvoir effectuer les tests en même temps que vous les rédigez. Comme expliqué plus haut, ils doivent permettre de contrôler l’adéquation du produit fini avec les spécifications, pas du produit fini avec le produit fini et les souvenirs du concepteur.

Pour rédiger vos plans de tests, vous aurez donc soin de fermer toutes les applications en dehors de votre traitement de textes et des spécifications fonctionnelles et techniques de l’application à tester, et c’est tout.

N’oubliez pas que ces plans de tests et les données afférentes vont devoir évoluer avec votre application au fur et à mesure des évolutions. Le cahier de recette est un document vivant qui suit parfaitement le cycle de vie de votre application.

Que mettre dans les plans de tests

Tout, évidemment, et c’est long, très long, même s’il est possible d’automatiser un certain nombre de choses.

Pour être un tant soit peu complet, vous diviserez vos tests en 3 lots :

1. Les tests unitaires.
2. Les tests fonctionnels.
3. Les scénarios d’usage de l’application.

Les tests unitaires.

Les tests unitaires vont principalement vous servir à vérifier que les inputs sont bien enregistrés en base et ressortis comme ils doivent l’être. Ce n’est pas à vous de les écrire, mais à vos équipes au fur et à mesure du développement. L’idéal est d’utiliser une méthode de développement dirigée par les tests :

1. Le développeur rédige les tests.
2. Il développe son module.
3. Il lance les tests, si ça marche, il passe à la suite.

Ces tests sont terriblement longs et fastidieux à réaliser, et c’est pour cette raison que vous devrez immédiatement les automatiser. Bien que coûteuse, l’automatisation se justifie d’elle-même par le temps gagné ensuite et l’absence d’erreur due à l’interface chaise-clavier en charge d’effectuer les tests. En fonction du langage et du framework utilisés, vous aurez à votre disposition tout un tas d’outils pour ce faire : PHPUnit, JUnit, rails::test… les solutions ne manquent pas.

Les tests fonctionnels

Plus complexes que les tests unitaires, ils ont pour but de vérifier la cohérence fonctionnelle de l’application sur de très courtes séquences en fonction des spécifications fonctionnelles de l’application.

Exemple : selon les spécifications, si l’utilisateur rentre un identifiant ou un mot de passe erroné, il est renvoyé sur l’écran d’authentification et un message d’erreur est affiché. Le test consistera donc à contrôler que c’est effectivement le cas, et que le bon message est affiché à l’écran.

Là aussi, il s’agit d’une partie très longue, et pas très rigolote ni à écrire ni à effectuer. C’est un travail de fourmi titanesque et rébarbatif qui nécessite de recommencer cent fois la même chose afin de tester tous les cas possibles, sans pour autant avancer dans l’utilisation de l’application. Mais rassurez-vous, là aussi il et possible de les automatiser, au moins en partie.

Les scénarios d’usage de l’application

Les scénarios d’usage ont ceci d’intéressant qu’ils permettent de tester le produit fini dans des conditions réelles ou quasi réelles. À travers des scénarios représentant l’utilisation quotidienne de l’application, ils permettront de :

• Vérifier que l’application fait bien ce qu’elle a à faire.
• Détecter les erreurs de conception afin de pouvoir les corriger par la suite.
• Corriger toutes les erreurs typographiques, ou de nomenclature qui auraient pu être oubliées pendant la réalisation.

Il est possible d’automatiser cette phase également, mais je ne le recommanderais pas. Au delà d’une étude purement théorique de l’enchaînement des écrans sur le papier, ce sont en effet ces scénarios qui vont permettre de tester l’utilisabilité de l’application, et constater les difficultés de prise en main que pourront rencontrer les utilisateurs finaux amenés à participer aux tests.

Qui doit passer les tests ?

En ce qui concerne les tests unitaires, c’est évidemment le développeur qui doit les passer chaque fois qu’il effectue une modification de son application. Passer les tests de parties qui n’ont pas été impactées permet de détecter les régressions sur l’application ou les effets de bord imprévus. Si des parties plus anciennes sont touchées, il faut évidemment modifier les tests en conséquence.

En fonction de l’ampleur du projet et de la durée de la recette avec le client, vous pourrez faire passer les tests fonctionnels à vos équipes internes et au client, afin de valider tous les points et enchaînements dans les détails. Même si on peut raisonnablement imaginer que le client va méticuleusement vérifier l’ensemble de ces points – et on a parfois de bonnes surprises – lui fournir les scénarios de tests fonctionnels, que ceux-ci soient automatisés ou non, assure une base de connaissance que l’on peut espérer exhaustive.

Enfin, les scénarios d’usage sont à faire passer aussi bien en recette interne qu’avec le client. Il y a d’ailleurs des chances pour qu’il se cantonne uniquement à ces derniers, donc n’hésitez pas à les détailler au maximum.
Si vous en avez l’occasion, accompagnez les utilisateurs du client dans cette phase : c’est un excellent terrain d’expérimentation de l’utilisabilité de l’application sur ses destinataires quotidiens.

Comment rédiger ses plans de tests ?

J’imagine que chacun a ses propres plans de tests, personnellement, je fais comme ça :

Chacun de mes plans de tests – tests fonctionnels et scénarios d’usage – est rassemblé sous la forme de deux classeurs OpenOffice.org, et je place un scénario, ou ensemble de scénarios par feuille. La page est en mode “paysage” et comporte 5 cases :

1. Numéro d’étape.
2. Description de l’étape : quelques mots qui me permettent de savoir vers quoi je tends.
3. Actions : l’ensemble des actions à effectuer.
4. Résultat attendu : ce que je dois obtenir à cette étape du scénario.
5. Résultat obtenu : OK ou KO.

Je mets une étape par ligne, chaque étape correspondant à une fonctionnalité ou description de résultat à valider. Ensuite, ça marche ou ça ne marche pas, et l’utilisateur coche OK ou KO et remplit le rapport de bugs. On rentre maintenant dans la phase corrective, mais ceci est une autre histoire©.

La derniere keynote de Steve Jobs, la grande messe des zélotes de la Pomme a semble-t-il déçu bien des âmes pourtant toutes dévouées à la firme de Cupertino. Certes, Léopard est amusant avec ses effets visuels à tout va, et l’intégration de ZFS est une excellente nouvelle. Mais on en ressort tout de même de là avec une étrange insatisfaction, comme s’il avait manqué la killer app, ou la killer feature que tout le monde attendait. Au point de voir de nombreux blogueurs anglophones ne pas hésiter à affirmer que la keynote a perdu sa magie, comme si la seule mission d’Apple était de révolutionner les nouvelles technologies tous les six mois !

Qu’est-ce qui a bien pu décevoir à ce point les aficionados ? Certainement pas la sortie de Léopard, ni celle de Safari sous Windows, pied de nez en direction de Redmond et du défunt Internet Explorer 5.2. Pour comprendre l’ire des Mac Users, il faut se tourner vers le nouvel iPhone, et son absence – apparemment – de SDK. Ce que j’ai pu lire un peu partout sur le web à ce propos se résume à : Apple aurait pu révolutionner la téléphonie et l’informatique en sortant un téléphone ouvert pour lequel chacun aurait pu développer – et vendre – des applications spécifiques tirant partie de l’écran tactile et des spécificité de l’engin. C’est également le sentiment que nous partagions chez Actualys en septembre dernier lorsque nous discutions avec passions des premières rumeurs surgies autour de l’iPhone. Ce n’est plus mon sentiment aujourd’hui.

La réponse de Steve Jobs à ses détracteurs est cinglante, géniale, et, comme souvent, en avance sur son temps. Vous voulez développer – et vendre – des applications pour l’iPhone ? Rien de plus simple, rendez vos applications web compatibles avec Safari, rien de plus. Le SDK de l’iPhone, c’est du HTML, du Javascript et un peu de Flash, en un mot ce web que nous utilisons quotidiennement. Ce n’est pas nouveau, je suis un fervents partisan du web mobile et de l’ubiquité pour tous. Pas immédiatement, les opérateurs, les terminaux et les usages ne sont pas encore à niveau, et pas forcément de la manière dont on tente de le faire aujourd’hui – transposer ce qui doit s’afficher sur un écran de 17 pouces sur un téléphone – mais dans un futur proche, certainement. Avec Safari, l’iPhone met la barre très haut, et je suis vraiment impatient de pouvoir le tester pour le comparer à Opéra Mini.

Quant au SDK si âprement demandé, il existe, il est gratuit, multi plates-formes, convivial et installé par défaut sur Léopard (et ça pour une bonne nouvelle…) Il s’appelle Ruby on Rails.

Vous êtes un webdesigner ou graphiste de talent, et vous avez envie de vous faire un nom sur le web sans (trop) d’efforts tout en offrant quelques heures de votre temps à un projet open source motivant et motivé ? Cela tombe bien, l’équipe de Typo, le blogware en Ruby on Rails a besoin de vous, et plutôt deux fois qu’une !

Dans le cadre de la préparation de sa prochaine version majeure, Typo est à la recherche d’une bonne volonté pour le remettre graphiquement à neuf façon pub Bio de Danone : ce qu’il fait à l’intérieur doit aussi se voir à l’extérieur. Pour cela, nous avons besoin de deux choses.

Un nouveau thème par défaut

Azure, le thème par défaut de Typo a fait son temps, et il nous faut maintenant passer à autre chose d’un peu plus actuel, tout en restant à la portée du grand public. Étant la première chose que le futur utilisateur voit, le thème par défaut est fondamental, et les features et benefits (cherchez pas, c’est une private joke) de la prochaine version justifient très largement cette refonte.

Les contraintes du projet :

• Un thème sur deux colonnes, le menu à droite.
• Un design fluide – au moins jusqu’à une certaine largeur.

Un nouveau thème pour l’admin

L’administration de Typo (login et password : admin) laisse graphiquement à désirer alors qu’un gros travail a déjà été fait sur l’utilisabilité de la chose, et là aussi, une refonte graphique est plus qu’indispensable. Nous avons bien conscience que les zones d’administration ne sont pas la partie vue du grand public et permettant d’améliorer son Page Rank, et que cette partie du site est beaucoup moins attirante, mais nous ne pouvons malheureusement pas rétribuer qui que ce soit pour ce travail : Typo ne nous rapporte pas d’argent – il aurait même tendance à m’en coûter – et nous travaillons dessus bénévolement. La personne qui accepterait de prendre cette partie en charge le ferait donc pour l’amour de l’art

Un peu d’humour dans ce monde de brutes.

Bien connu des blogueurs, Feedburner est un service américain permettant de gérer son flux RSS en disposant de tout un tas de services for pratiques : statistiques, régie publicitaire, liens permettant de publier les billets sur la grande majorité des services communautaires… Parmi les fonctionnalités intéressantes du dernier rachat de Google se trouve la possibilité de s’abonner au flux par courriel, ce qui est bien pratique pour ceux que souhaitent suivre des blogs sans toutefois entrer dans l’ère de l’agrégateur.

Ce matin, en recevant mon abonnement à mon propre flux – cela me permet de contrôler qu’il est bien arrivé à destination – j’ai eu la surprise de lire ceci dans le pied de page du mail :

If you prefer to unsubscribe via postal mail, write to: Frédéric de Villamil .com, c/o FeedBurner, 549 W Randolph, Chicago IL USA 60661

C’est à dire :

Si vous préférez vous désabonner par courrier postal, écrivez à Frédéric de Villamil .com, aux bon soins de Feedburner, 549 W Randolph, Chicago IL USA 60661

S’abonner à un flux RSS par courriel ne me semblait déjà pas la chose la plus naturelle qui soit, pour ne pas dire que je trouve ça contre nature, mais pouvoir résilier son abonnement par courrier postal, ça ne me serait jamais venu à l’idée.

La très grande majorité des gens que j’ai vu arriver en entretien d’embauche sans préparation se sont plantés dans les grandes largeurs, et je ne fais pas exception à la règle. Si la plupart d’entre eux n’ont pas obtenu ce qu’ils voulaient faute d’avoir su le formaliser de manière convaincante, d’autres ont tout simplement été recalés à la porte d’un emploi pour lequel ils étaient probablement faits. La préparation d’un entretien d’embauche relève à la fois de l’entraînement du coureur de fond et des essais libres d’un grand prix : il s’agit d’un travail de longue haleine très général ponctué de phases très spécifiques au moment de rencontrer le recrutement d’une entreprise.