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!

From Crossroads to a Bridge

Four years ago I reflected on the crossroads in my career. Should I go technical or do projects? Will having too many interests hurt my career? I eventually applied a mixed-background of business analysis, project management, and Tridion expertise into a Web Functional Consultant role that I've enjoyed for almost four years.

I recently accepted an offer as a Technical Product Manager in Amsterdam with SDL, which changes everything again. This time I'm taking a bridge-of-sorts across the Atlantic pond. Before I go, let me share...

Lesson Learned from Web Consulting

Doing software consulting for almost four years taught me a few things.

1. Time is your most valuable resource. Value your time.
2. Good habits make a difference. Since I made a habit of writing, I have over 200 Tridion-related blog posts. A list, like a Travel SMaC can help reinforce good habits.
3. Bad habits make a difference. Since I haven't kept up my physical activity, I've gained more than a few pounds.
4. Be flexible when scheduling travel for projects but also clear with your needs and preferences. If you fall behind in a project, the client may want more time. But even if you're wildly successful, the client may want more time. This goes back to #1--value your time.
5. Make friends. You can work remote, but spending time with the team in the office can be worth a move (to the Bay Area in my case). Camaraderie turns coworkers into colleagues.
6. Make a change. There's never a perfect time for change. You can just prepare as much as you can and trust you'll work out the details whether it's a change at work (e.g. new project or role) or at home (e.g. new family members or a move).
7. Life's too short, don't wait.

I survived the last career change with a rather tough October in 2011. In August we'll replace "moving to San Jose" with "moving to Amsterdam." Wish me luck. I hope my Tridion-from-a-Functional-Consultant perspective posts have helped, because things are changing again.

Goldilocks of Creative Design from a CMS Perspective

One of the challenges CMS professionals have with the website and content management design is confusion around content, example content or prototypes, and "templates."

As the functional consultant in Tridion projects I tend to see some trends.

• Just Right. The homepage tends to get special treatment as the "just right" Goldilocks example with enough detail that there's not that much confusion between creative design and CMS design.
• Too little. Index Pages are sometimes overlooked or underestimated in the creative design, where it's tempting to assume similarly-looking pages have the same functionality (and thus same Schemas in Tridion).
• Too much. Finally I often get extra detail on Editorial Pages for all the variations that might present on articles.

Homepage, Just Right

The homepage, especially for the creative design, tends to be the actual homepage, with real or near-real content. The header and footer navigation elements often have the latest-and-greatest, business-approved lists.

As the most visible page, at least internally, everyone is an interested stakeholder for the homepage. It's approval is a milestone for the designers or design agency, it overviews the type of content the site has as well as the navigation approach for the CMS team, and it likely needs multiple levels of approval.

The homepage is one of the few cases where we get documentation for actual content or Component Presentations.

Ironically, I suspect among today's social-savvy website visitors, the homepage may be important for establishing credibility, but visitors are probably more interested in getting things done. Read about top tasks vs tiny tasks if you suspect the same. 

Index Pages, Too Little

Index page designs might have example Lorem Ipsum content. But I see confusion on separating types of index pages versus instances of those pages. Is it the same page type with two instances? Or do we need separate content definitions and/or templates (Schemas and Templates in Tridion)?

For example, I had a project where everyone dismissed one proposed page type with, "oh that page will be just like this other page." This meant we could mostly skip the wireframe, creative, and HTML design knowing everything will be "the same."

However, the team had to revisit this because the actual content was different and needed different entry fields and website functionality.

This comes from a confusion between the design "template," which is the proposed visualization of a page and the actual content model or relationship between content and pages. You don't have enough context from a wireframe or creative design to be sure.

Two hints to prevent this is giving elements real names and exploring dynamic functionality.

Hint 1: Give it a Name

The quickest way to test how you might model something in a CMS is to give it a name. Are the pages called...

• Services, Products, or Solution page types, each with their own name and relationship between pages?
• Department Landing Page, as seen on an Intranet where each department lists the people and documents related to it?
• An "About Us" or Corporate page?

With a modular CMS like Tridion, you can have lots a variety across pages that all have the same page template, with different sets of content on each page. The design "template" isn't related to the CMS "template." Each example from creative design might be a separate page instance in the CMS.

Hint 2: Dynamic Functionality, Filterable Options, and Libraries

If the website has dynamic functionality that lets visitors filter on or search for different content, your approach will depend on what you're filtering on.

If each selection returns a different type of content such as a venue versus a person versus a product description, then you'll likely want a Schema for each type.

If the selection returns the same type of content, as from a library of articles or gallery of images, then you're dealing with classification which means either Metadata and/or Taxonomy. From a functional perspective I'm not partial to how you implement this in delivery. You might consider one of more of the following:

• Content Delivery API is a familiar, common approach well-known within the Tridion community.
• Taxonomy can group similar functionality, with the ability to to also get related Keywords or look for Keywords across Categories.
• SmartTarget can help if the organization is familiar with personalization or you start seeing shifting requirements.

After dealing with homepages and confirming instances vs. templates, you might notice an excess of editorial pages.

Editorial Pages, Too Much

Some editorial pages might be examples like a generic article or actual pages like the terms and conditions or FAQ* page. These tend to be lower in the site hierarchy and the confusion here is the opposite of landing pages.

You might see wireframe examples of:

• FAQs
• Terms & Conditions
• Accordion Example
• Article
• Advanced Article 

Often these can be managed as fewer page types which means one page template in Tridion with variations in the Component Presentations. This are probably the easiest to model since the same article Schema could present as an accordion, with rich text for an advanced article, or as an FAQ based on either content or a template selection (in other words, you can easily enter a question in any "subheading" field along with its answer in the body field).

*I'm compelled to mention you might not even want an FAQ page in your next CMS project.

If I could influence the creative design process, I'd ask for this instead:

• Consolidate the editorial pages by providing the outside global header and footer along with the variations in content you might have for each. I want counts for each type of content as well as where they feature in the site map. Content strategy matters.
• Provide the relationships between index pages and their linked detail pages. If possible, consider a standard approach related to the site map hierarchy. For example, level 2 pages could be index pages with detail pages at level 3.
• Include more index page examples, especially for items in the top navigation.

More context would be appreciated on the text and how it might vary. Part of the content analysis done by a business analyst or functional consultant includes challenging assumptions and getting clarity on the content model. For example, you'll often need to confirm if Calls-to-Action (CTA) always have the same text.

Sometimes you'll see "Read more..." in some places but then "CTA text" elsewhere. Just because Tridion is modular doesn't mean editors want to create and manage separate pieces for essentially the same piece of content.

Whether you get too much, too little, or just the right amount of creative design examples, pictures are never enough. Get the context you need to make a well-fitted, managed website.