DAVIDLESIEUR.com - Concepteur-développeur web et expert Drupal /// Montréal, Québec

Whisky Echo Bravo a un vrai site Web!

Wed, 26 Aug 2009 11:03:13 -0500

Après avoir longtemps passé pour des cordonniers mal chaussés, nous avons enfin pris le temps de créer un site Web digne de ce nom pour Whisky Echo Bravo. C'est désormais sur ce site que je publierai mes billets à propos de Drupal ou d'autres sujets en rapport avec le développement Web. Ce nouveau blogue risque même d'être plus intéressant, puisque mes collègues y contribueront aussi.

Pour en savoir un peu plus sur notre démarche dans la création du nouveau site, voyez cet article plus détaillé. N'hésitez pas à y laisser vos impressions!

Parler Drupal à Paris

Mon, 22 Jun 2009 12:12:18 -0500

Patrick Fournier, mon associé chez Whisky Echo Bravo, et moi-même seront présents à la prochaine conférence Drupal, qui se tiendra à Paris du 1er au 5 septembre prochain.

En plus d'être une occasion idéale pour renforcer nos liens avec plusieurs collaborateurs virtuels et apprendre des pratiques d'autres développeurs, l'évènement DrupalCon permet de prendre le pouls de la communauté Drupal, de découvrir les dernières tendances et d'obtenir une vision claire des stratégies préconisées par les leaders de la communauté pour améliorer la plateforme dans les mois à venir. En effet, lors de la conférence DrupalCon tenue à Boston l'an dernier, j'ai été surpris par la richesse des échanges et la quantité de décisions importantes prises sur place. Même dans une communauté à ce point virtuellement connectée, tout ne se joue donc pas dans le cyberespace! Pour Whisky Echo Bravo, l'implication dans le développement de Drupal et la participation à cette conférence contribuent à la prise de décisions judicieuses pour nos clients, notamment pour assurer la viabilité de leur plateforme Web à plus long terme.

Il y a fort à parier que nous nous intéresserons de près aux activités liées à la diffusion vidéo et aux moteurs de recherche (dont les projets ApacheSolr et Faceted Search), des sujets au coeur de notre travail. Ceci dit, les conférences passées n'ont jamais manqué de matière intéressante et nous tenterons d'en toucher le plus possible!

En marge de la conférence, nous espérons aussi rencontrer quelques-uns de nos clients et partenaires Français. D'où que vous soyez, si Drupal vous intéresse et que vous êtes à Paris début septembre, n'hésitez-pas à nous contacter afin qu'on programme une rencontre!

RIP: Remix Manifesto

Mon, 20 Oct 2008 22:13:06 -0500

À l'invitation de Brett Gaylor de EyeSteelFilm (à travers Whisky Echo Bravo, nous avons eu le plaisir de collaborer à son projet OpenSourceCinema.org à quelques reprises durant l'année), j'ai assisté vendredi dernier à la représentation du film RIP: Remix Manifesto dans le cadre du Festival du Nouveau Cinéma de Montréal.

En commençant d'abord par l'exemple de l'industrie de la musique et de ses rebelles tels que Girl Talk et Napster, ce film très engagé montre les dérives du droit d'auteur qui, de son origine qui visait à compenser équitablement les créateurs pour les coûts liés à leur production, est graduellement devenu un bête outil mercantile au service d'une poignée de richissimes multinationales, déconnecté des raisons morales qui le justifiaient à l'origine.

L'on découvre ensuite l'effarant paradoxe de Disney qui, après être devenue l'une des plus grandes entreprises de divertissement au monde en remixant et recyclant des contes anciens, ne manque pas une occasion d'attaquer tout individu qui souhaiterait à son tour engendrer une oeuvre à partir de l'environnement culturel auquel il appartient — un environnement qui inclue bien sûr les personnages de Disney. La culture ne vit pourtant pas en vase clos, elle repose toujours sur un certain héritage.

Plus tard, l'on trace le parallèle entre les lobbys du droit d'auteur et l'emprise de l'entreprise privée sur les découvertes et les inventions scientifiques par le biais des brevets, un réel frein à l'avancement de la médecine et de la science en général. Bref, dans toute l'histoire de l'humanité, ces droits n'ont été reconnus que pendant le XXe siècle. Voilà qui donne à réfléchir... L'humanité aurait-elle pu évoluer s'il avait été interdit de bâtir sur l'héritage de nos prédécesseurs et les idées de nos pairs?

Baigné d'une riche trame sonore qui contribue à appuyer le propos, parsemé de clips et montages savoureux (et souvent tordants), éclairé par les propos de Lawrence Lessig (fondateur de Creative Commons), RIP: Remix Manifesto sera sans doute un électrochoc pour toute personne n'ayant encore songé à l'impact du droit d'auteur sur notre société, et un fouet de plus pour le partisan du logiciel libre! Un film à regarder, copier et remixer!

DrupalCamp Montréal 1.0

Wed, 01 Oct 2008 16:07:48 -0500

Le premier DrupalCamp à voir le jour à Montréal aura lieu vendredi et samedi, les 3-4 octobre 2008. Tous sont les bienvenus, les novices comme les experts! Le seul pré-requis: désirer en apprendre plus sur Drupal.

Le détail de la programmation sera défini collectivement le vendredi matin. On prévoit surtout des séances informelles en petits groupes thématiques.

Une occasion à ne pas manquer, inscrivez-vous! L'évènement gratuit est organisé par Koubmit et commandité par plusieurs organisations, dont Whisky Echo Bravo.

Mise à jour (2008-10-02): Le DrupalCamp montréalais a maintenant un site!

Whisky Echo Bravo a un an aujourd'hui!

Wed, 01 Oct 2008 15:26:34 -0500

Whisky Echo Bravo, la compagnie que j'ai co-fondée avec Patrick Fournier, a déjà un an aujourd'hui! En rétrospective, je constate que les choses ont beaucoup bougé au cours de cette année, comme en témoigne la liste de réalisations qui suit. Un seul regret, celui de ne nous n'être pas dotés d'un vrai site Web dès le début de l'entreprise! En effet, notre carnet de commandes n'ayant pas dérougi depuis le lancement, nous n'avons pas tellement pu y travailler, ce qui fait de Whisky Echo Bravo un cas classique de cordonnier mal chaussé!

Un rapide tour d'horizon de nos principales dernières réalisations :

