Back-Office et Drupal : quelques pistes (Partie 1)

En auditant ou simplement en voyant récemment quelques sites réalisés par mes concurrents mais néanmoins concurrents sous drupal 6, une évidence m'a sauté au visage : le Back-Office contributeurs (webmasters, éditeurs, journalistes...) de la plupart des sites réalisés sous drupal n'est souvent pas à la hauteur du niveau fonctionnel du Front-Office. Je ne dis pas que c'est le cas de tous les projets sous drupal, mais le manque de temps (et surement de poste budgétaire), et/ou de connaissance de certains modules sur ces sites font qu'un super site se transforme en cauchemar à administrer pour le client, avec une interface soviétique à faire pâlir d'envie Youri Gagarine.

Forcément, drupal est réputé pour sa faible ergonomie par défaut, et cela fait les beaux jours des éternels trollsdébats sur la guerre des mondes Wordpress/Drupal, comme dans ce genre de manifestation où votre serviteur était présent (bien que flou).

Inventaire à la Prévert de mauvaises pratiques rencontrées

Pour illustrer mon propos, un florilège de Back-Office minimalistes rencontrés au hasard de mes explorations drupalistiques, y compris mes vieux projets (ceci n'engage que moi et ceux qui auraient envie de m'écouter).

Ce bon vieux garland en thème d'administration

Qu'on ne s'étonne pas après si la plupart des gens pensent que drupal est une chose bleue : pourquoi s'acharner à infliger aux clients ce thème de démo, et pousser le vice jusqu'à le proposer comme thème d'administration (outre le faire que je ne suis pas prsonnellement convaincu de l'intérêt d'utiliser la fonctionnalité : "Thème pour le Administrateurs", qui à mon sens détériore plus l'ergonomie qu'elle ne l'améliore).

Aucun bloc/menu dédié aux administrateurs

Même si aucun poste budgétaire n'est prévu pour développer un Back-Office digne de ce nom sur un projet, créer un menu dédié aux administrateurs regroupant les fonctionnalités de base, et leur fournir ce bloc lorsqu'ils sont logués est le minimum syndical (et non, le menu par défaut "Navigation" et l'excellent module admin_menu ne vont pas aider les webmasters à s'y retrouver dans le jungle de drupal).

Une recherche de contenu se résumant à la simple page admin/content/node/overview

Avouez que y'a plus sexy et fonctionnel que cette page qui date de drupal 4 ! Et honnêtement, cela prend moins d'une heure à refaire avec une View, et sera nettement plus évolutif.

Sans même parler de la granularité des permissions sur cette page...

Des formulaires d'ajout/modification de nodes kafkaïens

L'inventaire serait long mais au moins, donnons-nous la peine sur ces formulaires de :

• traduire les termes apparents pour le end-user (aucune excuse avec le module l10n_client)
• ordonner et organiser le CCK (en fieldgroup par exemple) de manière logique
• paramétrer les formats d'entrée et l'editeur rich text
• masquer les fieldgroups qui ne servent pas pour l'utilisateur final (souvent en configurant correctement les permissions utilisateurs)

Mais alors, que faire ?

Il existe un ensemble de bonnes pratiques à mettre en oeuvre qui vous aideront à combler les faiblesses innées de drupal au niveau du Back-Office (d'ailleurs la plupart de ces bonnes pratiques ont été mises en oeuvre dans la version 7).

Vous trouverez ci-dessous quelques pistes et modules intéressants, je n'ai aucune prétention à être exhaustif et servir de référence.

Travailler la présentation et l'ergonomie du formulaire d'ajout/édition de node (node/xxxx/edit)

C'est l'élément de Back-Offcie dans lequel les utilisateurs passent plus de la moitié de leur temps, alors c'est par là que vous devez commencer :

• Veillez à ce que tous les éléments de cette page soient localisés (traduits en français)
• N'hésitez pas à travailler les titre et les textes d'aide de vos champs (core et CCK)
• Pensez à organiser (FieldSets et CCK Multigroups, repliés par défaut si pas de champ obligatoire en leur sein) et ordonner de manière logique pour le contributeur ce formulaire
• Un CCK FileField ou ImageField ? Vérifiez que vous avez activé l'option avec barre de progression dans les paramètres du champ (cf ce billet de blog)

Wysywig mon amour

Un éditeur rich text est la norme de tout CMS aujourd'hui, mais il existe un tas de modules/astuces vous permettant d'offrir la meilleur expérience à vos utilisateurs :

• WYSIWYG : la base pour Drupal 6. C'est LA méthode pour implémenter un ou plusieurs éditeurs rich text en s'appuyant sur une API puissante. A OWS, on a une légère préférence pour TinyMCE (cf modules suivants)
• IMCE : Gestionnaire d'images et de fichiers pour TinyMCE, il constitue un excellent point de départ pour la mise en oeuvre d'une bibliothèque de médias partagée entre les contributeurs (ne pas oublier d'installer le module IMCE Wysiwyg Bridge si vous utilisez TinyMCE avec Wysiwig)
• TinyMCE Node Picker : Longtemps absent de drupal 6, ce module vous permet de créer de manière ergonomique des liens vers vos contenus interne, sans avoir à en connaitre l'url. L'interface de recherche utilise Views, aussi votre imagination est la seule limite à son ergonomie ! (on me parle aussi du module similaire Linkit, mais je ne l'ai pas testé)
• N'oubliez pas de paramétrer vos formats d'entrée (le contributeur ne doit même pas à avoir à choisir un format d'entrée) et vos filtres HTML. Je vous conseille à cet usage le module Better Formats qui couvre la plupart des cas d'utilisation.

Ces petits (ou presque) modules qui vous changent la vie

Toujours en parlant du formulaire d'édition de node, voici une liste de modules indispensables pour le rendre sexy :

• CheckAll : Créé par markus_petrux, le maintainer de cck pour drupal 6 (cela veut dire : module de bonne facture ;-) ), ce tout petit module vous permet d'ajouter (par interface et en programmation) une checkbox vous permettant de cocher/décocher/inverser toute une liste de checkboxes. Simple mais tellement efficace
• Node Relationships : Bon là, on est sur du très très lourd, mais à mon humble avis, ce module est indispensable à tout site drupal utilisant le système CCK de nodereference. Je pense que cet autre module de markus_petrux méritera un autre billet de blog à part entière
• Vertical Tabs : Backport de Drupal 7, c'est un des changements majeurs du formulaire d'édition du node, qui le rend d'un seul coup limpide. A utiliser sans modération
• Content Taxonomy : Oubliez à jamais l'utilisation des champs fournis par défaut par le module Taxonomy. Content Taxonomy est LE module à utiliser pour gérer les taxonomies dans les nodes (d'ailleurs il est dans le core Drupal 7)
• Hierarchical Select : Si vous devez gérer des taxonomies arborescentes qui contiennent plus de 10 termes de taxo, alors ce module est fait pour vous. Vivement conseillé car l'utilisateur final remarquera la qualité de l'interface de saisie

"Ca vous a plu hein, vous en voulez encore" (Bonnie and Clyde)

Dans le prochain épisode de ce billet je vous parlerai de Views et de son utilisation pour des vues d'administration fantastiques, et des pistes à explorer pour offrir au contributeur un tableau de bord digne de ce nom.

Et j'essaierai aussi de mettre à jour ce billet avec des screenshots !

N'hésitez pas à me contacter sur twitter (@slybud) si vous voulez en discuter.