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

Dans le cas où vous seriez de nationalité français, majeur, titulaire de vos droits civiques, que vous n’auriez pas été irresponsable au point de ne pas aller vous inscrire dans votre mairie avant le 31 décembre 2006 et que vous ne seriez pas déjà sorti de chez vous depuis ce matin, merci de bien vouloir fermer votre explorateur ou votre agrégateur afin de vous rendre dans le bureau de vote le plus proche.

N’étant pas un blogueur influent (mouahahahaha kikooolol) je ne me permettrai pas de vous donner de consignes de votes, ni de vous proposer de vous accompagner jusqu’à la porte de l’isoloir pour être certain de vous voir voter pour le bon candidat. Mais par pitié, votez. Dans le cas où vous vous abstiendriez pour quelque raison que ce soit, vous perdriez de fait tout droit à récriminer contre un président à l’é[le|vi]ction duquel vous n’auriez pas participé.

Ceci était un message à caractère civique. Tout de suite, la reprise de notre programme habituel.

On n’est jamais mieux servi que par soi-même, dit le proverbe. Aussi, afin de remplacer Photostack vraiment trop limité et brouillon ai-je décidé de développer ma propre galerie d’images, mais vite (et bien), car je n’ai pas vraiment que ça à faire.

En termes de fonctionnalités, je compte partir sur des bases simples, que j’améliorerai au fur et à mesure.

• De multiples galeries.
• La prise en charge du redimensionnement des images.
• La création automatique de vignettes.
• Un slideshow qui permette aux visiteurs de faire défiler l’ensemble d’une galerie sans aucun effort.
• Un flux XML pour du RSS ou de l’atom.

Pour le côté technique, j’ai dit vite – le temps d’avaler un plat de sushi – et propre. Cela exclue donc forcément PHP, au profit de Ruby on Rails. Maintenant, on fait comme dans la chanson, on monte sur les tables, on lève les bras bien haut, allez c’est parti !

Création de l’application

Nous commençons par créer une nouvelle application Rails.

Et pour fêter ça, j’attrape un premier sushi à l’oursin. Miam !

Ajout des galeries

Nous créons maintenant tout ce dont nous avons besoin ajouter, parcourir, modifier et supprimer des galeries.

Notre galerie possédera les attributs suivants :

• Un titre.
• Une description.
• Un état (en ligne / hors ligne).
• Une position.

Nous avons utilisé les fonctionnalités de génération automatique de Rails. Elles nous permettent maintenant de disposer de :

• Le formulaire de création et de modification de notre galerie /galleries/new.
• L’affichage HTML (sommaire) de notre galerie: /galleries/1.
• Un flux XML, for fun and profit : /galleries/1.xml

Aurais-je omis de dire que l’application est RESTful ? Oui ? Comme c’est dommage. Je vais donc noyer mon chagrin dans un second sushi, au saumon cette fois.

Ajout des images

Il nous manque le plus important : l’ajout et la visualisation des images. Comme précédemment, nous allons laisser Rails travailler pour nous et générer tout ce dont nous avons besoin, ou presque.

Nos images auront pour attribut :

• Une galerie parente. Nous créerons le menu déroulant plus tard.
• Un nom de fichier.
• Une vignette.
• Un sushi aux oeufs de saumon.
• Un poids en ko.
• Une hauteur en pixels.
• Une largeur en pixels.
• Une position.
• Un titre.
• Une description.
• Un état (en ligne / hors ligne).

Gestion de l’upload et du redimensionnement

Pourquoi faire compliqué et réinventer la roue quand on peut faire simple et laisser les autres travailler pour soi ? Je vous propose donc d’installer le greffon attachment_fu, et de manger un sushi à l’anguille fumée avant qu’il ne soit complètement froid.

C’est fait, il ne nous reste plus qu’à lier les briques ensemble.

Dans app/model/gallery.rb