Couzin Films est une compagnie de productions cinématographiques, télévisuelles et numériques établie à Montréal dont les projets allient diversité culturelle, réflexion sociale, innovation artistique et potentiel commercial. Nous avons conçu et réalisé pour eux une plateforme Web basée sur Drupal 6 qui leur permette d'exprimer la richesse de leurs projets et de faire connaître l'actualité les entourant. Le concept mise surtout sur les relations entre les contenus, qui permettent de naviguer rapidement vers les éléments qui nous intéressent, tandis que le design graphique créé par Sherpa Design tire avantage de l'identité visuelle forte de Couzin Films. Inauguré en septembre 2008, le site continuera encore d'évoluer au cours des prochaines semaines.
Delta Furniture est un important fabricant de meubles offrant à ses clients (hôtels, transporteurs ferroviaires et maritimes, commerces, restaurants, bureaux) un service personnalisé et haut de gamme. Avec l’agence créative Bluesponge, nous avons créé un site Web permettant aux clients de feuilleter le catalogue complet des produits de Delta Furniture et de leurs fiches techniques, ainsi que d’obtenir des soumissions en ligne. Nous avons été appelés à conseiller Bluesponge, tout au long du projet, sur les possibilités offertes par Drupal, à mettre au point de nouvelles fonctionnalités pour Drupal, à intégrer un design graphique léché et audacieux, bref à assurer l'implémentation complète du site Web. Inauguré en septembre 2008.
Suite à un projet-pilote de plateforme de travail collaboratif basée sur Drupal qu'elle avait complété en début d'année, l'Université du Québec (siège social) a décidé de faire appel à nous pour la suite du projet, soit la mise au point d'une plateforme similaire, revue et améliorée, et destinée à être « clonée » pour plusieurs groupes et communautés de pratiques gravitant autour de l'Université. Dans une perspective de viabilité à plus long terme, nous avons revu toute l'architecture du système. À ce jour, parmi les fonctions intégrées à la plateforme, on retrouve diverses fonctions de type wiki (notamment le versionnage, comparaisons et suivi des changements), des groupes (via Organic groups), des forums, la gestion de documents multimédia (audio, vidéo, images, textes), la modération des contenus, les notifications par courriel, des outils d'aide à la prise de décision, un moteur de recherche par facette, un calendrier d'évènements, un bottin, des signets, etc. L'idée est de fournir un large éventail d'outils, puis de laisser chaque communauté adapter la plateforme à ses besoins. Ce sont ainsi des dizaines de sites Drupal qui verront le jour au cours des prochains mois! Le tout dans un environnement Drupal « multi-sites » conçu pour minimiser le travail d'entretien lié au grand nombre de sites. Inauguré en septembre 2008.
Moteur de recherche par facette: Depuis plus d’un an, nous collaborons avec le laboratoire NT2 de l’Université du Québec à Montréal à un projet de recherche et développement visant à offrir un moteur de recherche par facette particulièrement adapté à des bases de données et des répertoires bâtis par des chercheurs et riches en informations soigneusement analysées et classées. Ce travail est basé sur le module Faceted Search pour Drupal.
Le Centre de solidarité lesbienne est un nouvel organisme voué à l'amélioration des conditions de vie des lesbiennes en leur offrant des services et des interventions adaptés à leur réalité et ce, dans les domaines de la violence conjugale, du bien-être et de la santé. Le site, que nous avons conçu et réalisé est encore très simple pour l'instant, mais comportera bientôt un riche portail d'informations à l'intention des lesbiennes, des intervenants et des chercheurs. Inauguré en août 2008.
Très impliqué dans le mouvement des femmes et ayant des liens avec de nombreux groupes de femmes, Relais-femmes avait besoin d'une plateforme permettant de gérer plus dynamiquement ses contenus Web. Nous avons donc migré leur site HTML conventionnel vers Drupal, tout en préservant, tel que demandé, le design graphique de l'ancien site et en repensant son architecture de l'information afin de favoriser la repérabilité des contenus, puis en l'enrichissant d'un moteur de recherche par facette. Inauguré en juillet 2008.
Providing a Voice offre aux jeunes ghanéens un lieu de rencontre virtuel où ils peuvent échanger des idées sous forme de textes, de photos et de clips vidéo. Notre mandat consistait à proposer une solution qui corresponde aux besoins du client tout en demeurant dans les limites du budget établi, et à réaliser le site en se basant sur la charte graphique fournie par le client. Inauguré en juillet 2008.
Homeless Nation apporte aux personnes sans abri du Canada un lieu de rencontre virtuel où ils peuvent échanger avec d’autres sans abris ou avec des travailleurs de rue. Notre mandat consistait à proposer une nouvelle charte graphique du site et à améliorer et ajouter des fonctionnalités, notamment des fonctionnalités liées au traitement et au stockage des vidéos. Inauguré en mars 2008. Le site a reçu en 2008 le prix « Excellence in New Media Creation/Social Media Production/Nonprofit Division » de la Society for New Communications Research et le prix « Excellence in Social Media Websites « du Canadian New Media Awards.
L’Ordre des optométristes du Québec est un ordre professionnel régissant la profession d’optométriste au Québec. L’Ordre possédait déjà un site Web, réalisé à l’interne. Nous avions pour mandat de procéder à la refonte complète du site, de réorganiser l’information et de proposer une nouvelle charte graphique. Inauguré en janvier 2008.
OpenSourceCinema est un site collaboratif dédié à la réalisation d’un documentaire sur l’impact d’Internet sur les médias. Le site invite ses visiteurs à participer à la réalisation du film en versant du contenu audio et vidéo et en le remixant en ligne. Notre mandat consistait à apporter des améliorations à la charte graphique du site et à ajouter des fonctionnalités, notamment des fonctionnalités liées à la manipulation et au stockage des vidéos. Inauguré en décembre 2007.
Le Sommet du millénaire est un évènement d'envergure internationale au cours duquel convergent de grandes personnalités afin de sensibiliser les populations à l’importance d'oeuvrer au mieux-être collectif par le biais du développement international. En collaboration avec l'agence de création Bluesponge et dans un court délai, nous avons développé cette plateforme Web basée sur Drupal qui permit d'adapter les contenus au jour le jour, à mesure que l'évènement prenait forme. Inauguré en octobre 2007.

Les perspectives pour la prochaine année s'annoncent excellentes et notre choix d'appuyer tous nos projets sur Drupal n'y est pas étranger. En effet, Drupal est plus flexible et innovateur que jamais, et gagne la faveur d'un nombre grandissant d'utilisateurs et d'experts. Drupal est bâti et défini par sa communauté, alors plus la communauté grandit, plus Drupal se renforce!

Le prix Pulitzer, Drupal et la recherche par facette

Sat, 19 Jul 2008 10:02:14 -0500

