Ergonomie web, Ruby on Rails et Architecture de l'information :

Arrêtez de masquer les mots de passe !

Sun, 28 Jun 2009 16:18:00 +0200

Le dernier Alertbox de Jakob Nielsen Stop Password Masking a provoqué pas mal de discussions, certains n’hésitant pas à le qualifier de plus grand ramassis de conneries qui ait jamais été publié sur Internet. Nielsen y explique que les erreurs dues à l’obfuscation des mots de passe dans les champs de saisie entraînent la frustration des utilisateurs, et une perte en termes de business pour l’auteur du site.
Sans entrer en totale opposition avec Nielsen, son article me semble oublier ou passer sous silence un certain nombre de problématiques qui rendent sa position caduque. La dissimulation des mots de passe me semble au contraire indispensable, bien que les implémentations doivent aujourd’hui être totalement changées.

Une double question de sécurité

Le masquage des mots de passe dans les champs de saisie s’impose d’abord pour une question de confidentialité. Les ordinateurs sont de plus en plus souvent utilisés dans un contexte de mobilité : clientèle, aéroport, lieux publics dans lesquels peut tout à fait se trouver des caméras de surveillance. L’affichage des mots de passe en clair à l’écran fait donc courir un risque non négligeable de récupération des données. Si Nielsen n’oublie pas ce point, qu’il traite en deux lignes ajoutant que l’utilisabilité doit parfois passer après la sécurité, l’idée d’un champs password à l’obfuscation débrayable me semble un cataplasme aussi hâtif que contre productif.

Nielsen met en avant le fait que masquer les mots de passe entraîne des erreurs, et que, afin d’éviter les erreurs, les utilisateurs choisissent des mots de passe volontairement simplistes. C’est, pour le coup, une des plus grosses conneries que j’ai pu lire depuis que je suis sur le web, à égalité peut-être avec e Telnet, ca prends combien de raw sockets en sur-adressage sur un FDDI ?, mais c’était de l’humour.
Le choix d’un mot de passe simple répond à un besoin de mémorisation. Il est plus simple de se souvenir d’un mot de passe simple, ou d’un élément familier toto, nom de son chien, date de naissance… que d’une chaîne de 10 caractères générée aléatoirement mélangeant lettres majuscules et minuscules, chiffres et caractères spéciaux.

Le nécessaire masquage des mots de passe dans les zones de saisie correspond également à un besoin de sécurité côté utilisateur. Tout comme la réaction naturelle est de s’attendre à ce que valider un formulaire force le rechargement de la page – et ce même si toutes les données sont envoyées en AJAX – l’utilisateur s’attend à ce qu’un tiers ne puisse pas voir son mot de passe, même si ce dernier est écrit en clair sur un post-it collé à son écran.

Une nouvelle implémentation nécessaire

Nielsen a en revanche raison sur un point important : l’implémentation des champs de type password y compris sur les navigateurs modernes n’est pas adapté à l’évolution des usages, et particulièrement à celui de la mobilité. La taille des claviers, l’utilisation d’une même touche pour gérer plusieurs caractères, ou les claviers tactiles rendent délicate la frappe d’un mot de passe complexe en aveugle.

La méthode mise en place par Apple (et peut-être d’autres) sur l’iPhone depuis la version 2.0 de son OS est peut-être la réponse la plus adéquate au problème du masquage des mots de passe. Chaque caractère entré s’affiche en clair à l’écran durant une seconde avant d’être caché. Dans un contexte de mobilité, cela assure à l’utilisateur la relecture de son mot de passe tout en en conservant la confidentialité d’un bout à l’autre du processus de saisie.

La mise en place d’un tel procédé est du ressort des éditeurs de navigateurs, puisqu’il s’agit de redéfinir le comportement du champs de type password. Une implémentation partielle utilisant Javascript me semble possible, mais limitée à quelques navigateurs, seulement pour le processus de saisie initiale, et non accessible. Sa mise en place en édition est en revanche à repousser aux calendes grecques.

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.

Projets collaboratifs en entreprise : vous savez pourquoi ? Demandez-vous maintenant comment

Fri, 26 Jun 2009 22:08:00 +0200

On a pas mal parlé de l’opposition entre le pourquoi et le comment dans la mise en place des projets web, et particulièrement des projets web collaboratifs chez les grands comptes, et c’est quelque chose que je conçois bien : plutôt que de vous demander comment vous allez le faire, demandez-vous plutôt pourquoi.

Effectivement, justifier du pourquoi est indispensable quand on va à l’encontre des credo du milieu, et des méthodes de management ancrées depuis parfois des décennies. Il faut de bonnes raisons non solum pour bousculer des habitudes bien ancrées dans la maison, sed etiam pour faire changer les modes de travail de ceux qui en sont les gardiens. Le pourquoi devant évidemment démontrer en amont en quoi le changement aura un impact positif sur le sacro-saint ROI, quelle que soit la manière de le calculer.

Pourtant, je ne suis pas d’accord avec la plupart des ténors de ce qu’on appellera pudiquement l’entreprise 2.0, le terme ayant pour moi autant de sens que web 2.0, comme s’il y avait eu un jour avant et un jour après.

Le comment est au moins aussi important que le pourquoi, ne vous déplaise.

Il y a d’abord le comment en termes de conduite du changement procédural. L’étude du sujet pourrait mener à la publication d’un nombre impressionnant d’ouvrages, tant le modus operandi dépend à la fois des particularités internes à l’entreprise et à ce fameux pourquoi. Ce n’est pas mon propos, bien que mon quotidien m’ait donné pas mal de grain à moudre le sujet.

Il y a ensuite le comment en termes de conduite du changement technologique, et là, j’ai le sentiment que les forces d’inertie sont encore plus importantes que lorsqu’il s’agit de faire migrer les processus. Sans vouloir rentrer dans les clichés, le plus dur sera globalement de rentrer dans le pré carré des DSI. Pour beaucoup d’entre-elles, et on les comprends, un système d’information qui fonctionne n’a surtout pas vocation à changer. Contrairement à ce que j’ai pu penser un certain temps, il n’y a pas toujours que de la flemme et une volonté d’immobilisme derrière ce credo, mais bien un soucis de qualité de service qui se traduit en fin de trimestre par des statistiques de disponibilité.

Il y a également une question d’intégration avec l’existant, laquelle n’est pas à prendre à la légère. Pour beaucoup d’entre nous, changer d’outil est déjà pénible ; changer de méthodes de travail pour le moins déconcertant ; devoir également changer totalement d’écosystème, ou pire, faire cohabiter deux écosystèmes en parallèle sans dénominateur commun est certainement le meilleur moyen de partir dans le mur. Et là encore, le comment n’est pas une mince affaire : intégration avec un annuaire LDAP existant, à minima, avec un système de messagerie, une charte graphique des applications internes… Et ne parlons pas de s’interfacer avec des applications métier parfois vieilles de 10 ans afin de récupérer des flux d’informations…

J’ai lu dernièrement pas mal de ~~conneries~~ ~~bullshit~~ choses sur la phase techniques du déploiement des applications web collaboratives en entreprise. Une fois la décision prise, il semble que ce soit d’une simplicité déconcertante : du passé faisons table rase, de toutes manières l’existant a vécu, le ROI supposé s’impose à la technique, et nous serons les seuls sur terre dans un système d’information tombé en désuétude et dès lors forcément rangé aux oubliettes pendant la phase d’avant projet.

J’aurais envie de paraphraser Pierre Desproges, mon grand maître à penser, qui disait qu’en politique, l’adulte, lui ne croit plus au Père Noël : il vote. Dans le joyeux monde de l’entreprise 2.0, le consultant ne vote pas, mais il croit qu’il va changer le monde en déployant un wiki.

Une vidéo publicitaire percutante pour Internet Explorer 8

Thu, 25 Jun 2009 22:29:00 +0200

