Stratégies pour les projets sans tête avec des systèmes de gestion de contenu structurés

C'est le guide que j'aurais aimé avoir ces deux dernières années lors de l'exécution de projets avec des systèmes de gestion de contenu (CMS) sans tête. J'ai été développeur, consultant en expérience utilisateur et technologie, chef de projet, architecte de l'information et auteur. Les différentes casquettes m'ont fait prendre conscience que même si nous avons depuis un moment des CMS dits « headless », il reste encore du chemin à parcourir pour réfléchir à la meilleure façon de les utiliser.

Nous sommes maintenant à un endroit où beaucoup d'entre nous s'appuient sur des frameworks JavaScript pour le travail frontal, en utilisant des systèmes de conception constitués de composants et de compositions, plutôt que de simplement mettre en œuvre des mises en page plates. Il y a beaucoup de traction vers les JAMstacks et les applications isomorphes/universelles qui s'exécutent à la fois sur le serveur et le client. La dernière pièce du puzzle est alors la façon dont nous gérons tout le contenu.

Les CMS traditionnels ajoutent des API pour diffuser du contenu via des requêtes réseau et le format JSON. De plus, des CMS « sans tête » ont émergé pour servir exclusivement du contenu via des API. Mon argument dans cet article, cependant, est que nous devrions passer moins de temps à parler de « sans tête » et plus de « contenu structuré » . Car c'est la qualité essentielle de ces systèmes. Ces systèmes impliquent de nombreuses implications pour notre métier, et nous avons encore du chemin à parcourir pour déterminer les bons modèles de gestion de ces technologies.

Venant au conseil en technologie avec une formation en sciences humaines, j'ai beaucoup appris sur la façon d'organiser et de travailler avec des projets Web qui adoptent une approche centrée sur le contenu - à la fois avec les nouveaux API basés sur les API et les CMS traditionnels. J'en suis venu à comprendre comment commencer tôt avec le contenu réel en direct d'un CMS ; le faire dans un cadre interdisciplinaire a non seulement permis de découvrir les complexités à un stade plus précoce, mais a également donné une agence à toutes les personnes impliquées et donné l'occasion de réfléchir aux défis et aux possibilités de la technologie et du design dans son sens le plus large.

Dans cet article, je proposerai quelques stratégies globales, avec des exemples concrets et réels sur la façon de penser à travailler avec un contenu structuré. Au moment d'écrire ces lignes, je viens de commencer à travailler pour une société SaaS qui fournit un tel service de gestion de contenu, pour l'hébergement de contenu diffusé via des API. J'y ferai référence, à la fois en raison de mon expérience passée avec lui dans des projets auxquels j'ai participé en tant que consultant, mais aussi parce que je pense qu'il illustre bien les points que je veux faire valoir. Considérez donc cela comme une sorte de clause de non-responsabilité.

Cela étant dit, j'ai pensé à écrire cet article pendant quelques années, et je me suis efforcé de le rendre applicable à n'importe quelle plate-forme avec laquelle vous choisissez d'aller. Alors sans plus tarder, remontons vingt ans en arrière pour comprendre un peu plus où nous en sommes aujourd'hui.

Premiers pas avec les normes Web

Au début des années 2000, le mouvement des standards Web a inspiré un domaine à changer ses façons de travailler. À partir d'une approche « mise en page d'abord », ils ont attiré notre attention sur la façon dont le contenu d'une page doit être balisé sémantiquement en utilisant HTML : le menu d'un site Web n'est pas un <table> , c'est un <nav> ; Un titre n'est pas un <b> , c'est un <h1> . Il s'agissait d'une étape importante dans la réflexion sur les différents rôles que joue le contenu Web afin d'aider les utilisateurs à le trouver, à l'identifier et à l'intégrer.

Le mouvement Web Standards a introduit l'argument selon lequel le balisage sémantique améliorait l'accessibilité, ce qui a également amélioré son classement dans les résultats de recherche Google. Cela a également marqué un changement dans la façon dont nous concevons le contenu Web . Votre site Web n'était plus le seul endroit où votre contenu était représenté. Vous deviez également réfléchir à la façon dont vos pages Web étaient présentées dans d'autres contextes visuels, comme dans les résultats de recherche ou les lecteurs d'écran. Cela a ensuite été alimenté par les médias sociaux et les aperçus intégrés des liens partagés. L'état d'esprit est passé de l' apparence du contenu à ce qu'il devrait signifier . Cela se trouve également être la clé pour travailler avec un contenu structuré.

