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?

Training your SDL Tridion CMS

First read Eileen Webb's post, "Training the CMS" for background (thanks Paceaux, for the great recommended reading).

Done?

Awesome. She describes exactly what I'm hoping, encouraging, or looking for in my SDL Tridion functional designs and setups, but in a technology-agnostic way for any CMS. As a thank you and contribution to the discussion, here's how to accomplish her points but with Tridion per her prompt in the comments (see the great comments as well):

"Everyone, please feel free to share any tools, modules, plugins, or tutorials you’ve come across for your favorite CMS that can help improve the authoring experience!"

Content Type Overviews

Tridion's Content Manager Explore, the "back office" interface, is much like any other business system (folders and forms following desktop software expectations). Its in-context GUI (Experience Manager), however, lets editors preview and update a "Staging" version of a website.

System admins can create sets of content types based on example prototyped content (Components in Tridion). It's all configurable through check-boxes and selections, the real challenge is making sure the business and technical teams work together to set these up.

Power Authors Part 3: Troubleshooting Tridion Pages

In my last post, we looked at authoring rights and responsibilities.

I just spent a few weeks working with authors, making content updates, and helping when things didn't seem to work out just right. So let me end this three-part series with some practical Tridion publishing troubleshooting tips that are fresh in my mind.

First, the basics:

1. First basic check is to confirm your CMS environment and publication target (website).
2. Ask yourself, "which publication am I in?"
3. Then start backwards or forwards, comparing to known working examples.

• Forwards is useful when troubleshooting functionality, fixing specific content, or reviewing an author's experience. Use this when you know how the content model works.
• Backwards is useful when investigating why something is showing (or not showing) on the website as expected. Use these steps when the wrong language shows up on a site, links don't work or appear, or content doesn't display correctly. I'm forced to use this when there isn't documentation or the system has been updated since the original functional design.

Backwards Page Troubleshooting Checklist

For example, let's start at the end. Backwards page review:

• Does the page show your latest changes?
• Is it the right page and content?
• Is the page checked in (no lock icon)?
• Is the page published at all? Look for the icon.
• Is it published to your specific Publication Target (Target Type for authors)?
• Did the page have changes since it was published?
• As a shortcut for the above, you could Save & Close the items in the Content Manager and publish.
• Open the page, editing its parent if prompted.
• Is it actually the right page based on its path and filename? 
• Is the page template and metadata correct?
• If functionality is controlled by a "Navigation" page, has it been published for your target?

If the page seems okay, look into the content. Especially for translation, be sure you're looking at the correct Component for that Publication.

The Multilingual Surprise

If content related, open the page in shared mode, especially for translated content and pages. Otherwise you may miss child translated content as you look at parent versions of components. This will happen in most multilingual setups where shared master pages point to global shared content, but content is localized in a translation layer as seen below:

• 020 Global Content (us-EN)
• 030 Translated Language (ca-EN) (translated from 020)
• 040 Master Site (acme) (content from 020)
• 050 Site (acme.com) (content from 020 and pages from 040)
• 050 Site (acme.ca) (content from 030 with pages from 040 or ".com")

When you edit a Page in 050 using "Edit Parent," you get access to 040 Pages with Components coming from 020. To really see translated content from within the page, you need to open the local version the page (in read only mode), so that the Component Presentations are using already-translated Components.

Tip: if you're ever not promoted to edit parent, you're editing a local or localized item.

Component Troubleshooting Checklist

• Is the correct Component Presentation on the page?
• Is it the right Component Template?
• Correct Component?
• Is it checked in?
• Are the fields right? 
• Less likely, but is the schema right?

As a shortcut for the above, use Where Used and BluePrint viewer (hierarchy).

The BP viewer is like GPS for an item. But most of my recent authors don't use it. Why? It's the Parking Garage scenario, but for an office. Once you know where the bathroom is, you don't need directions or someone to point it out. You just walk the floors (BluePrint and folder tree) on your own.

Template-Placed Content?

Finally, does the presented content you're troubleshooting really belong to a given Tridion Page and/or its Components? Global settings, code, and "labels" may come from other Tridion items such as Structure Groups or Publications or even from other systems.

If you know how the content model works, this should be quick and relatively painless. Unfortunately for Tridion consultants new to a setup, it can take some time to understand a given content model. Familiar patterns, common practices, and the backwards approach above can help get you up to speed.

Quick Checklist (for Tridion Consultants)

For those familiar with Tridion the quick check becomes:

1. Check environments.
2. Check-in and Publish to be sure.
3. Check page and components for details, missing Component Presentations, and correct fields.
4. Check content using Where Used.
5. Check metadata for functionality.

Have any practical advice for troubleshooting or favorite "gotcha" stories? Please share in the comments.

Power Authors Part 2: Rights and Responsibilities