Si vous partagez votre ordinateur avec un habitué des sites de bon goût comme Rotten, Ogrish, XXXJihad ou Xmat pour ne citer qu’eux, il peut parfois vous arriver d’avoir envie de vomir après avoir mis les clics là où vous n’auriez pas dû.

C’est cette thématique qu’aborde la dernière vidéo publicitaire de Microsoft pour Internet Explorer 8. La sécurité y est abordée avec un humour pipi caca qu’on associe difficilement avec la firme de Redmond, mais qui devrait assurer la diffusion du spot à défaut de celle du navigateur.

À la fin de la vidéo, le spectateur est invité à se rendre sur le site Browser for the better, sur lequel il pourra télécharger Internet Explorer 8, le meilleur navigateur du monde. En échange, Microsoft offrira 8 repas à des américains en situation de grande pauvreté.

Et c’est parti pour l’analyse façon café du commerce… mais pas tant que ça

Le message transmit par la vidéo est particulièrement astucieux. Microsoft s’adresse plus ou moins explicitement aux deux personnages, quitte à en rajouter des tonnes dans les clichés.

À gauche, Madame Michu, prototype de l’utilisatrice moyenne, probablement femme au foyer. Madame Michu est un peu effrayé par cette zone de non droit qu’est le web, mélange exclusif de téléchargements illégal, de pornographie chevaline et de pédophilie. Heureusement, la fonctionnalité Private Browsing d’IE8 la mettra à l’abris de tout ça. Le film ne lui explique pas ce qu’est le Ptivate Browsing, mais c’est pas grave.

À droite, le jeune, un peu geek sur les bords. Il passe son temps sur des sites peu recommandables et ne craint qu’une chose : que sa femme / mère / petite amie ne découvre ses vices cachés. Le mode private browsing d’Internet Explorer lui permettra de continuer à surfer sans se faire griller. Et ça marche aussi au bureau.

Histoire d’enfoncer le clou, et de pousser au téléchargement, Microsoft nous refait le coup de la campagne humanitaire, cette fois en faveur des américains qui meurent de faim. De l’extérieur, ça fait carrément foutage de gueule intégral, et j’en connais un paquet qui auront du mal à le digérer, c’est le cas de le dire. C’est bien la première fois que les États-Unis font l’objet d’une campagne contre la faim dans le monde, et c’est malheureusement très sérieux.

Microsoft prend ici le contre-pied de la Fondation Mozilla, qui avait axé la campagne de lancement de Firefox 3 autour du record du monde de téléchargement, et montre qu’elle s’attaque à un tout autre public : non plus celui qui va vouloir s’amuser pour battre un record, mais celui qui se sentira concerné par la faim aux États-Unis. Bien joué Microsoft, il est difficile de vous refuser le téléchargement après ça, j’y vais d’ailleurs de ce pas.

Ah mais non, IE8 n’existe pas sous Mac… Tant pis, j’imagine de toutes manières que les États-Unis s’en tireront très bien sans moi.

Analyse d'une usine à spam déguisée en application virale : two tweets and a lie

Sat, 20 Jun 2009 21:28:00 +0200

À force de coups de pieds dans le derrière, certaines agences de communication et autres spécialistes auto proclamés du “buzz marketing” finiront peut-être par comprendre qu’il ne faut pas confondre viralité et spam. J’admet que la différence est subtile, et certains esprits trop limités pour la comprendre, aussi je me permettrai d’aller à l’essentiel. Un message est viral quand ses destinataires le reçoivent volontairement. Quand ils y sont forcés par des moyens plus ou moins licites, légaux, ou moraux, on appelle ça du spam.

Le dernier spam déguisé en machine virale m’a été montré du doigt par mon amie Christine Cavalier et a pour nom Twables, 2 teets and a ~~spam~~ lie. Twables est un de ces jeux comme il en existe déjà des milliers sur Facebook, dont le seul objectif est d’attirer les utilisateurs en se basant sur une idée aussi stupide que simpliste.

Le formulaire, aussi simpliste soit-il, contient pourtant un piège grossier, mais efficace : une discrète checkbox cochée par défaut et placée juste sous le bouton de validation. Celle-ci a pour label Envoyer les invitations par message direct, et s’accompagne d’un court message explicatif.

Le truc est simple, mais terriblement efficace.

Le bouton de validation est le seul élément coloré du formulaire. Il attire donc en premier le regard de l’utilisateur qui va ensuite remonter vers les champs texte. La case à cocher est donc absente du parcours visuel du formulaire.

La case à cocher se trouve dans l’alignement exact du bouton de formulaire. La placer dans l’ombre de ce dernier permet de la dissimuler encore au regard de l’utilisateur lors du scan visuel de la page, mais également du remplissage du formulaire.

La checkbox est cochée par défaut. L’envoi des messages directs est donc forcé, à moins d’opt out. En France, cette pratique est illégale, les formulaires devant proposer uniquement de l’opt in pour ce genre de choses.

La case à cocher se trouve sous le bouton de validation. Dans le processus de remplissage naturel du formulaire, elle passe donc après l’envoi de ce dernier. L’utilisateur doit donc faire un effort supplémentaire pour en tenir compte.

Enfin, les messages directs sont envoyés à l’intégralité des followers de l’utilisateur. Il n’est laissé aucune possibilité de restriction ni de filtrage.

On pourra qualifier mon analyse d’enculage de mouches : peut-être les concepteurs de Two tweets and a lies ont-ils simplement commis quelques erreurs de débutant en concevant leur formulaire. Je ne le pense pas. La mariée est trop belle, et la conception de ce formulaire montre une certaine maîtrise de la chose, en se limitant à un comportement borderline qui pourrait laisser la place au doute. À peine plus que si la checkbox avait été remplacée par un input type hidden.

Windows 7 livré sans Internet Explorer nous renvoie 15 ans en arrière pour pas grand chose

Sat, 13 Jun 2009 08:48:00 +0200

J’avoue avoir été atterré quand Microsoft a annoncé hier matin que, suite à la décision de la commission Européenne, Internet Explorer ne serait pas livré en standard sur Windows 7, mais que chaque constructeur, assembleur et revendeur de PC serait libre de l’installer, lui, Firefox ou le navigateur de leur choix.

Atterré d’abord, par les cris de joie de certains zélotes décérébrés du logiciel libre, et autres anti Microsoft primaires qui ne voient dans cette annonce qu’une victoire de la cause sans regarder plus loin que le bout de leur nez, au point de ne pas voir le retour en arrière que cela implique pour les utilisateurs.
Pour rappel, le dernier système d’exploitation livré en standard sans navigateur fut Windows 95. Internet Explorer était livré à part dans le Service Pack, à l’époque un ensemble d’améliorations et non un patch correctif plus gros que l’installation originale. Outre Internet Explorer, on y trouvait un jeu de papiers peints, et l’Active Desktop de triste mémoire, qui permettait de donner à votre bureau le look and feel d’une page web. En 2009, fournir un OS sans navigateur revient à vendre une voiture sans moteur, et je ne doute pas que Microsoft saute sur l’occasion pour mettre en avant l’obscurantisme de l’Union Européenne. Ce serait certes facile, mais de bonne guerre.

Atterré ensuite par l’hypocrisie de l’annonce, mais aussi par le manque d’analyse des articles que j’ai pu lire ici et là sur la toile, qui se contentent de donner l’information, rappeler l’historique de l’affaire Microsoft contre la Commission Européenne.

Microsoft a annoncé que Windows 7 serait livré sans navigateur. Soit, mais rien ne l’empêche de l’installer par défaut lors de la première mise à jour, obligatoire, consécutive à l’installation. Je doute que les navigateurs concurrents aient droit au même traitement de faveur.

