Rubriques et assemblages

« Franchement, je crois qu’on est en pleine bataille : Blobs contre Chunks. » Nous sommes dans une guerre entre des blobs de contenu géants et non structurés, et des champs de contenu propres et bien structurés auxquels sont attachées des métadonnées. Nous sommes en pleine bataille : Blobs contre Chunks. Vous faites tous partie de l’équipe Chunk. Nous ne pouvons pas laisser les blobs gagner. » — Karen McGrane

Tous les gestionnaires de contenu étaient sous le choc. Une guerre ? Dans la gestion de contenu ? Les guerres, ce n’était pas seulement entre les utilisateurs d’éditeurs de texte Unix ? Pourquoi quelqu’un ferait-il la guerre dans le monde des systèmes de gestion de contenu (CMS) ? Après tout, ce qui réunissait les responsables de contenu, c’était la conviction que tous les CMS laissaient à désirer. Cela avait permis de maintenir la paix, même si elle restait fragile.

Alors pourquoi Karen McGrane les appelait-elle à la guerre ? Les CMS traditionnels sont les descendants des « systèmes de publication assistée par ordinateur », dans lesquels les éditeurs concevaient des pages — généralement destinées à l’impression — en utilisant des fonctions WYSIWYG (What You See Is What You Get).

Pour la publication imprimée, le format de sortie était fixe. Avant le numérique, la réutilisation n’était pas une priorité. Republier le même contenu signifiait généralement le redessiner.

Cela pose problème pour les plateformes numériques. Les responsables de contenu l’ont toujours su ; ils avaient simplement accepté qu’il était de leur cruel destin de devoir concevoir chaque page du Web une par une.

Cependant, avec l’arrivée sur le marché de nouveaux appareils de toutes formes, tailles et formats, le nombre de jeux de polices, de résolutions, de profondeurs de pixels et de capacités des appareils s’est multiplié. Il est devenu douloureusement évident que les plateformes numériques ne pouvaient pas servir du contenu en utilisant les mêmes méthodes et les mêmes flux de travail que ceux créés pour la publication imprimée.

Avec la prolifération des plateformes, le WYSIWYG (What You See Is What You Get) est vite devenu WYSIWTF (What You See Is What The…).

Karen McGrane explique :

« L’ère de la publication assistée par ordinateur est terminée. Même chose à l’époque où l’on donnait la priorité absolue à l’interface web sur desktop. Les outils que nous créons pour gérer notre contenu sont des vestiges de la révolution de la publication assistée par ordinateur, où l’on cherchait à permettre la manipulation la plus directe possible du contenu. Dans un monde où les sorties possibles de notre contenu sont infinies, il est temps de dépasser les outils qui s’appuient sur le style visuel pour transmettre un sens sémantique. Si nous voulons une véritable séparation du contenu et de la forme, cela doit commencer dans le CMS.

Nous avions besoin d’une véritable séparation du contenu et du contexte dans lequel il apparaissait. Et nous avions besoin de cette séparation dans le CMS.

Contenu organisé en blobs

Qu’est-ce qu’un blob, exactement ? Karen explique :

« Nous avons des CMS qui permettent aux gens de dire : « Je veux que cela fonctionne comme Microsoft Word. » Je veux pouvoir intégrer des tableaux, des polices et des images, et je veux pouvoir styliser et concevoir mon contenu de manière à ce qu’il corresponde parfaitement à l’idée que je me fais de son apparence et de son fonctionnement. Je veux un outil qui fonctionne exactement comme Microsoft Word, afin de pouvoir imaginer l’apparence et le fonctionnement de mon contenu dans l’unique contexte que j’ai en tête : le site web en version desktop. Du coup, des personnes peuvent créer d’énormes blobs de contenu non structuré, avec de la mise en forme, des images et tout le reste intégrés. »

Un blob est une collection de données produites par des éditeurs de type WYSIWYG qui permettent aux éditeurs d’intégrer des polices, des tableaux, des images et tout autre élément dans leur contenu.

Le problème, c’est que ce n’est pas la meilleure façon de travailler, mais pratiquement toutes les plateformes CMS existantes fonctionnent de cette façon.

Andrew, un utilisateur de StackOverflow, a décrit le flux de travail de contenu lors de l’utilisation d’un CMS basé sur des blobs, alors qu’il essayait de trouver un CMS qui prenait en charge le contenu adaptatif :

« Avec un outil de publication Web traditionnel, j’aurais probablement dû créer une nouvelle page sous Actualités, puis taper et mettre en forme l’article d’actualité dans un éditeur de texte WYSIWYG vierge. — c’est-à-dire des pages de contenu »

