Part 4: The ProcessThe first three steps in this content analysis process define template logic. The last three define schemas. I'm feeling particularly Covey-esque and throw in a 7th Habit for refinement (go sharpen your design saw).
Your implementation team takes your page and content types, which combine component template logic against the content fields and multimedia, and identifies semantic HTML or functional elements. These could be considered tentative schema fields. Then using the context of who, what, where, when, how, and why, they can do the following.
Separate Content from Layout and DesignAll authored fields go in one "authored" list. The rest belong to "template logic." Hey, put the text items you thought were "templated" back in the authored list. These should still be managed content (in components), but placement can be driven by templates.
Identify Template Logic"Template" text or assets that are consistent between component presentations or pages. Use update frequency and priority to determine what should be templated.
Find automation and template logic opportunities such as text parsing (e.g convert & into &), reorganizations/placement (e.g. splitting lists into columns or placing "right rail" component presentations), or adding numbers to a sequence.
4. Define DetailsDetermine any required fields, number format, dates, and other schema restrictions. Plan a meeting (or two or three) for rich text requirements to address your specific requirements for encoding, internationalization, and special characters.
5. Confirm Relationships
Distinguish between Embedded Fields and Linked ComponentsFind groupings of fields, look for repetition, and split components to creates your content model. This is similar to, but not exactly like, database normalization.
Embed fields when you have:
- a structured set of re-usable fields (e.g. image and alt text) that should be authored with the rest of your content
- a one-to-one or one-to-many mapping from components to "instances" of these fields
- the need to nest or possibly repeat a given set of fields (e.g. name, title, url)
- a structured set of re-usable fields (just like embedded fields) that can be authored separate from your content (and re-used elsewhere)
- a many-to-many relationship, where different sets of containing content may link to one or more components*
- different authors manage these fields separately
*For large sets of content, if the development team is willing to create queries and filters, use metadata to create these many-to-many relationships.
6. Simplify Selection
Identify Categories/KeywordsConsider Category and Keywords for schema selection options. The full context matters, for example SEO keywords might have made sense as select-able options a few years ago but a simple text box might make more sense for sites serious about SEO today.
7. Check for Practicality and RefineIn the end, you should have a few possible schemas per author group, preferrably with a clear naming convention to simplify schema selection. For each schema, the author should be able to pick from a few templates.
If you find yourself with a schema for every component presentation, consider consolidating. If you have dozens of templates for a single schema, consider consolidating. If most schemas have optional fields, consider making distinct schemas or removing unused fields.
I simplified the above process by having "template logic" cover both page and template logic. Up to you if you want to analyze these in two passes or together in each step, just understand that the process isn't completely independent. Page template decisions affect component templates and vice versa.
Ready for Part 5, the last post in this series?