Les constructeurs, assembleurs et revendeurs de PC pourront fournir Firefox, ou un autre navigateur par défaut. Oui, mais à quel prix ? Difficile d’oublier les politiques tarifaires de Microsoft à l’égard des assembleurs qui auraient voulu vendre du PC/DOS ou de l’OS2 à côté de MS DOS dans les années 80.
Sans compter le peu de réalisme de la chose. On va retrouver du côté des assembleurs la même problématique, peut-être à une moindre échelle, que celle des constructeurs de voitures. L’installation de certaines options sur une voiture coûte cher, car elle nécessite de modifier les chaînes de production, pour un faible volume en sortie. Tant que la demande en Internet Explorer sera supérieure à celle de Firefox, il y a très peu de chances de voir ce dernier installé en standard sur les machines grand public.

En poussant l’analyse de comptoir un peu plus loin, on peut même trouver une certaine logique perverse, et un peu cynique, dans cette annonce. Microsoft va pouvoir se racheter une virginité en Europe à peu de frais. D’abord parce que la Commission Européenne pénalise les utilisateurs en les empêchant d’avoir un navigateur web sur leur machine. Ensuite parce que, si au final, rien ne change, Microsoft pourra se décharger sur les revendeurs de machine : ce n’est plus nous qui imposons Internet Explorer, ce sont les revendeurs de matériel. Chapeau bas ! Et vous, vous en pensez quoi ?

Une balise NSFW dans HTML5 ? Mais WTF ?

Wed, 10 Jun 2009 09:00:00 +0200

Un nouveau tag NSFW (Not Safe For Work) a été proposé au groupe de travail sur HTML5 afin de marquer les contenus considérés comme pouvant choquer les plus jeunes. Cette balise pourra par la suite être interprétée par les navigateurs, et son contenu caché dans le cas de l’activation du filtre parental, par exemple.

One of the most common descriptive notes people have to write using text when they post links or images to blogs, comments or anywhere in HTML is to say “this link is not safe for work” or simply “NSFW”. By adding the tag, this could be made much simpler and standardized. Browsers could then have an option to automatically hide all content. A tag is preferred to an attribute since it could then also be used around content and not just links.

Examples:
<nsfw><a href="http://www.example.com">Pics here!</a></nsfw>
<nsfw><img src="badkitten.jpg"></nsfw>

Je m’étais déjà exprimé il y a 3 ans sur la différenciation nécessaire entre structure et sens, notamment dans le cadre des Microformats. Je n’ai pas vraiment changé d’avis sur le fond, et je pense que cette balise NSFW est une connerie monumentale à tous points de vue.

D’un point de vue du rôle du HTML, je continue de penser que la structure doit être détachée du sens, bien qu’elle puisse toutefois transmettre des informations. C’est notamment à ça que les servent les attributs rel, rev ou alt, mais une balise dédiée me semble totalement inappropriée. On a encore assez de mal à faire comprendre aux gens qu’il faut différencier structure et mise en forme, et qu’il ne faut pas préférer h2 à un p stylé parce que ça rend plus gros à l’écran. Le jour où le contenu aujourd’hui NSFW sera rentré dans les moeurs, on se retrouvera comme des cons à devoir supprimer la balise inutile, tout comme on a du un jour virer toutes ces saloperies de td des designs intégrés en tableaux.

Au regard d’HTML5 ensuite. HTML a pour particularité d’être un monolithe figé, contrairement à XHTML qui est extensible avec la DTD qui va bien. On a donc la fâcheuse tendance à vouloir y caser tout et n’importe quoi, juste au cas où. En termes de développement, on parle de design smell, et c’est MAL. Contrairement à la balise video, dont je ne suis pas fan, mais qui a un sens vus les usages actuels, nsfw n’apporte rien en termes de structure. Une balise nsfw aurait donc pour seul intérêt d’alimenter les arguments des détracteurs du HTML au profit de l’extensibilité du XML. /troll.

Enfin, le problème est culturel. Si le microformat hCard indique la présence d’une carte de visite quel que soit mon pays d’origine ou ma culture, un même contenu ne sera pas perçu de la même manière en fonction de ma nationalité, de ma culture, de ma religion… La balise nsfw va donc introduire une notion de valeur morale, et à ce titre, elle n’a strictement rien à faire dans HTML.

Via Jeffrey Zeldman.

Lifestream, real time web, et le retour de l'infobésité

Mon, 08 Jun 2009 07:24:00 +0200

À force de ventiler son identité numérique façon puzzle aux quatre coins du web, avant de croiser sites spécialisés, réseaux sociaux et verticaux dans une grande débauche de contenus pris et repris ad libitum et ad nauseam, l’avènement du lifestream, cet agrégat de toutes les miettes de votre identité numérique devenait évidente.
Certains, comme le défunt – au moins sous sa forme originale – Ziki, s’y sont essayés il y a déjà quelques années avec le peu de succès que l’on sait. On pourra attribuer cet insuccès au manque de contenus à rassembler, à une absence de conscience de son identité numérique, à des erreurs de stratégie de la société, ou tout simplement à un produit pas vraiment sexy, le débat n’est pas là. Et le récent “réveil” de Friendfeed, aussi bien que l’initiative du géant américain Skittles de transformer son site web en miroir de sa réputation en ligne au mépris des canons les plus sacrés de la communication institutionnelle montre bien que le lifestream a le vent en poupe.

En termes d’architecture de l’information, le lifestream représente, selon le point de vue, une avancée significative, ou une catastrophique régression.

Le portail, une architecture hyper hiérarchique

Au commencement était le portail, basé sur une structuration pyramidale outrancière de l’information, dans laquelle tout partait du haut – aussi bien l’accueil du site que du management, pour descendre vers le bas. Certaines implémentations les plus kafkaïennes allaient jusqu’à bannir tout lien transverse, et le fil d’Ariane y était inconnu. Il était donc impossible de remonter d’un niveau, et il fallait repartir de l’accueil pour revenir sur ses pas.

Ce système, pour aussi aberrant qu’il puisse sembler aujourd’hui, avait pourtant ses raisons d’être. D’un point de vue conceptuel, il tentait de transposer un modèle apparemment efficace dans d’autres domaines. Chaque information est à sa place, triée selon une hiérarchie catégorielle stricte, dans laquelle Milou est un représentant de la race fox terrier à poils durs, lui même héritant du chien, membre de la classe animale, appartenant aux êtres vivants… Vous me suivez toujours ?
Politiquement, on pouvait faire travailler parallèlement des services concurrents sans jamais les faire se rencontrer : Chacun chez soi, et les vaches seront bien gardées.

Dans les faits, on avait le plus souvent une information hyper fragmentée, introuvable, inexploitable, et surtout généralement incomplète : à trop chercher l’exhaustivité, on tombait sur une armée de pages en travaux, éventuellement associées au gif animé qui a bercé d’horreur la jeunesse de bon nombre d’entre nous.

L’arrivée des blogs et des wikis ont changé pas mal de choses dans l’organisation de l’information, au point que les premiers se soient vus décliner à toutes les sauces pas forcément les plus appropriées.

Les blogs, entre timeline et étiquetage

Avec le blog, on passe dans une organisation verticale, marquée dans un premier temps par une très forte temporalité. À l’époque, la très grande majorité d’entre eux offraient une navigation calendaire explicite, qui venait compléter l’affichage en ordre chronologique inverse. À cela, il faut ajouter un classement en thématiques simples ou multiples, les catégories, ces dernières progressivement remplacées depuis 2005 par un système d’étiquetage, le tag. J’ai beaucoup écrit sur les tags à une certaine époque, si vous êtes mal à l’aise avec cette notion, je vous recommande donc la lecture de La recherche par tags, complément indissociable de la recherche sur le contenu.

Dans ce modèle d’ordonnancement, Milou devient un article de premier niveau, publié dans la catégorie animaux en 1930. Milou se voit attribuer les étiquettes chien et fox terrier à poils durs. Une visite sur la page chien permettra ensuite de remonter vers Lassie, Rintintin, Rantamplan… La navigation devient beaucoup plus simple, et croisée, tout en conservant une certaine hiérarchie. Et là encore, la transmission de l’information est purement verticale de haut en bas, bien qu’elle s’ouvre également aux réactions de la base.