En revanche, la plateforme de contenu qu’il recherchait fonctionnerait différemment :

« Je dirais au CMS le type de contenu que je crée, et on me demanderait de remplir un formulaire avec des champs individuels adaptés aux articles d’actualité (par exemple, titre, sous-titre, texte intégral, extrait court et images). — c’est-à-dire des éléments de contenu »

La guerre des chunks contre les blobs a été immédiatement stoppée sur ce fil de discussion de StackOverflow, la discussion étant close sous prétexte que la question n’était « pas constructive ».

Contentful est une infrastructure de contenu qui répond à des besoins tels que ceux d’Andrew pour une plateforme de contenu, et plus encore. Elle vous permet de définir votre contenu par des éléments individuels, en utilisant des types de contenu composés de champs et de références, puis en fournissant ce contenu via une API ; ce qui lui permet d’être présenté dans n’importe quel contexte, sur n’importe quelle plateforme, avec n’importe quelle pile technologique.

Il est important de noter que l’API est un élément clé ici, notamment en raison de son mode de fonctionnement. De nombreuses plateformes CMS de style publication assistée par ordinateur disposent également d’une API ; cependant, celles-ci sont basées sur des blobs et équivalent à du contenu fourni via « Blobs as a Service », plutôt que de fournir du contenu directement via l’API.

Nous n’avons pas besoin d’API qui fournissent des blobs. Nous avons besoin d’API qui fournissent des chunks.

Karen McGrane est notre sensei. Elle nous montre pourquoi les CMS traditionnels, issus de la publication assistée par ordinateur et fonctionnant en termes de pages, sont une mauvaise solution pour la diffusion numérique de contenu.

Une page n’est pas du contenu, jeune sauterelle, c’est un contexte dans lequel le contenu s’affiche.

Bruce Lee nous permet de comprendre cela plus en profondeur :

« Videz votre esprit, soyez sans forme, sans contour, comme l’eau. Maintenant, vous mettez de l’eau dans une tasse, elle devient la tasse, vous mettez de l’eau dans une bouteille, elle devient la bouteille, vous la mettez dans une théière, elle devient la théière. Maintenant, l’eau peut couler ou elle peut s’écraser. Soyez comme l’eau, mes amis. »

Le contenu est comme l’eau, et la grande variété de plateformes numériques exige que le contenu de fond soit défini en tenant compte de la validation et de la réutilisation, et qu’il soit séparé du contexte et de la structure.

Cela nécessite une approche centrée sur le sujet, plutôt qu’une approche centrée sur la page.

Ann Rockley, une experte de premier plan dans l’organisation et la présentation d’informations en ligne, et une vétérante de la guerre contre les blobs, a développé son concept de « contenu intelligent » depuis longtemps. Elle explique :

« Le contenu intelligent est un contenu structurellement riche et sémantiquement catégorisé, et donc automatiquement détectable, réutilisable, reconfigurable et adaptable. »

Ann Rockley a eu une influence majeure sur la Darwin Information Typing Architecture (DITA), un modèle de données XML pour la création et la publication. XML est un format de données conçu pour être lisible à la fois par l’homme et par la machine. Il ne fait bien ni l’un ni l’autre et, à l’instar des piqûres de moustique, provoque souvent une réaction allergique chez les développeurs.

Les piqûres de moustiques ne sont pas intrinsèquement irritantes : c’est une réaction allergique qui provoque les démangeaisons ; il se trouve que presque tout le monde a cette allergie. Selon une théorie, les moustiques transmettent diverses maladies, mais les personnes allergiques à leurs piqûres avaient tendance à s’éloigner des zones très peuplées de moustiques et à se protéger, ce qui leur permettait d’éviter également les maladies associées.

La raison pour laquelle presque tout le monde aujourd’hui présente cette allergie, c’est que nos ancêtres ont agi ainsi. Ceux qui n’étaient pas allergiques n’étaient pas tellement gênés par les piqûres, et n’ont pas quitté les zones infestées ou pris ces mesures, et n’ont donc pas survécu pour devenir des ancêtres. Il a dû y avoir, à un moment donné, des développeurs qui n’étaient pas allergiques au XML. Nous ne savons pas ce qu’ils sont devenus.

Qu’est-ce qu’une rubrique ?

Cependant, DITA nous donne une arme clé dans notre guerre contre les blobs, la « rubrique ».

