Comment présentez-vous les balises et autres métadonnées non hiérarchiques comme une livraison pour votre client?
Auparavant, c'était simple. Un site Web a toujours été construit autour d'une structure hiérarchique qui rendait le plan du site assez facile à visualiser. Mais ensuite sont venus les blogs, les tags et la navigation contextuelle. En conséquence, la hiérarchie d'un site Web beaucoup moins important.
Par exemple, en lisant sur un événement sportif sur votre site d'actualités local, vous pouvez facilement consulter des liens vers plus d'informations sur les équipes, les faits concernant les joueurs, le stade et la ville. Toutes les informations que vous trouveriez ailleurs sur les sites Web précédents, c'est-à-dire pas dans la section des nouvelles sportives.
Toutes ces fonctionnalités sont basées sur tags. Ces connexions sont difficiles à établir dans un plan du site hiérarchique. Bien sûr, vous pouvez les expliquer dans les représentations filaires annotées, mais vous et votre client ne pouvez pas obtenir un aperçu rapide de la façon dont les éléments de contenu de votre site sont connectés les uns aux autres.
Alors, comment présentez-vous les balises et autres métadonnées non hiérarchiques comme solution de navigation à vos clients?
Je dois vous signaler ce BBC Internet Blog post pour une excellente référence.
Ce billet de blog décrit la stratégie technologique que le département BBC Future Media utilise pour évoluer d'un modèle de contenu relationnel et d'un cadre de publication statique vers une architecture de publication sémantique (DSP) entièrement dynamique.
Vous devrez définir et décrire un ensemble d'ontologies décrivant les structures et, surtout, les relations entre le contenu.
La manière hiérarchique de décrire les structures est largement basée sur la prémisse des "pages" comme éléments constitutifs du site. La réflexion doit être déplacée vers les éléments de contenu.
Lorsque vous pouvez amener les parties prenantes à penser à des éléments de contenu qui se combinent dynamiquement pour créer une expérience de page (je l'expliquerai brièvement), vous avez la moitié de la bataille gagnée. Cela peut être assez difficile.
Un des exemples de problèmes que vous pourriez rencontrer: Afin d'obtenir l'approbation légale d'un site Web bancaire, nous devions soumettre des descriptions très précises de tous les articles qui apparaîtront sur chaque `` page '' du mois avant la mise en service. Y compris la publicité et les panneaux latéraux (oui, je sais ...).
Le problème est que l'idée d'une page statique n'est plus d'actualité. J'ai qualifié la situation actuelle d '"expériences de page". Il peut s'agir de différentes combinaisons de contenu à différents moments pour différentes personnes. Décrire une page devient une tâche floue.
En résumé:
Vous devrez définir un modèle décrivant des éléments tels que les classes/catégories, les sous-classes, les relations ou les attributs. Le modèle est une conclusion logique d'un audit et d'une stratégie de contenu. [Voir l'exemple de la BBC ci-dessous]
N'oubliez pas: ce n'est pas définitif. Le modèle est une chose vivante qui changera et devrait changer avec le temps pour refléter le comportement. Ce que vous faites est de définir la scène à partir de ce qui est actuellement connu.
Mais comment faire plaisir aux parties prenantes? Une chose que je recommanderais est de créer des scénarios pour montrer comment ces modèles fonctionnent pour créer une expérience de page pour des personnages particuliers à des moments particuliers.
Une autre méthode que j'ai utilisée consiste à créer un ensemble d'exemples de wireframes montrant des composants individuels (pour le contenu) plus un ensemble les assemblant selon des modèles représentatifs (modèles avec un exemple de contenu). L'une d'entre elles, j'annote les modèles de balises qui déterminent chaque composant. Cela permet de faire le lien entre votre modèle et ce qu'un utilisateur peut voir.
Exemple de modèle BBC: 
Construire le modèle
Je ne pense pas que je pourrais mieux décrire cela que cette citation du blog de la BBC:
(RDF - Resource Description Framework - est basé sur l'idée de faire des déclarations sur les concepts/ressources sous la forme d'expressions sujet-prédicat-objet. Ces expressions sont appelées triplets dans RDF terminologie. Le sujet désigne la ressource et le prédicat désigne les traits ou les aspects de la ressource et exprime une relation entre le sujet et l'objet.
Dans certains projets sur lesquels j'ai travaillé, nous n'avions pas besoin d'aller aussi loin. Au lieu de cela, nous avions 3-4 ensembles de structures de balises qui décrivaient non seulement le contenu, mais la relation qui décidait quand ils devaient apparaître - le contenu et la stratégie marketing.