Creating an SDL Tridion BluePrint

I've yet to achieve BluePrinting mastery, but I've learned some useful strategy and tactics along the way. First some SDL Tridion terms for the uninitiated:

• A Publication is a repository of content, the largest "container" in SDL Tridion. It may feel like a Web Cabinet to Documentum Web Publisher users, but it differs in how publications share or inherit items across publications.
• A BluePrint is the relationship of SDL Tridion publications, which have parent-child relationships in a hierarchy of sorts. The layers in this diagram are logical and don't necessarily represent actual levels in Tridion.
• A Shared item is a representation of an item in a child publication. All items are shared by default from the publication immediately above. They don't all have to be used in pages nor published below, though.
• Localization in Tridion is the ability to change the text in a component, while keeping its place on a page or relationship to other components.

Let's Make a BluePrint

A general approach at creating a BluePrint design is to:

1. Start with the scalability layer ("empty" parent) at the top with a Schemas publication below it.
2. Add a Content Publication.
3. Add a translation layer if needed. I typically assume so, but I've seen one-language BluePrints.
4. Add the publishable sites at the bottom and their localized child publications. You can use current Web domains to estimate the number of publications needed. You don't have to add them all to the diagram up front, though :-)
5. Add corresponding publications on the design side.

I personally like a flatter design layer with a design publication per publishable site, but some might prefer replicating the content relationships--meaning if you have a Master Publication to create Structure Groups and Pages with children publication, you'd have a Master Template Publication and two children publications on the design side. This assumes you're okay with localizing templates, though.

The rest of BluePrint design is revising, adding, and removing publications as needed. I personally prefer a minimalist approach with just enough separation and publications, but I've seen the "let's create the fully-exploded tree first" approach work as well.

Avoid a Bad BluePrint

You might have heard horror stories about "BluePrinting Gone Wild" and problems from bad BluePrint designs. Don't let this scare you off, it's really a matter of avoiding three scenarios:

1. A single publication. It's actually not impossible to pull this apart, but expect down time and lots of manual work including infrastructure changes and "re-doing" pages.
2. A missing scalability ("empty") parent. Simply because we can only add children publications. Not having an empty parent means any future high-level publications are forced to inherit whatever you have at the top (typically all the schemas from the schemas publication).
3. An over-engineered marvel of a diagram that achieves ultimate flexibility. Too much choice is really a bad thing.

Understand that if you have a central set of content authors (who also edit pages), jumping between publications can be tedious. Really consider the authoring context surrounding your content before attempting to create multiple content layers.

Changing a BluePrint

If you really need a future Publication layer, the biggest challenge is avoiding naming conflicts in folder and structure group paths. Also, pushing items down is easier that moving them up, especially with "dynamic" content. So adding a "Shared set of pages" or components above your publishable Publications is relatively easy later, but re-doing publications with pages is hard since templates are "in use."

Though we might segment regions at the lowest publication level (e.g. "Canadian French"), it gets problematic if we attempt to use BluePrinting and localization for personalization.

Read more on how Localization and Personalization differ on TridionDeveloper.com.

Seven Quick SDL Tridion Experience Manager Tips

Some quick "good design" considerations for setting up Experience Manager page and content types (that also apply to schemas and templates in general). Offer good defaults with flexibility and build much of the decisions into the system itself.

1. Offer clear, select-able options. Use brief, business friendly-names like "home," or "article." Users don't need to know they're templates, not in the context of selecting them.
2. Be visually clear. Use icons (very cool feature), but 48 pixels and smaller can be kind of small. Use wireframes, maybe some color, or even text to make it clear what each item is (good tips from colleague Hao).
3. Offer good defaults. In content types, add practical descriptions and use good default text. Make it clear what the Lorem Ipsum parts are.
4. Reduce options. Reduce the number of available types where possible, similar to hiding schemas and template options from certain authors.
5. Prevent mistakes. Remove the Default Template options. Authors may assume you want them to use them. Add default settings when required.
6. Encourage ownership. Have the business own these naming conventions, settings, images, and descriptions. Descriptions probably shouldn't match schema names.
7. Try it. Finally, try creating or editing content with your setup. Or better yet, have your colleague or an author try it out, preferably before all-hands training.

Got some nice examples or gotchas when working with Experience Manager to share?