Le prix Pulitzer, particulièrement reconnu dans le domaine du journalisme, s'est tout récemment doté d'un nouveau site Web basé sur Drupal. Depuis sa création en 1904, le prix a engendré une riche base de données, dont l'exploration est désormais facilitée par la recherche par facette, via le module Faceted Search pour Drupal. On peut combiner différents critères de recherche tels l'année, la catégorie du prix, le genre de nomination et, bien sûr, des mots clés.

Ceci n'est pas sans rappeler le classique site de démonstration du système Flamenco qui, dans le même esprit, exploite les données du prix Nobel. Cet exemple, conçu par des pionniers de la recherche par facette, m'avait grandement inspiré le développement de Faceted Search.

Sans parler des incontournables modules CCK et Views, plusieurs autres modules pour Drupal ont aussi été employés sur le site du prix Pulitzer. Dans un article intéressant (en anglais), les créateurs du site, OpenFlows, en identifient quelques-uns et décrivent leur approche dans le développement du projet.

Drupal au CodeFest 2.1 de PHP Québec

Thu, 15 May 2008 12:08:14 -0500

En fin de semaine, PHP Québec organise CodeFest 2.1, un évènement où programmeurs de tous horizons et de tous niveaux seront accueillis pour participer au développement de leur logiciel libre préféré. Une très belle occasion de découvrir les techniques employées par différents projets, de rencontrer d'autres programmeurs et, d'une manière générale, de simplement se motiver à se jeter à l'eau avec un projet!

L'un des thèmes de l'évènement concerne l'implémentation de test automatisés, un thème qui tombe à point compte tenu de la récente intégration de la plateforme de tests automatisés SimpleTest dans le noyau du futur Drupal 7.

CodeFest 2.1 arrive alors que je n'ai même pas encore eu le temps de conclure sur le récent sprint de recherche auquel j'ai eu la chance de participer, mais je compte bien utiliser ce nouvel évènement comme prétexte pour compléter quelques tests en rapport avec le moteur de recherche de Drupal.

Je serai donc présent samedi et heureux d'aider quiconque souhaiterait mettre la main à la pâte avec Drupal 7! Patrick Fournier, mon associé à Whisky Echo Bravo, sera aussi sur place.

L'évènement est tenu simultanément à Montréal et Sherbrooke. Même si j'aime beaucoup la ville où j'ai étudié, pour des raisons pratique c'est bien sûr à Montréal que je serai. ;)

Si l'évènement vous intéresse, n'hésitez pas à vous inscrire sur la fiche Drupal de l'événement!

En direct du Minnesota

Sat, 10 May 2008 21:49:40 -0500

Ces jours-ci, la mention «live from the Minnesota Search Sprint» (en direct du sprint de recherche du Minnesota) apparaît régulièrement en en-tête des soumissions de modifications apportées au moteur de recherche de Drupal.

En effet, tel que je l'avais annoncé récemment, une petite équipe de programmeurs (Earnest Berry, Robert Douglass, Chad Fennell, Doug Green, Djun Kim, Blake Lucchesi et moi-même) se trouve maintenant en plein «sprint» de programmation pour enrichir le module search de Drupal. Notre centre d'opérations se trouve sur l'immense campus de l'Université du Minnesota à Minneapolis, où Chad Fennell a gentiment pris soin de la logistique.

Notre principal défi consiste à atteindre un bon équilibre entre les réalisations concrètes et la vision globale du projet. Établir une feuille de route pour l'avenir est important, mais dans l'univers du logiciel libre, la seule chose vraie c'est le code! Les plans à long terme sont particulièrement difficiles à tenir dans cet univers, puisque Drupal évolue avec les disponibilités des contributeurs et les priorités des projets qui financent leur travail. La vélocité même du développement de Drupal en fait une cible particulièrement mouvante.

Par conséquent, ces deux derniers jours nous avons alterné entre la réalisation de tâches simples (pour les résultats concrets) et les remue-méninges (pour les enjeux de plus grande envergure), avec un souci d'aligner même les tâches mineures sur les objectifs plus importants, histoire d'aller dans la bonne direction, petit pas par petit pas. Il s'agit d'un réel puzzle; des pièces insignifiantes en elles-mêmes prendront, une fois accolées aux autres, tout leur sens.

Quelques pistes...

Voici quelques-unes des pistes que nous explorons dans ce sprint :

Unification du processus d'analyse lexicale appliqué à l'indexage et lors de la recherche.
Analyse lexicale au moyen d'une chaîne de traitements personnalisable, basée sur la même architecture que les filtres d'entrée de Drupal.
Varier l'analyse lexicale en fonction de paramètres tels la langue ou le format du contenu. Par exemple, des algorithmes de lexémisation distincts s'appliqueraient en fonction de la langue.
Calcul de classement des résultats extensible. Hormis les facteurs de base déjà prévus pour établir le classement des résultats, de nouveaux facteurs pourront être programmés dans des modules tiers et activés à la demande par l'administrateur d'un site. Par exemple, un site de commerce électronique pourrait rehausser le classement d'un produit en fonction de son volume de ventes.
Possibilité d'activer ou de désactiver différents modules de recherche séparément. Dans Drupal 5 et 6, activer le module search active toutes les fonctions de recherche, sur les noeuds et les utilisateurs, même si toutes ne sont pas pertinentes au site.
Abstraire la représentation des résultats pour éventuellement permettre la construction de facettes à partir d'un ensemble arbitraire de noeuds, qu'ils proviennent, par exemple, d'une recherche ou d'une vue.
Utiliser un objet plus «intelligent» qu'une chaîne de caractères pour représenter la requête, tout au long du processus de recherche. Cet objet pourrait être construit via une interface de programmation (accessible à n'importe quel module) ou via une chaîne de caractères. Il pourrait également produire la chaîne de caractères qui lui correspond en sortie, pour génération d'hyperliens. Présentement, les modules Faceted Search et ApacheSolr ont tous deux des éléments qui s'approchent de ceci. Ultimement, si cet objet pouvait représenter une requête du module Views, un grand pas serait accompli pour que des facettes puissent se rattacher directement à une vue...
Scinder la logique d'indexation de la logique de recherche. Les fonctions de recherche de base sont un fardeau inutile pour les site utilisant Faceted Search ou les filtres de recherche de Views 2 — ces modules utilisent l'index de base, mais implémentent leur propre logique de recherche.
Unifier la recherche d'éléments hétérogènes dans une seule page de résultats. Ceci pourrait rendre particulièrement utile l'éventuelle indexation d'éléments comme les blocs, les vues (du module Views) et les panneaux (du module Panels).
Indexer des données qui sont présentement omises de l'index afin d'augmenter la pertinence des résultats : Chemin (URL) du contenu, nom de l'élément de menu associé au contenu, etc.
Abstraire le système d'indexation des contenus afin de pouvoir lui substituer l'indexation par un moteur externe, par exemple Solr ou Sphinx.