Votre modèle de contenu doit inclure des rubriques bien définies. Les rubriques sont ce dont parle votre application ou votre site. Peut-être avez-vous un écran de montre connectée qui affiche les prochains événements ; ces événements seraient les rubriques. Peut-être que votre application a un composant carrousel avec des produits connexes ; les produits seraient les rubriques. Peut-être avez-vous une page Web présentant des articles ; les articles seraient les rubriques.

Votre modèle de contenu doit inclure des types de contenu qui forment vos rubriques. Les événements, les articles, les produits et tout ce que vous avez doivent être définis comme des types de contenu, décomposés en champs nécessaires et inclure des validations pour s’assurer qu’ils sont correctement saisis.

Les rubriques doivent :

• Pouvoir être créés individuellement. Chaque rubrique concerne un domaine et peut être créée indépendamment.

• Toujours être réutilisables. Une rubrique peut apparaître à plusieurs endroits et sur différents canaux. Elle ne doit donc pas être verrouillée sur un contenu ou une mise en page spécifique et doit être utilisable partout.

• Être compréhensible indépendamment. Chaque rubrique doit être suffisamment complète pour pouvoir être présentée de manière indépendante.

Un événement, par exemple, est un contenu que vous voulez voir à la fois sur une page web et sur un écran de montre, donc dans plusieurs contextes différents.

C’est le concept : les éditeurs ne devraient pas avoir à multiplier leurs efforts en dupliquant les rubriques. Le dicton « Créer une fois, publier partout », rendu célèbre par NPR, décrit cette idée.

Par exemple, au lieu d’avoir une version initiale de l’événement pour le Web et une version copiée-collée pour un écran de montre, les éditeurs devraient pouvoir réutiliser le même événement partout.

Lors de la création de vos rubriques, il est important de vous assurer que chacune d’entre elles dispose de types de contenu propres et distincts. Même lorsqu’elles partagent les mêmes champs que d’autres types de contenu, elles ont souvent des modèles de gouvernance différents, nécessitant des autorisations, des plans d’internationalisation, des exigences fonctionnelles sur le front-end et des exigences d’organisation différents. Rachel Lovinger donne l’exemple suivant :

« Un communiqué de presse peut être très similaire à une page de contenu générale, mais seul le type Communiqué de presse apparaîtra dans une Newsroom agrégée automatiquement. Il est plus facile de les filtrer s’il s’agit d’un type de contenu unique. »

Pour diffuser des rubriques sur plusieurs canaux, elles doivent être exemptes de toute mise en page et de tout contexte prédéfinis, et composées d’éléments de contenu sous forme de champs et de références.

Votre collection de rubriques peut être vue comme le modèle de domaine de votre contenu. Une fois que vous avez vos rubriques, vos auteurs peuvent créer du contenu.

Qu’est-ce qu’un assemblage ?

Dans la plupart des cas, les éditeurs auront toujours besoin d’un moyen de gérer les contextes dans lesquels ces rubriques apparaissent. Rachel Lovinger appelle cela le modèle d’assemblage, qu’elle décrit comme « la façon dont les créateurs de contenu assembleront des éléments de contenu individuels pour créer des pages Web, des campagnes, des documents ou d’autres produits de contenu ».

Pour construire votre modèle d’assemblage, vous créerez des assemblages en plus de vos rubriques. Les assemblages sont également des types de contenu, mais généralement avec des champs moins diversifiés, car ils ne décrivent pas le sujet de votre site, mais plutôt la façon dont il est assemblé.

• Les assemblages ont des champs liés à la mise en page et à la navigation du site ; ils peuvent également inclure des métadonnées supplémentaires pour le référencement ou l’analyse d’audience, mais ne portent aucun contenu. Les assemblages utilisent des champs de référence pour faire référence à des rubriques.

• Les assemblages peuvent être imbriqués à l’intérieur d’autres assemblages, de sorte qu’ils peuvent également avoir des champs de référence qui font référence à d’autres assemblages.

• Les assemblages structurent votre contenu pour le présenter à l’utilisateur final.

Des d’assemblages peuvent être par exemple un carrousel, un ensemble d’événements en vedette, une mise en page modulaire, une page de base, etc.

Vous pouvez commencer à planifier votre modèle d’assemblage en décomposant la conception ou le wireframe de votre application ou de votre site. Chaque zone de la page et la page elle-même est une entrée d’un type de contenu d’assemblage.

Par exemple, un assemblage de page peut avoir un identifiant d’URL, un code Google Analytics et un ensemble de références permettant à un éditeur de sélectionner des modules de page ; y compris les composants dans le wireframe (c’est-à-dire une bannière, un carrousel de produits, une vidéo en vedette et un article en vedette).

