Tridion Content Analysis: Part 2, Context

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

I've heard some Tridionauts admit they're capable of Tridion functional analysis but may not necessarily enjoy it. I actually enjoy the process, but Tridionauts and customers have asked me why it's such an involved process.

Although "because Alvin talks a lot" may be a factual and obvious reason, it's an over-simplistic answer.

If you're completely comfortable doing Tridion schema design, read Will Price's brain-challenging schema discussion/case study on TridionDeveloper or Part 1 to get comfortably uncomfortable again.

Part 2: Context

Like all information systems, Tridion involves people, process, and technology. We need to know who will update the content, what will be manageable, where similar content is re-used, when content is updated (frequency), and possibly how and why it should be Tridion managed.

Who

"Who" influences number of schemas, authorization, and folder structure. Separate permissions require separate schemas or non-mandatory fields (and some trust). Identify your authors for each of your managed text and media assets. Assume at least a regular author, some sort of "power author," and a developer role if not sure.

Skill level and preferences influence your interface choice (Content Manager Explorer vs Experience Manager/View). Power users might prefer simple text boxes and access to the source, whereas newer authors may appreciate user-friendly controls and a rich text editor.

What

"What's managed" helps determine content types, which you may refer to as modules, content chunks, components, or regions. Bring wireframes, existing CMS entry forms, and screen shots to describe your managed content. Don't forget to include "hidden" content such as SEO keywords, alt text, and metadata.

Where

"Where" your content appears affects your BluePrint, re-use, and template logic. For example, you may prefer to add headers and footer information via the page template to avoid necessary manual steps (such as adding a "footer" component presentation to every page).

Identify the "where" details with terms like Global, Local, or Single (Instance) along with the number of variations and instances. This count is vital as you'll want to put your efforts to fit some variation of the Pareto Principle; for example, you may be able to address 80% of your content management use cases with 20% of your schemas and templates. This brings us to frequency.

When

Though we could map all content and media to something in Tridion with its own schema and template, you risk wasting time on design and implementation on items that rarely change. Start by implementing and documenting moving parts likely to change or have a business impact (e.g. generate revenue or contribute to your mission).

Feel free to go big with a scaleable "framework" to handle all future content scenarios, but involve your various stakeholders and understand the trade-offs between project timeline and technical debt.

Determine the frequency of change for your content (e.g. daily, weekly, monthly, quarterly, annually, or "not-ever-in-the-time-I've-worked-here").

Combine the who, what, where, and when to identify templated and application-specific content. Text that presents in a large number of CPs, authored by developers, that rarely changes, and is specific to a publication could be managed in a component linked from Publication metadata, referenced by a re-usable template building block, which is used in most templates, for example.

How and Why

Your Tridionaut can help with how this may all work in the CMS. If you already have a CMS, bring that information in the form of a demo or screenshot.

Your organization, department, or project stake holders determines the "why." Why Tridion. Why this particular site. Why this page. Why this content. If you're only working from a "Tridion Project Plan" (which makes for a poor name for a project, really) consider peeling back the layers to the real project, initiative, or reason (or person--aka executive sponsor) for the change. The why for some parts (reduced maintenance costs) may differ for other parts (improved author experience) or your most critical parts (time-to-market and sales revenue).

Share your project plan, specifically the business opportunity / problem statement with your team.

Starting a project, we don't know who will do what, when, or where in the CMS. Bring your "why" to help the team figure out a good appraoch. In summary, we need to know:

• Who. Choose an author group for each managed text or media asset.
• What. Bring wireframes, existing CMS entry forms, and screen shots to identify content types.
• Where. Count instances and find locations.
• When. Calculate frequency of change.
• How and Why. Share your business opportunity or problem / statement.

Read Part 3 for an example inventory.

Read more about content strategy and approaches from Aby Gilmore on VerticalMeasure, Sally Bagshaw on Web Content Strategy, or that little red book I'm currently digging, Content Strategy for the Web (2nd edition) by Kristina Halvorson and Melissa Rach. For Tridion strategy, poke this guy for his next great post.