In my last post, I described how to avoid the Parking Garage problem.

Now that you're sure where you are, let's consider authoring rights and responsibilities. If you're entrusted, or stuck with the job of teaching others how to use new CMS functionality, content, or pages, then use the following to add some practical accountability to your projects.

Suggested Authoring Rights

I often see "bill of rights" for certain types of customers. For example, New York's taxi passengers have a Taxicab Passenger Bill of Rights. Here are some for new Tridion content authors:

• Authors should know where to work and have the right authorization.
• You should have all the Urls and logins to do your work.
• You should have the appropriate authorization to do your work and ideally even restrictions to prevent you from things you shouldn't. For example, if you can't make or change templates, you'll never be responsible for fixing them or when they go wrong.
• Authors should have a working system and way to report issue.
• Publishing and unpublishing should work.
• You should know where to report issues with the website and CMS.
• Authors are not responsible for everything.
• Though you may care they work properly or make sense, you are not be responsible for template code or front-end design.
• Over time, your stakeholders should learn what parts are under your control so they can ask for appropriate changes from the right people.
• Authors should be aware of content constraints. This includes communication on deadlines, amount of content, any special restrictions on content, if not already built into the system.
• Authors shouldn't be afraid of the system and should have a system to test on! Content Manager Preview may or may not be exactly what you see on the website, but you should have a Preview or Staging site to test changes against. Dress rehearsals are important.

Rights also come with responsibilities. I might have the right to free speech, but must use it responsibly (by apparently not yelling "fire" in a crowded theater).

Some Authoring Responsibilities

I suggest your first responsibility as an author is to create and even break any page types your team delivers. This is especially important for "Power" Authors or editorial content "administrators." If you've followed instructions and document any issues, this helps everyone on the team.

You're not in charge of completely testing a setup, but considering adding the following to your responsibilities for new page types.

• New. Make the page using the new components and templates.
• Old. Add existing component presentations. The old content types should still work.
• Test outliers. Create a few varieties. Use different sized images. Have a set of "labeled" images.
• Confirm field behavior. Make a page where you enter the field description in the field. Translate or localize everything. The documented behavior should be mostly correct, but you might interact with a content model after revisions to the design, with future options visible,
• Test layout. Make a page with as few fields filled out as possible. Try different templates. Pick the "wrong" templates. Confirm the template names make sense.
• Get your feedback to development.

If you can, ask to be considered for "hallway tests" early on before coding starts (this is where you can check how usable the content forms are before the templates are built on these schemas). Authors don't always get to be part of the CMS design process, but agile setups imply collaboration and iterative development.

Be quick, decisive, and vocal if needed. Development will move to the next assignment and if you don't speak up and/or confirm something was delivered as expected, you may miss an opportunity to get fixes. Developers deliver content management functionality, not the final presentation created from content. That's your responsibility.

But if you can get on the mind if developers by appreciative but honest and practical feedback, your authoring experience will be that much better. Be cordial with your team and have realistic expectations, but as an author that has to live with and support the results of a significant investment, it's worth being practical while maintaining high standards.

So we considered how to manage user's context within the Content Manager and now Power User rights and responsibilities. That covered where to find an environment and how to treat new CMS functionality.

Though checklists can apparently save lives, the best I can offer in the next post are some checklists to troubleshoot Tridion Pages.

Power Users Part 1: The Parking Garage Problem

Today's enterprise CMS users are more like Content Directors or Conductors rather than just authors or editors. These Power Users orchestrate content from multiple stakeholders and systems. After about a month of helping a customer's Power Users actually use Tridion, I have another multi-part post, this time covering:

• Confusing Contexts and the Parking Garage Problem (this post)
• Authoring Rights and Responsibilities
• Troubleshooting Tridion Pages

Today's Editor is really a Conductor. Source: GinaR on Free Images.

Let's explore the problem with Confusing Contexts, which isn't unique to Tridion, but happens anytime you have a familiar, near-duplicate environments.

The parking garage (loft) problem happens when you go to a parking garage floor or hotel floor, and swear you had the right parking spot or room, only to find you're on the wrong floor. You may have experienced even in a parking lot without multiple floors if you visit it frequently enough.

Parking Garage Problem

Is this your floor?

"Is this your floor?" Source: vierdrie on Free Images.

You will occasionally (often) have the same problem in similar-looking systems.

Off-topic, but here's an oversimplified idea from gender psychology: apparently men and women have differences in how they navigate. Studies and experiments show men tend to rely on turns and distances (more often) whereas women use landmarks (more often). I wouldn't completely redesign systems on this observation--if you read the brief on a Netherlands parking lot experiment, you'll see they were careful to say "women reported more landmarks in their route descriptions than men, whereas men used metric terms more often than women." Before assuming men are better at navigating than women, read a more holistic perspective that hints we need both and another point that the difference might not even be because of evolution.