Nous spécifions la relation entre les galeries et les images : à une galerie correspond plusieurs images.

Et ligne 18 :

Il s’agit du champ correspondant à l’image que notre greffon s’attend à recevoir. Ne le décevons pas.

Dans app/model/picture.rb

Nous appelons notre greffon avec toutes les informations dont il a besoin :

• Nous stockons nos images sur le disque local. Nous pourrions aussi le stocker sur le service S3 d’Amazone de manière totalement transparente.
• L’image fera maximum 500 ko.
• Elle sera redimensionnée en 600*450 pixels.
• La vignette fera 120*90 pixels.

Dans app/views/pictures/new.rhtml ligne 5

Tout ça m’a donné faim. Et vous ?

Dans app/vews/galleries/show.rhtml

L’affichage plein écran et le slideshow

Une fois de plus, pas question de réinventer la roue quand d’autres le font pour moi. Nous nous en allons donc faire un tour du côté de chez Xuan et télécharger Splash Image, un script clica convi qui remplace avantageusement Lightbox sans nécessité 2go de RAM. Et pourquoi ne pas manger un sushi au thon tant qu’on y est ?

wget http://www.chez-xuxu.net/ressources/javascript/splash.image/splash.image.zip

Nous décompressons l’archive dans public/javascripts, et faisons les inclusions qui vont bien.

Dans app/views/layout/galleries.rhtml

Dans app/vews/galleries/show.rhtml

Nous remplaçons la ligne précédemment ajoutée par celle-ci :

Elle nous permet de grouper les images de cette galerie et de les faire défiler en pleine fenêtre comme si de rien n’était.

Conclusion

Voilà, c’est fini, ou presque. Il ne me reste plus qu’à ouvrir mon plat de maki et à nettoyer tout ça. Certes, ce n’est pas bien joli, mais ça marche. Je vais faire un peu de nettoyage dans le code, rajouter une feuille de style correcte, et mettre les sources sur un subversion afin que vous puissiez récupérer tout ça. Merci beaucoup à Bastien pour m’avoir montré le plugin upload_fu et avoir supporté mes blagues vaseuses toute la journée.

Vendredi, nous ajouterons une authentification basique, l’upload de masse depuis un système de fichier ou un ftp, les jolies URL search engine friendly et les tags le temps de nous siffler une ou deux pintes de Guiness que vous aurez eu la gentillesse de m’offrir par SMS comme il se doit.

[Edit] J’ai mis une démonstration du résultat final en ligne. Elle est accessible sur 20 minutes gallery et la démonstration est totalement fonctionnelle.

Ceci est la traduction de The futur of Typo sidebar plugins, billet que j’ai publié en anglais sur le nouveau blog officiel de Typo.

