Quick, Pick the most Important SDL Tridion Item!

The unofficial SDL Tridion fridge magnet kit is alive and well in the office.

I didn't take an updated picture. Not seen here are bucky ball magnets and an impossible-to-implement BluePrint design.
To quiz our project manager, I asked which part was first and most important. Some choices included:
  • Schemas
  • Components
  • Structure Groups
  • Folders
  • Publications

More on XPM Regions: Difference between Insert and Drag-and-drop

SDL Tridion's inline editing interface, or Experience Manager (XPM), lets authors update content in a way familiar to any post-Web 2.0 user: in context.

Rather than focusing on organizing content like the Content Manager Explorer, XPM lets you quickly set up pages and content in the context of your site.
Tangent: typical Web users and especially digital natives may take in context editing for granted, but consider the fact that this works even when applied to sites never designed to be editable. It could be a plain HTML site, powered by data feeds, or a typical .NET or Java setup. But I digress, today I want to explain a powerful, but likely overlooked XPM feature: regions.
Regions let us control what valid component presentations (schema and component template) and their quantities are allowed in certain parts of a Tridion-managed page.

Example from SDL Live Content (requires login):

<!-- language: lang-xhtml-->

    <!-- Start Region: {
      title: "My Region",
      allowedComponentTypes: [
          schema: "tcm:2-26-8",
          template: "tcm:2-32-32"
          schema: "tcm:2-27-8",
          template: "tcm:2-32-32"
      minOccurs: 1,
      maxOccurs: 5

Authors interact with pages and regions in two was: drag and drop or with the Insert button.

Use These Automation Options Sparingly

A published piece of content may include a mix of author-managed text and images along with automated values such as Content Management System (CMS) author, published date, or last updated date.

There are some automation options that I've seen implemented well (and easily with SDL Tridion, btw), but don't reflect the actual long-term business or visitor requirements.

  • Original author. Relevant because we want to automate adding the author to a given piece of content. Organizations also want audit, track, and blame, I mean credit who created what.
  • Original publish date. Relevant because we don't want authors to have to manually add this value.
  • Last updated date. Relevant because we want to know if content has been updated.

These are all great requirements, but don't rely on just your CMS's automated values for these.

  • Original author may not match the editor that enters the content. Typical scenarios include a a centralized team of authors creating and managing content. Your subject matter expert might want to review that blog post or their upcoming article, but they might not actually enter it into the system (or might not be the author that starts the article).
  • The system's initial publish date is fine until you move content between environments or migrate parts of content. 
  • Last update date is tricky because this can't just be the last published date or the last edit. For content types where dates matter (policies, guidelines, and other official documentation), you'll tend to need several types of dates such as:
    • Published, Posted, or Release Data
    • Effective Date

To better reflect these requirements, consider a mix of approaches:
  • Set good defaults and make options select-able. For example, by default set author to the most prolific author for a given type of content.
  • Read values from organizational items (folders), metadata, and taxonomy--if items have the same author you could manage all articles by a given author in the same folder and have your templates get this information from the folder's metadata. 
  • Automate these values, possibly in creation, but leave them in actual content fields to give authors the ability to change and update them as needed.
  • Default to system values unless authors enter something different. The automated options then become just-in-case "fall backs."
Which approach to choose? It depends on your team's skills and interests and content strategy. I've seen everything from organizations fully extending the CMS's UI to developers that can easily automate  anything to teams that live mostly in delivery (.NET or Java).

If accurate, timely updates help your organization accomplish it's mission (revenue, conversions, whatever) or incorrect values can lead to pain (i.e. lawsuits), put in the effort to create a good experience for the visitor and your authors. If the numbers, research, or your authors' feedback suggest no one reads this part of your site, then maybe skip these altogether and work on the content and context that matters.

Update: We recently saw a question on how to get the Last Published Date for SDL Tridion on Tridion Stack Exchange from community member, Hiren. This value isn't as bad as original publish date or last updated, except for system changes. It's worth confirming if authors would ever want to "back date" the value--if so, then we'd want an actual component field or way of letting authors change this value.

Documenting Component Presentations

This question came up today in a functional workshop:
"When and how do we document Component Presentations?"
A component presentation is the combination of a specific component and template. It becomes the rendered output to whatever digital channel you're managing. The basic, intuitive answer might be that we do not document these directly. We define the content management system and it's up to content authors to put in the "real" content. It's all structured and templated so we don't care, right?

Typically we define and confirm a few CMS elements:
  • Page Types
  • Content Types*
  • Schemas
  • Component and Page Templates
We define or specify individual components mainly through their schemas, which determine component fields and options. What about component presentations?