Participer, en savoir plus...

Que vous soyez sur place ou non, il est facile de participer à ces travaux ou de les suivre de plus près! Il suffit d'examiner les propositions, les réviser, les tester, les commenter!

Demain sera, déjà, la dernière journée du sprint. En plus de poursuivre certaines des pistes présentées ci-haut, nous comptons examiner les questions de performance d'exécution. À suivre!

Journée portes ouvertes Design Montréal

Mon, 05 May 2008 14:47:53 -0500

Montréal vivait hier sa seconde édition des journées portes ouvertes Design Montréal. Grâce à l'agence de création, cliente et amie, Bluesponge, j'ai eu la chance de participer à l'évènement! En effet, depuis l'automne dernier, mon associé au sein de Whisky Echo Bravo (notre nouvelle boite de développement Drupal) et moi-même sommes «colocs» de Bluesponge qui, après son succès de l'année dernière, ne pouvait manquer l'occasion d'ouvrir grandes ses portes aux visiteurs.

Samedi, tandis que toute l'équipe de Bluesponge s'éclatait à transformer la salle de réunion en terrain de boulingrin, un bureau en autel de prière en faveur des Canadiens ou à mettre au point l'une des multiples installations interactives, nous avons, de notre côté, transformé un coin du bureau en point de rencontre avec Drupal.

Nous avons monté une petite forêt de ballons d'hélium auxquels étaient attachées de petites bribes d'information à propos de Drupal... Les curieux pouvaient tirer sur la corde retenant un ballon pour découvrir le propos qui y était rattaché. Quelques exemples : «Drupal vous rend autonome pour gérer votre site web», «Drupal est un logiciel libre», «plus de 250 000 sites reposent sur Drupal», «Drupal vous permet d'innover», «Drupal favorise la collaboration», et bien d'autres...

Dimanche, les visiteurs sont venus en grand nombre (malgré la pluie) découvrir notre milieu de travail quelque peu transformé, tout en se délectant de pancakes aux bleuets offertes par Bluesponge... Nous espérons que notre installation fut intéressante pour un public n'ayant même jamais entendu le nom «Drupal» auparavant et, en cette journée ludique, pas nécessairement intéressé à plonger dans des détails techniques ou à s'asseoir devant un écran d'ordinateur.

Chose certaine, Druplicon a charmé beaucoup de monde, puisque nos macarons à son effigie se sont envolés comme de petits pains chauds! Voici quelques images de l'évènement... On peut s'attendre à en voir plus bientôt sur le blogue des «Spongies».

Doter Drupal d'un moteur de recherche plus performant

Tue, 22 Apr 2008 15:54:33 -0500

Drupal possède un excellent moteur de recherche par mots-clés, le module search qui est fourni à la base avec Drupal. On peut employer plusieurs opérateurs de recherche, l'intersection de mots-clés (ET), l'union (OU), la négation (NON) de même que la recherche de phrases complètes. L'algorithme de classement tiens compte de plusieurs facteurs tels la fréquence du mot, son balisage HTML, la popularité et la date de publication du contenu. En étant détaché de la mise à jour des contenus via la commande cron, le processus d'indexation ne nuit pas au fonctionnement rapide du site. Par-dessus tout, le moteur est très facile à utiliser puisqu'il suffit de deux clics pour activer le module!

Par conséquent, le module search sert les besoins de milliers de sites. Cette popularité extrême en fait aussi un module fréquemment critiqué. On voudrait plus facilement personnaliser l'interface de recherche et les pages de résultats, accroître la vitesse sur les sites très lourdement chargés de contenus, brancher d'autres algorithmes de calcul du classement, rechercher des mots partiels, rechercher du texte dans des champs spécifiques, rechercher des plages de valeurs, se faire suggérer des termes similaires, rechercher dans les fichiers joints, etc. Bâtir un moteur de recherche qui répond à toutes les demandes n'est pas une mince affaire!

Plusieurs modules additionnels visent à répondre à certaines de ces demandes, notamment Faceted Search (je dois le mentionner :)), Views Fast Search, Apache Solr, Fuzzy Search et Swish-E.

À chaque nouvelle version de Drupal, le module search connaît son lot d'améliorations. Dans Drupal 6, les améliorations ont surtout concerné la vitesse d'exécution des requêtes de recherche. Pour le futur Drupal 7, la course aux améliorations est lancée et, à l'occasion d'un sprint inédit qui aura lieu du 9 au 11 mai prochain à l'Université du Minnesota, atteindra une vitesse folle! En effet, c'est à cette date que sera tenu le Search Sprint, une rencontre de plusieurs développeurs chevronnés impliqués dans le développement de Drupal et d'outils de recherche. J'aurai la chance d'y prendre part moi-même, avec l'appui du Laboratoire NT2 de l'UQAM — qui utilise mon moteur de recherche à facette dans de nombreux projets et qui souhaite poursuivre le développement d'outils de recherche avancés pour Drupal — et de Acquia. Les autres participants ayant confirmé leur présence jusqu'à présent : Earnest Berry, Robert Douglass, Chad Fennell, Doug Green, Michael Hess, Djun Kim, Blake Lucchesi.

Lors de la dernière conférence Drupalcon à Boston, j'ai pu constater à quel point réunir au même endroit des développeurs intéressés pouvait créer des synergies et orienter les efforts autour de directions communes. Semblable au Search Sprint, un sprint s'est tenu à Paris et vient de se terminer avec la mise en place d'un système de tests unitaires automatisés pour Drupal, un gain énorme qui permettra d'accélérer le développement de la plateforme sans risquer d'en compromettre la qualité. Bref, ce genre d'évènement a fait ses preuves et, malgré la nature décentralisée et géographiquement dispersée à laquelle nous sommes habitués dans l'univers Drupal, tout le monde s'entend sur les bénéfices de ces sprints!

Nous ne règlerons pas tous les enjeux de la recherche sous Drupal lors d'un sprint de 3 jours, mais on pourra s'attendre à des résultats plus qu'intéressants.

Photos de Drupalcon Boston 2008

Thu, 13 Mar 2008 15:40:25 -0500

J'avais quatre journées pour immortaliser en images cette singulière congrégation de plus de 800 geeks à Drupalcon! Mais je me suis plutôt affairé à courir les présentations et les groupes de discussion... Heureusement, de nombreuses autres personnes se sont chargées de la chasse photographique, comme en témoignent les milliers de photos de Drupalcon Boston 2008 sur Flickr.

L'État de Drupal

Wed, 12 Mar 2008 20:32:27 -0500

