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.

Left Rail, Right? How RWD or RESS impact CMS terminology.

My last few clients have projects that include Responsive Web Design (RWD), often with Server-Side Components (RESS).

Their websites will either feature the same HTML markup which behaves differently based on browser size or if using SDL Mobile or similar technology, the websites might also present different markup or prioritize content differently based on the visitor's device.

It might be too early to tell, but I suspect the focus of the RESS side of mobile devices will be on images. For example SDL's Contextual Image Delivery will transform, deliver, and cache images upon request based on the visitor's context.

From Positions to Priority

However, even in "Mobile First" projects, I still see "left" and "right" column fields or a "left template" in some setups.

Your Next Knowledge Day Session

If you work with a professional services or other expertise-based team, you may eventually be asked to present something to a mixed audience of beginners to experts. We often have these as part of our Knowledge Day Sessions (read about my presentations from last year's sessions).

This post offers some tips, tricks, and suggestions on choosing a Tridion-related topic, though you could apply this to other technical presentations.

1. You Know, and Assume Others Know, Too Much

First of all, with the curse of expertise you don't realize how much you know compared to your audience. It's okay to go over basics to connect with both the experts and beginners--then work your way into the details where it gets challenging by the end. If you're read Art of Explanation, you'll know to start with the forest, then the trees, and use analogies (like I just did). See some quick insights from Art of Explanation's Lee Lefever.

2. Non-Technical Presentations are Okay

Your presentation doesn't have to be technical--you could review what services your team offers, describe plans, or review processes. You could share team history, give consulting tips, or do an ice breaker (like last year's CXM games).