Tridion Content Analysis: Part 4, The Process

1. The Trivial Example and Question
2. Context
3. Inventory
4. Process
5. The Answer

In the previous posts, we saw the trivial Tridion article example then the context that make content type analysis challenging. We reviewed the content inventory details we need for design sessions. Now let's look at how we design from the top down (I owe Kelly Thompson for the catchy point that we design from the top-down but implement from the bottom-up).

Part 4: The Process

The 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).

1. Collect

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.

2. Refactor

Separate Content from Layout and Design

All 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.

3. Automate

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 Details

Determine 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 Components

Find 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)

Consider separate schemas and thus separate, but somehow related components, when you have:

• 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/Keywords

Consider 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 Refine

In 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?