Du 3 au 6 mars dernier, plus de 800 personnes intéressées par Drupal, concepteurs, programmeurs, designers, architectes de l'information, entrepreneurs et utilisateurs provenant de tous les coins de la planète (une dizaine venait de Montréal), ont convergé sur Boston pour la conférence Drupalcon Boston 2008. Voilà un évènement que je ne pouvais pas manquer!

Pour lancer la conférence, Dries Buytaert, fondateur du projet Drupal, a présenté son traditionnel discours "State of Drupal" faisant un tour d'horizon des plus récents accomplissements du projet et donnant un aperçu de ce qui s'en vient.

Des statistiques qu'il a présentées semblent confirmer une tendance ayant déjà été relevée par le passé: L'intérêt envers Drupal double à chaque nouvelle version majeure du logiciel. Drupal 6 a été lancé en février dernier après 9425 modifications au code source réalisées par 741 personnes. Un mois après son lancement, Drupal 6 avait déjà été téléchargé plus de 100 000 fois. En comparaison, le développement Drupal 5 avait sollicité 472 personnes pour 4927 modifications, tandis que cette version connaissait 50 000 téléchargements dès son premier mois d'existence.

Par ailleurs, à partir de sondages réalisés l'année dernière auprès de milliers de membres de la communauté Drupal, autant utilisateurs que développeurs, onze priorités ont été identifiées afin que le futur Drupal 7 réponde le mieux possible aux attentes exprimées:

Améliorer la prise en charge des contenus multimédia.
Intégrer la personnalisation des types de contenus.
Intégrer l'édition WYSIWYG.
Améliorer la performance.
Améliorer les outils pour structurer et organiser les contenus.
Intégrer une partie du module Views.
Automatiser les mises à jour.
Améliorer l'architecture de contrôle d'accès.
Améliorer les interfaces internes de programmation.
Améliorer les interfaces externes de programmation (importation/exportation, services Web).
Améliorer la convivialité.

Bien qu'il y ait peu d'éléments nouveaux dans cette liste, l'idée maîtresse est de solidifier ces aspects au sein du noyau Drupal afin d'offrir une plateforme plus solide pour les modules tiers. Par choix délibéré, ces objectifs demeurent plutôt vagues. En effet, il s'agit ici de logiciel libre! Par conséquent, le développement se fera, comme d'habitude, au gré des participants, en fonction de leurs intérêts et de leurs besoins, ou de ceux de leurs clients.

En outre, une stratégie de développement fort judicieuse (et ambitieuse) a été proposée: Développer une suite complète de tests unitaires pour le noyau Drupal. Ce plan est motivé par l'hypothèse selon laquelle la phase de "stabilisation" précédant le lancement de Drupal 7 pourrait être réduite à seulement trois mois, si une telle suite de tests existait, au lieu des sept mois ayant été nécessaires lors du cycle de développement de Drupal 6. Le pari a de quoi faire jubiler n'importe quel programmeur: Le cycle complet ayant une durée d'environ 12 mois, au lieu de disposer de seulement cinq mois pour développer de nouvelles fonctionnalités cool et hallucinantes pour le noyau Drupal, c'est de 9 mois dont nous disposerions!

Enfin, Dries s'est longuement attardé sur l'importance accrue des données (par rapport aux fonctions) dans un contexte "post-Web 2.0". L'interopérabilité est primordiale, surtout si l'on considère Drupal comme une plateforme de services Web. À cet égard, RDF jouera vraisemblablement un rôle important. D'ailleurs, il m'est apparut, tout au long des quatre jours de la conférence, qu'un grand nombre de personnes s'intéressait à la question et travaillait activement à harnacher le Web sémantique. Ainsi, peut-être Drupal contribuera-t-il à grandement élargir la portée du Web sémantique?

Réaliser un design pour Drupal - Partie 3 : La charte graphique

Wed, 21 Nov 2007 23:16:31 -0600

Ceci est le dernier d'une série de trois articles à travers lesquels j'explore les principales particularités de Drupal auxquelles doit faire face un designer graphique. Ceci s'adresse non seulement aux designers, mais également aux intégrateurs et programmeurs qui souhaiteraient communiquer quelques trucs à leurs équipes afin de créer des concepts graphiques bien adaptés à la plate-forme et, en même temps, réalisés plus rapidement. Ces articles seront particulièrement utiles aux designers ayant peu ou pas d'expérience avec des systèmes de gestion de contenus. Toutefois, j'ose croire que tout le monde pourra y trouver son compte, ne serait-ce que pour formaliser quelques idées. Un seul pré-requis : Avoir déjà conçu ou intégré un design Web.

Maintenant que nous connaissons la structure et les principaux éléments d'une page Drupal, le temps est enfin venu d'élaborer la charte graphique!

Puisque les contenus et éléments apparaissant dans une page sont hautement dynamiques, il est impossible de prévoir d'avance la teneur exacte d'une page. Par conséquent, il convient de penser la charte graphique d'un site dynamique en termes de normes graphiques applicables à une variété de contextes, un peu à la manière d'un cahier de normes graphiques pour une grande organisation. Bien sûr, l'on souhaite que la charte graphique inclue les maquettes des pages clés du site (notamment la page d'accueil), mais l'intégrateur aura surtout besoin de normes qu'il pourra appliquer aux différents éléments d'une page et qui pourront par la suite s'agencer dans une multitude de combinaisons (prévues ou non au moment de la conception graphique).

Lorsque les maquettes remises à l'intégrateur graphique sont conçues pour une structure fixe et un contenu pré-établi, l'intégrateur est confronté à plusieurs problèmes. Une telle maquette ne révèle ni la logique ou la réflexion ayant guidé les choix du designer, ni l'ensemble des éléments pouvant constituer une page générée dynamiquement ou altérée par l'interaction de l'utilisateur avec le système. Que survient-il si tel contenu vedette de la page d'accueil n'est pas accompagné d'une illustration tel que sur la maquette? À quoi doivent ressembler les sous-titres, si un éditeur en introduit dans un article? Qu'en est-il des tableaux et des listes numérotées? Peut-on ajouter un nouvel élément au menu sans casser le design? Où placer les menu d'administration du site qui ne sont pas visibles aux visiteurs normaux? Que fait-on avec les messages d'erreur? À quoi ressemblera la pagination si un grand nombre d'articles est ajouté? Que fait-on de la boîte « évènements à venir » lorsqu'elle est vide parce qu'aucun évènement n'est prévu? Comment adapter l'interface aux libellés plus longs de l'autre langue utilisée sur le site? Telles sont des questions typiques que posera l'intégrateur graphique.