Les wikis

Le wiki se construit sur un ensemble d’éléments indépendants, avec une densité de liens internes particulièrement importante. La hiérarchie y est généralement plate, même si pas nécessairement, et n’importe quel point d’entrée permet une navigation sur l’ensemble du site. Cette absence de réel point d’entrée et de hiérarchie font partie des difficultés d’appréhension du modèle wiki, au delà du fonctionnement collaboratif.

Cette architecture de l’information à plat fait partie des nombreuses raisons pour lesquelles je n’aime pas les wikis. Il est quasiment impossible d’y trouver quelque chose si

On ne sait pas ce que l’on cherche.
On n’accepte pas une bonne dose de sérendipité.

Le lifestream

Le lifestream est l’agrégation de l’ensemble des éléments de l’identité numérique d’un individu, d’un groupe ou d’une entreprise, affichée selon une ligne chronologique, ou chronologique inverse comme cela se fait sur le modèle blog. Quant à la notion d’éléments de l’identité numérique, elle regroupe diverses définitions, mais principalement :

Ce que je publie sur les divers sites et réseaux sur lesquels je suis inscrit (blog, twitter, photos sur flickr…).
Ce que les membres de mon réseau publient sur les sites sur lesquels ils sont inscrits.
Ce que le web dit de moi.
Les trois à la fois.

Le lifestream amène 3 conséquences importantes :

L’information n’a de valeur que si elle est reçue, traitée et utilisée dans un laps de temps très court après son émission. Au delà d’un laps de temps parfois très court, elle perd sa valeur – encore plus dans le cas d’une conversation – ou se noie dans le flot constant de données émis.
Dans le cas d’un lifestream à double sens, par exemple celui mis en place par Skittles pour remplacer son site corporate, l’éditeur n’a plus le contrôle de l’information émise en son nom. Si c’est intéressant du point de vue expérimental, cela peut aussi s’avérer très dangereux, que ce soit légalement ou en termes d’images.
Le format lifestream ne permet (à ce jour) plus de poser des filtres sur l’information. Il est toujours possible de remonter à sa source, et d’en suivre le flux particulier, par exemple votre compte Flickr, votre blog, votre Twitter… mais plus de filtrer efficacement sur des média, des thématiques… L’information arrive brute, se traite immédiatement, et on risque rapidement l’infobésité.

Mon troisième point est, volontairement, un peu biaisé. Dès lors qu’il est possible de récupérer le flux de l’information, il est possible de mettre en place des filtres. Mais les services comme Yahoo Pipes sont réservés aux spécialistes, ou en tout cas aux technophiles avertis.

Ce qui m’amène à mon dernier point, et je vous fout la paix, promis. Le lifestream, comme Twitter d’ailleurs, est un outil destiné aux geeks, parce qu’il nécessite d’appréhender des flux d’informations bruts et non des informations.

L’agence Heaven a récemment remplacé son blog par un lifestream. C’est bien joli, cela surf sur une certaine mode et fait preuve, au moins pour ses clients, d’un certain avant-gardisme, mais c’est inexploitable pour quelqu’un souhaitant se renseigner sur l’agence. Et pour cause, l’information ne se trouve pas dans le lifestream, mais bien dans la colonne de gauche, statique elle : contact, expertises, case study… tout le reste n’est que poudre aux yeux.

Les utilisateurs de Facebook s’en sont bien rendus compte, et la tentative du géant des réseaux sociaux de se transformer en lifestream a fait long feu devant la vox populi. Nous ne sommes dans l’ensemble pas faits pour digérer des flux d’informations continues, qui deviennent caduques en quelques secondes. Nous avons besoin que l’information nous arrive traitée, classée et structurée avant de nous y intéresser, et c’est très exactement ce besoin auquel Facebook s’est heurté en tentant de copier Twitter.

Pourquoi choisir XHTML, par Steven Pemberton du W3C

Tue, 02 Jun 2009 21:00:00 +0200

Molly E. Holzschlag a réalisé une interview de Steven Pemberton, chairman des groupes de travail HTML et formulaires au W3C à propos d’XHTML, et plus précisément des raisons pour lesquelles il faut choisir XHTML. Cette traduction en français devrait éclairer pas mal de zones d’ombre à l’heure où HTML5 a clairement le vent en poupe.

Premièrement, quelques rappels. je donne régulièrement des conférences dans lesquelles j’explique pourquoi le livre est condamné. Je pense que le livre est condamné pour les mêmes raisons que j’ai pensé que les écrans cathodiques ou les appareils photos argentiques l’étaient. Les personnes présentes à ces conférences font généralement l’erreur de penser que, puisque je pense que le livre est condamné, je milite pour sa disparition, et viennent par là me chercher des poux dans la tête. En réalité, j’aime les livres. J’en possède même des milliers… mais ça ne m’empêche pas de penser qu’ils sont amenés à disparaître.

De la même manière, beaucoup de gens pensent que, puisque je suis la voix derrière le XHTML, je pense nécessairement que le XML est parfait, et qu’il va résoudre le problème de la faim dans le monde.

Je ne le pense pas, même si…

On m’a demandé de créer XHTML et je l’ai fait.
XML n’est pas parfait. En fait, je pense que ses concepteurs étaient trop focalisés sur l’impression, et n’ont pas anticipé correctement toutes les applications qui pouvaient en être faites. Comme le dit si bien Tim Bray, Vous savez, les mecs qui ont inventé XML étaient une poignée de fondus des technologies de publication, et nous pensions réellement créer le format de documents du futur. On n’avait aucune idée du fait que les gens l’utiliseraient pour créer des flux de syndication ou pour donner des ordres d’achats.
J’ai à plusieurs reprises tenté de faire corriger quelques unes des pires erreurs de XML, et pas toujours avec succès.
XML existe, il existe un paquet d’outils permettant sa manipulation, il est interopérable, et il résout une bonne partie des problèmes de l’humanité.

Le parsing

Ah, le parsing. Tout le monde ou presque a grandi avec la permissivité du HTML et a fini par s’y habituer. HTML a été conçu pour être user friendly. J’ai coutume de l’appeler le balisage de grand-mère. Il reste pourtant un problème sous-jacent qu’on a un peu trop tendance à cacher sous le tapis : ce contrat non écrit que le développeur passe avec son navigateur. Vous créez le document, le navigateur l’interprète. Maintenant, si votre syntaxe n’est pas correcte, le navigateur va tenter de deviner ce que vous avez voulu faire et va l’interpréter quand même. Mais vous n’avez pas rempli votre partie du contrat.

Si la page ne s’affiche pas correctement, c’est de votre faute, même si vous ne le savez pas forcément (en particulier si vous êtes Madame Michu). Comme votre navigateur va tout de même tenter de l’afficher comme il peut, vous allez devoir tester votre code sur tous les modèles du marché, puisque chacun vous corrigera à sa manière. En d’autres mots, l’interopérabilité devient la responsabilité de l’utilisateur (c’est d’ailleurs la même chose pour le langage C, mais pour des raisons à la fois semblables et différentes).

Maintenant, si HTML n’avait pas eu un parseur aussi laxiste, il n’y aurait pas une seule page au monde qui ne serait pas syntaxiquement parfaite, parce que tout le monde teste visuellement ses pages et se fout du reste :

J’écris ma page.
Je regarde ce que ça donne dans mon navigateur.
Ça compile ? On se casse !

Et on réessaie jusqu’à ce que ça ait l’air de fonctionner. Si cette itération incluait également la validation de la syntaxe HTML, personne ne se plaindrait. Personne ne râle parce qu’un compilateur remonte les erreurs de syntaxe (ça c’est à voir, ndt), mais sur le web, personne ne vous dit que vous avez corrigé vos erreurs.

