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?).


Other times to opt for flexible, changing schema designs or to skip them altogether:

• Promos. Quick-changing, promotional content types might be quickly designed and expire after a short period of time. If you never change the content, do you really need to manage it?
• Products. Fields and details may vary greatly for a given content type. Consider managing these outside the Web Content Management (WCM) system if all the variations don't quite fit an XML schema (.xsd).

Patterns to help with these products and promos:

1. Treat as multimedia. Especially if the image, size, and data are closely related, you may consider creating content types such as "banner" or "promo" as multimedia with metadata to help with translation and accessibility needs. Examples:
• See the Semantic Multimedia Recipe on the Cookbook
• Consider Tridion's External Content Library feature to possibly integrate products 
2. Integrate at publish or create designs in delivery (dynamic views/renderers or even client-side templating if you're that far into the cutting edge of Web development).
3. Treat markup like markup. See a way to blend markup with flexible managed fields on TridionDeveloper.
4. Prototype good defaults or the many scenarios. For example, if authors need control over text alignment, pop-up sizes, and even color, you could still create a (fairly complicated) schema for these, but give them a series of good defaults through boilerplate prototypes (specifically Content Types for Experience Manager or Custom URL integrations to insert these variations).

Add Features at the Right Level

Only integrate the parts your team needs to manage and at the right level. Consider a top-down approach.

• Publication. If you need to manage site-wide features, consider publication metadata or publication-level configuration items (i.e. components or Application Data).
• Sections or Structure Groups. If the features apply to certain sections of the site, consider structure group metadata.
• Page-Specific Features. Likewise consider page metadata for per-page features.
• As Component Presentations. If authors need to control placement, give them component presentations, even if the components don't contain actual content (as in a configuration or widget approach).
• Field-Specific. If authors need a field, confirm at which level its needed and offer good defaults or fallback options.
• Rich Text Format Areas. Use platform-agnostic "hooks" with either class attributes or maybe HTML 5 attributes. Avoid placing code into your rich text unless you're willing to manually or programmatically fix these in the next redesign or major platform change.

Ideally, you want to manage the differences, not the same content in multiple places. Ultimate flexibility has a practical business cost (consider a hypothetical 1,001 pieces of content x 6 extra fields + risks from mistakes + training + author/developer frustration).

Manage the Differences

Sometimes you will have variations on the same content type. For example a blog post might be slightly different than a press release, which might be a variation on a generic "article."

With Tridion, consider embedded schemas in this case with a core set of fields that represents "article." Create a layout template for these fields, and then manage the differences by wrapping it with an editorial schema (used by authors) to add blog- or press release-specific fields. Read more on when near-duplicate schemas make sense.

If you'd prefer not to use Categories and Keywords to manage field selections, consider an embedded schema to do the same.

Follow Industry Standards

Look to the industry on how it views content. For example, Google, Microsoft, and Yahoo are suggesting semantic standards at http://schema.org.

I wouldn't recommend their entire set of definitions nor every field, but with the rise of "reverse marketing" and Search Engine Marketing, your content types no longer belong solely to you.

My name. My "content." Google's presentation.
Search results are "content types" derived more from semantics than presentation.

In terms of standards, the W3C describes accessibility standards and I've seen an acute focus on "alt text" as a (the main) requirement, which is akin to focusing on just wheel chair ramps for real-world accessibility.

Yes, you're image tags must have an alt attribute. But your CMS fields don't always need an alt field (see how many do alt text right for the wrong reasons). Rather than assume name and alt for every image, start with a proper content types analysis of your multimedia needs.

Such semantic multimedia might change your fields in the following ways:

• Design and style-related images: no alt needed
• Product and promos: alt needed only if you're not already displaying the text on the page from another field
• Marketing images (e.g. banners): no alt-text needed for stock images of smiling business people
• Images that have the same meaning regardless of context: alt in the image

Be Abstract... Enough

Go abstract and generic, but really consider your content types. If a promo or marketing piece has an image, it's most likely for decoration, which means you probably don't need an alt text field. Go modular, but keep related content together or linked. Structured items in order on the same topic that get updated together should be structured (think paragraph embedded schema), but don't necessarily need to be modular).

Avoid classifications tied to today's technology. You didn't tag content for Netscape, Internet Explorer, or Firefox, did you? Why tag content to specific devices or mobile browsers? Is anyone suggesting their website is "best viewed on an iOS browser?"

Web-related technologies and formats change. In no particular order, we've seen XML, RSS, SOA, HTML, HTML 4, XHTML, HTML5, server-side approaches, JSON, JQuery libraries, server-side JavaScript (and even middle-ware powered robots). Each new language or format rarely completely replaces its predecessors.

• When the field values seem very technical and to a specific format, focus on your author's needs. 
• When your authors want very specific features, take a step back and focus on your visitor's needs. 
• When visitors (or the business) seems to want everything, measure and find out what they really want or do (evidence trumps opinion).

Content models don't change much. Take a look a few decades back. The Web basics of navigation, promos, banners, and articles have not changed much. At the core these are just URLs, text, and images. The challenge is making it fit together in a way that works for your authors, visitors, and development team.

Think in terms of functions, develop for features, but implement with the latest-and-greatest technical techniques. Don't fight your CMS. Manage your content, but also your content and classification definitions in a way that scales and evolves over time. It's worth repeating:

Everyone manages content. Not everyone manages the definitions.

If you got this far, you're definitely not everyone. Thanks for following. Comments, tips & tricks, and differing opinions (eloquently expressed) are always appreciated.