En vue de créer une charte graphique adaptée aux systèmes de gestion de contenu — Drupal en particulier — je propose de l'articuler autour de quatre volets :

La plastique des pages.
Les normes graphiques générales.
Les normes graphiques spécifiques.
Les maquettes des pages clés du site.

La plastique des pages

Cette première section de la charte graphique présente les éléments structuraux requis par les différentes pages du site, sous forme schématique. À la différence du schéma wireframe typiquement produit pendant la phase d'architecture du site, plutôt que de procéder à l'identification des éléments de contenu, il s'agit ici de définir une structure sur laquelle reposeront les règles stylistiques.

Une notion essentielle à ce stade-ci consiste à identifier les zones à taille fixe et les zones « fluides » (à taille variable) de chaque modèle de page. La fluidité est une propriété fondamentale de la page Web suivant les normes XHTML et CSS, puisqu'on ne contrôle ni la taille de la fenêtre du fureteur, ni la taille et les caractéristiques exactes de la typographie. Soyons clairs : À moins d'avoir affaire à un élément de taille absolue tel une image, un extrait vidéo ou un objet Flash, tout élément possède une taille variable! Un titre qui entre sur une ligne chez un internaute pourrait très bien en exiger trois chez un autre.

La taille des éléments étant affectée par l'environnement dans lequel la page est visualisée, le design doit donc intégrer l'expansion et la contraction des différentes zones sur au moins sur l'axe vertical, sinon sur les deux axes (vertical et horizontal). Embrasser cette contrainte procure un double avantage : Non seulement la page devient-elle lisible sur un grand nombre de périphériques, aussi peut-elle accommoder les fréquentes modifications de contenus inhérentes à un système de gestion de contenu.

Voici un exemple illustrant cette notion. L'orientation du dégradé vert indique l'axe d'expansion ou de contraction (un dégradé en diagonale dénote une fluidité sur les deux axes), tandis que le rouge désigne une zone dont la taille est fixe sur les deux axes (tout contenu de taille excédentaire pourrait alors être tronqué ou empiéter sur d'autres zones) :

L'observateur averti pourra constater dans cet exemple une erreur de design (sans doute un compromis, en fait) : Les onglets et la boîte de recherche sont à taille verticale fixe, de telle sorte que ces zones ne peuvent accommoder une taille de caractères tellement différente (en hauteur) de celle espérée par la feuille de style du site.

Les normes graphiques générales

La seconde section de la charte graphique donne les principes généraux de la signature visuelle du site, ainsi que l'apparence par défaut de tous les éléments primitifs, notamment :