En fait, la chose a un jour été essayée avec les langages de programmation. PL/I avait un parseur très laxiste, avec pour résultat que la majorité des programmes ne faisaient pas du tout ce que leurs concepteurs souhaitaient qu’ils fassent. Par chance, les autres langages de programmation n’ont pas suivi cette voie.

Pour un langage de programmation, le laxisme est une catastrophe. Pour une page HTML, c’est juste un désagrément, même si, avec Ajax, les choses pourraient s’améliorer si seulement vous saviez vraiment que le DOM était ce que vous pensiez qu’il est.

Les concepteur d’XML ont dit ne refaisons pas deux fois la même erreur, et si tout le monde avait été d’accord, les choses auraient marché. Mais sur le web, dès qu’un des joueurs décide de ne pas tenir sa promesse, ça se termine en course à l’armement, et tout le monde finit par redevenir laxiste. On a perdu une bonne occasion.

Cela dit, connaître les erreurs de syntaxe est toujours une bonne chose, même si le navigateur les corrige. Et je pense qu’une gestion des ferme des erreurs ne doit pas être aussi draconienne que certaines personnes aimerait que nous la pensions.

Je suis donc un supporter modéré du parsing stricte, tout comme je le suis avec les langages de programmation. Je veux que mon navigateur m’indique quand mes pages sont incorrectes, tout en corrigeant les erreurs des autres sur lesquelles je n’ai aucun contrôle de telle sorte que je puisse toujours les voir.

Il y a autre chose. Le monde ne se compose pas uniquement de navigateurs. Le parsing du XML est vraiment chose facile, tout comme il est simple de créer un parseur XML. Écrire un parseur HTML est beaucoup moins évident, à cause de tout le HTML pourri qui traîne ici et là. Si vous vouliez écrire un parseur HTML, il vous faudrait beaucoup de travail pour obtenir un résultat correct, comme j’ai pu le constater en observant certains projets de recherche.

Laissez-moi vous raconter une histoire. J’étais à une époque rédacteur en chef d’un magazine, et j’acceptais les articles dans n’importe quel format, car nous avions tout un tas de filtres d’importation vers le logiciel de publication que nous utilisions alors. Nous acceptions entre autres le HTML, et notre système d’import en corrigeait les erreurs comme il se devait. Une fois la version papier du magazine sortie, nous la publiions également sur le site. Un des auteurs me signala un jour que les liens contenus dans son article étaient incorrects, et me demanda de les réparer. Il s’avéra que notre système d’import avait réglé les problèmes de parsing d’une manière totalement différente de celle choisie par le navigateur. Il m’a fallu beaucoup de travail pour régler le problème.

Une autre fois, un des programmes de la chaîne de publication générait du HTML qui plus tard corrigé de telle sorte qu’il faisait planter le processus un peu plus loin. La seule solution fut d’arrêter la chaîne, récupérer la sortie d’un du programme fautif dans un fichier, l’éditer manuellement, puis l’injecter dans le logiciel suivant.

L’utilisabilité, c’est le fait de vouloir faciliter la vie des utilisateurs en simplifiant leurs tâches : les rendre plus rapides, exemptes d’erreurs, et agréables. HTML a totalement raté cette mission.

XHTML

XHTML devient pertinent le jour où l’on comprend que le monde ne se limite pas à un navigateur. Nombreux sont les producteurs de XHTML qui le font parce qu’ils génèrent une sortie en XML à un endroit de la chaîne, et qu’ils souhaitent pouvoir en récupérer également un peu plus tard. Leurs bases de données comprennent le XML, leurs chaînes de production génèrent et valident du XML, et le résultat final donne du XML, sous forme de XHTML. Ils veulent juste que votre navigateur affiche leur XHTML, puisque c’est ce qu’ils produisent. C’est la raison pour laquelle je pense qu’envoyer du XHTML en text/html. Tout ce que je veux, c’est que le XHTML soit affiché, sans que rien ne viennent casser le modèle de génération du HTML.

Mais il y a plus. Le but du XML est d’autoriser un design de balises distribué. Chaque bit du récit transmis dans le markup peut être conçu par des experts dans leur domaine : graphisme, mathématiques, multimédia, formulaires… Et il existe une architecture permettant à toutes ces parties d’être liées les unes aux autres.

SVG, MathML, SMIL, XForms etc… sont le résultat de cette conception distribuée. Et si quelqu’un tombait un jour sur une niche nécessitant un langage descriptif, il serait libre de le créer. C’est un processus réellement ouvert, et il existe des manières simples, ouvertes et clairement définies de le faire, et d’intégrer leurs balises à des systèmes existants. Un des problèmes aujourd’hui avec HTML5 est qu’il est conçu comme un bloc monolithique par des gens qui ne sont en aucun cas experts dans les domaines dans lesquels ils devraient l’être.

La raison pour laquelle nous avons besoin du XHTML est que les architectures XML ont besoin de la couche hypertexte pour se brancher les unes aux autres. C’est une erreur de compréhension que de penser que XHTML 1.* n’offrait aucune porte de sortie vers de nouvelles fonctionnalités. Ces nouvelles fonctionnalités étaient SVG, SMIL, MathML etc…

La meilleure concrétisation de cette architecture fut Joost (malheureusement disparu), qui combinait des pans entiers de ces technologies afin de créer un lecteur de télévision sur IP extrêmement complet, au point que vous ne vous rendiez même plus compte qu’il tournait dans un navigateur (en l’occurrence Mozilla).

Hors des intranets, de nombreuses sociétés utilisent cette architecture pour faire leur travail, avant d’en rajouter une couche afin de le rendre disponible aux navigateurs, créant au passage une fois de plus un résultat monolithique.

Ce que je prévois aujourd’hui, c’est l’avènement de bibliothèques Javascript XML, qui rendront disponibles les contenus XML dans les navigateurs. Ces derniers deviendront alors simplement des coquilles combinant moteurs de rendu et processeurs javascript. HTML deviendra alors l’assembleur du web. HTML ne satisfait plus les besoins du monde réel. Nous avons besoin d’un langage de balises de bien plus haut niveau.

En bref, nous avons besoin de XHTML parce que 1) les générateurs de XML en produisent naturellement, 2) il y a des gens qui tirent vraiment profit de l’architecture XML.

Tweetup Paris on social commere and the futur of social media

Thu, 21 May 2009 11:07:00 +0200

This is a translation of my french article Futur des média sociaux et social commerce au premier Tweetup Paris.

I enjoyed yesterday the first parisian Tweetup, held for the venue of Jeremiah Owyang, social computing analyst at Forrester. Tweetups are twitter users meetings, organized via twitter. This definitely had a taste of early bloggers meeting 6 years ago, or even IRC live meetings 10 years ago. The more connected you are, the more you want to meet people in real life.

Jeremiah did a quick summary of his presentation about the future of social media, followed by a series question and answer. And a drink.

When you spend 12 hours a day working on social media and social software, Jeremiah analysis may sound familiar, despite a definitely optimistic timeline. Commerce actors are not ready for social commerce, and I don’t think they will be in 2013. They will have to adapt to a new model where they don’t control the whole sale chain anymore. I even fear some reaction comparable to the record industry one: better stop innovation than change an outdated model.

The problem is even more acute in France, where controlling your brand image and message often turns to a form of paranoid obsession. Skittles turning its corporate website to a Twitter timeline in unthinkable here where no one is ready to let its consummer become their spokesmen. With the Martine cover generator case, Casterman (one of the major French youth publishing company) showed that it couldn’t handle a message coming from the crowd, but also a real fear and misunderstanding of media and way to communicate used since 5 or 6 years. Martine is a quite old fashion series of books, that was rejuvenated by the crowd. Casterman was unable to control its character new image, so they decided to shut everything down.

To conclude on social commerce, I’m still doubtfull with a total social commerce era as defined by Jeremiah. It’s too close of the old 1:1 personnalization dream at a time of mass production for costs reduction. it also implies that every node of a network is at the same time consummer, actor, whether or not they opt in, and prescriptor. It’s really having a high opinion of a crowd intelligence.

