Part 3: Inventory
For each of your page and content types, if possible bring:- Wireframe, screenshot, or comps
- Content details (including hidden information such as alt text and SEO metadata)
- Business and technical terms
- Who authors which parts
- Where else you use all or part of this content
- Priority and update frequency
- Existing content management system (CMS) entry forms
- How you expect this to be managed in the CMS, used within your website framework, and possibly incorporated with your build process
Content Type
|
Field or asset
|
Example /
Estimated instances |
Author(s) and Layout
|
Also used in
|
Managed?
|
Priority and Frequency
|
Product Teaser
|
Image
|
Picture of book/
Dozens |
Nivlong
|
Product Details
|
Custom CMS
|
High,
updated annually |
Product Teaser
|
Product name
|
“Create and Break, The Book”/
Dozens |
Nivlong
|
Product Details
|
Custom CMS
|
High,
rarely updated |
Product Teaser
|
Short description
|
"A blog about nothing,
really"/
Dozens |
Nivlong
|
none
|
Custom CMS
|
High,
updated monthly |
Product Teaser
|
Price
|
$0.01/
Dozens |
Automatic
|
Product Details
|
From external feed
|
Low,
auto- updated daily |
Product Teaser
|
Read more link
|
Dozens |
Templated
|
From template
|
High,
rarely changes |
|
Product Details
|
Product name
|
“Create and Break, The Book”/
Dozens |
Nivlong
|
Product Teaser
|
Custom CMS
|
High,
rarely updated |
Product Details
|
Image
|
Picture of book/
Dozens |
Nivlong
|
Product Teaser
|
Custom CMS
|
High
|
Product Details
|
Price
|
$0.01/
Dozens |
Automatic
|
Product Teaser
|
From external feed
|
Low,
auto- updated daily |
I'm not sure if such an inventory is commonplace, but it makes implicit assumptions explicit.
We can then "refactor" fields to get a high-level approach at schema design and template logic. Each duplicate item might be a shared schema field. Each presentation variation suggests a different template.
For example:
We can then "refactor" fields to get a high-level approach at schema design and template logic. Each duplicate item might be a shared schema field. Each presentation variation suggests a different template.
For example:
Possible Schema Fields
|
Template(s)
|
Image
|
Product Full
Product Summary |
Product name
|
Product Full
Product Summary |
Short description
|
Product Summary
|
Price (from external feed)
|
Product Full
Product Summary |
“Read more” link in Product Summary
|
Tridion is flexible enough to handle the details, you just need to specify what goes where.
The specific format you collect this information in doesn't matter as much as going through the process; I don't care if you do this in your head (impressive if you can), use magnets and a white board, follow Big Design Up Front, practice agile (big or little "A"), or do a POC with a follow-up "real" implementation.Feel free to recommend other columns or analysis questions. I've seen the basic approach at converting page and content types into schemas and templates dozens of times, but I'm curious how the details differ between consultants, projects, and regions.
When the architect says, "no no no no no, Alvin, the crucial thing is..." or your technical shakes his head with, "it won't work," or the infrastructure guru gives you a wink and remarks, "well, you could do that..." it means they've processed this input and see something you've missed.Let's break that process down in Part 4.
My SEO fu must be better if I'm getting comments from "Custom CMS."
ReplyDelete