Arrêtez de masquer les mots de passe !
le 28/06/2009 à 19h45
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
le 26/06/2009 à 22h24
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.
Article original écrit par Frederic de Villamil et publié sur Ergonomie web, Ruby on Rails et Architecture de l'information | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie web, Ruby on Rails et Architecture de l'information, c'est qu'il a été reproduit illégalement et sans autorisation.
Une vidéo publicitaire percutante pour Internet Explorer 8
le 25/06/2009 à 22h47
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.
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.
Analyse d'une usine à spam déguisée en application virale : two tweets and a lie
le 20/06/2009 à 22h26
À 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.
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.
Windows 7 livré sans Internet Explorer nous renvoie 15 ans en arrière pour pas grand chose
le 13/06/2009 à 9h05
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 ?
Article original écrit par Frederic de Villamil et publié sur Ergonomie web, Ruby on Rails et Architecture de l'information | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie web, Ruby on Rails et Architecture de l'information, c'est qu'il a été reproduit illégalement et sans autorisation.
Une balise NSFW dans HTML5 ? Mais WTF ?
le 10/06/2009 à 1h45
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:
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<nsfw><a href="http://www.example.com">Pics here!</a></nsfw> <nsfw><img src="badkitten.jpg"></nsfw>h2à unp
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 detddes 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 balisevideo, dont je ne suis pas fan, mais qui a un sens vus les usages actuels,nsfwn’apporte rien en termes de structure. Une balisensfwaurait 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 balisensfwva donc introduire une notion de valeur morale, et à ce titre, elle n’a strictement rien à faire dans HTML. Via Jeffrey Zeldman.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.
Lifestream, real time web, et le retour de l'infobésité
le 08/06/2009 à 7h27
À 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.
Article original écrit par Frederic de Villamil et publié sur Ergonomie web, Ruby on Rails et Architecture de l'information | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie web, Ruby on Rails et Architecture de l'information, c'est qu'il a été reproduit illégalement et sans autorisation.
Pourquoi choisir XHTML, par Steven Pemberton du W3C
le 02/06/2009 à 21h07
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.
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.
Tweetup Paris on social commere and the futur of social media
le 21/05/2009 à 11h29
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.
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.
Futur des média sociaux et social commerce au premier Tweetup Paris
le 21/05/2009 à 1h07
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.
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.
Modération des commentaires et problèmes de performances
le 01/05/2009 à 6h24
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.
Article original écrit par Frederic de Villamil et publié sur Ergonomie web, Ruby on Rails et Architecture de l'information | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie web, Ruby on Rails et Architecture de l'information, c'est qu'il a été reproduit illégalement et sans autorisation.
Le dernier sprint meeting d'Hitler, chef de produits agile
le 30/04/2009 à 6h46
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.
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.
Lire tous les avis (0) / Poster votre avis