Last but not least, I’d like to conclude with a discussion I had with Fred Cavazza on how Facebook can use profile data for social commerce. I agree with him when he says this information are too vague and not enough to be really usefull. Most of them can be found on search engines, which lower their added value despite being ordered, tagged and easily searchable. So what? Facebook real value comes from contents sent by people on applications, walls: names, brands, opinions, people they really share with… That may one of the reason why Facebook tried to turn into some Twitter and Friendfeed like life stream: generating more and more up to date usable data.

Futur des média sociaux et social commerce au premier Tweetup Paris

Thu, 21 May 2009 00:39:00 +0200

Je sors un instant de la caverne dans laquelle je me terre depuis quelques temps pour vous parler du premier Tweetup Paris, organisé à l’occasion de la venue de Jeremiah Owyang, analyste es réseaux sociaux chez Forrester. Le tweetup est une rencontre entre utilisateurs de Twitter, généralement dans un bar, organisée par ce même canal de communication, qui profite du bouche à oreilles pour recruter ses participants. Pour votre serviteur, l’exercice avait un léger goût des premiers Paris Carnets, et autre rencontres de blogueurs il y a déjà 6 ans.

Jeremiah a profité de l’infrastructure de la Cantine pour nous faire une rapide présentation de l’avenir des média sociaux, suivie par une série de questions réponses destinées à lancer une conversation poursuivie autour d’un verre.

Si vous avez la tête dans les réseaux sociaux 12 heures par jour, l’analyse de Jeremiah peut sembler un peu convenue, malgré une timeline résolument optimiste. Les acteurs de la distribution ne sont pas encore prêts pour le social commerce, et je les vois mal s’adapter à un nouveau modèle dans lequel ils ne contrôlent plus toute la chaîne de consommation. Je crains au contraire une réaction semblable à celle de l’industrie du disque, qui préfère brider l’innovation technologique plutôt que remettre en cause un modèle dépassé.

La problématique est d’autant plus aiguë en France, où la maîtrise de l’image et du message par la marque tourne souvent à l’obsession paranoïque. L’initiative de Skittles qui a choisi de remplacer son site institutionnel par sa timeline Twitter, annonçant explicitement que leurs clients sont leurs meilleurs messagers est inimaginable dans un pays où le management ne s’imagine que de haut en bas. La réaction de Casterman au succès du générateur de couvertures de Martine il y a deux ans en est le parfait contre exemple. Faute de ne pas pouvoir contrôler le message autour d’un produit. On y verra également l’aveu explicite d’une grave impréparation à des modes de communication pourtant présents depuis 5 ou 6 ans.

Pour finir sur ce point, je reste dubitatif quant à l’avènement d’un social commerce dans sa forme extrême telle que nous l’a décrit Jeremiah. Ou du moins pas tout de suite, ne serait-ce que parce qu’il fait resurgir le vieux mythe éculé de la personnalisation en 1:1 à l’heure de la consommation de masse. Mais également parce qu’elle implique que chaque noeud d’un réseau est à la fois consommateur, acteur – volontaire ou non – et prescripteur, et c’est donner beaucoup trop d’importante à l’intelligence grégaire.

Enfin, je terminerai sur un échange eu avec Fred Cavazza sur les possibilités d’exploitation des données contenues dans les profils Facebook. Je suis parfaitement d’accord avec lui sur un point : les informations fournies dans les profils Facebook sont bien trop faibles pour faire mieux qu’un peu de taxinomie des utilisateurs en utilisant des données trouvables sur la majorité des moteurs de recherche, même si mieux classées, et n’apportent donc aucune valeur ajoutée. Les informations vraiment importantes sont celles que les utilisateurs laissent dans leurs interactions sur la plate-forme : opinions, citations de marques ou de lieux, préférences en termes de consommation ou d’habitudes… et c’est très probablement une des causes de l’orientation de Facebook vers le life stream : favoriser encore plus ces interactions, et la récupération de données véritablement exploitables.

Quand à moi, je vous laisse, et je retourne dans ma caverne, le temps de terminer un projet qui me tient particulièrement à coeur.

Modération des commentaires et problèmes de performances

Fri, 01 May 2009 06:00:00 +0200

Vous avez peut-être remarqué que, depuis quelques temps, les commentaires étaient modérés sur ce site, et qu’accessoirement, leur publication prenait beaucoup de temps. Typo ne parvenait tout simplement plus à joindre Akismet, le service anti spam que j’utilise afin de séparer le bon grain de l’ivraie dans les conversations. Une fois la durée de timeout atteinte, les commentaires étaient tout simplement placés en modération, ce qui est le comportement attendu ici en cas de panne d’Akismet.

J’ai trouvé la cause du problème un peu par hasard hier soir : mon DNS cache était tombé, et Typo ne parvenait tout simplement plus à résoudre akismet.com, ni aucun autre nom de domaines d’ailleurs. Et comme un bonheur ne vient jamais seul, j’ai mis à jour la version de Bluecloth utilisée sur Typo. Autrefois écrite en Ruby, celle-ci repose maintenant sur un parser développé en C, donc beaucoup plus rapide. Résultat : moins de 2 secondes pour générer et afficher une page avec une quarantaine de commentaires, laquelle est également placée dans un cache statique pour ne pas avoir à être régénérée.

Le dernier sprint meeting d'Hitler, chef de produits agile

Thu, 30 Apr 2009 06:00:00 +0200

Beaucoup de projets informatiques connaissent un échec retentissant parce qu’à un moment clé, une des parties a eu un énorme coup de flemme et a choisi de contourner la difficulté… par exemple en désactivant le lancement des tests unitaires dans le processus d’intégration continue, histoire de ne pas avoir à réparer ceux qui plantent. C’est exactement ce qui arrive à Hitler, reconverti dans le rôle de chef de produit agile dans un énième détournement de la scène principale du film La Chute. À hurler de rire.

Et si l’intégration continue vous intéresse, je vous recommande la lecture de cet article autrement plus sérieux sur le déploiement de Cruisecontrol.rb + git sous Mac OS X.

Et si vous arrêtiez un peu de faire des sites optimisés pour iPhone ?

Wed, 29 Apr 2009 06:00:00 +0200

Pourquoi concevoir des sites spécialement optimisés pour iPhone ? Il fait l’effort d’offrir un véritable Safari, en rien affecté par les limitations des navigateurs de la très grande majorité des smartphones, et gère donc parfaitement les sites non mobiles. C’est du moins ce que pense Bradly Feeley dans un coup de gueule poussé en février dernier contre ceux qui n’ont visiblement rien compris à l’iPhone, c’est à dire, par extension, au web mobile.

If you want an iPhone specific interface for your site, write an iPhone App. But if I’m using Safari, please just give me what I want– a full functioning site that I’m familiar with and has what I am expecting.

À première vue, la diatribe de Bradly peut paraître relativement juste. Je crois pourtant qu’il est totalement à coté de la plaque – comme ça c’est dit – quelles que soient par ailleurs ses préférences.

Je passerai rapidement l’existence d’une application Facebook, en sus de la version mobile du site, citée comme exemple de son courroux, tout comme il existe de nombreux clients Twitter pour iPhone, souvent bien plus complets que le site original par ailleurs. La raison d’être de la version iPhone d’une application web et d’une application iPhone pour un service web sont aux antipodes l’une de l’autre. C’est bien simple : la première est conçue pour une utilisation online, l’autre pour une utilisation offline – avec ou sans synchro – et l’expérience utilisateur de l’une et de l’autre sont donc censées être sensiblement différentes.

