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?

Shifting Requirements

As a follow-up to my last post, I want to share a familiar story about stories (aka software development requirements), specifically for "dynamic" Web content types.

As soon as you create the rules to automatically display certain content for a given page, the business may want changes. So instead of just displaying all press releases in reverse order by date, the requirement may evolve to eventually include some to all of the following.

• but make the sort order controllable by the user (and save the setting until the next user session)
• and "lock" certain 2, no 3, actually 5 articles at the top as curated or selected by authors
• also show related articles on the side (but not on the mobile site, show them at the end in a one-column format for mobile devices)
• oh wait, don't forget to remove duplicates and include promoted content while you're at it
• and show disclaimers in the footer...
• based on certain phrases in the content*
• oh and let users save favorite items
• ...and manage them in their profile
• ...and share them to their favorite social media sites
• now let's do the same for products, but with more (taxonomy) sorting options than just release date

I've personally seen these in SDL Tridion implementations and general Web development scenarios, but I suspect the same story is familiar in other contexts. If this sounds (painfully) familiar, consider making some of these options configurable with Tridion (components can be more than just content).

Also evaluate your investment in this much Web application logic. Basically, does your Web analytics and user research support the cost and maintenance for adding these features and/or can you standardize an approach? Do users find your content through the "related articles" links, via navigation, or through search? If it's search, maybe search experience optimization or inbound marketing is the most important thing.

Though features may make your site look like you spent a lot of effort on it, not all features are benefits.

Otherwise, consider a personalization engine instead of just metadata and (custom) queries.

*By the way, I haven't seen an out-of-the-box solution for the "automatically add disclaimers" requirement, but it is easier with modular content. Approaches for such dynamic disclosures include:

• The content management system lets authors add disclaimer definitions inline and custom client-side script manipulates the markup (DOM) to place numbered disclaimers at the end while removing duplicates
• The same approach and logic is done, but during publish or rendering on the content manager side
• Optionally the disclaimer text can be re-used if contained in separate components

I suspect True Automation is around the corner. Combine the fact that recommendation engines can promote successful content with stories of robots writing stories, and I think we'll see very interesting content management implementations well before the Singularity changes everything.

CXM Requirement: Don't Be Creepy

The video pitch for SDL Innovate 2013, noted "Customer Experience Management is as old as people are." The familiar neighborhood store is charming, but scale it to an enterprise level and what corporations know about us can be creepy.

I was enchanted by the conference, which showcased our solutions, partners, and expertise in helping businesses navigate some fairly sophisticated content management and customer experience requirements. I've also previously explained that Customer Experience Management doesn't necessarily change your Tridion BluePrint requirements, but post-Innovate I'm suggesting that creating and managing the customer experience across your enterprise and digital channels requires two very important requirements.

• External: your customers or users need tools to manage their preferences, profiles, and privacy.
• Internal: your enterprise needs the ability to manage such experiences.

Transparency. Control. Got it?

Don't settle for simply copying the competition. If you're developing incrementally, assume your users want control over preferences, profiles, and privacy in the very first release. Include being trustworthy when figuring out your business, functional, and technical requirements and make transparency and control a part of your content strategy.

Need convincing? Target knowing when you're pregnant is old news, so I made a new creepy slide to sell the idea for transparency in your personalized customer experiences. Imagine you're at SDL Innovate, and you see slides telling you not about the presenter, but about you!

Customer Experience Management: Transparency and Control Requirements from Alvin


But what does this mean to content management teams and specifically Tridion implementations?

External Requirements: Data Sources and Rendered Output

We can design SDL Tridion functional designs (FDs) top-down, starting from the expected rendered output. The focus is currently on page types and content types, though I suspect we'll need better terminology to fit the reality of today's service-oriented, multi/omni-channel Web.

When creating your content inventory or matrix, be sure to include the sources for where content and data comes from. All of my recent SDL Tridion FDs include content and data from non-Tridion systems such as product information, social media plugins, script libraries, analytics tags, and even tags to manage tags.

Tridion is flexible at helping your teams manage non-Tridion content in Tridion without that data being in Tridion (by letting you extend the GUI to show other data). By recognizing that not all Web-visible Content is necessarily in the Web Content Management system, Tridion is the "ultimate corporate team player" and doesn't assume it will take over your website.

By tracking especially end-user data in requirements to implementation, you'll better address the external requirement to be transparent on how and why you present certain content to a given user.

Tridion implementation tip: consider translate-able label schema(s) over key-value configuration pairs if you're considering a multi-lingual site (nearly assumed if you're using SDL-Be-Global. You may need to translate phrases such as, "recommended because of," "profile," or "also viewed."

Note that some of this transparency is already law (e.g. refer to the EU "Cookie law").

Internal Requirements: Preview as User, Metadata, and Personalization

You will need a way to test your user's experience in a "preview" environment. This is easy with a a basic Tridion architecture that includes two target types:

• Live
• Preview (or Staging)

In addition, use SDL Tridion features, test different user profiles, and understand the trade-offs to "automation."

• Use SDL Tridion 2013's CXM-friendly features. If you're testing variations of content for different devices, especially with SDL Tridion 2013, consider using Device Preview and Footprint sets. If needed, create and test with different user profiles, however you manage them. As you create content and pages, consider using 2013's Bundle feature to publish or release new "experiences" together.
• Don't assume one user, one browser, or one "channel." One of the biggest mistakes I've seen (and unfortunately have committed) in Content Management and Web development is assuming all users are the same, across all browsers. Offer the ability to Preview as a given User (or Profile) to the appropriate support staff. Just be careful with personal information requirements such as HIPAA.
• Automation isn't automatic. I frequently get requests in projects that end with: "and we'd like to automate this going forward." This usually means authors want to simplify their lives and not have to create a page per user profile or attribute. Authors can reduce the amount of work they do by creating an "indirect association" once, in each content component's metadata, so that Tridion or website code can deliver the right content based on context. But this isn't complete automation, it's just a consolidation of authoring steps from a "choice per page" to "a metadata selection in modular content" (i.e. check box in a component). The trade-off is losing the ability to easily sort or curate the displayed results. I'll have to follow up on other automation trade-offs in a future creepy post.

In addition to Tridion features, I've seen organizations find or create solutions to manage browser sessions, spoof user agents (to test as other devices), automate front-end testing, and present user-or profile-specific information. A quick online search gives you plenty of options, the hardest part will be finding the best fitting options for your team and teaching each other how to use them. One of my customers aptly refers to the "socialization" part of business analysis and requirements gathering--this applies just as much to the ad hoc tools in your development ecosystem.

In your journey to personalize your content and experience for your customers, first don't be creepy. Be transparent and give users control. Secondly, make it easier on your content management team by getting the most out of SDL Tridion and related solutions.