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.

Fields and Folders are about the How not the What

Imagine being a Tridion consultant, helping content authors with setup you're not quite familiar with yet. You're asked:

"What does this field do?"

That can be the most embarrassing and challenging question I get from content authors when looking at an unfamiliar SDL Tridion setup simply because the entry forms are templates are configurable, programmable, and extensible.

Related to this is, "Where should we put these items?"

This one is slightly easier because the answer depends on the update process in terms of:

• Who updates them
• What types of items are they
• Where are they used?
• How frequently are they updated?

The answer to both these "what" and "where" questions should be a "how."

Swapping Parent-Child Publications in SDL Tridion

Tridion BluePrint changes can be difficult simply because of dependencies. Creating a BluePrint and some changes like inserting layers, adding branches, and changing priority are trivial.

You could even "copy" certain items up a BluePrint by changing releationships, making a copy, and rewiring the original setup. Again, the biggest catch is not having the right dependencies higher in the BluePrint (e.g. no templates to make pages in a content Publication)

Don't let anyone tell you BluePrint changes are impossible or extremely hard unless they understand BluePrinting and how your BluePrint is designed.

Here's an example where I swapped a Parent and Child relationship. Don't try this at home without a backup and a strong understanding of the Tridion Object Model (I'm not taking about the API).

You most likely have this in your BluePrint:

New Publication

Inserting a new Publication is simple:

1. Create a new Publication (250 in the example), adding the same 200 parent Publication before saving
2. Add the new 250 Publication as a parent to the 300 Publication

It's like cutting in line.

Swap

To perform a "swap" make the changes in reverse:

1. In 300 swap parents.
2. In 250 swap parents. 
3. Fix names.

What can go wrong?

For most issues, Tridion will prevent you from saving a Publication change that breaks a dependency, thing includes things like:

• Naming conflicts
• Links to items local to a parent Publication that would break
• Localized items in child Publications as seen below

But with clever timing or dumb luck you might be able to trick Tridion into saving an invalid reference. So always make a backup before making these types of changes and possibly validate relationships manually or with the Content Manager APIs (Core Service for the developers).

BluePrint Change in Under Five Minutes

After SDL Innovate 2014, I'm feeling bold enough to add audio and my smiling, drowsy, face. But notice the "Context Collapse" David Wesch describes. Without an audience, it's easy to draw inward.

Maybe I'll present to an SDL Buddy or when I'm more awake to liven up the presentation next time.