Ces dernières semaines, nous avons sorti un produit que nous préparons depuis pas mal de temps. Il s’agit de FatCap. Ce site, visible en francais sur www.fatcap.org, et initialement créé en 1998, est un des leaders mondiaux des magazines d’arts urbains en ligne. Pour cette nouvelle version, les objectifs à atteindre étaient multiples:
- Bâtir une plateforme solide, basée sur le contenu des utilisateurs (photos, vidéos) ET sur le contenu produit par l’équipe éditoriale (vidéos maison, articles, interviews, reportages, mises en avant)
- Rendre cette plateforme entièrement géolocalisée, afin de pouvoir suivre l’évolution de l’art dans une ville, dans un état américain, dans un pays, ou même dans un continent.
- Tirer la plus grande valeur de chaque élément de contenu en créant une base intelligente et structurée censée représenter l’art urbain de manière exhaustive: Ainsi, chaque artiste devra avoir sa page, ainsi que chaque groupe d’artiste. De même, chaque photo pourra être multi-taggée avec une quinzaine de critères afin de répondre de manière complète à tout type de demande de la part des internautes.
- L’ensemble de la plateforme devra être internationalisée, et mieux encore, localisée, c’est à dire que la couche éditoriale devra être différente sur les différents sites locaux. L’actualité de chaque version localisée étant adaptée au pays ciblé par la version, à l’inverse de sites internationalisés au contenu unique, traduit soit à la main soit par un traducteur automatique.
La conception
Nous sommes donc partis pour quatre mois de conception dès mi-2007, où il s’agissait d’abord de faire un état des lieux des technologies en présence. En effet, il fallait contourner par la technologie les problèmes suivants:
- Géolocalisation: Il était bien sûr hors de question de se baser sur des champs texte, qui laissent la part belle aux fautes en tout genre. Il fallait se baser sur une API (et donc sur des ID), et proposer un système souple et intelligent qui permettrait aux utilisateurs de renseigner les villes de manière intuitive. Côté API, elle devait être pérenne, et n’avoir aucun risque de cessation d’activité à court ou moyen terme. Nous avons opté pour les bases de Yahoo! Geoplanet (qui, hasard ou chance, sont sorties en plein milieu de notre phase de conception), car ce sont celles utilisées par Flickr et celles qui de loin présentent les fonctionnalités les plus puissantes et les meilleures garanties.
- Ce dernier point fut en outre à l’origine d’un problème plus global: ayant un contenu méta-taggée de manière très riche, il convenait d’adopter un système de tagging très simple à utiliser, très loin donc, des éléments de formulaires mis à notre disposition par le simple fruit de l’HTML (menu déroulants, boutons radio, etc..). Le JavaScript allait donc être intensivement utilisé sur certaines pages. En effet, plus vous rendez une information compliquée à rentrer, plus vous risquez d’avoir des informations lacunaires.
La solution à ces deux problèmes peuvent être illustrés au travers de l’exemple du tagging d’une ville. Voici à quoi ressemble le formulaire d’inscription, par exemple:
fig. 1
fig. 2
fig. 3
Comme vous le voyez sur le drapeau, on préselectionne automatiquement le pays dans lequel l’IP du visiteur se situe. S’il le souhaite, il peut évidemment changer ce pays. Cela nous permet de restreindre notre recherche de ville au pays sélectionné, évitant ainsi les multiples doublons constatés à l’échelle mondiale. Ensuite, la puissance de l’interactivité avec l’API se déploie lorsque la ville est inconnue en base (fig. 2). La, alors que l’utilisateur va taper entièrement le texte de sa ville, nous ne sommes pas encore en mesure de la relier à une ville issue de la base de données des villes Flickr, disponible à travers Yahoo! Geoplanet. Alors, une fois le texte rentré, nous effectuons par Ajax la bonne requete YQL, et sommes capables, s’il y a confusion, de proposer des options à sélectionner (fig. 3), ou, si nous avons un résultat unique, de simplement qualifier le texte tapé en une puce signalant la validation du contenu.
- Ensuite, il y a la spécificité d’un site au contenu localisé. Un tel site ne saurait abriter toutes ses différentes version sous un seul et même serveur. Au contraire, le contenu doit être servi au plus près des internautes, ce qui sous entend d’héberger chaque version dans le pays des visiteurs qu’il cible. Cela pose donc entre autres le problème de l’appel aux images, puisque des images sont chargées sur des serveurs distants de 7000 km, et que nous ne souhaitions pas utiliser de technologie de synchronisation des fichiers (même si unison a longuement été étudié), car technologie sujette aux lags, à la consommation frénétique de bande passante (qui n’est pas chère en France mais hors de prix aux Etats Unis), et sous-optimale en terme d’optimisation de l’espace disque.
Nous avons donc développé un système de gestion intelligent des assets, qui est capable de déterminer sur quel serveur du cluster une image a été chargée, et de l’afficher en conséquence, ainsi que de faire une copie permanente des assets sur le service de stockage tiers Amazon S3. Une fois une image répliquée (dans les 10mn de sa validation), c’est le chemin physique le plus court jusqu’au serveur qui est choisi, dans le but d’optimiser la vitesse et les couts.
Le design
Printemps – été 2008: Une fois les documents établis (specs fonctionnelles et techniques, wireframes détaillées, etc.), l’élaboration du design fut assez “simple”. Déja, parce que nous travaillions avec une des meilleures agences de Paris (CubeDesigners), mais aussi parce que nous avions une idée très claire de ce que nous souhaitions, facilitant les allers retours. Ainsi, élaborer une page clé complexe ne prenait pas plus d’une journée, sans que nous n’ayons, jusqu’au dernier jour, besoin d’y retoucher le moindre pixel.
Le défi ergonomique de ce design était de bâtir des listes filtrables, sur un système d’entonnoir. Ainsi, une liste de photo peut être celle d’un artiste, comme C215, mais aussi la liste des photos de Paris, celle de tous les “personnages” apparaissant dans une oeuvre, celle de France, de Californie, etc… C’est là la puissance du site: structurer à l’extrême un contenu par ailleurs désorganisé, rendu simple par une utilisation de repères identiques à travers la visite.
Un bon exemple de ce souci de facilitation du parcours de visite est la page de vue d’une photo. Sur cette page finale (rien après ce niveau de navigation), il convenait de proposer aux visiteurs d’autres contenus reliés. Etant donnés nos multiples niveaux de classification d’une photo, nous avons opté pour un coverflow, grâce auquel on peut continuer sa visite sur des frises, toutes classées selon un des critères clés choisis à travers le site (timeline, artiste, ville, type, style, support).
Le développement
Beaucoup de travail nous attendait chez SeedWeb. Nous avons passé l’été 2008 à concevoir le design, et l’automne fut l’occasion pour notre équipe d’intégrateurs HTML d’intégrer toutes ces maquettes en XHTML selons nos critères très stricts, dans le but d’améliorer le référencement naturel, et en parallèle pour notre équipe de développeurs front, de développer la couche Javascript (avec jQuery), en particulier les interfaces de tagging. Le développement lourd a donc commencé à l’hiver 2008-2009, ce qui concordait avec la sortie de Symfony 1.2, qui intégrait enfin Doctrine comme un ORM de choix, ce qui tombait bien car vue la complexité de certaines requêtes du site et la puissance du DQL, nous aurions difficilement pu nous en passer.
De cette base Symfony, nous avons presque tout étendu: les classes de base bien sûr, le moteur lui même, puisque nous lui avons adjoint la puissance des composants Zend Framework, notamment pour la gestion des services tiers (FatCap est un site ouvert, interfacé avec Twitter, Youtube, Dailymotion, Vimeo, Flickr, etc..), nous avons également étendu les actions de manière à ce qu’elles héritent d’une classe mère par application, qui hérite elle même d’une action commune à l’ensemble du projet, afin de factoriser au maximum le code. Idem pour les composants. Toute notre gestion des images (redimensionnement, intégration à notre système de réplication) est le fruit d’une nouvelle classe de traitement de l’upload des fichiers (qui étend sfValidatedFile), et qui se base sur des fichiers de configuration puissants afin de déterminer la liste des miniatures à effectuer, des emplacements de stockage, etc… L’ensemble des modèles de données est étendu grâce à des templates doctrine, comme par exemple le choix du serveur pour afficher une image, ou encore la réplication S3, le tout en minimisant les requêtes et le temps d’affichage, et en rendant toutes les actions longues asynchrones.
L’ensemble de cette belle machine est surveillée par des milliers de tests fonctionnels et unitaires, et servie par un cluster de serveurs répartis dans le monde, avec des systèmes de réplications de bases de données complets, une utilisation intensive de memcache, et un accent fort mis sur la sécurité. La base de données est constamment “purifiée” par une cinquantaine de démons qui tournent à longueur de journées et de nuits, et qui s’appuient sur un logging statistique étendu pour garder une base de données propre, qualifiée, et à jour (qui sert aussi à produire les différents graphiques sur le site).
En bref, un très long projet, et une belle prouesse technologique pour SeedWeb, qui synthétise l’ensemble de nos champs d’expertise, et qui correspond à notre positionnement ambitieux de s’employer à produire des sites de très haute qualité, facilement extensibles et utilisant un éventail de technologies matures et professionnelles, en utilisant notre expertise en marketing internet et en ergonomie pour maximiser l’expérience utilisateur, et diminuer les couts d’acquisition.
Au lendemain du lancement par Google de 