Avec l'adoption d'appareils de poche connectés à Internet, le Web est soudainement devenu un concurrent sérieux dans les applications. La concurrence, cependant, était principalement pour les globes oculaires de l'utilisateur final. De nombreuses organisations avaient encore besoin de diffuser des informations sur leurs produits et services à la fois dans leurs applications et leurs différentes présences sur le Web. Parallèlement, le Web a mûri, et JavaScript et AJAX ont facilité la connexion de différentes sources de contenu via des API. Aujourd'hui, nous avons GraphQL et des outils qui simplifient la récupération de contenu et la gestion de l'état. Et ainsi les pièces du puzzle technologique commencent à se mettre en place.

"Créez une fois, publiez partout"

Bien qu'il soit principalement décrit comme un « changement technologique », l'intégration de contenu dans les charges utiles JSON (voyageant le long des tubes HTTP) a un impact démesuré sur la façon dont nous pensons au contenu numérique et aux flux de travail environnants. À certains égards, c'est déjà le cas. Il y a près de dix ans, l'invité de la National Public Radio (NPR) Daniel Jacobson a blogué sur programmableweb.com à propos de leur approche, résumée dans l'acronyme COPE qui signifie "Create Once, Publish Everywhere". Dans l'article, il présente un système de gestion de contenu fournissant du contenu à plusieurs interfaces numériques via une API - et non via une machine de rendu HTML - comme le faisaient la plupart des CMS à l'époque (et sans doute maintenant).

La « couche de gestion des données » COPE de NPR est ce qui deviendrait la notion de « CMS sans tête ». Au début de COPE, on y parvenait en structurant le contenu en XML. Aujourd'hui, JSON est devenu le format de données dominant pour le transfert de données via des API, y compris les appareils de l'Internet des objets et d'autres systèmes en dehors du Web. Si vous souhaitez échanger du contenu avec des chatbots, des interfaces vocales, et même des logiciels de prototypage visuel, vous parlez très souvent HTTP avec un accent JSON.

"Uncoining" Le terme "Headless CMS"

Selon Google Trends, les recherches de « headless CMS » ont gagné en popularité jusqu'en 2015, soit six ans après l'article COPE de NPR. Le terme "sans tête" (du moins en ce qui concerne la technologie numérique et non l'aristocratie française de la fin du XVIIIe siècle) a été utilisé un bon moment pour parler de systèmes qui fonctionnent sans interface utilisateur graphique.

Note : On pourrait dire qu'une interface en ligne de commande est bien « graphique » comme les logiciels sur serveurs ou les environnements de test (mais gardons ça pour un autre article).

Je suis partagé en qualifiant ces nouveaux CMS de "headless". On pourrait aussi bien les appeler « polycéphales », c'est-à-dire qui ont plusieurs têtes. Ce sont les Hydres et Cerbeuses des CMS. "Headless" définit également ces systèmes par la capacité qui leur manque (c'est-à-dire un moteur de template pour le rendu des pages Web), au lieu de les définir par leur véritable force : permettre de structurer le contenu sans les contraintes du Web. Cela étant dit, à ce jour, de nombreuses solutions de cette catégorie pourraient également être appelées "Nearly Headless Nick". Parce que l'interface d'édition est toujours étroitement liée au système. Leur « absence de tête » découle de leur absence de moteur de template, c'est-à-dire de machinerie produisant du balisage à partir du contenu.

Note : J'utiliserais presque certainement un CMS appelé "Mimsy-Porpington" (connu de l'univers Harry Potter).

Au lieu de cela, ils rendent le contenu disponible via une API, vous donnant ainsi plus de flexibilité pour savoir comment, quoi et où vous souhaitez afficher et utiliser ce contenu. Cela en fait des compagnons parfaits pour les frameworks frontaux JavaScript populaires tels que React, Angular et Vue. Et malgré la prétention de pouvoir fournir du contenu à des "sites Web, applications et appareils", la plupart d'entre eux sont encore limités par le fonctionnement du contenu Web. Ceci est particulièrement visible dans la manière dont la plupart gèrent le texte enrichi - en le stockant au format HTML ou Markdown.

Les CMS traditionnels ont également commencé à ajouter des API quelque peu génériques en plus de leurs systèmes de rendu de modèles et appellent cela "découplé" comme un moyen de se distinguer de leurs nouveaux concurrents. « Tout cela, et les API aussi ! » est la revendication. Certains de ces CMS sont également assez agnostiques en ce qui concerne la modélisation du contenu. Par exemple, Craft CMS ne fait presque aucune hypothèse sur votre modèle de contenu lorsque vous l'installez pour la première fois. Wordpress s'oriente également vers l'utilisation d'API pour la diffusion de contenu. Je soupçonne que l'écart entre les anciens joueurs dans le domaine des CMS et les nouveaux se rétrécira au fur et à mesure.

