Preparing for Your Internal Demo with SDL Tridion (SDL Web)

Don't wait for the requested internal demo to prepare for the demo.

With SDL Web (Tridion), there are a few things you can prepare from project start for any and all internal demos in the future.

This post has four points:

1. Think with +1 more in mind
2. Use the Digital Experience Accelerator (formerly known as the Standard Reference Implementation)
3. Go for quick wins
4. Build the demo into your development process

Note: I wrote most of this post while I was still consulting, so read it from an implementation perspective.

+1 More in Mind

With BluePrinting, you can re-use and apply CMS functionality you've already implemented in another site, template, site section, or page. When developing the following types of functionality, you'll likely get a request for yet another version of the same thing.

• Classify content. If you dynamically display tagged content by classification (Taxonomy), you'll likely need to also display other types of content by tags as well and will want to make the content type (Schema) configurable.
• Translate content. If you allow translation for a given site, new sites may need translation. Even if it's "not in scope," a proper BluePrint design can support the request for translation when it comes.
• Control website functionality from the CMS. If you let content editors present a form or other "widget" (CMS-controlled website functionality), you'll likely need a similar form with different content on a different page. Make the content editable and translatable.
• Create a site. If asked to create a microsite, you'll likely have more requests. Consider sharing web application functionality within the CMS.

Be careful to avoid gold plating in any development process, but within reason consider how content management will evolve and take advantage of the tools..

One More Item or Feature. Not More Types.

Assume +1 more as in "we'll likely apply this functionality again." But avoid cluttering your content model and CMS entry forms with functionality that isn't ready yet. For example, if you need to display an image, assume you'll display more images but don't add video or audio options to your content forms until they're actually ready to be used.

Do this:

• Category for "features" with a single keyword for "mandatory." This lets you add additional options later, but keep the forms specific to today's available options.
• Have a field for images used in the current content model.
• Design a scalable BluePrint and folder structure, starting with the Publications and folders you need.

Not this:

• Add potential fields, Keywords, folders, or other items before they're needed. Or at least only use them in non-Production environments.
• Add a field for video "just in case."
• Add Publications and folders, "just in case"

Accelerate Your Implementation

Years of practical experience and expertise went into the Standard Reference Implementation, most recently released as the Digital Experience Accelerator (DXA). Use it. Learn from it. Know what Tridion is capable of. After seeing familiar patterns in the DXA, read about or even contribute to SDL's other open source initiatives.

DXA modules continue to evolve, but so far include:

• .NET and Java versions
• Modules for:
• ECL
• Media Manager
• SmartTarget
• Search (with both Solr and AWS CloudSearch support)

Quick Wins

You're busy installing, implementing, and developing but save a few moments each sprint or day to go for quick wins. The following take little or no development work:

• User interface integration such as:
• Consolidating related web systems (as links) or custom areas in the Slide Out Navigation 
• Custom Pages, as iframed pages within the CMS
• Custom URLs with links for content field descriptions
• Sites setup (quick links to the sites for each Publication)
• Translation, if already set up (for either Translation Management or just new Publications)
• Sharing CM-side functionality through BluePrinting
• Experience manager visual hints
• Page type example url
• Template icons
• Component Presentation borders
• Even the border colors themselves
• Moving items up or down a BluePrint (only in SDL Web 8 and later)

Development Process

I've made the mistake of asking, "is Experience Manager in scope?" The response varies from, "I'm not sure" to "we're just going to get this done for now."

Whether you're a partner, customer, or colleague in SDL professional services, I'm explicitly telling you, as someone that's worked with Tridion since 2008, was part of SDL Professional Services from 2011 through 2015, and now in Product Management, that "yes, Experience Manager is in scope for all new SDL Web projects."

You want Experience Manager for SmartTarget, for mobile setups, for easy page creation. Don't go for inline editing without first starting with in-context creation. The best parts are the easiest.

In other words, in-context beats inline.

At the minimum, you should include the page button (via the page bootstrap script tag) for Staging sites. Regardless of templating approach, you can and should generate XPM markup for Component Presentations.

Now back to your development process. For any SDL Web-related code or functionality you deliver, you should expect the following:

1. Experience Manager is enabled for this page
2. There's at least one page type
3. There's at least one (possibly custom) content type for each Component Template
4. If you have a demo in your DTAP setup, your code and functionality should work on the demo environments.

*DTAP has long stood for Dev, Test, Acceptance, and Production. With the announcement that SDL Web 8 brings free developer licenses and if you maintain a separate demo setup, you might have DDDTAP. 

Let me end with some observations and warnings.

A demonstration of what you've built should be a demonstration of what you've built.

Good:

• You know you're presenting well in a demo when the audience starts daydreaming about cool new functionality or asking about new features. If aligned with your agile process, an informal review demo should elicit feedback (read about sprint demos here, here, and here).
• You're also doing well when your project manager wants to show the demo to the client, who wants to show it to the boss, who wants to show it to other stakeholders. I call this the Demo Onion because... layers.

Be careful:

• Be careful when you're being compared to the latest new website, the client's competitor, or worse--you're competitor. In the demo, defer to your leads or if you are the lead, address or diffuse any concerns appropriately. After the demo, work with your team and client on how to fix issues and build trust before the next demo.
• But be careful to manage expectations. A demo is not a requirements workshop and don't accept new requirements without validation from the implementation team or project manager.

When a project or program is going well, demos are exciting, well... demonstrations of what you've built. You'll hear, "hey, let me know you something!" rather than, "so, when can we have a demo?"