That Should be in the Product!

Alex Klock, of Razor Mediator fame, presented his work on Content Bloom's Alchemy GUI extension framework at this year's SDL Tridion Community Award (MVP) retreat (2014 video). As the community releases, and even re-releases, SDL Web (Tridion) extensions, some might ask, "why isn't that already in the product?"

There are a lot of business decisions from legacy requirements, to market desires, to customer needs, to an entire development process that drive what's actually in the box. I can't speak for what's in Tridion today (maybe tomorrow), but I respect the history (and love the product!).

But since I'm joining the Product Management, making it fair game to ask, let's explore some ways to evaluate product suggestions by looking at BluePrinting and Content Management System (CMS) development.

The following diagram has a Y-axis for Publications (roughly SDL Web-managed sites) and an X-axis for CMS environments. DTAP refers to the CMS environments of Dev, Test, Acceptance, and Production. Combining the varations give us this table and a graphic:

Publication (site) variation	DTAP variation	Example
Different per publication	Different per CMS environment	Site system settings
Different per publication	Same across CMS environments	Language Codes
Same across publications	Different per CMS environment	CMS Instance configuration
Same across publication	Same across CMS environments	Organization-specific settings

Notice a few patterns in this matrix:

• Content manager, "single source," and some developer-related settings tend to be the same across environments. Building blocks like Schemas, Component Templates, and Components for headers and footers are also consistent across the DTAP environments.
• Delivery-side configuration varies between sites or Publications, though many need values for Language Code or Site URL.
• Settings that vary across both DTAP and Publications start to multiply. It might help to have easier ways to manage the delivery-side topology of a given DTAP environment (that's a hint).

Plotting various managed elements, including configuration in Tridion Component or Metadata, creates a snapshot of a given organization. Add a Z-axis to represent different customers and you can evaluate when something applies universally, in which contexts.

For example, if all customers used certain Publication Metadata fields with the same options (e.g. language codes in the format of xx-YY where xx is language and YY is Country/Region) across all their environments, it would make sense to add "language code" as a Publication product feature, rather than an implementation option.

Before wanting something in the product, you want to be aware of how it will function across websites and DTAP environments. Adding additional dimensions such as "type of user" or "size of implementation" can further help analyze a request for "productization."

For a given Alchemy 4 Tridion module (or any extended SDL Web functionality), considering who needs what functionality and where (in which publications/environments) helps address "why something isn't in the product" and maybe even "when" something will be. Even knowing all of this still leaves the interesting question of if we should put something in the product (and even who's the right people to build some functionality, but that's a different post).

With the "coding" part of the retreat done, I want to say thank you to Alex, Content Bloom, and the SDL Web MVP participants. Community contributions (and use) can highlight what features are important to you, your colleagues, and customers. I've been a fan since I joined the community and will continue to support your efforts in whatever role I play.

Everyone else, have your GUI extension developers or consultants check out Alchemy 4 Tridion as Alex and Content Bloom introduce this framework to the community!

Left Rail, Right? How RWD or RESS impact CMS terminology.

My last few clients have projects that include Responsive Web Design (RWD), often with Server-Side Components (RESS).

Their websites will either feature the same HTML markup which behaves differently based on browser size or if using SDL Mobile or similar technology, the websites might also present different markup or prioritize content differently based on the visitor's device.

It might be too early to tell, but I suspect the focus of the RESS side of mobile devices will be on images. For example SDL's Contextual Image Delivery will transform, deliver, and cache images upon request based on the visitor's context.

From Positions to Priority

However, even in "Mobile First" projects, I still see "left" and "right" column fields or a "left template" in some setups.

From Unmanaged Text Field to Managed Fields in Tridion

In 2011 I mentioned you can change how a Schema text field displays. I had the chance to test one type of change from a plain text field to a text field with values selected from a Category.

If you find a text field has the same set of options used several times, you may want to change it from an unmanaged text field to a field based on a managed list of elements.

When making this change, you have two options:

1. Schema defines the list: if you want control of the order of the field options and the options do not need translation, consider placing the options in the Schema directly. Optionally use an Embedded Field to manage the same list everywhere its needed.
2. Category defines the list. if you want editors to have the ability to bulk apply and search for items tagged with the option as well as for dynamic website functionality along with translation of the options, use a Category and its Keywords instead instead.

Building Blocks setup:

The Catch with Embedded Link Schemas in Tridion

Re-use is great, except when it sucks is not-so-great.

Many (all) SDL Tridion implementations include an embedded Schema (content entry definition for a subset of fields) with something like the following:

• Text
• Internal Link
• External Link

If you already know Tridion, the tl;dr lesson for this post is: please do not use generic (text, component/external embedded) links when injecting content (creating a Component Presentation based on a linked Component).

This embedded link Schema lets you re-use this set of fields in other Schemas (read about how others handle this embedded Schema for links).

Description field tip: I like the SDL Tridion Standard Reference Implementation's (STRI) description for the external link, which adds "-- OR -- " as a prefix, so it's clear to editors to make a Component or External (http:// or relative) link. See other field-naming ideas in my training Tridion post.

Tridion User Expectations for the HTML Design (and beer metaphors)

I'm wrapping up my most recent visit to the Amsterdam office. One of my colleagues had a prompt from a client on what to request from the creative agency in terms of the markup. Of course we had to compare notes.

We gathered our "best practices" but needed non-technical descriptions for the business user communicating their preferences to the creative design agency (if you really want the technical details take training and/or read this post by Frank M Taylor).

So let's look at some user stories for those using an in-context CMS editor:

"As a CMS user I need the ability to add content to and from the page. I should be able to add, re-order, or remove content in the in-context or form-based editing interfaces."

This translates into movable elements. Lists and “flat” markup are preferred where possible—especially on a page. This lets editors add, move, or remove in the Content Manager and Experience Manager.

You don't need markup to see which is easier to manage. Here's an example from our CMS Design Principles training: perhaps your presentation looked like a box of sorts:

A B C

D E F

G H I (that's the end of the training example, the rest is my metaphor)

Would you prefer a list that automatically displays in rows?

Documenting SDL Experience Manager and Smart Target Specifications

The idea of "regions" are important to:

• Experience Manager (XPM), SDL Tridion's in-context editing interface, where XPM regions allow content placement
• Smart Target, the connection between SDL Tridion and Fredhopper, where ST regions show certain content based on things like search terms or visitor or session-based triggers (and show fallback content when nothing triggers)
• Content Management System (CMS) Functional Designs for (SDL Tridion), where "regions" identify where content types are allowed and in what quantities

Although technical users or developers will implement these pieces, XPM and ST requirements are business-driven. Here as some example formats I've been using on recent projects. Although I hint at some of the process, this isn't a comprehensive guide as there is more that you'll want to consider in a SmartTarget or Experience Manager setup!

As an overview, consider the following details in your next Functional Design:

Min, Max, and Everything in between

You can better understand a content model using two numbers for quantity: minimum and maximum. Data modeling might refer to the cardinal relationships between data tables, but in terms of an enterprise CMS we're mostly interested in how many elements can exist (this content type or text in this location, on this page, etc):

Let's look at:

• Min
• Max

I have these in the example "mobile-first" page type breakdown from my last post. But it could also apply to any managed elements such as fields, images, regions, selectable options, or websites (think Tridion BluePrinting).

Modeling Split-Style Labels and Headings

I'm working on a CMS design with text labels that look like:

SPECIAL
DEALS

BUY
NOW

ON-SITE
SPECIALS

PRODUCTS &
SERVICES

Pretty simple, right? How would you model this in Tridion?

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."

Quick and Dirty Way to Determine X and Y Coordinates

Sometimes Tridion content authors need to enter X and Y coordinates to position an element within an image, content or on a page. I believe there are often better ways to handle such positioning requirements including a mix of:

• Automatic for authors:
• Styles (e.g. automatic placing presentations)
• Relying on inline flow and block elements (e.g. placing selections and items in order from top-to-bottom or left-to-right)
• Making the entire component presentation, image, or area clickable rather than a specific (hot) spot
• Higher-level selections for authors:
• Relative positioning where authors choose something easier to understand than coordinates (e.g. top, right, bottom, left)
• Templates (for a few options, we don't want dozens of templates but "left" and "right" options could be reasonable)

But if you find yourself entering such “Battleship” fields, especially within an image, here’s a quick tip using Window’s MS Paint or another image editing program.

Paint

Paint’s status bar will show you dimensions as well as X and Y in pixels as you move your mouse over an open image.

Managing Robots META Tags with Tridion or any CMS*

*"Any CMS" refers to any system that lets you configure your own authorable-fields to be rendered as you prefer, in this case <META> tags with name attribute set to "ROBOTS."

I often see requirements that have likely made their way from an original Request for Proposal (RFP) to a CMS Functional Design that reads something like: "authors should have the ability to set page-level meta tags including the Robots meta tag."

This meta tag "tells" search engines how to index content on a given Web page and its links.*

Valid Content values for <META NAME="ROBOTS"> includes:

• INDEX
• NOINDEX
• FOLLOW
• NOFOLLOW

And if absent, the default is INDEX,FOLLOW. See the Web Robots Pages for the details.

*Bots aren't forced to actually listen to these instructions, though I'd say most search engines try to play nice. 

First Step in Designing Content Entry Forms

The first step in setting up authoring forms in a CMS that lets you create your own content types isn't making the content definitions or schemas. The first step is defining and naming the content.

I recently posted on how to model an example page for practically any Content Management System (CMS). But I didn't explain why the first step of naming the page and content types was important.

8 Reasons to Start with a Name

Here's what I've learned in the last few years and why I think naming types of content is very important:

1. Names mean something to the business that will have to manage the content. If the team calls something "rich text" it implies authoring freedom whereas a "product" has completely different requirements.
2. Names imply owners, a process, and possibly a content life cycle.
3. Naming a type of content lets you define where it is allowed, how it displays, and additional processes or functionality associated with it.
4. Names let you compare and contrast with others. For example, are you using the same schema names that Microsoft, Google, Yahoo!, and Yandex use for defining "content?" If so, should you consider (some) of the same fields?
5. Names give you relationships and priority when viewing options in an alphabetical list.
6. Names tell you if you're mixing content structure with presentation. For example a schema called accordion suggests how it will present. But an accordion is basically repeated headings and subsections. Schemas should drive structure and control re-use rather than functionality simply because it is much easier to make a new accordion template (or update an existing one) than it is to move existing content into an accordion schema for a presentation change.
7. Plural names suggest content relationships and whether you should group sets of fields (with embedded schema) or keep them in separate components. You have different approaches if the business updates "the FAQ," versus several "FAQs," or even many "Q&As."
8. Finally, a name gives you a way to interpret the significance of content by quantifying, planning for, and confirming its business impact. My favorite non-CMS example is the Million Dollar Homepage, where 100 pixels cost $100. The business case included pixel-perfect placement, no text, and no changes; so no CMS required. When implementing a CMS, the homepage for a major retailer will have different requirements than a microsite or even a corporate homepage. Terms like "product," "tool," or "gallery" all at least imply different approaches.

Content Modeling Best Practices

Content modeling for Content Management Systems (CMS) is the act of designing the relationship between content, their fields, and their containers (i.e. pages).

I don't use "best practice" lightly, but the best practice in CMS content modeling is opting for a semantic (update: meaningful) content model (see exceptions below), where content types and their managed fields mean something to people and machines.

Though standards like schema.org offer much needed content types or definitions, they do not create your content model. Your business and available systems determine your content model.

As an example, consider "Person." You'll notice it has a "structured value" for Postal Address. So we know with a CMS we'll likely have authorable fields that we template or render to a "semantic" output.

• But what are the direct and indirect relationships?
• Do you keep a list of separate addresses with a many-to-many relationship?
• To what extend is it worth normalizing the data?
• Could you simply do a reverse geo-code lookup?
• Most importantly, in CMS-terms, are you going to re-use the same content in a different context or page?

So consider markup read-able by people and machines along with standards like schema.org, but define and evolve your own content model.

Having said this, here's when to break the rules:

• Functional or Feature-based scenarios (maybe)
• Promotional Content

Feature-Based Content Model

You may opt for a functional or feature-based content model in a "multi-tenant" scenario. This is when you use a CMS like SDL Tridion to create a mini-site management platform for distributed and separate groups. This works to the extend that mini-sites and blogs literally have one or two content types (blog index and blog post).

Example content types will include generic names like "generic content" or "article" (that's use for anything on a web page).

Ultimate flexibility has a trade-off though. Wide spread changes to the model and design and new channels can become difficult.

Promotional Content Types

I've mentioned it before and I've seen setups that break all CMS conventions. But because of their short times online, how they compete with the "main" content, and variations, promotional content types or promos disregard many CMS best practices.

Promotional content would traditionally be calls-to-actions, promos, and advertisements. More recently we're seeing interactive multimedia like games as well as targeted content from sites and advertising platforms. 

You can still manage these items in terms of metadata, placement, and profiling though the "content" might be markup or a baked image.

This is more okay when:

• It would take more time, cost, and effort to model the variations into content forms. At this point, especially for graphical design-intense promos, it's not worth making the details configurable to the pixel. At that point, you're "coding in a form."
• Design owns and is willing to create these variations in their favorite IDE and syntax. If regular authors shouldn't be able to pick any RGB or Hex color code and designers don't want to enter these into a CMS form, then there is no need to "separate design from layout."
• You can demonstrate the business impact and/or these are from somewhere else, ideally being measured and adjusted by your analytics.

Personally, I suspect if we looked at the majority of promos and call-to-action banners, we'll find some of the scenarios aren't worth it. It really comes down to the context--do you visitors finding what they need on certain sites and are these promos helpful?

So there are your best practices. Use a CMS content model with terms that mean something beyond their presentation. Break the rules to scale or sell. Mix and match approaches as needed.

Feature-Driven CMS Development Part 3

In the first post of this series we looked at a content modeling scenario that assumed authors needed ultimate per-content-instance flexibility. I described ways to instead focus on features with a more practical perspective.

In the last post, I described ways to measure the practical impact your content model has, especially when taking on technical CMS debt. I used duplicate schemas as an example, which can be a valid approach sometimes, but only if done as an informed choice based on business needs or a semantic content model.

Let's finish this series by reviewing other ways to consolidate your content modeling design choices.

There's Always an Exception

There are times when you don't want to completely separate design from content. Sometimes you may need tcontrol down to the pixel. Consider the Million Dollar Homepage, where a pixel per dollar for a one-time setup suggests no content/design separation and even no CMS required. However, don't assume you want pixel-perfect management, especially if you don't have the analytic business insights to back it up (is per-item padding helping you sell and/or is it costing your business?).

Feature-Driven CMS Development Part 2

In my last post I described ways to manage CMS-influenced features. Before offering a field to authors, confirm it's at the right context in the content model. Authors shouldn't need to manage fields that are always the same for a certain type of content. Also, you can manage current and future features with keywords rather than as new schema fields.

Everyone manages content. Not everyone manages the definitions.

The difference is subtle and you won't realize any technical debt until a few years with a given CMS. But a Category of boolean features beats "Yes/No" options over time for large sets of content (Categories make features searchable and extendable without schema changes).

Feature-Driven CMS Development Part 1

In a recent training session, I came across a content definition (schema in Tridion) that had an author-able field to set a page as "share-able." The field's description included a specific social media feature (e.g. "AddThis" in this case, but it could have been "Share to Facebook" or other currently popular option). The Boolean choice was presented as a drop-down for either "yes" or "no."

I like the per-page ability to enable such a feature, but I'd be careful with this type of flexibility for two main reasons, since this approach might be:

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?

Tame the Content Injection Monster

Content Injection, or rendering Content Types (Component Presentations in Tridion) within the context of another Content Type (Component Presentation) is a powerful content management option.

But be careful it doesn't wreck havoc in your implementations and become a monster to manage.

Run! It's the multi-level, deeply-nested content injected monster!
Source: TridionWorld, with a minor tweak and much respect to the authors--
I regularly cite this article in my own engagements..

Dynamic Vs. Static Component Presentations Vs...

I recently made the mistake of asking a client about their preference for dynamic versus static component presentations and of course got the response, "we prefer dynamic!"

Component presentations (CPs) are simply the combination of some content (a component in Tridion) and how it displays (with a template in Tridion). When created by an author, these CPs on a page display according to page template rules. CPs on a Page are a Good Thing. They are appropriate with context, placement, and order matters. CP behavior is configured in your Component Templates.

Nothing Wrong with CPs on a Page

I prefer terms such as "embedded," "curated," or "assembled" to refer to Component Presentations on a Tridion Page. "Static" works, but as seen in my story, it suggests there's something outdated or wrong about assembling pages. There's nothing wrong with a Tridion page with embedded Component Presentations!

Don't Let a Format Dictate Your Content Model

In the SDL Tridion workshops I've given, developers sometimes ask fairly technical questions on everything from publishing to rendering to architecture. I understand it's hard to grasp a content management system in a few sessions. And maybe I get the questions because I offer answers ("I'm just functional" doesn't seem to work anymore)?

At the 2012 MVP Summit, Nuno Linhares pointed out the related technologies on StackOverflow's #tridion tag. The snap shot to the right is already outdated by the time you read this and it doesn't even include concepts and "basic" Tridion terms nor the architecture options. Bart Koopman points out these questions reflect complexity of the product (though not necessarily its difficulty).