Néanmoins, placer la gestion de contenu derrière les API (au lieu d'un moteur de rendu HTML) est une étape importante vers des méthodes de travail plus sophistiquées à une époque où le texte, les images, les vidéos et les médias d'une organisation sont numérisés et exposés aux utilisateurs et clients internes et externes. Il est temps cependant de passer de la définition de leurs capacités de rendu frontales manquantes à ce qu'ils peuvent vraiment faire pour nous : nous donner un moyen de travailler avec du contenu structuré . Alors, devrions-nous les appeler « Systèmes de gestion de contenu structuré » ? Comme dans "Non Bob, ce n'est pas votre CMS habituel. C'est un SCMS, croyez-moi, ça va être une chose.

Il ne s'agit pas des têtes, mais du contenu structuré

Le changement le plus radical imposé par les systèmes de gestion de contenu structuré (SCMS) consiste à s'éloigner de l'organisation du contenu selon une hiérarchie de pages pour vous laisser libre de structurer le contenu dans le but que vous jugez approprié. Éviter le contenu dupliqué est un avantage évident car il augmente la fiabilité et réduit la charge administrative (vous n'avez pas à gérer le contenu dupliqué sur plusieurs canaux). En d'autres termes : créez une fois, publiez partout . Si vous n'avez qu'à mettre à jour la description de votre produit une seule fois - dans un système - et qu'elle est mise à jour partout où votre produit est exposé à l'utilisateur, c'est clairement un avantage.

Alors que les fournisseurs SCMS utilisent fréquemment "votre site Web et une application" pour justifier une réflexion différente sur la structure des pages, vous n'avez pas à traverser la rivière pour tirer parti d'une structure de contenu structurée. Avec la popularité des frameworks JavaScript, il est de plus en plus courant de créer des sites Web comme une composition de composants individuels, qui peuvent être « remplis » avec un contenu différent en fonction de l'état et du contexte. Vous pouvez avoir une fiche produit qui apparaît dans de nombreux contextes différents dans votre application Web. Nous constatons que le développement Web moderne s'éloigne de la création de documents et de pages pour composer des composants en fonction d'un mélange d'entrées d'utilisateurs, d'algorithmes et de personnalisation.

Ces tendances sur la façon dont les systèmes de conception sont créés et sur la façon dont nous sommes encouragés à travailler en équipe à travers des processus de test, d'apprentissage et d'itération rendent le domaine de la gestion de contenu mûr pour de nouvelles façons de penser. Certaines tendances ont émergé, mais nous avons encore beaucoup de chemin à parcourir. Par conséquent, sur la base de mon expérience de travail dans des équipes et des projets qui ont mis le contenu au premier plan, et en tant que membre d'une équipe qui construit un service pour celui-ci (et je vous exhorte à être conscient de tout préjugé ici), je veux proposer des stratégies qui, à mon avis, peuvent être utiles et créer des points pour une discussion plus approfondie.

1. Abordez le contenu dans des équipes multidisciplinaires

Je crois que c'est une chose du passé qu'un graphiste puisse remettre des pages obsolètes et parfaites au pixel près à un développeur frontal dont la responsabilité était de «mettre en œuvre» la conception. Nous créons maintenant des systèmes de conception composés de composants plus petits, disposés dans des compositions qui viennent avec plusieurs états possibles prêts à l'emploi. Le plus souvent, ces composants doivent être résilients aux entrées générées par les utilisateurs, ce qui signifie que plus tôt vous introduisez du contenu en direct dans le processus, mieux c'est. La responsabilité d'un développeur frontend n'est pas de reproduire la vision d'un graphiste ; il s'agit de manœuvrer un domaine complexe de la façon dont les navigateurs restituent HTML, CSS et JavaScript, en s'assurant que les interfaces utilisateur sont réactives, accessibles et performantes.

En tant que consultant en technologie chez Netlife (un cabinet de conseil spécialisé dans l'expérience utilisateur), j'ai vu de grands pas se faire vers la collaboration entre développeurs, designers et chercheurs utilisateurs. Même si nos éditeurs de contenu ont toujours été impliqués dans le projet dès le départ, leurs contributions n'ont pas intégré le flux de travail de conception principalement en raison de frictions techniques.

Le goulot d'étranglement était souvent un CMS hérité auquel nous ne pouvions pas toucher, ou qu'il fallait du temps pour construire la structure du contenu car cela dépendait de la mise en page de conception. Cela entraînait souvent un double travail : nous avons créé un prototype HTML, souvent basé sur du contenu analysé à partir de fichiers Markdown, qui a dû être réimplémenté dans la pile CMS lorsque les tests utilisateur ont été effectués, et tout le monde était parfaitement satisfait. . Il s'agissait souvent d'un processus coûteux, car les limitations du CMS ont été découvertes tardivement dans le processus. Cela crée également une pression sur toutes les parties pour "faire les choses correctement du premier coup" et laisse moins d'espace pour le type d'expérimentation que vous voudriez dans un projet de conception.

Le travail multidisciplinaire nécessite des systèmes agiles

Passer à un SCMS dans lequel il fallait quelques minutes pour coder un modèle de contenu (où les champs et l'API étaient prêts instantanément) a bouleversé notre processus - et pour le mieux. Je me souviens d'avoir été assis avec l'éditeur de contenu du nouveau u4.no dans les premiers jours du projet. Parler de la façon dont ils ont travaillé et aimeraient travailler avec leur contenu. Assez rapidement, nous avons traduit nos conclusions en simples objets JavaScript qui ont été instantanément transformés en un environnement d'édition dans le navigateur. Trouver des titres utiles et des descriptions pour les titres. Nous avons parlé de la façon dont ils voulaient des extraits de texte qu'ils pouvaient réutiliser sur différentes pages et contextes, qu'ils appelaient en interne des "pépites", que nous avons ensuite créées sur-le-champ.

Permettre ce type d'exploration au début du développement du projet - un éditeur de contenu et un développeur parlant ensemble pendant que l'interface était en cours de création devant nous - nous a semblé puissant. Sachant que nous pouvions continuer à concevoir le frontend dans React pendant qu'elle et ses collègues commençaient à travailler sur le contenu. Et ne pas se soucier de nous mettre dans un coin, comme nous le faisions souvent avec les CMS dans lesquels la structure était étroitement liée à la façon dont vous deviez coder la partie frontale.

Un système de contenu doit permettre l'expérimentation et l'itération

Mis à part les projets de refonte créative, un système de contenu structuré devrait également vous permettre de continuer à améliorer, tester et itérer votre contenu dans le cadre de l'ensemble de votre système de conception. Les concepteurs UX doivent pouvoir créer rapidement des prototypes avec du contenu réel à l'aide d'outils tels que Sketch ou Framer X. Vous devez être en mesure d'augmenter la gestion du contenu avec des mesures quantitatives, qu'il s'agisse d'échelles de lisibilité ou de la performance du contenu là où il est utilisé.

Remarque : J'ai utilisé le terme "concepteurs UX" ci-dessus malgré l'opinion que nous devrions tous - d'une manière ou d'une autre - nous rapporter au processus de création de bonnes expériences utilisateur. Nous sommes tous des designers UX dans nos différents domaines de conception.

Travailler avec du contenu structuré nécessite un peu de temps pour s'y habituer si vous avez l'habitude de n'afficher que du contenu WYSIWYG directement sur la mise en page de votre page Web. Pourtant, cela se prête à une conversation qui correspond davantage à l'évolution du domaine de la conception numérique. Le contenu structuré permet à une équipe de concepteurs, de développeurs, d'éditeurs de contenu, de chercheurs d'utilisateurs et de chefs de projet de réfléchir collectivement à la manière dont un système doit fonctionner pour répondre aux besoins et aux objectifs stratégiques des utilisateurs. Cela vous oblige également à penser différemment la façon dont le contenu structure, ce qui nous amène à la stratégie suivante.

2. Vous n'aurez peut-être pas besoin d'un ordre hiérarchique

L'un des changements les plus notables pour beaucoup est que les systèmes de contenu structuré sont orientés vers des collections et des listes de documents et non vers des hiérarchies de type dossier qui reflètent les structures de navigation du site Web. Ces structures n'ont plus de sens dès qu'une partie du contenu doit être utilisée dans d'autres contextes, qu'il s'agisse de chatbots, de médias imprimés ou d'autres sites Web. Les CMS traditionnels ont essayé d'atténuer cela en autorisant des blocs de contenu réutilisables, mais ils doivent toujours être placés sur des mises en page et difficiles à raisonner via des API.

Chaque page à sa propre

Comme indiqué dans The Core Model, lorsque l'un de vos principaux référents est Google ou le partage sur les réseaux sociaux, vous devez considérer chaque page comme une page de destination. Et si vous regardez la répartition des pages vues, vous remarquerez que certaines de vos pages sont bien plus populaires que d'autres. À moins que vous ne soyez un site Web d'actualités, il ne s'agit généralement pas d'actualités, mais de celles qui permettent à l'utilisateur de réaliser tout ce qu'il espérait réaliser sur votre site Web. Ils sont là où les affaires se déroulent réellement.

Votre contenu numérique doit être au service de l'intersection de vos propres objectifs stratégiques et des objectifs individuels de vos utilisateurs. Lorsque l'agence numérique Bengler (prédécesseur de sanity.io) a créé le nouveau site Web d'oma.eu, elle n'a pas structuré le contenu après une hiérarchie élaborée de pages. Ils ont créé des types de contenu qui reflétaient la réalité quotidienne de l'organisation, c'est-à-dire après les projets , les personnes et les publications . En fait, le site Web OMA est presque complètement plat en termes de hiérarchie de contenu, et la page d'accueil est générée à partir d'un mélange de règles algorithmiques et éditoriales.

Alors, comment s'y prendre ? Je pense qu'un mélange de réflexion sur votre contenu reflète le modèle mental de votre organisation et ce qu'il doit être pour être utile à tout ce pour quoi vos utilisateurs en ont besoin.

Voici un exemple de base : lors de la création d'une page d'employés, vous devriez probablement commencer par un type de contenu appelé personne . Une personne peut avoir un nom, des coordonnées, une image, différents rôles organisationnels et une courte biographie. Un document personnel peut être réutilisé dans les listes de contacts, les signatures d'auteurs d'articles, les interfaces d'assistance par chat et les badges d'accès aux bâtiments. Peut-être avez-vous déjà un système interne qui sait qui sont ces personnes et qui vient avec une API ? Super, alors synchronisez-vous avec ça.

Ne vous perdez pas dans un terrier de lapin ontologique

Il est utile de revenir à la façon dont Google indexe les pages Web et à la façon dont ils essaient d'indexer les informations du monde. C'est pourquoi ils consacrent du temps et des efforts aux données liées (RDFa, microformat, JSON-LD). Si vous annotez vos pages Web avec des éléments JSON-LD, vous apparaîtrez plus en évidence dans les résultats de recherche. C'est également pertinent lorsque vos informations doivent être prononcées par des assistants vocaux et affichées dans une interface utilisateur d'assistant. Si votre contenu est déjà structuré et facilement disponible dans une API, il vous sera relativement facile de l'implémenter dans ces microformats.

Je ne suis pas sûr que je recommanderais d'aller à fond sur les ontologies de schema.org et diverses ressources de données liées, du moins pas à des fins d'éditeur. Vous pouvez rapidement vous perdre dans un terrier de lapin en essayant de créer des structures platoniques parfaites où tout convient.

Newsflash : Ça n'arrivera jamais, parce que le monde est un endroit désordonné, et parce que les gens pensent les choses différemment.

Il est plus important de structurer votre contenu dans un système qui a un sens intuitif et se prête à être adapté au fur et à mesure que les besoins changent. C'est pourquoi il est important de commencer par la modélisation du contenu dès le début du processus de conception et de développement — vous devez apprendre comment l'utiliser.

Extraire de la réalité, pas des conventions de la CMS

Il peut être tentant de suivre les conventions fournies par votre CMS. Rappelez-vous comment Wordpress vous donnera des "Posts" et des "Pages", et tout d'un coup tout doit être rangé dans ces cases ? Un champ de texte enrichi WYSIWYG est flexible dans la mesure où il vous permet de mettre n'importe quoi, mais le contenu ne sera pas structuré et facilement adaptable - il n'est flexible qu'une seule fois. Mais vous avez besoin d'un endroit pour commencer votre mappage d'un modèle de contenu. Ma suggestion est de commencer par parler aux gens, c'est-à-dire les auteurs et les lecteurs.

Comment les gens parlent-ils du contenu en interne ? Comment les gens appellent-ils différentes choses ? Vous pouvez exécuter un exercice de liste libre, une méthode utilisée par les ethnographes pour cartographier les taxonomies folkloriques. Par exemple, vous pourriez demander :

"Nommez les différents types de contenu dans notre organisation."

Ou, à un niveau plus spécifique :

« Pouvez-vous nommer les différents types de rapports que nous avons dans cette organisation ? »

Le but de cette enquête est de démêler les taxonomies intériorisées que les gens portent, et non leurs opinions ou leurs sentiments sur les choses (ce qui a souvent tendance à faire dérailler les processus de conception). Vous n'avez pas besoin d'en demander beaucoup avant d'avoir une liste assez exhaustive à partir de laquelle vous pouvez travailler. Vous constaterez probablement que certaines parties de votre liste proviennent des conventions de votre CMS actuel (c'est bon à savoir si vous devez faire un remodelage). Maintenant, vous devriez parler avec votre éditeur et essayer de déterminer ce qu'il a besoin que le contenu fasse .

Certaines questions que vous pouvez poser pourraient être les suivantes :

• Avez-vous besoin d'utiliser ce contenu à plusieurs endroits ? Où?
• Quelles sont les différentes relations entre les types de contenu ?
• Où avons-nous besoin que le contenu soit affiché aujourd'hui et demain ?
• De quelle manière avons-nous besoin que le contenu soit trié ? La commande peut-elle être effectuée de manière algorithmique, par l'utilisateur, ou doit-elle être manuelle ?
• Existe-t-il des systèmes ou des bases de données dans d'autres systèmes avec lesquels nous pouvons nous synchroniser afin d'éviter les doublons ?
• Où voulons-nous que le contenu canonique vive ? Le SCMS devrait-il en être la source, ou simplement augmenter le contenu existant, par exemple la copie marketing pour les produits vivant dans un système de gestion de produits ?

Cela ne signifie pas que vous devez jeter l'architecture de l'information traditionnelle avec l'eau du bain désormais tiède. Il est toujours logique d'avoir des articles comme type de contenu, si les articles font partie de la réalité du contenu de votre organisation. Mais peut-être n'avez-vous pas vraiment besoin de la convention abstraite des catégories , car ces articles font référence au type de services ou de produits qu'ils contiennent. Et cette relation permet d'interroger ces articles dans des circonstances où cela a du sens, sans obliger quelqu'un à avoir une "gestion des catégories d'articles" dans le cadre de sa description de poste.

L' article est également ce qui rend difficile le découplage complet du contenu de la couche de présentation. Nous sommes tellement habitués à penser à la mise en page et au style de l'article, mais à une époque où vous êtes censé héberger votre propre contenu sur votre propre domaine, puis le syndiquer sur des plateformes telles que medium.com, vous avez déjà abandonné contrôle sur la présentation visuelle. Cela nous amène à la stratégie suivante.

3. Les contextes de présentation sont également des types de contenu

Soyez prêt pour la refonte

Vous souhaitez également pouvoir adapter et modifier rapidement la structure de navigation de votre site Web, sans avoir à reconstruire l'ensemble de votre architecture de contenu ni à lutter contre une interface stricte de type dossier. Vous voulez également pouvoir avoir une certaine hiérarchie de contenu, car cela a parfois du sens, et parfois cela dépasse deux niveaux, où la plupart des interfaces du département des CMS API-first ne fournissent pas beaucoup d'aide.

Fait intéressant, les systèmes de gestion de contenu pour les chatbots ont tendance à utiliser des structures hiérarchiques similaires pour organiser les arbres d'intention et les flux de dialogue. Cela revient à dire que les hiérarchies de contenu jouent des rôles différents dans différents canaux, mais elles fournissent souvent des moyens de naviguer dans le contenu. Une façon d'aborder cela consiste à créer des types pour la navigation, où vous pouvez organiser le contenu par références, et créer des itinéraires pour les pages Web, les menus ou les chemins pour les interfaces conversationnelles.

Conseils relationnels

Les références (ou relations) sont ce qui rend possible un système de contenu structuré, et c'est vraiment le cœur de tout ce que nous traitons quand il s'agit de contenu sur le Web (c'est la raison pour laquelle on l'appelle métaphoriquement le Web en premier lieu). Être capable de faire des références entre des morceaux de contenu est une chose très puissante, mais cela peut aussi être coûteux en termes de capacité des backends à écrire et à récupérer ces données. Vous devrez donc peut-être penser différemment si vous avez une multitude de documents, car l'échelle est rarement gratuite.

Il convient également de considérer que vous n'avez pas toujours besoin d'une référence explicite pour joindre des données ; le plus souvent, cela peut être fait par des critères liés au contenu, par exemple "donnez-moi toutes les personnes et tous les bâtiments dans cette géolocalisation". Le bâtiment et les personnes n'ont pas besoin d'avoir une référence explicite l'un à l'autre, tant que cela est implicite dans un champ d'emplacement sur les deux types de contenu.

Les références entre les types de présentation et d'autres types de contenu sont utiles lorsque vous ne pouvez pas laisser un algorithme de la couche de présentation joindre les données. Il peut sembler un peu fastidieux de dessiner explicitement ces types de présentation et de créer des compositions de contenu référencé, mais c'est une solution à un problème que vous rencontrerez souvent avec les SCMS : il est difficile de savoir où le contenu est utilisé. En incluant des types de navigation, vous lierez explicitement le contenu à la présentation, mais pas un seul. Cela permet de raisonner pour travailler avec des structures de navigation indépendamment du contenu auquel elles mènent.

Par exemple, dans les captures d'écran, nous avons lié Google Experiments au type de routes , ce qui permet d'ajouter plusieurs pages composées de références au contenu, ce qui signifie que nous pouvons exécuter des tests A/B sans presque aucune duplication de contenu. Étant donné que nous recevons également un avertissement si nous essayons de supprimer du contenu référencé par d'autres documents, cette façon de structurer nous empêchera de supprimer quelque chose que nous ne devrions pas.

Les relations entre les types de contenu sont une épée à double tranchant. Cela augmente la durabilité et est essentiel pour éviter les doubles emplois. D'un autre côté, vous pouvez facilement vous couper parce que vous créez des dépendances entre le contenu, ce qui (s'il n'est pas rendu transparent) peut entraîner des changements involontaires sur les canaux où vos données sont affichées. Ce serait par exemple mauvais si nous pouvions supprimer une « page » utilisée par une « route » sans avertissement.

Cela nous amène à la stratégie suivante, qui (certes !) dépasse en partie le pouvoir de l'utilisateur normal à ce jour, car elle a à voir avec la façon dont les différents systèmes sont architecturés. Pourtant, cela vaut la peine d'y penser.

4. Ne mettez pas de texte enrichi dans un coin

Le texte enrichi est plus que HTML

Je peux comprendre pourquoi le HTML est si répandu dans le contenu numérique, mais je sais que cela vient aussi de quelque chose ; c'est un sous-ensemble de SGML, une manière généralisée de structurer des documents lisibles par machine. Comme le souligne Claire L. Evans dans le merveilleux livre "Broad Band: The Untold Story of the Women who made the Internet" (2018), il y avait déjà une communauté dynamique de personnes qui réfléchissaient aux documents liés lorsque HTML a été introduit. La proposition de Tim Berners-Lee était beaucoup plus simple que la plupart des autres systèmes à l'époque, mais c'est probablement pourquoi elle s'est propagée et a rendu possible - à partir de maintenant - le Web ouvert et gratuit.

Lorsque vous êtes dans un navigateur sur le World Wide Web, HTML est génial. Si vous êtes un écrivain qui souhaite publier quelque chose qui se termine en HTML simple, Markdown est génial. Si vous voulez que votre contenu de texte enrichi soit facilement intégré dans quelque chose qui n'est pas un navigateur, ou un framework JavaScript populaire qui vous permet d'augmenter HTML avec JavaScript dans des composants complexes (oui, nous parlons de React et Vue.js) , avoir du HTML dans vos réponses d'API commence à être un peu compliqué, surtout si vous avez besoin de l'analyser.

Presque tout le monde le fait cependant, même les nouveaux venus : j'ai parcouru tous les fournisseurs sur headlesscms.org et j'ai parcouru la documentation, et je me suis également inscrit pour ceux qui ne l'ont pas mentionné. À deux exceptions près, ils stockaient tous du texte enrichi au format HTML ou Markdown. C'est bien si tout ce que vous faites est d'utiliser Jekyll pour rendre un site Web, ou si vous aimez utiliser dangereusement SetInnerHTML dans React. Mais que se passe-t-il si vous souhaitez réutiliser votre contenu dans des interfaces qui ne sont pas sur le Web ? Ou si vous voulez plus de contrôle et de fonctionnalités dans votre éditeur de texte enrichi ? Ou voulez-vous simplement qu'il soit plus facile de rendre votre texte enrichi dans l'un des frameworks frontaux populaires et que vos composants prennent en charge différentes parties de votre contenu de texte enrichi ? Eh bien, vous devrez soit trouver un moyen intelligent d'analyser ce démarquage ou HTML dans ce dont vous avez besoin, soit, plus commodément, simplement le stocker de manière plus sensée en premier lieu.

Par exemple, que se passe-t-il si vous souhaitez sortir votre texte enrichi sur une interface vocale ? Nous savons que les assistants vocaux gagnent en popularité. Les plates-formes les plus populaires pour ces assistants ont la capacité d'obtenir le texte du contenu parlé via des API. Ensuite, vous souhaitez tirer parti de quelque chose comme Speech Synthesis Markup Language. Un système de texte portable adopte une approche plus agnostique du texte enrichi, ce qui vous permet d'adapter le même contenu à différents types d'interfaces.

Lecture recommandée : Expérimenter avec l'interface de synthèse vocale

Texte portable en tant que modèle de texte enrichi agnostique

Le texte portable est également utile lorsque vous créez principalement du contenu pour le Web. Que se passe-t-il si vous souhaitez avoir la possibilité d'imbriquer et d'enrichir votre texte avec des structures de données, telles qu'une note de bas de page en texte enrichi ou un commentaire éditorial en ligne ? Ou une phrase ou un libellé alternatif pour les cas de test A/B ? Markdown et HTML sont rapidement insuffisants, et vous devrez compter sur l'ajout de quelque chose comme des balises spéciales de code court, tout comme Wordpress l'a résolu. With portable text, you have an agnostic representation of content structures, without having to marry a certain implementation. Your content ends up being more sustainable and flexible for new redesigns and implementations.

There are also other advantages to portable text, especially if you want to be able to edit content collaboratively and in real time (as you do in Google Docs); you need to store rich text in another structure than HTML. If you do, you'll also be able to take advantage of microservices and bots, such as spaCy, in order to annotate and augment your content without locking the document.

As for now, portable text isn't widely adopted, but we're seeing movements towards it. The specification isn't very complex and can be explored at portabletext.org.

5. Make Sure Your SCMS Is In Service For Your Editors, And Not The Other Way Around

Digital content isn't just used for your organization's online web page leaflets anymore. For most of us, it encapsulates and defines how your organization is understood by the world, both from those within it and those outside: From product copy, micro texts to blog posts, chatbot responses, and strategy documents. We are millions of people that have to log into some CMS every day and navigate interfaces that were imagined twenty years ago with the assumptions of people who have never made much effort to user test or challenge their interfaces. Countless hours have been wasted away trying to fit a modern frontend experience into a page layout machine. Fortunately, this is soon a thing of the past.

As a technology consultant, I had to read through pages of technical specification whenever someone thought it was time to acquire a new CMS for themselves. There were demands from which server architecture it should run on (Windows servers, of course) to their ability to render “carousels” and “being able to edit web pages in place”, despite also requesting a “modular redesign”. When editors had been allowed to contribute to these specifications, they were also often dated to the what the editors had begotten used to. They seemed not aware that they could demand better user experiences, because enterprise software has to be big, lumpy and boring.

This is partly the fault of us making these systems. We tend to communicate technology features and specifications, and less what the everyday situation working with these systems look like. Sure, for a frontend designer, something supporting GraphQL is shorthand for how conveniently she is able to work against the backend, but on a higher level, it's about the systems ability to accommodate for emerging workflows, where a content model could survive visual redesigns and design systems should be resilient to changes of its content.

Questions To Ask Of Your (S)CMS

If we are to embrace design processes, we can't know prior to solving the problem whether the user tasks are best solved by making carousels ( newsflash: most probably not ), or whether A/B-testing makes sense for your case, even though it sounds cool.

Instead, ask questions like this:

• Is it possible, and how exactly will multi-disciplinary teams work with this system?
• How easy is it to change and migrate the content model?
• How does it deal with file and image assets?
• Has the editorial interface been user tested?
• To what extent can the system be configured and customized to special workflows and needs of the editorial team?
• How easy is it to export the content in a moveable format?
• How does the system accommodate for collaboration?
• Can content models be version controlled?
• How easy is it to integrate the system with a larger ecosystem of flowing information?

The goal of these questions is to explore to what degree a content management system allows for a cross-disciplinary team to work effortlessly together, without too many bottle-necks or long deployment cycles. They also push the focus to be more about the content should be doing, and less about how things should look in a given context. Leave that for the design processes, where user testing probably will challenge assumptions one may have when looking into getting a new content system.

There are, of course, many factors in addition to this that probably have to be taken into consideration. The easiest thing to assess is the fiscal cost of software licenses and API-related costs if you are on a hosted service. The invisible cost (in time and attention spent by the team working with the system), is harder to estimate. From my experience, many of the SCMSs in combination with one of the popular frontend frameworks can significantly cut development time and allow for an agile ( there's my coin for the swear jar ) design process. With the caveat that your team is prepared to solve some of the problems that come out of the box with traditional CMSs.

Towards Structured Content

The ways we work with digital content has changed dramatically since the World Wide Web made working with interconnected documents mainstream. Organizations, businesses, and corporations have amassed gigabytes of this content, which now is stuck in rigid page hierarchies, HTML markup, and clunky user interfaces.

Using a Structured Content Management System can be a great way to free your content from a paradigm that begins to feel its age. But it isn't a trivial exercise, and success comes from being able to work multi-disciplinary and put your content model to the test. You need to get rid of some conventions you have grown used to by dealing with CMSs designed to output hierarchical websites. That means that you need to think differently about ordering content, make presentations types in order to make it easier to orchestrate content across multiple channels and to consider how you structure rich text so that it can be used outside of HTML contexts.

This article deals with some of the high-level concerns working with SCMSs. There are, of course, loads of exciting challenges when you start working with this in your team. You have to rethink stuff we've taken for granted for many years, but that's probably a good thing. Because we are forced to evaluate our content, not only from its place on a digital page but from its role in a larger system that works for whatever goals your organization and your users may have.

I believe that we can achieve content models that are more meaningful and easier to sustain in the long run, and that means saving time and expenses. It means more flexibility in terms of inventing new outputs and services, and less tie in with software vendors. Because a well-made Structured Content Management System will make it easy for you to take your content and go elsewhere. And that makes for some interesting competition. Hopefully, all in favor of the users.