Entre les versions 4.0 et 4.1, l’architecture des greffons de Typo a connu un profond bouleversement. Ces derniers ont été réécrit afin de se conformer au fonctionnement des greffons Rails. Il est désormais possible de les installer via script/plugin install {#PLUGINSOURCEURI}. Le but était de déplacer un certain nombre de greffons du coeur de l’application vers un dépôt officiel.

Pourquoi cela ? Après tout, plus un outil possède de fonctionnalités, mieux c’est, non ? Pas toujours, et voici pourquoi :

• Typo est lourd par rapport aux fonctionnalités qu’il propose. Le grand nombre de greffons présents en est une des causes.
• Chaque fois qu’un service change son API, les utilisateurs des greffons doivent attendre la version suivante de l’application. Ce ne sera désormais plus le cas. Nous modifierons le greffon, et les utilisateurs n’auront qu’à le mettre à jour.
• Il y a beaucoup trop de redondance. Je doute que les gens utilisent à la fois Magnolia et Delicious. Et je me demande combien de gens utilisent VRAIMENT le plugin Xbox Live.
• Nous souhaitons donner plus de visibilité aux auteurs d’extensions. La mise en place d’un annuaire et d’un dépôt officiels nous aideront à aller dans ce sens.

Nous garderons cependant un certain nombre de greffons au coeur de l’application :

• Archives. Ce greffon sera activé par défaut dans l’installation de base.
• Amazon. Cela peut sembler étrange, mais ce greffon est le meilleur exemple dont nous disposions d’interaction entre un filtre texte et un greffon.
• Catégories. Ce greffon sera activé par défaut dans l’installation de base.
• Derniers commentaires.
• Espace statique. Ce greffon sera activé par défaut dans l’installation de base avec la liste des contributeurs de l’application.
• Tags.
• Syndication XML. Ce greffon sera activé par défaut dans l’installation de base.

Nous allons entamer le déplacement des greffons ce soir, en commençant par Audioscrobbler et Xbox Live. La migration complète se fera pas à pas avant la prochaine version de l’application. Nous avons conscience que cela risque de casser les blogs utilisant le trunk, à commencer par le mien, et que certaines personnes risquent de s’en plaindre. Cela ne servira à rien de râler : vous utilisez le trunk à vos risques et périls.

On vient de me signaler que le quotidien gratuit 20 Minutes m’avait inclus dans le classement ”Top 50 Tech et Média” de son numéro du 10 avril 2007.

Non pas que cela m’en touchât une sans faire bouger l’autre, mais mais je vous préviens tout de suite, maintenant les interviews, c’est une pinte (par texto si vous n’êtes pas à Paris) minimum. Aujourd’hui 20 Minutes, demain la Creuse Active, et dans une semaine le Washington Post ?

Vous avez développé une petite application pour vos propres besoins, par exemple un outil de publication en ligne. Des gens l’ont remarquée et ont commencé à s’y intéresser, au point que vous la publiiez sous une licence quelconque, pour le plus grand bien de la communauté. Et un jour, ce qui allait très bien pour une seule personne ne suffit plus, et vous décidez de franchir le pas : rendre votre application multi utilisateurs. Belle initiative, mais par où commencer ?

Quels utilisateurs ?

Commencez par remettre à plat l’ensemble des fonctionnalités de votre outil. Recensez chacune d’entre elles et classez les par groupe en fonction des utilisateurs “type” qui seront amenés à les utiliser.

Dans notre cas, nous séparons les fonctionnalités de l’application en 3 groupes distincts :

L’administration

• La configuration.
• Le paramètrage du thème.
• La sélection des greffons.
• La gestion des utilisateurs.

La publication

• La gestion / publication des billets.
• La gestion des catégories.
• La gestion des média.
• La modération des commentaires.

La contribution

• Ajout de commentaires.

Et voilà, nous avons défini 3 profils types, et défini leurs attributions possibles. Nous aurions pu en définir plus, par exemple un rédacteur qui aurait des droits d’écriture mais pas de publication, ou un modérateur pour les contributions qui n’aurait pas de droits en écriture, mais nous choisissons la simplicité. Reste maintenant à l’implémenter dans notre application, et là, deux choix s’offrent à nous.

Implémentation par profils

L’implémentation par profils est la plus simple à mettre en oeuvre, au détriment de la souplesse. On attribue un profil à chaque utilisateur, puis, pour chacune des actions possibles, on contrôle le profil de l’utilisateur, et on agit en conséquence. Pour cela, on va créer 3 méthodes, vérifiant que l’utilisateur dispose bien du profil voulu :

Vous remarquerez que pour chaque profil inférieur, on vérifie également que l’utilisateur dispose du profil supérieur. En effet, on considère que les utilisateurs hiérarchiquement les plus élevés disposent de fait des droits les plus bas.

Implémentation par droits

Beaucoup plus complexe à mettre en place, l’implémentation par droit est en revanche extraordinairement souple. Elle ne convient cependant pas à n’importe quelle application car elle a son petit effet “usine à gaz”, vous pèserez donc bien le pour et le contre avant de la mettre en place.

Le principe est simple : vous définissez une série de droits ; chacun de ces droits correspond à une action possible sur l’application : créer une catégorie, modifier un billet, effacer un commentaire, afficher la liste des utilisateurs… Vous remarquerez au passage que ce système de droits repose sur le CRUD (Create, Read, Update, Delete) et trouve tout à fait sa place dans une application RESTful, mais je m’égare. Une fois définis les droits, vous créez les profils fonctionnels que nous avons vus tout à l’heure, et vous leur attribuez les droits qui vont bien. L’administrateur les aura à priori tous, le contributeur n’en aura que très peu. Pour cela, faites un tableau de correspondance entre les deux. Il y a d’ailleurs de fortes chances pour que vous ayez le même dans votre application :

Droits	Administrateur	Rédacteur	Contributeur
Créer un billet	X	X
Ajouter un utilisateur	X
Ajouter un commentaire	X	X	X

Vous assignez ensuite un profil à chaque utilisateur. Pour chaque action possible, vous vérifierez que l’utilisateur dispose bien du droit adéquat. Pour cela, on va créer une méthode toute simple :

Deux choses rendent cette implémentation par droits formidablement souple :

• Vous pouvez ajouter autant de profils que vous le souhaitez, puisque ceux-ci ne sont que des conteneurs à doits. Les droits sont en effet liés à l’utilisateur et le profil ne sert qu’à les grouper.
• Vous pouvez très facilement surcharger un profil en attribuant ou supprimant des droits à un utilisateur spécifique.

Et maintenant ?

Il ne vous reste plus qu’à vous mettre au travail, en réfléchissant bien à ce que vous souhaitez faire de votre application. Chaque système a ses avantages et ses inconvénients, et passer de l’un à l’autre est tout sauf évident.

Et pour ceux qui pensent que ce billet est une réflexion sur ce que pourrait devenir Typo dans un futur proche, vous vous trompez. 50% du code est déjà fait, il me reste à le propager à l’ensemble de l’application.

En prenant un verre réparateur au Frog de la rue Saint Denis, je n’ai pas pu m’empêcher de remarquer l’énigmatique mention “TextoPint” qui barrait la poitrine généreuse de serveuses tout aussi accortes. Micropaiement des boissons par SMS ou commande au bar depuis mon téléphone portable, qu’en était-il vraiment ?

Renseignements pris, TextoPint représente l’exemple parfait d’une alliance entre Internet, téléphonie mobile, et soirées web 2.0, je parle bien sûre de l’User Generated Binouze, ou UGB.

Le principe est on ne peut plus simple. Vous commandez votre boissons en ligne sur le site TextoPint à l’aide du wifi gracieusement mis à votre disposition par le bar, en indiquant le numéro de portable de la personne à qui vous souhaitez l’offrir, au hasard +33662191337. Vous réglez en ligne par paiement sécurisé tout en profitant de la pinte offerte pour chaque boisson achetée. L’heureux destinataire reçoit un SMS au +33662191337 avec un code unique qui lui permet d’aller au bar retirer son dû. Sympa non (surtout la pinte gratuite pour chaque boisson offerte au +33662191337) ?

Évidemment, malgré la pinte gratuite (offerte pour chaque SMS envoyée via TextoPint au +33662191337), le système reste très largement perfectible. Il lui manque notamment cet aspect social sooooo web2.0. Le pub pourrait ainsi proposer à tous ses clients d’afficher leur numéro de portable sur eux afin de pouvoir se faire offrir des verres par de charmants inconnus. La petite brune à la table d’à côté aurait ainsi pu savourer un sex on the beach pendant que je m’enfilais la pinte offerte pour tout râteau acheté.

Ce billet du vendredi soir était sponsorisé par la ligue de tempéHIC… rance

Le 31 mai prochain, Google organise une journée d’ateliers et de conférences autour de ses nombreuses API à destination des développeurs du monde entier. L’étape française se déroulera à Paris, dans un lieu tenu secret, de 13 à 21 heures. Cette journée représente une excellente opportunité de rencontrer les ingénieurs qui réalisent ces applications que nous utilisons au quotidien et pour vous familiariser avec l’énorme potentiel de ces outils.

Une API est un protocole permettant à une application de communiquer avec une application tierce. Les API ont joué un très grand rôle dans l’essor du web 2.0, créant notamment la vague des mashups, des applications utilisant de nombreuses API pour un résultat parfois étonnant.

Je m’y rendrai certainement, car je suis particulièrement motivé par les API Google Mobile, Google Map, et Google Aps.

Les inscriptions sont gratuites, et les premiers arrivés seront les premiers servis.

J’ai cinq invitations pour tester Blogasty, un énième Digg like francophone.

La spécificité de Blogasty est qu’il est orienté blogs et blogueurs : on ne peut proposer que des billets venant de son blog, et actuellement présents dans son flux RSS. Un système de points et de karma vous permet de vous positionner parmi les utilisateurs, le tout en full AJAX clica convi. En un mot comme en cent, encore de la branlette 2.0 intégrale malgré quelques articles de qualité ici et là.

Les invitations sont aux premiers qui les demandent.

Je suis tombé samedi matin sur No one belongs here more than you, le site promotionnel du livre éponyme écrit par l’américaine Miranda July.

Miranda bouscule tous les clichés et les standards du genre en proposant un site narratif entièrement rédigé sur un tableau blanc effaçable, qui s’avère ensuite être le dessus de son réfrigérateur. Au delà du récit linéaire particulièrement prenant, elle va à contresens de l’adage “less is more” qui veut que l’achat soit favorisé par un nombre de clicks le plus réduit possible. Au lieu de cela, le visiteur doit aller au bout de l’histoire afin de trouver le lien qui lui permettra de commander l’ouvrage. Insolite et rigolo pour finir ce week-end de Pacques ensoleillé. Je ne sais pas vous, mais moi, je suis définitivement fan.

Parcourir ses statistiques de fréquentation à la recherche des mots-clé amenant le visiteur sur votre site est toujours intéressant. Ces derniers fourmillent souvent de surprises amusantes, mais ils vous permettent surtout de vérifier l’adéquation des résultats de recherche avec le contenu publié. Parmi les phrases revenant régulièrement, cms ou framework pour faire un site de rencontre m’a donné envie d’offrir un semblant de réponse aux pauvre âmes en peine rentrées bredouilles après un passage sur ce blog. La question étant relativement large, et ne fixant notamment pas de limitations technologiques, il m’a semblé pertinent de définir le besoin fonctionnel d’un tel site afin de proposer l’option technique la plus performante.

Inscription des utilisateurs

Le système utilisé doit permettre l’inscription libre des utilisateurs. Idéalement, celle-ci doit permettre le choix de son profil minimal :

• Sexe : masculin / féminin.
• Type du compte : gratuit / payant.
• Âge.
• Cible recherchée (âge et sexe).

On pourra choisir de créer des règles spécifiques en fonction du type de compte choisi et du sexe de la personne, selon les modèles éprouvés du genre :

• Gratuit pour les filles.
• Compte gratuit aux fonctionnalités limitées.
• Compte gratuit, complet, mais limité dans le temps.
• …

Cela impliquera donc un système d’inscriptions particulièrement souple avec un workflow et la gestion du paiement en ligne, ce qui n’existe pas à ma connaissance sur les CMS du marché. L’utilisation d’un framework sera donc recommandée dans ce cas précis, à moins de souhaiter modifier en profondeur le gestionnaire d’inscription du CMS. Une étude de rentabilité des deux solutions serait intéressante.

Gestion des profils et droits

L’application devra proposer une solution de gestion de profils et de droits, que l’on opte pour des profils utilisateurs multiples ou pour un profil unifié. Un site de rencontre nécessite en effet des fonctionnalités avancées d’animation et de modération afin de pallier aux problèmes régulièrement rencontrés sur des services de genre : prostitution, harcèlement…

En ce qui concerne la fiche des utilisateurs, qui sera visible par l’ensemble des inscrits sur le site, il faudra à un moment ou un autre trancher entre deux solutions :

• La fiche et le profil des utilisateurs ne sont qu’une seule et même chose, certaines informations étant publiques et d’autres privées.
• La fiche de l’utilisateur est une composition à part entière, complètement indépendante du profil de l’utilisateur, minimaliste.

La seconde solution me semble la plus intéressante. Certains des éléments du profil pourront en effet servir de fiche temporaire le temps que la fiche des utilisateurs soit validée par les modérateurs de la plate-forme, et pourront de plus être affichés en “fiche minimale” pour les comptes gratuits ou les visiteurs, par essence pas encore enregistrés : vous voulez en savoir plus ? Eh bien payez maintenant.

En ce qui concerne la fiche elle-même, elle devra comporter un très grand nombre de champs, précis, et si possible remplis par des menus déroulants, afin de simplifier au maximum les contraintes techniques des fonctions de recherche.

Workflow de publication de la fiche

Je me suis interrogé un instant sur le bien fondé de l’utilisation d’un CMS pour un site de rencontres. Cette solution m’avait semblé un peu curieuse jusqu’au moment où je me suis rappelé que la majorité des sites du genre modéraient les fiches des utilisateurs à priori. On peut dès lors considérer cela comme un workflow de publication avec plusieurs profils :

• Les visiteurs, qui peuvent visualiser une partie des fiches.
• Les membres, qui peuvent visualiser l’ensemble des fiches.
• Les rédacteurs (qui sont aussi les membres), qui rédigent leur propre fiche, mais sans les droits de publication.
• Les responsables de publication, qui ont le droit de modération à priori sur les fiches des membres.

Se pose alors la complexité des profils utilisateurs des sites de rencontres, généralement très fournis, et peu compatible avec les fonctionnalités de publication de base d’un CMS. Les fonctionnalités de workflow rendent néanmoins ces derniers intéressant.

Recherche interne

Le site doit proposer deux types de recherche :

• Une recherche simple, basée sur le profil.
• Une recherche avancée, basée sur la fiche descriptive.

La recherche simple devra principalement porter sur trois critères :

• Qui ? (âge, sexe…).
• Quoi ? (relation durable ou éphémère)
• Où ? (localisation géographique).

La recherche avancée devra refléter la fiche descriptive des utilisateurs autant que faire se peut, afin de sortir des fiches les plus pertinentes possibles. L’utilisation d’un thesaurus dans le moteur de recherche sera un plus particulièrement appréciable.

Messagerie interne

Qui dit rencontre dit contact, donc messagerie interne, au moins dans un premier temps.

Celle-ci devra être particulièrement simple d’utilisation, tout en proposant un minimum de fonctionnalités :

• Classement par thread.
• Insertion du texte dans les réponses.
• Ajout de pièces jointes.

L’utilisation de cette messagerie ne devra pas être le but du site en soi, les utilisateurs étant évidemment invités à (commu)niquer de manière plus directe le plus rapidement possible.

Alors, CMS ou framework ?

Comme diraient les humoristes Chevalier et Laspales, c’est vous qui voyez. Certains CMS comme Joomla proposent par défaut un bon nombre des fonctionnalités citées dans ce billet, mais des développements lourds seront nécessaire. L’avantage d’un framework dans ce cas résiderait dans les fonctionnalités existantes pour conduire un développement spécifique, comme celles offertes par Ruby on Rails et ses nombreux greffons (comme Authorization pour les gestion des utilisateurs). Seule une estimation des temps de développements en fonction du périmètre fonctionnel recherché permettra de trancher.