Tout comme l’expérience utilisateur de Safari sur iPhone est sensiblement différente de celle que l’on peut avoir sur un iMac 24 pouces, n’en déplaise à Bradly Feeley. Il suffit de voir la différence de taille entre les deux écrans, mais également la différence entre les périphériques de pointage. Un doigt est beaucoup moins précis qu’un pointeur de souris, tout comme il est beaucoup plus simple d’écrire un pavé sur un clavier traditionnel que sur celui d’un smartphone. On peut d’ailleurs y voir une des raisons du succès de Twitter sur les applications mobiles, au delà de l’usage même du service qui y est totalement adapté. Malgré la puissance d’un Safari pour iPhone, que ce soient en termes de support des applications web modernes ou d’adaptation des pages à la taille de l’écran, on ne peut décemment utiliser correctement un site ou une application web destinée à un écran au moins trois ou quatre fois plus grand, utilisant un clavier et une souris traditionnels.

Je rejoindrai pourtant Bradly Feeley sur un point. Par pitié, cessez de sortir des versions bâclées ou diminuées de vos applications sous le simple prétexte que vous les destinez à un terminal mobile. Que vous supprimiez certaines fonctionnalités strictement incompatibles avec les usages du web mobile est cependant tout à fait compréhensible, mais le problème ne vient le plus souvent pas de là.
Tout comme je trouve aberrant de vouloir porter à l’identique et sans réflexion d’usages préalable une application métier desktop vers le web, au risque de passer à côté de nombreuses évolutions possibles permettant de gagner en productivité, il est stupide de vouloir porter un site web vers les terminaux mobile en en diminuant simplement la résolution, quitte à couper les branches gênantes. C’est pourtant beaucoup plus simple, et beaucoup moins coûteux, que d’étudier des usages nouveaux, et accepter de se repenser afin de s’adapter à un environnement différent, avec au bout, un risque de fiasco certain.

Via Julien.

Coup de peinture printanier 2009

Thu, 23 Apr 2009 16:30:00 +0200

En attendant d’avoir un vrai design digne de ce nom, j’ai profité de mes quelques heures d’avion et d’attente à l’hôtel pour donner un petit coup de peinture au design de ce site, qui en est donc à sa troisième déclinaison en un an et demi. Rien de fondamental cela dit, même si le travail en back a été beaucoup plus important qu’il n’y parait.

True blue version 1.

t37.net/

True blue version 2.

t37.net/

True blue version 3.

Si vous utilisez Typo, le moteur de en Ruby on Rails, vous serez peut-être intéressé par les sources du thème, qui montrent ce qu’on peut faire de plus avancé en termes de templating Typo.

Avec ses profils, Google met un pied de plus dans le web social, l'autre dans la recherche de personnes

Wed, 22 Apr 2009 07:42:00 +0200

Si vous n’avez pas encore rempli votre profil Google, il serait peut-être temps de le faire, tant la dernière fonctionnalité de l’omni ~~président~~ moteur de recherche fait parler d’elle dernièrement. Ce n’est pourtant pas la première fois que Google se lance dans le web social, et nombre d’entre nous ont fait leurs premières armes sur Orkut, peut-être la première expérience de réseau social digne de ce nom.

La création d’un profil Google prend quelques secondes si vous disposez déjà d’un compte Google, quelle qu’en soit l’utilisation que vous en faites. L’interface est sobre et épurée, comme d’habitude, et va à l’essentiel. Mais ce n’est pas – pour une fois – ce qui a retenu mon attention.

Je ne vous insulterai pas en vous expliquant combien il est aujourd’hui important de bien gérer son identité sur Internet, ni que vos futurs employeurs risquent de vous chercher sur Google avant même de lire votre CV, et si Google ne met pas encore les profils en avant dans la recherche, il n’y a pas de raisons pour qu’il ne le fasse pas à court terme, tout étant probablement une question de masse critique d’information à atteindre. On remarquera au passage que le scope des informations demandées dans le profil Google n’est pas innocent, et permet la création d’un graphe social hors Internet, aujourd’hui lâche, mais là encore je pense que nous n’en sommes qu’au début.

Évidemment, et malgré leur taille et leur ancienneté, j’en connais quelques uns à l’arrivée de ces profils doit faire grincer les dents. Ne citons pour rester entre francophones que l’ancêtre Copains d’Avant, qui trust les premiers résultats de recherche pour la plupart des gens “normaux”, et définit au passage pour eux leur identité numérique, même si les profils publics de Facebook ont déjà commencé à saper leurs fondations. Quant à moi, je vous laisse, on me souffle dans l’oreillette que la plage risquerait bien de ne pas m’attendre.

Retrouvons-nous à Tel Aviv du 19 au 27 avril

Fri, 17 Apr 2009 19:00:00 +0200

J’arrive lundi à Tel Aviv pour une semaine de vacances au soleil bien méritées. J’en profiterai également pour rencontrer pas mal de monde sur place, alors si vous avez envie de me rencontrer histoire de prendre un café, ou plus si affinités, vous pouvez me contacter via les moyens habituels :

Téléphone : +33 6 62 19 1337
Skype : fdevillamil
Twitter : fdevillamil

Si vous êtes à Bordeaux ce week-end, et que vous voulez prendre un verre dimanche avant que je ne prenne mon avion, c’est également possible.

7 euros de réduction sur la version papier de 5 Simple Steps To Webdesign

Tue, 14 Apr 2009 06:00:00 +0200

Si vous n’avez pas encore commandé l’excellent 5 Simple Steps A Practical Guide to Designing For The Web, je vous propose de vous rattraper en profitant d’une réduction de 7 euros sur la version papier.

Pour gagner, il vous suffit d’être les deux premiers à vous signaler dans les commentaires. Je vous ferai alors parvenir le code qui vous donnera droit à une réduction de 6 Livres Sterling lors de votre commande à partir de mardi 12 heures.

Skype et iPhone, histoire d'une intégration réussie

Wed, 08 Apr 2009 06:00:00 +0200

L’annonce de la disponibilité de Skype sur iPhone m’a, pour ainsi dire, touché l’une sans faire bouger l’autre, et contrairement à Fabrice Epelboin, je ne crois pas qu’elle ait sonné comme un coup de tonnerre dans le landerneau des opérateurs téléphoniques, bien qu’elle ait de quoi leur donner des raisons de s’inquiéter à long terme. Ça ne m’a pas empêché de l’installer sur mon iPhone dès cette dernière disponible sur l’Apple Store. Et pour cause, le portage d’une application desktop aussi riche fonctionnellement sur une plate-forme mobile, aussi évoluée soit-elle, relevait de la gageure, et le défi s’annonçais passionnant.

Skype pouvait-il réussir son passage à la mobilité sans perdre en fonctionnalités, ou allait-on nous servir une énième application inutilisable à force de vouloir reproduire un existant sans s’adapter ? Et surtout, qu’en était-il de l’intégration de Skype dans l’iPhone ? C’est ce que vous saurez dans le prochain épisode. Don’t miss it!.

Mais sans plus attendre une page de publicité.

Ça vous fait rire Pub-Pub ?

Skype a fait un réel effort d’intégration de son application dans l’iPhone, tout particulièrement dans la gestion des contacts.

Lors de l’ajout d’un nouveau contact, Skype propose 3 options :

Chercher dans l’annuaire Skype.
Ajouter manuellement un numéro de téléphone.
Chercher dans les contacts iPhone.

Skype vous donne alors accès au répertoire de contacts de l’iPhone, dans lequel vous pourrez choisir votre nouveau correspondant.

Vous pouvez dès lors ajouter votre nouveau contact à votre listing Skype. Bluffant d’intégration.

La même intégration a été faite au niveau des appels téléphoniques. L’interface ressemble particulièrement à celle de votre téléphone habituel, avec la présence de votre répertoire de contacts en bas à gauche.

Et là, ô surprise, les contacts Skype natifs sont mélangés à votre répertoire de contacts téléphoniques, vous permettant de choisir entre les deux avant d’appeler votre correspondant.