So let's expand the Parking Garage metaphor to software with development environments. First imagine a parking lot that changes over time. Your team is responsible for designing, building, and updating this parking lot in near real time. First add multiple floors then replicate it so you also have a "development" parking structure, a test version to make sure your design changes work, and a near-duplicate dress rehearsal parking lot where you accept changes.

In Tridion terms, take 3 or 4 CMS environments times 2 or 3 target types to get 6 to 12 combinations. Add BluePrinting (floors in our metaphor) and you can easily get lost without the right tools and practices. This is ignoring scenarios where a new cloud instance is just a right-click away.

Here are some practices to avoid or reduce the Parking Lot problem with Tridion setups.

Don't Lose Your Car

Visual Hints

Ask your team to skin your CMS environments. It doesn't have to be a big front-end effort, but make the environments different. At the minimum replace the landing page set in the default Custom Page.

Examples:

• Tridionaut Mihai went dark a few holidays back
• I "branded" or skinned the Content Manager Explorer with a different logo and set the CMS name
• Find non-Tridion examples in the real world anywhere you see a themed parking lot, floor-specific decorations, and/or colors.

At my last trip, the hotel kindly added floor-specific art work to let hotel guests know what floor they were on. 

XPM Button

Use Experience Manager (XPM). In addition to letting you start XPM, the Tridion button basically says "this is not Live."

Naming Conventions and Structural Differences

Ask IT Operations to replace IP addresses with domain names when possible. Use a naming convention to easily identify or switch between URLs. For example you might have subdomain a such as dev, test, qa, or accept. Production might just be "cms." For example, the SDL Web Professional Services training environment has:

• CMS.Electridion.com for the CMS
• Staging.Electridion.com as the Staging US English site
• www.Electridion.com as the "Live" US English site

Though you might localize folder names (if following this advice to not rely on naming conventions from Ant P), which is similar to re-arranging the furniture on a floor, this might impact templates that rely on paths and make porting content harder.

Use Tridion's GPS and Browser Search

Within a given CMS environment, use Tridion's version of GPS: the BluePrint Viewer. This pop-up lets you quickly see where an item is created (which Publication) as well as how its been shared or localized in child Publications.

Interestingly enough, I don't see Power Users actually using the viewer much. In terms of the Parking Garage and multi-floor building analogy, I think it's because you eventually become familiar with an environment and its organization, including Publications, Folders, and Structure Groups.

When you first arrive somewhere you might ask, "where's the bathroom." But once you're familiar with a place you don't have to ask anymore.

In my next post we'll take a look at author rights and responsibilities.

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.

How Many Users Can SDL Tridion Support?

I've personally supported dozens of fairly smart SDL Tridion content authors in a "small" setup of three or four sites with thousands of pieces of content. I've worked with organizations with around 200-300 users and more recent ones looking to grow to some 700 users. From other colleagues I've heard of setups with tens of thousands of users. And these aren't even software limits, but more likely caused by the practicalities of supporting that many users (and all that content!).

When someone asks this question, I'm seeing potentially two parts:

• A prospective company (actually the content management organization and individuals vetting solutions) is doing its due diligence. It's making sure it doesn't get burned and is considering the big picture.
• Those looking to disqualify you. 

But since SDL Tridion is decoupled between content management, delivery, and even distribution, it's almost guaranteed server technology will be able to support more users than your organization can.

Here's the good and bad news, depending on how you look at it.

The content management industry--the CMS professionals and content management users themselves, not the vendors, are pointing out that "Big Content" has its costs. Just read a few posts by Content Strategists to see the importance of creating a content matrix or inventory, of having a strategy, and focusing on your end-users' (visitors') needs (learn about top tasks by Gerry McGovern). The paradox of content is more isn't necessarily better.

The other part is users should not be the only number you're looking for. The ability to scale is a question an organization needs to confirm with both its vendor and itself.

In terms of content authors (users), are you ready to:

• Train them now and into the future (please don't expect to successfully cram 25 users into a session and though "train the trainer" works to an extent, do you really have trainers in your organization?) 
• Support them (any system or technology has support costs--I'm de facto "iOS support" for my daughter's iPad for example)
• Convince them to change from their existing systems

Technology has the ability to transform and change roles but also to disrupt existing processes and even people. If you're asking if SDL Tridion or any system can support X users, be sure to account for the change. If done right, you'll be able to do more with the same.

• Some will get to do less manual work
• Some may do more technical work
• Some may do more analysis, design, and content modeling (my favorite)

So have a plan on the benefits and trade-offs (especially in personnel) for a new system. Change leadership matters.

The real question you should consider:

• How much content do you have
• How often will you update it
• What systems does it live in today
• Where do you want that content to live tomorrow (it doesn't all have to be in the CMS)

Is having X users actually a benefit? Are you looking forward to it? Is your organization ready for X users?

SDL Tridion, as a piece of technology (it's an application backed by database(s) like many many others not quite like it) can support as many users as you need. The real question is how many do you really need? How many can your organization support?

A Must Read: Content Strategy for the Web

As promised in my last post, here'a quick post on why I highly recommend Content Strategy For the Web (Second Edition) by Kristina Halvorson and Melissa Rach (of @BrainTraffic) to fellow CMS consultants and customers alike.

CMS Analyst/Author/Strategist Robert Rose admits being a @BrainTraffic Fanboy as well.

As a CMS consultant, I see customers face and take on the same challenges and situations described in Content Strategy. I often see deep functional or technical designs focusing on non-critical parts of a CMS implementation (rather than the parts that have a business impact). So we have lots of tactical pieces in content management systems, SEO, analytics, information architecture, and more, but we forget to step back and look at the entire context.

I cringed knowing I've been guilty of the "It's go time!" email that starts of with:

"Hey, you! [Project manager] here. We're finally ready to have you start cracking on your share of the content. You should find all the information you need in the attachments..."

The book makes excellent points that "content is not a commodity" and that content is political.

Top Five Reasons I love and recommend this book.

1. It reaffirms I wasn't crazy when I first got involved with content management systems.
2. It describes both content and people parts of content strategy.
3. It acknowledges the context that surrounds content.
4. Examples. Specifics (content sampling size based on quantity). Practical examples.
5. Permission to jump in and enjoy this type of work.

I gladly join The Order of People Who Have Read Content Strategy for the Web. In my more recent projects, I've invoked a little content strategy; against my previous and typical "yes-my-product-will-do-it-all-for-you" stance, I asked customers to consider the business impact more websites, more links, or more content might have.

The great news is that more-and-more of my customers are reading about and following content strategy. My latest project includes topics on creating an editorial governance board of sorts. +1 to centers of excellence, regardless if it's for projects, content projects, or a specific CMS.

A content strategy helps you decide what you'll do before you're faced with the tactical reality of content opportunities and challenges. Make this practical by starting with a good Content Strategy book.

Content Strategists

You can tell I follow most of SDL Tridion's thought leadership online because you've likely seen me comment on a few of the many Tridion blogs.

But I also follow practitioners, consultants, and industry gurus with broader or more in-depth Content Management System expertise. Here's an overview of a few great strategists that can help you craft "content" implementations that addresses your business, technical, and most importantly, visitor needs.

Robert Rose

Most recently, I've caught Robert Rose's SDL presentation at the Customer Experience Summit in London. His challenge-the-status-quo presentation style and sense of humor are backed up with very very familiar CMS stories. He makes a strong point that content is an asset that deserves to be managed strategically.

Highlights from his video include:

• 12:00 on Silos in Marketing where we've "basically thrown teams at stuff" including Social, Social CRM, Web, Web content, E-commerce team, E-business strategy, etc.
• At 22:00 he suggests a team for facilitating your content in the form of an editorial board or center of excellence.
• The story about "42 clicks to publish something out to the web" at 32:00 was awesome because he points out that you can call the vendor. Customers wonder, "We can do that?
• You might chuckle or wince at the point that RFPs come back with all 5's.

He suggests individuals should have the ability to change their details, one of the points I've made separately in my "don't be creepy" post.

Gerry McGovern

If you're struggling with massive amounts of content and don't know where to start, consider determining your top tasks, seeing if your CMS can poop (Tridion can!), and following industry thought leader Gerry McGovern.

Practical, evidence-based approaches to content management create business, organizational, and customer wins. The long tail may work great for selling products, but pay attention to the Stranger's Long Neck (it's on my reading list) in terms of your content strategy.

Kristina Halvorson & Melissa Rach

Content Strategy for the Web by Kristina Halvorson & Melissa Rach was one of the first books I've read on the bigger content strategy picture. I'll share a quick "why you need to read it" post soon.

And More...

And I'm finding more content strategists:

• Seth Gottlieb has 15 years in several CMS roles and blogs on the sweet spot where "Content Meets Technology"
• Jonathon Colman, former Principal Experience Architect (yes, there are such roles) at REI turned Content Strategist at Facebook, has a great collection of presentations (check out "Why Our Content Sucks"). If you think my list is a bit much, check out his Epic List of Content Strategy Resources.
• Deane Barker also has years of CMS industry experience. And he's been sharing since before many of my colleagues (including myself) were even practitioners.

Tying this back to my favorite CMS, Deane Barker has an interview on North Patrol describing the history and challenges of Content Management Systems. Be sure to read to the end, then contemplate the Future of Content from an SDL Tridion Product Management perspective.

In your CMS projects, in additional to the functional whats and technical hows, consider or even start with the strategic whys.

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:

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.