Les assemblages ne peuvent pas être créés ou modifiés individuellement, mais ils peuvent être gérés individuellement. Contrairement aux rubriques, les assemblages ne peuvent pas être créés individuellement, car ils font référence à des rubriques et à d’autres assemblages. Pour créer une rubrique, il suffit de remplir certains champs, mais avec des assemblages, il faut créer toutes les rubriques qui le composent et les rassembler dans un assemblage. Lors de l’ajout de nouvelles rubriques, cela peut être fait en même temps que l’ajout de l’assemblage. Lors de la réutilisation de rubriques, l’assemblage sert à référencer des entrées de rubrique existantes.

Qu’un seul créateur de contenu rédige ou non toutes les rubriques qui constituent un assemblage complet, il doit être possible pour un seul créateur de contenu d’en assurer la maintenance dans son ensemble. La maintenance individuelle signifie qu’une seule personne est capable de gérer tous les composants d’un assemblage.

Les assemblages sont parfois réutilisables. Si les rubriques sont toujours réutilisables (par exemple, un événement peut apparaître dans de nombreux contextes différents), ce n’est pas toujours le cas des assemblages. Les assemblages structurent la façon dont les rubriques sont présentées et relient les rubriques aux contextes dans lesquels elles apparaissent. Certains assemblages peuvent être liés au contexte et, par conséquent, ne sont pas réutilisables.

Par exemple, un carrousel d’événements est effectivement réutilisable : il est peut-être judicieux que le même carrousel apparaisse à la fois sur une application et sur une page Web. D’autre part, une mise en page modulaire peut être utile pour les pages Web, mais pas pour un écran de montre. Il est possible que les mêmes rubriques soient présentées différemment lorsqu’elles sont affichées séparément sur un écran de montre et sur une page Web. Une mise en page modulaire fonctionnerait alors très bien pour la page Web, mais pas pour la montre.

Alors que les rubriques sont compréhensibles de manière indépendante — il suffit de consulter une rubrique pour savoir de quoi il s’agit — les assemblages, eux, sont incompréhensibles pris isolément. Cela signifie qu’un assemblage n’a aucun sens sans les rubriques auxquelles il fait référence, car il sert uniquement à composer des rubriques pour l’affichage.

Les assemblages vous permettent de créer des validations garantissant qu’un contenu valide et complet est composé et présenté à l’utilisateur.

Par exemple, dans un assemblage strict, chaque champ n’accepte qu’une seule valeur ou référence (comme dans le cas d’une page composée de trois blocs). Le type de contenu de l’assemblage peut comporter trois champs : « bannière principale », « carrousel de produits » et « offres spéciales ». Chacun de ces champs serait validé pour n’autoriser que le type de contenu approprié, permettant aux éditeurs de sélectionner les modules de page à inclure dans la page, mais pas de les positionner.

Changer la position de ces modules est moins simple. Par exemple, pour déplacer le carrousel de produits vers le bas et les offres spéciales vers le milieu, il faudrait modifier le code et redéployer le logiciel.

Une alternative consiste à utiliser un assemblage flexible, où au lieu d’utiliser des champs de référence uniques validés pour un seul type de contenu, un champ de référence multiple est utilisé et validé pour les trois types de contenu.

L’utilisation d’assemblages flexibles permet aux éditeurs de sélectionner tous les types de contenu valides et de les trier, ce qui leur permet d’organiser et de commercialiser le contenu par eux-mêmes sans l’intervention d’un développeur.

Les assemblages fixes sont parfaits pour les équipes axées sur les développeurs qui souhaitent contrôler la mise en page exclusivement dans le code, et permettre à des équipes plus axées sur l’éditorial de donner de la flexibilité à leurs éditeurs.

Votre collection d’assemblages peut être vue comme le pont entre votre modèle de domaine, tel qu’exprimé dans vos rubriques, et votre modèle d’affichage, qui est finalement rendu par vos modèles et composants front-end.

Les propriétés de vos composants et les espaces réservés dans vos modèles correspondront aux champs de vos types de contenu.

Synthèse

Les rubriques et les assemblages sont vos meilleurs atouts pour gérer la différence entre contenus découpés (chunks) et contenus massifs (blobs). En décomposant les thèmes de votre site ou application en rubriques claires, réutilisables et validables, puis en utilisant des assemblages imbriqués pour composer ces rubriques en vue de leur affichage sur différents canaux, nous pouvons gagner cette bataille en faveur de l’équipe chunk. Contentful est de votre côté, et nous sommes là pour vous aider.

Par Dmytri Kleiner et Stephen Pastan