What to Implement in Tridion First?

In a case of role-reversal from Functional Consultant to Product Manager, I'll soon have opportunities to prioritize development tasks.

I've told customers they might (should) prioritize based on their market/product/content strategy. For example, a client asked how to prioritize their website redesign from a Tridion perspective. After giving my feedback, the client pointed out my advice differed from my project manager. Oops.

• My Project Manager said to prioritize by difficulty.
• Separately, I suggested prioritizing following content strategy.

I was saved by the fact we were both correct from a CMS perspective. Combine perspectives to get some sagely advice:

Implement the harder, complex, and critical parts early. Use content strategy and business value to choose between tasks of equal complexity.

Use a top-down/outside-in approach to manage buildable sets of work for your sprints focusing on the hard, critical parts first.

1. Global “page template” elements (global navigation, footer, etc.)
2. Main editorial content and your main page/content types
3. Shared functionality that are not on all pages

Without page templates, you don't have pages. Without content, you don't have content.

Your content strategy is aware of quantity as seen in a content matrix, inventory, and/or sitemaps. From a CMS perspective there's value in “templating” something used 100s of times.

Remember that business value and metrics aren’t necessarily the same. Focus on the popular parts and perhaps postpone elements that don’t help your customers. Convince business stakeholders using numbers, customer feedback, and research.

In practical terms:

• Gather the latest site map and content inventory information—reports or the previous spreadsheets.
• Find or get in touch with whoever owns analytics (“hey, is this page popular?”).
• Add this to an outline of the FDD or whatever document manages your deliverables (work breakdown structure, Gantt chart, or agile board).

In the end, the advice was simple if not necessarily easy: prioritize according to your strategy. The hard part now is that I'll have to take my own advice for a change. ;-)

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

Hello from Amsterdam!

It's official. I've joined SDL Product Management and moved the family and dogs to Holland (well, the Netherlands really, but see this video to grok the difference*).

Here's a quick recap of my first month here and what's next.

Week 1: Arrival

Arriving mid-week on the 2 September, I had three days of paperwork and applications. The order was roughly:

1. HR and IT orientations at work
2. Register with the city and complete immigration at the Expat center
3. Get a bank account

Big thanks to the colleagues that helped us get over, from flights to passport information to tips and advice on Dutch culture, food, and where to live. Maybe a very helpful person in HR may start a blog someday. ;-)

Week 2: Presentation Preparation

I prepared for workshops for the SDL Open House, continued working on blog posts about SDL Web 8, finished an introductory slide deck, and prepped for the Tridion Developer Summit.

I also got acquainted with the team and started attending Product-related meetings, which have a different feel than client meetings and workshops.

Week 3: Open House. Open Community.

Last week was all about the open house and Tridion Developer Summit. Great job to the presenters, attendees, and especially Robert Curlette for braving a second year.

I particularly liked the impromptu session where you provided ideas for extensions, which I'm asking participants to list on Tridion StackExchange Meta.

Week 4: Connections

This past week I posted part 2 of our series on SDL Web 8. If the posts sound bigger and look nicer than what I usually post it's because they are. My boss asked me to work with my colleagues and even let me use our official materials as input into parts 1 and 2.

I've also had a chance to meet even more colleagues, answer questions, research, philosophize, and conduct other Product Manager-related activities.

What's next? I'm next working to clarify my role in the "new" team**. We'll spend time looking at what SDL Web 8 includes and what we should focus on in SDL Web 9. So if I ping you with a question or to introduce you to someone that has a question, please respond like I invented the Midas Rule (I did). And by the Midas Rule, you'll probably want to get your feedback in for the next release. ;-)

**Bart Koopman and I were introduced to the team as the new old guys, considering we have roughly two decades of Tridion experience between us and our combined ages make us 80 years old.

*Oh and if you think the Holland vs. Netherlands video was confusing, see another video from CGP Grey on the United States.

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!