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

Un tremblement de terre vient de secouer Los Angeles, et une fois de plus, les outils de microblogging comme Twitter ont permis de suivre en direct non seulement les événements, mais également le feedback à chaud de ceux qui les ont vécu.

En effectuant mon petit bout de veille quotidienne, je suis tombé par hasard sur ce qui pourrait bien être la pire interface utilisateurs de tous les temps, et ce n’est pas peu dire.

La majorité des outils de blog modernes viennent avec un système de permaliens soi-disant optimisés pour les moteurs de recherche permettant de retrouver un contenu dans une URL de manière relativement explicite.

À un schéma d’URL du type http://monsite.com/index.php?p=42 s’est substitué un schéma désormais plus classique du genre http://monsite.com/articles/année/mois/jour/titre-du-billet nettement plus explicite, aussi bien pour les lecteurs que pour les outils de recherche.

Il y a un an ou deux, je lisais un article sur lequel je n’ai malheureusement pas réussi à remettre la main, mais que son auteur aurait pu appeler User generated content killed the information architecture stars s’il avait seulement eu un peu d’humour, ou simplement de culture musicale. Il y défendait la thèse de la mort de l’architecture de l’information, achevée par l’anarchie auto régulée du contenu généré par l’utilisateur.

L’information, créée et auto modérée par l’action aveugle et déterministe de la foule intelligente devait générer d’elle-même son architecture propre, adaptative, et perpétuellement changeante, stabilisée par le modèle de la longue traîne. Merci de bien vouloir me donner une autre grille de buzzword bingo, la mienne s’est remplie plus vite que prévue.

Putain, 5 ans déjà, aurait soupiré la caricature de Jacques Chirac aux Guignols de l’info. 5 ans que j’ai balancé mon premier billet sur la toile, sans imaginer tout ce qui m’arriverait grâce et à cause de mes blogs. J’ai beau chercher, et je ne me rappelle pas que mes premiers sites, ouverts à l’été 96, m’aient autant apporté, énervé, fait sourire ou pleurer. Par manque d’interactions, certainement, parce que le format ne s’y prêtait pas, mais pas seulement.

Nan, je déconne… tout sauf ça.

Après cinq mois de travail, deux bêta, six-cent litres de Red Bull©, et douze kilos de pâtes de fruits Foucher, Typo 5.1 « Cartier Bresson » est enfin disponible. Cette nouvelle version majeure, autant par ses fonctionnalités que sa qualité apporte un très grand nombre de nouveautés ainsi qu’une stabilité retrouvée. Elle annonce également – je l’espère – un rythme de sorties plus soutenues, la prochaine étant d’ors et déjà prévue pour le 31 août, c’est à dire dans à peine 40 jours.

Mais sans plus attendre, passons à la liste des nouveautés.

Si comme moi vous possédez un iPhone première génération jailbreaké et désimlocké, que ce soit parce que vous ne pouviez pas attendre la sortie officielle ou pour profiter des applications tierces, peut-être êtes-vous frustré de ne pouvoir profiter des nouveautés de l’OS fourni avec l’iPhone 3G. Qu’à cela ne tienne, la dev team a travaillé pour vous et a sorti hier le Pwnage tool, qui permet de s’attaquer aux iPhones et iPhone 3G – malheureusement sans desimlockage – mais également aux iPod Touch.

Finie la ligne de commande et les manipulations compliquées, cette fois tout se fait nativement en graphique et en quelques étapes.

La phrase du jour (un peu vieux, mais quand même) :

Saying “Rails doesn’t scale” is like saying “my car doesn’t go infinitely fast”. Alternatively, saying “We’ll have no problems scaling because we’re using Django” is like saying “I will win every race because my car is the most powerful”. Maybe so, but you suck at driving, and you’re up against professionals.

If you’re having scalability problems and blaming it on a single technology, chances are, you’re doing it wrong.

Shut up about scalability, no one is using your app anyway.

En termes de planification, la maintenance évolutive d’un projet web est toujours la plus délicate à mettre en place. D’abord parce qu’elle ne participe pas du cycle de développement normal de ce dernier, mais de son cycle d’exploitation, elle risque donc interférer avec celui-ci. Ensuite parce qu’elle fait souvent participer de nombreux intervenants de culture différente, aux intérêts parfois divergents au sein d’une même structure. Enfin parce qu’elle répond souvent à des impératifs extérieurs qui la rendent difficile, sinon impossible à planifier.

Après confier la maintenance de ses projets web et Les cycles de maintenance collective, ce troisième volet de notre série sur la mise maintenance des projets web vous invite à vous intéresser à la maintenance évolutive.