Fields and Folders are about the How not the What

Imagine being a Tridion consultant, helping content authors with setup you're not quite familiar with yet. You're asked:

"What does this field do?"

That can be the most embarrassing and challenging question I get from content authors when looking at an unfamiliar SDL Tridion setup simply because the entry forms are templates are configurable, programmable, and extensible.

Related to this is, "Where should we put these items?"

This one is slightly easier because the answer depends on the update process in terms of:
  • Who updates them
  • What types of items are they
  • Where are they used?
  • How frequently are they updated?
The answer to both these "what" and "where" questions should be a "how."

Swapping Parent-Child Publications in SDL Tridion

Tridion BluePrint changes can be difficult simply because of dependencies. Creating a BluePrint and some changes like inserting layers, adding branches, and changing priority are trivial.

You could even "copy" certain items up a BluePrint by changing releationships, making a copy, and rewiring the original setup. Again, the biggest catch is not having the right dependencies higher in the BluePrint (e.g. no templates to make pages in a content Publication)

Don't let anyone tell you BluePrint changes are impossible or extremely hard unless they understand BluePrinting and how your BluePrint is designed.

Here's an example where I swapped a Parent and Child relationship. Don't try this at home without a backup and a strong understanding of the Tridion Object Model (I'm not taking about the API).

You most likely have this in your BluePrint:

New Publication

Inserting a new Publication is simple:

  1. Create a new Publication (250 in the example), adding the same 200 parent Publication before saving
  2. Add the new 250 Publication as a parent to the 300 Publication
It's like cutting in line.



Swap

To perform a "swap" make the changes in reverse:
  1. In 300 swap parents.
  2. In 250 swap parents. 
  3. Fix names.



What can go wrong?

For most issues, Tridion will prevent you from saving a Publication change that breaks a dependency, thing includes things like:

  • Naming conflicts
  • Links to items local to a parent Publication that would break
  • Localized items in child Publications as seen below



But with clever timing or dumb luck you might be able to trick Tridion into saving an invalid reference. So always make a backup before making these types of changes and possibly validate relationships manually or with the Content Manager APIs (Core Service for the developers).

BluePrint Change in Under Five Minutes


After SDL Innovate 2014, I'm feeling bold enough to add audio and my smiling, drowsy, face. But notice the "Context Collapse" David Wesch describes. Without an audience, it's easy to draw inward.

Maybe I'll present to an SDL Buddy or when I'm more awake to liven up the presentation next time.




SDL Innovate: The Consultant in a Hat

SDL Innovate featured a #selfie contest, which I'm not sure I was even eligible for. But as a social media contest of sorts, I thought it'd be fun to well, join the fun.

Like back when I used to dance, I've gotten more stage fright around friends and peers than in front of large, anonymous crowds. I was nervous before taking some of these. :-)

Laptop selfie. I wasn't as self-conscious since most didn't notice the Web camera. 


Dynamic range would have helped with the contrast... maybe.

If you're wondering, "why the hat?" it's because it was the nicest-looking one at Target and for practical reasons: my hair was not long enough to stay in a ponytail yet. The real question then is, "why the long hair?" You'll have to catch me on a project or another event to get that answer.

It's a sign. Literally. On the ceiling!

I was nervous before getting this selfie. The singer was great and didn't seem to mind, though.
I've performed in front of audiences before, but I doubt I could have walked on stage for a better selfie.

This was easy since I was hiding in plain sight.



Cheesy Smile meets the Tridionator.

Mae I take this pic?

My favorite. I'm a fan of books like The Art of Explanation. I loved watching Secret City when I was little. Much thanks and props to +ImageThink for drawing my personal, brand-fanatic CXM story. 

My colleagues dared me to grab this selfie with my future self.

See the screen? That's the little guy below...
"I don't always do software demos, but when I do, it's for Tridion."

You might not recognize this guy without seeing the shoes.

Personally, I think SDL Buddy should have won the #selfie contest.

The funny thing is the anticipation of either taking a pic or what people might think after posting it felt scarier than it really was. My younger friends and family on Facebook and they seem quite comfortable sharing (fairly) personal details, but I don't see many sharing about work except the odd complaint.

I wonder if it's always harder sharing with or for your peers and colleagues? It's kind of sad because my 5-year old loves sharing what she did, learned, or made at school. I don't want her to lose the belief that she's creative or that her "work" is worthy.

If I've told you to (blah blah) blog, it's because you have a wit, charm, or some expertise the World could use. It doesn't even have to be this particular industry. Share, engage, or leave a legacy. It doesn't have to be blog posts, you could perform, code, practice the Art of Explanation (draw), Enchant others, or otherwise Show Your Work. Be a Linchpin.

If you were at Innovate, keynote speakers Josh Linkner and Ted Rubin told you variations of the same theme.

And if you've noticed, smart and creative people are making a living encouraging others to be creative. After reading those books or hearing presentations, you'll realize it's not about being good enough, it's about passionately doing whatever it is you're good at. Today's most rewarding and effective work involves creativity, passion, and connection. These thought leaders are actually not much smarter and creative than us. They're consistently creating something new and helping break down old expectations of what work really is about.

We can have jobs, careers, or better yet, vocations. It's not play to work vs. work to play, but work to have fun. Work to make a difference.

This might be the first time in history where anyone's contributions could be recorded and saved for "eternity." Welcome to immortality. If it sounds like too much pressure, don't worry, the whole World won't read everything you post. Find a way to share more by caring less and my hat's off to you.

SDL Innovate 2014: When Copying Makes Sense with Tridion

I posted how Context was part of my SDL Innovate 2014 presentation. Let me explain the ideas behind prototypes and what "templates" mean to typical knowledge workers.

You've probably read before it's impossible to copy items across publications in SDL Tridion or that re-use is a good idea. I'm sharing ways to cheat this supposed restriction and when to break this guideline.

When Re-use Doesn't Apply

Though sharing and re-use are good CMS principles to apply, they don't always apply.

A classic "gotcha" is re-using a banner, image, or component across many, but not all, pages in a website. The temptation is to re-use these by placing them on many pages as component presentations (often statically).



As I've explained before, publishing will update items that use your item. So if you statically re-use a component in several pages, publishing it will publish it across those pages. In this case, moving this re-used element from a component presentation to something more dynamic, possibly referenced by templates will:
  • Reduce authoring steps (maybe set a banner in Structure Group or otherwise configure them)
  • Reduce publishing and isolate publishing to content changes
  • Increase consistency on the site (fewer images)

Retail's View of Versioning

Some of my customers intentionally make copies of managed items (components or pages).

Retail customers prepare weeks to months in advance of a page and related assets. To manage these in Experience Manager and publish and test well-ahead of schedule I've seen a few work on separate Content Manager items that will eventually become the "active" version on a given date.

You might cringe, thinking "but that's not managed!" and you're absolutely correct.

But again, start by naming the content types. Look for "product," "seasonal," or "promo" and you have plenty of non-managed Real-world counter parts to such an un-managed scenario:
  • Product Brochure (versions and variations)
  • Holiday Specials Flyer (each new one is copy and pasted)
  • Promotional Advertisement (submitted as an image or included in another pamphlet, event agenda, or brochure)

Saved As...

How often do you have a single physical or digital copy of these? Do these look familiar?
  • ProductBrochure_v0.1.docx
  • ProductBrochure_v1.0.docx
  • ProductBrochure_reviewed-by-CEO_v1.1.docx
  • ProductBrochure_variation_v1.1.docx
  • ProductBrochure_merged_final_v1.2.docx
  • ProductBrochure_final_final_v1.3.docx
On the Web and especially with Tridion, though you can re-use content definitions, templates, and site structure across seasonal campaign- or micro-sites, the the approval, authoring, and page placement are all fairly different which means though pages could be localized, the content is separate.

Item description variations seen for multinational customers might have very similar content that you would typically localize across translated/country-specific publications, but with enough differences that separate "versions" of the content are needed.

Prototypes Again

We're talking about the space between well-structured content and templating. This is the variations seen in prototypes, which is what everyone else call templates.
  • That Word template for proposals? Prototype.
  • Creating a new Blog post with some default rich text? Prototype.
  • Marketings PowerPoint template? Prototype (and a theme).
How do these apply to Tridion?
  • Copy & Paste
  • Page Types
  • Content Types
But you need good definitions up front. You can define them before-hand or create them, but without prototypes, authors lack examples and context.

Large setups with very different (internal) cliens on the same BluePrint might even copy templates. This wouldn't make sense except for cases where the chosen design and functionality is decentralized. So the central IT team can instead "release" sets of functionality. They can announce a new schema or component template and then dozens to hundreds of independent groups will slowly adopt or ignore "new" CMS functionality.

To make authoring faster, more consistent, and easier, you need to start with good default, or sets of defaults. So let's start with something everyone should be familiar with, document "templates" in the form of Tridion Page Types and Content Types.