Good News and Familiar Technology for Tridionauts

The back-end Media Manager API is exposed as a W3C SOAP service, which means you can use WCF, like you would with Tridion's Core Service

Custom Events help you with analytics and have three parts:

Users set calls-to-action. Media Managers optionally set custom times and key/value settings for assets (e.g. show a call-to-action from 0:05 to 0:10 seconds. The setup is flexible and simple, using key-value pairs (what to use and what the keys mean is up to your setup).

Results show in a dashboard. Results show in Media Manager in line graphs but more details are available over the Media Manager OData Web Service

So the API is just for the back-end like Tridoin's Core Service, but MediaManager's OData is for analytical results rather than SDL Tridion's Web Service. When working with Media Manager and Tridion, remember your terminology.

Terminology

OData is a standardized protocol. Avoid calling Tridion's web service or MediaManager's analytics APIs as "OData." That's like saying, "we will put the search box in the HTML5" or "the dynamic component presentations are called by the C#."

SDL is the company. Although I normally understand what you mean when you say, "we will store that in SDL," what does this mean if you have both SDL Tridion and SDL Media Manager?

Organization

Media Manager's structure is organized by accounts, clients, folder, and subfolders in the following arrangement:

(Environment or Instance)AccountClientFolderSubfolder

Each item can contain one or more subitems and the interface hints at these relationships.

Select an Account to see its Clients in the next drop-down. Select a client to see its folders. Easy.

Content Model

Folder and Subfolders can contain the following managed items:Assets, the actual image, file, audio, or video files, which are used in...Programs, as a collection of assets in a certain order, which are used in...Distributions, which present their included Programs (rendered by Outlets) and map to:Preview and/or…Live URLs

We were lucky enough to get some top Tridion sharers in the Bootcamp, so expect more examples, posts, and code in the next few weeks.

Bootcamps

This part is cheat sheet of sorts on what to consider when hosting your own knowledge transfer events.

Before planning your next bootcamp, be sure to confirm:

Why: Objectives (internal, external, partners, community, etc)

What:

Agenda (sent before and ready on site)

Examples (code, markup, royalty free assets)

Who:

External: Invitee list, being practical on the number of people that can follow in hands-on sessions (10-12 works for training, though fewer is better for even more knowledge transfer)

Also see the Tridion Developer Summit as an example of just how far you can extend knowledge sharing and workshops within the community. Though the first summit wasn't as hands-on as a Bootcamp, it shared the same considerations and even had workshops in parallel with presentations. I expect to see similar events and perhaps even a hack-a-thon of sorts (possibly mentioned in a California Tridion user presentation two years ago).

These are the things on my mind as we plan the US versions of the Media Manager Bootcamps. Let me know if you have any good tips or practices for Bootcamps in the comments below.

Starting a new community

In the last bootcamp we agreed SDL Tridion World would work for sharing Media Manager information in a centralized location. This is available, but taking lessons learned from the SDL Tridion Technical Community, I realize it's hard to effectively coordinate voluntary contributions because posts are unpredictable, deadlines are hard, and few posts are actually exactly the same.

So by Midas Rule, I started a new SDL Media Manager Google group to collect and gather posts and more importantly, the people working on active Media Manager implementations.

Why Google Groups? The old community forum is in read-only mode and Media Manager's community isn't big enough to start a Stack Exchange site. There are a other Tridion-related Google Groups including PowerTools and DD4T.

Two years and seven months after becoming a software consultant I know a little more about business travel.

Some of my earlier international trips. You can tell because the dates are backwards (May 2012 and Sept/Oct 2011).

Ten ways you know you travel a lot:

You can guess airline carrier by connecting flights (or lack thereof). "Was that direct flight to the Bay Area on Southwest?" "Oh so Phoenix was your hub, was it perhaps US Airways (now American Airlines)?" "Amsterdam? KLM!"

You know which airport seats to sit at by looking for the power cord rather than just power outlets.

You recognize airport personnel, or worse they recognize you (I've only experienced this once but the joke for serious travelers is when your local airport starts holding your mail).

After seeing this pattern at least three times I figured it's worth explaining here (and to remind myself to note these terms in future documentation).

Your SDL Tridion design describes the relationships between your building blocks but not exactly how you build or configure them.

Technically, the implementation details and settings are somewhat out-of-scope in a functional or system design. For example a UML class diagram typically doesn't include instructions on how to create the classes or use the objects in a given language or IDE. However, for software like Tridion, it's worth adding a hint or maybe referencing the documentation.

Relationships

See how these descriptions translate into relationships in your mind:

The empty parent publication gives you the ability to add publications later...

The 020 Content Publication has language-specific children publications....

These source publications have the following target publications for managed translation...

By setting scope setting in subgroups, which belong to parent groups for rights, you can simplify the number of authorization settings you have to manage...

A container component will embed linked components.

Conceptual Relationships and Design Conventions

These relationships combined with the typical diagrams we include in Tridion designs give us concepts such as:

Parent and Children Publication

Groups and Subgroups

Source and Target Publications

Linked Components and their Containers

You might expect to find a "parent" or "subgroup" option or setting in the system. However, except for sources and targets, these are mostly adjectives (or design conventions, if you will) used to help describe how publications, groups, or components are related.

Although you can see Members in a given Group's settings, you actually configure the Member of settings for a given Group. In other words you choose parent Groups, not children. You set the parent Publication, not children.

Settings

Though these design conventions may help explain how publications, groups, and components relate to each other, they don't explain how to set them. So if you ever find you can not set what the Functional Design suggests, make sure you have the other part of the above pairs. Specifically:

To make a "child" Publication, you first need a "parent" Publication. Then you make the relationship in the child publication as you're creating it. This is what the empty parent publication is for since you can only add child publications to an existing BluePrint branch.

To make a "subgroup" you first need the "parent" group. Then you make the relationship in the subgroup.

To make a translation target, you first need at least one source. Then you make the source setting in the translation target publication.

To be able to setup a "container" to linked Components, you first need to have a schema for the linked components, which you then reference in the Container's schema. Then with actual content you first need to have a the soon-to-be "embedded" component before using it in the container component (but there's a shortcut if you forget to make the component first)

Hopefully this makes the dependencies clearer. If you're feeling especially confident, revisit the other Tridion dependencies as described in SDL Tridion Bottom-Up or Top-Down.

In my last post, I described what I know about events and event planning. With our annual internal corporate team event coming up ("Knowledge Days"), I'm tasked with helping devise knowledge sharing games or ice breakers.

A past event included a great "who did it" game devised by +Elena Serghie (check out her blog, In Time for some some great SDL Tridion guides especially her first post, which is likely one of the most cited resources in the community). If I recall correctly, teams competed to figure out who did what in Tridion and where. I'm now creating some ice breaker games featuring the biggest thing for the group since, well since it was just the one (Tridion) group.

Based on a theme of "Connected," with a focus on team building across a mix of roles (not all technical), I've come up with three team-based games involving product knowledge, chance, risk, and Customer Experience Management. Feel free to try something similar at your next event and let me know how it goes in a comment.

I'm participating in and even helping plan more (corporate) knowledge sharing events.

I'm definitely not the greatest event planner (passable now after plenty of mistakes!), but having helped with the schedules, invitations, fliers, and other printed material for events at Champion Ballroom, the Holiday Dance Classic, and student events way back in college, I've learned a few things.