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:

• Technology-specific rather than technology-agnostic. Is there a general description of "AddThis?" that might apply across contexts? Could this instead be called "share-able" or similar? AddThis has been around forever, so this might be a bad example of a bad example.
• Too flexible. Is this really a per-page or per-component setting? Consider reducing the number of settings by instead choosing to offer this setting through:
• Component (Content) Templates (choose the non-sharing or sharing version)
• Page (checkbox in page metadata) or a Page Template selection
• Structure Group (apply to a section of a site or not)
• Publication (enable certain sites to be "share-able")

The last option might be appealing if you manage dozens or hundreds of sites. Your initial discussions with the business might include a discussion like:

"Since we built this feature before, we can enable your site for social media sharing with a simple checkbox. Would you like this feature? If you want to control it per section or only for certain types of pages or even individual pages, we can do that too, but the catch is you must choose when and where to apply this."

Also consider if "Boolean" on/off features like this are part of a growing set of functionality. If so, you might instead make "AddThis" a Category, with options for today's (and tomorrow's) social media sites.

Specifically in Tridion you might create a "Share to" Category with keyword options for individual sites. Map this to the specific code your sites need and you won't need schema changes as the options change. You'll have a feature-based approach manageable across sites as options migrate, consolidate, and/or mean something different based on context.

Category: Share

• Like
• Pin
• Tweet

In a similar approach, consider ways to classify navigation and interaction using SDL Tridion Categories and Keywords:

Category: Navigation

• Global Navigation
• Secondary Navigation
• Small Screen Navigation
• Touch-enabled Navigation

See how these are abstract, but business-friendly enough to handle a large number of scenarios? You might consider a device-specific list like this:

• Full view (Desktop)
• Mobile - iOS
• Mobile - Android
• Tablet

But the market is changing fast enough and new contextual features are making their way to the "Web" that you're likely better off focusing on features and progressive enhancement, rather than a show/hide approach for today's devices and features.

Consider contextual features like geo-location, (compass) direction, and perhaps access to a camera. Together these suggest options for augmented reality, which doesn't fit the second device-specific list. If you create non-Web digital experiences, the future might look like:

Category: Navigation (in the future?)

• Geo-location-aware (show the map)
• Handheld Small Screen (feature thumb-focused and swipe-able navigation)
• Interactive Wall (offer really large buttons)
• Motion-aware (show gesture instructions and UX hints)

Pro Authoring Tip: Using the feature's name as a keyword makes search better as well. Rather than getting too many hits for "yes" or "true" while checking schema options one-at-a-time, you could instead look for individual keywords.

Not (always) the Best Practice

Feature-driven keywords in Tridion is a good practice for managing large amounts of content and related features. However, technology- or website-specific and "yes/no" content fields are probably okay in a few cases, especially when:

• The content type is more of a form, rather than purely content
• There are fewer instances (components in Tridion) based on the definition
• An individual field is significant enough to have its own default and/or longer description
• When presentation and design elements are so closely related to the content, it's okay to mix them. The separation of content and design is a good (perhaps one of the ultimate) practices, but sometimes authors need control over the design without actually entering markup or CSS.

In the end, the authoring forms should make some sense to the authors. I've seen times when authors were expected to enter a hex value to control colors, which might be great for programmers and horrible for those that prefer RGB. ;-)

Actually, my preference for color selections in the CMS is the following, in order of preference:

• Avoid color selections for regular content authors if at all possible. Site-specific requirements and designs change so fast, you probably don't want these values baked into your content model.
• If required, offer business-friendly terms that have semantic meaning (e.g. "important" instead of "red"). Don't accept the excuse that developers need a hex value--Tridion keywords have a value, description, and key for authors, visitors, and developers, respectively).
• If the selection really must be a color, offer a drop-down of color terms, optionally offering a GUI extension with a color picker.

Regardless of content modeling approach, you'll satisfy the developer's technical format. It helps to consider the business impact to taking on CMS technical debt.

I'll revisit this topic in a part 2 follow-up with ways to assess the business impact of choosing between the quick-and-easy versus content models with longevity.