A question clients ask us a lot is: “Can you evaluate the structure of our content? Tell us how others are doing things?”
It’s a reasonable request, but what’s interesting is that it’s never really about evaluating “structured content best practices” etc.
That’s because, outside of some very basic stuff like “probably don’t store street addresses in JPEGs,” isn’t a moral compass with clear ‘good’ and ‘bad’ points, or a linear scale where you start at ‘none’ and aspire to ‘lots.’
I joke that nobody actually cares about “structured content” aside from those of us who spend our days working with it constantly. And that’s fine. What they care about is the specific problems that appropriately structured content makes easier to solve.
The emphasis there is “appropriately” — these days most organizations already have some degree of structure in their content; the question is how well the kinds of structures they have fit the things they’re trying to do.
I’ve talked about this on and off for years (this is one such rant) but focusing explicitly on “the jobs we want the structure to do for us” in recent projects has worked out really, really well.
There’s a big difference between “we have specific rules about what a valid product page should contain” and “we need to automate the production of device-tailored variations of each article” — they call for different KINDS of structure, not more or less or better structure.
Starting from that point — identifying the way each type of content is used (or will be used), then asking what special needs that type of content has that “structure” will need to facilitate. Reuse, consistency, validity, composition, inspectability, etc.
From there, existing content storage patterns and structures can be evaluated; new ones can be planned; gaps can be assessed. But without answering those “Why?” questions, structured content projects can devolve into over-engineering, or cargo-cult adoption of other orgs’ models.