J’avais initialement prévu d’effectuer une revue complète de Skype pour l’iPhone. J’ai finalement préféré m’orienter sur les points les plus marquants de son intégration. Skype pour iPhone est une application bluffante, et son intégration au sein de l’écosystème de l’iPhone justifie le temps qu’il nous a fallu attendre. Je suis maintenant impatient de voir le travail réalisé par Skype sur le Blackberry, ce qui vaudra certainement un article comparatif.

20 mauvaises pratiques de développement quand on développe avec Ruby on Rails

Tue, 07 Apr 2009 06:00:00 +0200

Le 30 mars, Chad Fowler a demandé sur Twitter Rails programmers: what’s an example of one thing you find in other people’s Rails code that you (almost) always consider to be wrong?. Les réponses ont fusé, donnant une liste de 20 mauvaises pratiques à destination des développeurs Ruby on Rails, mais également de tous ceux qui développent avec un framework MVC.

Quelles sont ces 20 mauvaises pratiques ?

Le code dans les vues (je plussois).
L’indentation avec des tabulations au lieu d’espaces, et les erreurs d’indentation.
Les tests absents, ou non pertinents.
La mauvaise utilisation des associations polymorphiques et de l’héritage simple.
La gestion d’exception à l’arrache.
Les assignations accidentelles de variables locales.
Le code qui entraîne des avertissements de la part de Ruby.
Le code qui utilise les fonctionnalités de Rails :-)
La mauvaise utilisation de validates_uniqueness_of.
Le code mis au mauvais endroit (du HTML dans le contrôleur, les requêtes SQL dans les helpers…)
Les fichiers de configuration contenant leur propre définition d’environnement.
Trop de code, surtout pour faire quelque chose de simple.
Bidouiller $LOAD_PATH.
La logique obfusquée.
Insérer des données dans les migrations (là, je ne suis pas d’accord).
L’envoi de données dans des requêtes GET. Ce point est cependant à nuancer.
Ne pas utiliser de transactions.
La mauvaise utilisation du Javascript, comme le Javascript bloquant.
Les méthodes trop longues.
Les commentaires trop verbeux.

Je rejoins la plupart des éléments énoncés dans ce sondage, et cela fait partie des travers dans lesquels j’essaie de ne pas tomber. Et vous, qu’en pensez-vous ? Tombez-vous souvent dans un de ces pièges ? Voyez-vous d’autres mauvaises pratiques qui pourraient rejoindre cette liste ?

Contentez-vous de développer cette application et de nous la livrer !

Mon, 06 Apr 2009 06:00:00 +0200

Combien de vos clients sont arrivés chez vous la gueule enfarinée en annonçant “Nous savons exactement quel logiciel il nous faut. En voici les prérequis, et les spécifications détaillées. Contentez-vous de le développer, le tester, et nous le livrer dans les temps”. C’est, semble-t-il, l’expérience vécue à plusieurs reprises par Abhijit Nadgouda, qui nous en fait part dans un coup de gueule incisif.

Il est quelque part normal que les clients aient l’impression de savoir ce qu’ils veulent, et je trouve ce reflex plutôt sain. Cela signifie tout simplement qu’ils ont un problème, et qu’ils ont fait le tour de la question avant de proposer une solution qui leur semble adéquate. Ils arrivent généralement avec deux tonnes de documents, souvent faits sous Excel, pleins d’études de cas, solutions et ROI à l’appui. Tout ce qu’ils vous demande après tout, c’est de développer leur outil, de le tester, puis de le livrer. Ils se sont chargés de la conception de A à Z, ce qui permet de gagner à la fois du temps, et de l’argent.

C’est peut-être là que le bat blesse. Bien que cette démarche semble pleine de sens et de bon sens, elle méconnaît quelques règles fondamentales du développement logiciel, et renvoie le côté technique au rang de simple variable d’ajustement ©, en rejetant le fait que la solution choisie puisse avoir un impact fondamental dans la résolution des problèmes à traiter.

De nombreux clients sont en décalage total avec l’évolution du monde du logiciel, quelles qu’en soient les raisons : manque d’intérêt ou de sang neuf au SI, attachement à une solution fermée sans possibilité de connexion externe… Si l’on s’en tient au seul domaine de la publication en ligne, ces derniers subissent un électrochoc culturel quand ils se heurtent aux solutions de publication modernes, au web participatif… Certaines clients revoient leur copie, en intégrant les solutions du moment à leurs besoins métiers, perdant ainsi beaucoup de temps, et d’argent. D’autres, au contraire, restent sur leurs position et leur culture, passant à côté d’un important retour sur investissement.

Abhijit Nadgouda définit le développement logiciel comme l’action de trouver une solution à un problème en y intégrant tous les enjeux de manière adéquate. Ce qui commence évidemment par identifier les problèmes et les enjeux. Bien souvent, en se focalisant sur la réponse à une seule question, les spécifications apportées par le client passent à coté de ces enjeux, et l’application en résultant est souvent un échec total.

Là où mon avis diverge de celui d’Abhijit Nadgouda, c’est sur les raisons qui mènent à un tel échec. Abhijit Nadgouda met en avant le manque de confiance du client envers son prestataire. Conserver un contrôle total sur la conception doit lui éviter de “se faire avoir” par un prestataire qui possède une maîtrise technologique qui lui échappe. Je ne pense pas que ce soit la principale raison, les outils développés en interne souffrant la grande majorité du temps de cette problématique. J’ai travaillé sur suffisamment d’outils métiers pour me rendre compte de la difficulté d’allier approche métier globale, culture du client, et expertise du développement logiciel chez une seule personne. D’où, peut-être, la méfiance mise en avant par Abhijit Nadgouda, mais également les erreurs commises par les deux parties, faute d’avoir pu englober la totalité du problème. Toute la difficulté pour le prestataire sera alors d’appréhender totalement le métier de son client, et sa manière de travailler, tout en lui montrant en quoi les solutions techniques disponibles vont répondre à ses problèmes, chacun profitant ainsi de cet échange de savoir.

Et vous, vous êtes-vous déjà retrouvé confronté à ce type de situation ? Comment avez-vous réagi ? Comment vous en êtes-vous sorti ?

Ergonomie web, Ruby on Rails et Architecture de l'information :

Arrêtez de masquer les mots de passe !

Une double question de sécurité

Une nouvelle implémentation nécessaire

À lire également

Projets collaboratifs en entreprise : vous savez pourquoi ? Demandez-vous maintenant comment

À lire également

Une vidéo publicitaire percutante pour Internet Explorer 8

À lire également

Analyse d'une usine à spam déguisée en application virale : two tweets and a lie

À lire également

Windows 7 livré sans Internet Explorer nous renvoie 15 ans en arrière pour pas grand chose

À lire également

Une balise NSFW dans HTML5 ? Mais WTF ?

À lire également

Lifestream, real time web, et le retour de l'infobésité

Le portail, une architecture hyper hiérarchique

Les blogs, entre timeline et étiquetage

Les wikis

Le lifestream

À lire également

Pourquoi choisir XHTML, par Steven Pemberton du W3C

Le parsing

XHTML

À lire également

Tweetup Paris on social commere and the futur of social media

À lire également

Futur des média sociaux et social commerce au premier Tweetup Paris

À lire également

Modération des commentaires et problèmes de performances

À lire également

Le dernier sprint meeting d'Hitler, chef de produits agile

À lire également

Et si vous arrêtiez un peu de faire des sites optimisés pour iPhone ?

À lire également

Coup de peinture printanier 2009

À lire également

Avec ses profils, Google met un pied de plus dans le web social, l'autre dans la recherche de personnes

À lire également

Retrouvons-nous à Tel Aviv du 19 au 27 avril

À lire également

7 euros de réduction sur la version papier de 5 Simple Steps To Webdesign

À lire également

Skype et iPhone, histoire d'une intégration réussie

À lire également

20 mauvaises pratiques de développement quand on développe avec Ruby on Rails

À lire également

Contentez-vous de développer cette application et de nous la livrer !

À lire également