Paragraphes — (comme pour tous les autres éléments de forme textuelle de la présente liste, les propriétés suivantes peuvent être prises en considération : marges, justification, police, taille, graisse, interlignage, crénage, couleur du texte, couleur du fond, filet.
Titres et sous-titres — potentiellement jusqu'à six niveaux.
Listes numérotées et non numérotées.
Tableaux — incluant les en-têtes.
Citations, définitions, extraits de code.
Hyperliens — incluant les états : normal, courant (présentement visité), déjà visité, survolé par la souris, sélectionné au clavier.
Images — penser à : taille, marges, alignement, filets, légende, comportement du texte autour de l'image.
Boutons — incluant les états : normal, pressé, survolé par la souris, sélectionné au clavier.
Champs de formulaires — incluant les états : normal, erroné, courant (présentement manipulé), ainsi que leurs attributs (libellés et descriptions).

Ces éléments correspondent directement à des balises XHTML, mais j'ai également inclu quelques états et attributs qui sont presque aussi fondamentaux sous Drupal.

Les normes graphiques spécifiques

La troisième section de la charte graphique prescrit l'apparence des éléments primitifs dans différents contextes, lorsqu'elles diffèrent des normes graphiques générales. On peut varier l'apparence d'un titre, par exemple, en fonction de la page, de la région, du bloc, du noeud, de l'auteur du noeud, ou même d'une catégorie associée au noeud dans lequel ce apparaît ce titre. De cette façon, un site pourrait appliquer un style général aux articles apparaissant dans différentes pages du site, puis un style spécifique lorsque ces articles apparaissent dans la page d'accueil. Sur le même principe, on pourrait accompagner les articles d'icônes distincts selon qu'il s'agisse d'un communiqué, d'un texte de référence ou d'un billet de blogue.

Le nombre et la nature des contextes varie grandement d'un site à l'autre. Tous les éléments primitifs peuvent adopter une apparence propre au contexte auquel ils appartiennent.

Voici quelques exemples de contextes possibles, un contexte étant, finalement, l'un des multiples « contenants » pouvant englober l'élément auquel on cherche à appliquer un style :

Page.
Région.
Bloc.
Noeud
Menu.
Fil d'Ariane.
Pagination.
Informations du publication.
Liens contextuels.
Catégories associées au noeud.
Message informatif ou message d'erreur.
Élément identifié.
Balise XHTML.

Bien sûr, cette liste n'est pas exhaustive, puisque chaque projet a l'opportunité d'ajouter ses propres éléments ou contextes.

Plusieurs de ces contenants s'emboîtent comme des poupées russes; il est donc possible de tirer parti de combinaisons pour appliquer un style. Concrètement, ceci signifie qu'un design pourrait, par exemple, prescrire la règle générale d'afficher les hyperliens en bleu avec soulignement, tandis que ceux-ci seraient verts dans le contexte d'un bloc situé dans la région A, jaunes dans la région B et sans soulignement dans le contexte d'un menu. On peut définir des règles plus ou moins spécifiques comme, par exemple : Tous les boutons sont rouges, sauf le bouton « Rechercher » de la page d'accueil qui est vert. L'idée maîtresse est de penser le design en fonction de classes d'éléments plutôt qu'en fonction d'occurences singulières de ces éléments, puisque ces occurences sont particulièrement éphémères dans un système de gestion de contenu.

Il s'agit d'éviter les situations où aucune règle d'application de style ne peut être établie en fonction des contenants disponibles! Si, par exemple, la couleur rose était affectée à un paragraphe de manière purement arbitraire, cette propriété ne serait applicable qu'à l'aide d'un éditeur WYSIWYG, ou manuellement en modifiant directement le contenu en XHTML. Dans les deux cas, l'on retirerait à la feuille de style du site son rôle de maître de la présentation et déleguerait une partie de ce rôle aux rédacteurs ou intégrateurs du site. Le dynamisme des contenus fera en sorte que, inévitablement, la règle de style irrégulière deviendra rapidement caduque ou mal appliquée (nuisant à la cohérence visuelle du site); les rédacteurs auront de la difficulté à l'appliquer s'ils n'ont pas les ressources ou les connaissances techniques pour le faire. Tout attribut de style qui ne puisse être appliqué par une règle automatique et qui complique la rédaction des contenus devient un élément dissuasif à la création et à la mise à jour des contenus, ce qui, forcément, est à éviter!

Lorsque des éléments semblent manquants pour arriver à établir les règles d'application de styles nécessaires à la réalisation d'un certain concept visuel, généralement il suffira d'une discussion entre designer, intégrateur et/ou programmeur pour rapidement définir une solution.

Enfin, un bon truc pour aider le designer à identifier les éléments, les contextes, ainsi que les règles possibles consiste à lui fournir un prototype du site. En effet, un processus de travail fort efficace consiste à, avant que le travail de design graphique ne soit amorcé, d'abord bâtir un prototype fonctionnel (même incomplet) à partir des schémas (wireframes) acceptés par le client, puis de laisser ensuite au designer tout le loisir d'explorer la structure du système. Au besoin, des tests de validation technique pourront même être réalisés directement sur le prototype afin de déterminer la faisabilité de certains concepts visuels ou interactifs plus complexes, et ce avant même de soumettre des maquettes au client.

Les maquettes des pages clés du site

La dernière section de la charte graphique présente un aperçu détaillé des pages clés du site, de manière traditionnelle, c'est-à-dire sous la forme d'un écran pour chaque page — quoique, bien sûr, d'autres formes de présentation sont possible. Ceci permet d'appliquer à des cas concrets l'ensemble des normes graphiques. Le travail même de bâtir les maquettes constitue une occasion de valider les normes.

Bien entendu, la plupart des designers réaliseront des maquettes bien avant de se pencher sur le détail des normes graphiques et de leurs règles d'application! La table des matières de la charte graphique n'a pas à dicter le processus créatif!

Conclusion

Par cette série d'article, j'espère avoir couvert les principales particularités rencontrées lors de la réalisation d'un design graphique pour un système Drupal. J'ai présenté la structure et les éléments d'une page Web générée par Drupal, puis un format de charte graphique ayant pour objectifs, d'une part, l'adéquation du design à la plate-forme à laquelle il est destiné et, d'autre part, la mise en place d'un riche outil de communication utile au designer graphique et à l'intégrateur.

Il est certes très exigeant de construire une charte graphique aussi technique et détaillée que je le propose. À chaque équipe de décider jusqu'où aller en fonction de ses besoins et de ses aptitudes!

Tous les articles de la série : 1/ La structure d'une page. 2/ Les éléments d'une page. 3/ La charte graphique.

Réaliser un design pour Drupal - Partie 2 : Les éléments d'une page

Tue, 20 Nov 2007 18:52:52 -0600

Ceci est le second d'une série de trois articles à travers lesquels j'explore les principales particularités de Drupal auxquelles doit faire face un designer graphique. Ceci s'adresse non seulement aux designers, mais également aux intégrateurs et programmeurs qui souhaiteraient communiquer quelques trucs à leurs équipes afin de créer des concepts graphiques bien adaptés à la plate-forme et, en même temps, réalisés plus rapidement. Ces articles seront particulièrement utiles aux designers ayant peu ou pas d'expérience avec des systèmes de gestion de contenus. Toutefois, j'ose croire que tout le monde pourra y trouver son compte, ne serait-ce que pour formaliser quelques idées. Un seul pré-requis : Avoir déjà conçu ou intégré un design Web.

Dans l'article précédent, nous avons vu qu'une page Drupal se découpait en régions. Les régions sont des contenants aptes à accueillir différents éléments d'information. Ces derniers sont fort variés et doivent être considérés lors de l'élaboration d'une charte graphique. Je vais tenter d'en faire l'énumération :

Éléments de contenu :

Noeuds : Ces éléments sont typiquement créés et modifiés par des utilisateurs du site. Différents types de noeuds sont possibles, par exemple : articles, nouvelles, billets, évènements, fiche de membre, notice bibliographique, etc. Chaque type de noeud comporte ses propres champs, par exemple : titre, corps, auteur, date de création, date d'évènement, adresse, code ISBN, etc. L'éventail de types de noeuds de même que le détail des champs est hautement personnalisable; chaque projet définira ceux qui sont requis. Sur le plan du design, il sera nécessaire d'établir comment seront présentés chacun des éléments d'information. Le noeud est la principale unité de contenu sous Drupal et l'essence d'un site basé sur Drupal tourne autour de la manipulation des noeuds. Le coeur de la plupart des pages est constitué soit d'un noeud, soit d'une liste de noeuds (ou vue). Une vue présente des champs de noeuds choisis selon certains critères (par exemple : une en ordre chronologique montrant le titre et l'auteur de tous les noeuds classés dans une catégorie « design »). Lorsqu'une page contenant une vue est demandée par un visiteur, le système recueille et présente dynamiquement tous les noeuds correspondant aux critères associés à cette vue. Encore une fois, le designer a donc affaire à du contenu dynamique.
Blocs : Les blocs sont des éléments d'information qui, généralement, servent à offrir l'accès à différentes fonctionnalités du site ou à offrir un complément d'information relatif au noeud (ou à la vue) présenté dans la page. Les blocs sont créés par des utilisateurs, contiennent une vue sur plusieurs noeuds, ou sont générés par différents modules du système. Comme les noeuds, les blocs sont hautement dynamiques et contextuels. Les blocs sont positionnés dans des régions par les administrateur du site et certains blocs n'apparaissent que dans certaines pages ou à certains utilisateurs. Par exemple, le bloc de connexion montre un formulaire où entrer un identifiant et mot de passe, mais disparaît une fois la connexion établie. Sur drupal.org, la table des matières d'une page de documentation n'apparaît que lorsque l'une des pages du manuel est visitée.

Éléments de navigation :

Menus : Les menus sont généralement le principal outil de navigation du site. Ceux-ci sont également dynamiques, puisque leur contenu exact peut varier selon le contexte et les droits d'accès de l'utilisateur. Les menus sont positionnés dans des régions et peuvent prendre différentes formes selon le contexte et le design souhaité : listes de liens, listes déroulantes, onglets.
Fil d'Ariane : Un outil d'aide à la navigation fréquemment offert, le fil d'Ariane est généré automatiquement par Drupal afin de présenter une piste du chemin parcouru par le visiteur pour atteindre la page courante.
Pagination : La pagination permet de naviguer dans des listes d'éléments (noeuds ou autres) réparties sur plusieurs pages. Quelques exemples d'éléments communément utilisés dans la pagination : liens vers la première et la dernière page, liens vers la page précédente et la suivante, indication de la page courante, nombre total d'éléments, etc.
Informations de publication : Un noeud est souvent accompagné de certaines métadonnées, telles que son auteur et sa date de publication. Ceci est tout à fait analogue à un champ, mais la présentation en est souvent distincte. En outre, il peut s'agir d'un élément de navigation, puisque le nom de l'auteur est couramment offert comme un hyperlien vers un profil de membre.
Liens contextuels : Un noeud est fréquemment accompagné de liens contextuels, par exemple : lien donnant accès au texte intégral, lien vers un fichier joint, lien pour ajouter un commentaire.
Catégories : Beaucoup de sites présentent des listes de catégories associées à chaque noeud en guise d'outil de navigation supplémentaire, une fonction offerte par Drupal à la base.

Éléments d'interface :

Messages : Les messages sont produits par le système pour fournir des informations utiles au visiteur. Deux types de messages sont produits : messages d'information et messages d'erreur. Plusieurs messages peuvent être présentés simultanément, auquel cas une liste HTML est utilisée comme contenant.
Formulaires : Pratiquement tous les sites comportent des formulaires permettant aux utilisateurs de saisir des informations, par exemple : formulaire de connexion, formulaire de contact, formulaire de commentaire, demande d'adhésion au site. Une variété d'éléments graphiques sont à prévoir dans un formulaire : Champ (texte, liste, liste déroulante, bouton radio ou case à cocher), titre de champ, description de champ, bouton, indicateur de champ obligatoire, regroupement de champs (ouvert ou fermé). À noter qu'un message est généré lorsqu'une erreur de saisie est faite dans un formulaire, tandis que les champs erronés sont soulignés de manière plus visible.

Voici un aperçu de quelques-uns des éléments mentionnés ci-dessus :

Légende :

Et voici un exemple de formulaire accompagné d'un message d'erreur :

Bien entendu, la plupart des sites quelque peu avancés comporteront des éléments supplémentaires; un calendrier ou un système d'évaluation (vote) des contenus sont des cas fréquents. J'ai tenté ici d'énumérer les éléments communs à presque tous les sites Drupal. Ces éléments devraient toujours faire l'objet d'une réflexion de design — et bien sûr, on peut par cette réflexion décider d'en omettre quelques uns ou d'altérer grandement leur apparence de base!

Drupal offre une pleine latitude sur la forme de ces éléments. Une critique souvent entendue est que beaucoup de sites Drupal se ressemblent, une situation que je dois admettre comme plutôt vraie. Cependant, ceci s'explique de deux ou trois façons, soit un faible investissement en conceptualisation graphique ou, tout simplement, l'omission par le designer prendre tous les éléments en considération. En outre, il arrive que l'intégrateur graphique ou le programmeur ne sache pousser la machine à fond, faute de connaître suffisamment la plate-forme (Drupal est encore nouveau pour un grand nombre de professionnels). Au final, les éléments graphiques qui ont été omis lors du design ou de l'intégration héritent tout simplement de la forme par défaut proposée par Drupal.

Nous avons maintenant les outils nécessaires pour développer la charte graphique, sujet de l'article suivant.

Tous les articles de la série : 1/ La structure d'une page. 2/ Les éléments d'une page. 3/ La charte graphique.

Réaliser un design pour Drupal - Partie 1 : La structure d'une page

Tue, 20 Nov 2007 17:19:17 -0600

Ceci est le premier d'une série de trois articles à travers lesquels j'explore les principales particularités de Drupal auxquelles doit faire face un designer graphique. Ceci s'adresse non seulement aux designers, mais également aux intégrateurs et programmeurs qui souhaiteraient communiquer quelques trucs à leurs équipes afin de créer des concepts graphiques bien adaptés à la plate-forme et, en même temps, réalisés plus rapidement. Ces articles seront particulièrement utiles aux designers ayant peu ou pas d'expérience avec des systèmes de gestion de contenus. Toutefois, j'ose croire que tout le monde pourra y trouver son compte, ne serait-ce que pour formaliser quelques idées. Un seul pré-requis : Avoir déjà conçu ou intégré un design Web.

Un système de gestion de contenu tel que Drupal offre aux utilisateurs d'un site Web un plein contrôle sur les contenus. Différents utilisateurs jouent différents rôles sur le site, qu'il s'agisse de l'administration, de la modération, de la rédaction, de la révision ou de la traduction des contenus, ou tout simplement de la rédaction de commentaires rattachés aux contenus (comme dans le cas d'un blogue ou d'un forum de discussion, par exemple). Les contenus sont créés et gérés directement sur le système, souvent par des individus ayant peu de connaissances techniques, sans qu'il ne soit nécessaire d'utiliser un logiciel tiers ou de faire appel à un designer ou un technicien.

Ainsi, les contenus sont extrêmement dynamiques, grandement hors du contrôle du designer. Non seulement les contenus sont-ils hautement variables, mais les contrôles d'accès font en sorte que différentes fonctions du système et différents contenus seront exposés à différents utilisateurs selon les accès autorisés à chacun, ce qui affecte également l'apparence des pages présentées aux internautes.

Ce dynamisme amène la nécessité de concevoir la structure des pages non pas en fonction de contenus spécifiques, mais plutôt en fonction de différentes régions qui contiendront des contenus, sans connaissance préalable de la nature exacte des contenus. Chaque région devient en quelque sorte un mur accueillant une ou plusieurs oeuvres (contenus), ajoutés, supprimés ou modifiés au fil du temps. La région elle-même prend place dans une page, à la manière d'une salle dans un musée. Bref, suivant cette métaphore, le site est comme un musée renfermant plusieurs salles (pages), elles-mêmes pourvues de murs (régions), auxquels se rattachent plusieurs oeuvres (contenus).

Voici un schéma des régions (en rouge translucide) utilisées sur une page du site drupal.org :

Il est possible de créer autant de régions que requis par le design et de leur assigner différents éléments, ce qui permet à différents sites d'adopter des structures plus ou moins complexes. En outre, certaines régions peuvent apparaître seulement lorsqu'elles contiennent des éléments, comme c'est le cas de la colonne de gauche (numéro 2 ci-dessous) dans une page de documentation de drupal.org :

Les régions sont l'une des principales unités de structure d'une page. L'article suivant aborde les autres types d'éléments que comporte la page.

Tous les articles de la série : 1/ La structure d'une page. 2/ Les éléments d'une page. 3/ La charte graphique.

Pour de la documentation plus technique liée à la création d'un « thème » Drupal, le lecteur peut se référer à d'autres ouvrages, tels le Theme Developer's Guide ou l'excellent chapitre 8 du livre Pro Drupal Development.

2007-11-22 — mise à jour : Merci à Patrick Fournier pour la métaphore du musée, plus visuelle et plus claire que la précédente!