Deal with the Shadowy Figure

Happy Halloween.

Question: How do you get KnewKnow to answer your question?

Answer: Post online, "This is so broken. How would you fix it?"

As a Tridion question, he is compelled to answer as part of some unholy contract he's made with some shadowy figure.

First, pick a "shadowy figure" of your choice.

"Please, make me a Tridion expert," pleaded KnewKnow to the shadowy figure. 

An ominous voice replied, "I shall grant your wish but when no one's looking, you will become a pair of chucks and will be compelled to answer all Tridion questions."

And that's the story of KnewKnow. [cue lightning and thunder... aww come on, I know it's nice weather here...]

More deals-with-the-shadowy figure. See if you can guess who's who.

1. An ominous voice replied, "I shall grant your wish but whenever someone says Java, you cannot resist."
2. An ominous voice replied, "I shall grant your wish but no one will intentionally listen to you in person. You will have to blog to share ideas."
3. An ominous voice replied, "I shall grant your wish but you will not be able to forget code you've written, especially if it's in .NET. Good or bad, it will forever be etched into your mind. You will also look quite young as those around you age like normal consultants."
4. An ominous voice replied, "I shall grant your wish but you will attract the attention of beautiful women possibly younger than you, but you won't realize they like you. After asking any technical question the answer will instantly come to you but only after you worry for exactly 3 seconds."
5. An ominous voice replied, "Wait, show me how you extended that extendable area in schemas, I've always wanted to do that!"
6. An ominous voice cracks, "No deal, man. I'm not a fool! You're already an expert! Please don't correct my TRex answers!"

Your turn. As the lucky and unfortunate hero in a similar tale of woe, what would the conditions of the deal be?

Answers in case you missed them: Mihai, me, The Huizard, a semi-anonymous "random" colleague and friend, the most interesting Tridionaut (Jaime), and the infamous Mr. P.  I'm excluding some well-worn inside jokes out of respect for my colleagues, audience patience, and my blogging quota.

How Can I Pass the Tridion Certification Exams?

I'll occasionally get questions about the SDL Tridion certification exams. As an SDL employee, I'm a qualified resource backed up by a team of other qualified resources, but taking the exam isn't a critical task on my to do list (it's covered by the company). However, occasionally I'll be tasked with updating the exam to keep it current and challenging even for myself or our Global Education lead.

You probably should Tweet this guy about the exam experience, he's passed the exams longer than I've been doing Tridion!

The SDL Tridion certification exams test your understanding of the training materials plus practical experience with the content management system. SDL recommends a year with the solution before considering the certification.

Experienced (non-Tridion) developers have failed the Developer certification, not because they weren't technical enough, but because the Tridion APIs reflect Tridion's object and publishing models. They're easy enough, but take time to really "get" Tridion (or "enterprise" CMS, for that matter).

Tips for passing:

1. Take the education tracks which cover the majority of the certification questions.
2. Spend ideally a year developing or using SDL Tridion. One month of experience 12 times is not the same as 12 months of experience. :-)
3. Be very careful with Tridion-specific terms, especially in the BA exam. For example, "metadata schemas" sounds basic enough, but do you understand the difference between these and component metadata, which are defined in schemas? Are target types the same as publication targets? How about Custom Urls versus Custom Pages?
4. Versions matter. Terms get updated (Experience Manager replaces SiteEdit) and new features change old "gotchas" into myths (e.g. Taxonomy changes what you can do with Content Delivery APIs).
5. If you understand the CME, you have a better chance at passing the certifications, in my opinion.
6. General test-taking tips:
1. Read questions carefully.
2. Take your time, but don't get stuck on one question.
3. Improve your odds by eliminating wrong statements (don't start an argument with the wrong statements).
4. Be careful with adjectives such as all, nothing, never, and only (the presence of these words don't mean certain answers are necessarily wrong).
5. Don't over-think the exam.

Get trained. Get experience. Get certified. Easy enough?

I've provided feedback on the last two versions of at least the BA exam and the majority of the dozen or so test takers I've administered the exam passed. They also were trained and had at least a year of Tridion experience.

One last tip: join the community. Sign up for Tridion Stack Exchange, Google Tridion questions, and consider contributing what you do know. It's a free and easy way to see what's easy versus hard and find out what you don't know. Being able to explain Tridion is a good sign you're ready for any question or exam about it.

SDL Tridion Trainees Predict the Content Manager Explorer

Inspired by Wired Magazine's article on Radical New Teaching Methods, several books on presenting visually (Art of Explanation, Back of the Napkin, and Slideology), and recent internal white boarding training, I started giving the following exercise in my SDL Tridion Functional training.

Nothing beats playing Socrates and watching a group figure something out, though I admit it's very tempting to interrupt.

The steps are simple, but take some disciple:

1. Ask a question
2. Optionally draw a starting point
3. Let the audience arrive to a reasonable conclusion, preferably drawing in the details themselves 
4. Minimally guide the group, but allow for exploration and dead ends
5. Confirm their expectations or explain why or how the answer differs

The presentation format above is inspired by Julian Wraith's Tridion Drawn Badly series, but you could do this with chalk on a sunny day, if for example you're training in nice weather.

Video details:
The AWW app lets you collaborate on a drawing and even draw on one device while recording from another. I used free Camstudio for the recording, but probably need to touch base with Robert Curlette of TridionTalk fame on improving the audio.

See if the approach works for you, let me know, and have a great training session!

Technical Questions in SDL Tridion Foundation and Workshops

Update:
After hearing that maybe functional training or workshops aren't for technicals, let me be clear that technical resources should absolutely want to be part of the workshops (that define what you'll have to build). You should also know how to use the software and what CMS designs mean to authors. Most importantly, you'll likely benefit from seeing how we transform wireframes into actual CMS functionality.

After two separate weeks of two BA trainings, I've addressed probably too many technical questions (again, but it's my fault). So, apologies to those that were hoping for some nice, easy software training. You probably learned how to make content, edit pages, and publish the changes plus a whole lot more!

SDL Tridion's business analyst functional training track covers at least:

1. Foundation: How to use the software.
2. Content Modeling: What you need the software for and how to document it.
3. BluePrinting and Authorization: Who can update which parts of the content model and where.
4. Functional Design: How to document everything above in a way you can implement.

To help future functional trainees and my peers, here are general answers to frequently asked technical Tridion questions. Pick one that fits.

• Yes, you can do that, otherwise I wouldn't be training your team. :-)
• Yes, you can do that, it's covered in technical training.
• Yes, you can do that, it's covered in the technical documentation.
• Yes, you can do that, have you tried searching or asking online?

For technicals in a functional class or workshops, please understand that you may be:

Cancelling Booking Requests, A Story of Slightly Scary Usability

Sometimes certain user actions are scary, though harmless. For example, cancelling an online booking request might seem twice as painful as the SDL Tridion BA certification exam (so a TBACE factor of 2).

When booking online travel through an online booking company that shall remain nameless, as a consultant I will:

1. Pick the right dates at a reasonable fair, balancing pain of the trip with what fit corporate travel guidelines.
2. Enter project-related details
3. Request approval from one of the office superstars.

I'm not sure about anyone else, but if it wasn't for GPS and online booking services, I'm not sure I'd be a consultant.

For example, my trip to Amsterdam last year was pretty much, "Alvin, book a flight to HQ for these dates." I confirmed the details of course, but Google and GPS confirmed I had the right office, that the shady cab driver got me to the right hotel, and pointed out I took the wrong train to the office as my blip got farther away from the office.

But despite the convenience, after balancing and picking from 105 flights with travel times from no stops for a direct 2-hour flight for $2,315 to 3 stops with 13 hours of travel for $215, I'll sometimes miss step 2, which prompts one of the office superstars to deny my request. :-(

And because my respect for the approving superstar outweighs the pain of re-booking, I was apparently the first to click a fairly scary option called: cancel approval request.

Wait, what happens if I click that? Apparently not much. Go ahead, try it!

Knowing a little about Web technology and content management systems makes me fairly picky Web user. Both of my complaints are data- and content-related:

Feature-Driven CMS Development Part 3

In the first post of this series we looked at a content modeling scenario that assumed authors needed ultimate per-content-instance flexibility. I described ways to instead focus on features with a more practical perspective.

In the last post, I described ways to measure the practical impact your content model has, especially when taking on technical CMS debt. I used duplicate schemas as an example, which can be a valid approach sometimes, but only if done as an informed choice based on business needs or a semantic content model.

Let's finish this series by reviewing other ways to consolidate your content modeling design choices.

There's Always an Exception

There are times when you don't want to completely separate design from content. Sometimes you may need tcontrol down to the pixel. Consider the Million Dollar Homepage, where a pixel per dollar for a one-time setup suggests no content/design separation and even no CMS required. However, don't assume you want pixel-perfect management, especially if you don't have the analytic business insights to back it up (is per-item padding helping you sell and/or is it costing your business?).

Feature-Driven CMS Development Part 2

In my last post I described ways to manage CMS-influenced features. Before offering a field to authors, confirm it's at the right context in the content model. Authors shouldn't need to manage fields that are always the same for a certain type of content. Also, you can manage current and future features with keywords rather than as new schema fields.

Everyone manages content. Not everyone manages the definitions.

The difference is subtle and you won't realize any technical debt until a few years with a given CMS. But a Category of boolean features beats "Yes/No" options over time for large sets of content (Categories make features searchable and extendable without schema changes).

Feature-Driven CMS Development Part 1

In a recent training session, I came across a content definition (schema in Tridion) that had an author-able field to set a page as "share-able." The field's description included a specific social media feature (e.g. "AddThis" in this case, but it could have been "Share to Facebook" or other currently popular option). The Boolean choice was presented as a drop-down for either "yes" or "no."

I like the per-page ability to enable such a feature, but I'd be careful with this type of flexibility for two main reasons, since this approach might be:

Can SDL Tridion Poop?

CMS Guru Gerry McGovern points out the Web has a digestive problem.

"If the Web were a digestive system it would have no capacity to poop. It just grows and grows and grows..."

In another post he continues:

"If most websites were organisms, they would constitute very dysfunctional ones. They would have a strange digestive system. It would have a capacity to eat lots and lots of content. But that content would either remain in the stomach or colon. Because most websites cannot poop."

Can SDL Tridion Poop?

Emphatically, yes it can!

The basic process is called unpublishing. This will remove an item from your site and everywhere it appears. If removing an item everywhere, unpublishing can even have a laxative affect.

Though you might call it a defect, the Tridion publishing and unpublish rights are combined. If you can publish you can unpublish. "I put you online, I can take you offline!" yelled the content author to the content component.

SDL Tridion has strategic digestive awareness and capabilities:

• Content Digestion. Both ways. It can let you remove content or a page from the site, then use it again later. No digestive metaphor needed, thank you.
• Delayed Digestion through Freshness. It lets you easily find all the places something is used at and lets you transform them specific to each the site. So the content stays as fresh as you can make it.
• Transparent Content Digestive System. SDL Tridion lets you search, find, and tag items and optionally group them into bundles for digestion, mastication, or whatever digestive-to-content metaphor is appropriate.
• Pinpoint Accuracy. For "dynamic" and modular content, it lets you, with single-item, pinpoint accuracy, add or remove items from one or more sites. That's pooping specific items at will, if you will.

SDL Tridion has the potential of a mechanical bovine with multiple stomachs ready to process content and send it out to pasture at will.

In addition, the latest version has a Bundle (multi-item) Workflow feature to let you put workflow items "on hold" to be revisited later, without taking up computer cycles. Customers are using this to appropriately implement expiration workflow. This is scheduled digestion at its best.

Will we see more customers making a leaner, meaner, more efficient customer-friendly Web? That depends. The capability is there in SDL Tridion and plenty of other content management systems, it's up to organizations to be brave enough to unpublish.

Read some more New Thinking, then go ahead, poop some content. It's only natural.

Let's Play What Published That (aka SDL Tridion Link Propagation)?

"Link propagation" or the SDL Tridion feature that causes items that use your item to be republished comes up frequently.

• Some ask about how to not publish pages when publishing content
• Or the status of linked components when unpublishing
• It gets interesting when unpublishing pages when mixing DCPs with static CPs
• Someone eventually notices that related items also get published
• But occasionally someone gets it (congrats!)
• Most recently the newer questions seem to get it so this post might be redundant until we forget how it all works.

I didn't really understand what published what even after a few years of Tridion experience. See my embarrasing comment to KnewKnow's post where I get it backwards. Most recently I explored the differences between (dynamic) components on a page and template's publishing component presentations with Bart Koopman on TRex.

The main take-away is when an author publishes a page, most of the content will update, even if it's dynamic. Publishing a component is tricky, because SDL Tridion will assume you want to update it everywhere it's used.

Here are the basic rules. Understand this and you might pass the SDL Tridion Business Analyst exam.

• By default publishing an item will republish the items that use it.
• Pages publish the dynamic presentations embedded on them.
• Dynamic components publish all presentations when published directly as well as items that use them.

SDL Tridion Humour Part 5

I'm taking a step back from the contextually-aware future and want to share some more Tridionaut fun.

The Random Tridion Blogger made a version of the
Success Kid meme congratulating The Huizard.
I updated it. 

Here's another take on D-Rex, the artistic creation of @wntr.

Another of @wntr's creations. We're still trying to figure it out.
I'm guessing it's something to do with either Jules' worst nightmares or dietary preferences.

I'm not sure where I was going with this. But I probably deserve posting it.

Mr. P's pizza!

Force Finish. Get it? No?

Maybe CMS_Borat could give me a good caption for this one.

"I, too, plan learn Tridion 2013 in 2016."

Enjoy!

Contextually Aware Content Part 3

My last post theorized on contextual use cases. Let's project a bit into global trends, revisit ways to avoid creepy CXM, and keep this practical. At some point there'll be a backlash at this much "contextuality," a huge part of your contextual experience will be offline.

You will start with responsive design and device detection, but also plan for possible future scenarios (I read too much):

• The rising billion will encounter your digital channels for the first time, either on under-powered or completely capable devices
• Today's five year olds will become teenage consumers in ten years, then join your workforce in another ten. Get ready for Generation 2020.
• "Context" willl eventually include ambient light, proximity to other devices, mixed audiences (different ages, languages, and locations in a room), and the context switches from room to fridge to car? Sorry, that's not the future, that's your iPhone, XBox Kinect, Netflix, and digital cable services.
• Content creation will includes a mix of automated content, employee-written pieces, and crowd-sourced information

In the end, your design process will be informed by the data you collect about your users. We already have some automation with profiling and personalization engines, but you still need to provide the content and business strategy. Take a point from PlayFun, an AI that learned to play Nintendo games. It optimized for points for Tetris by quickly dropping blocks and pausing indefinitely so it wouldn't lose. The web design equivalent would be an automated system that made huge promotional banners because users had no where else to click.

You can't get away from design, at least not yet. The first question about doing mobile design with Tridion is if you can do mobile design now. You can grab a template off the Web or hire/train your team to get mobile design expertise, it comes down to core competencies and what decisions you're willing to outsource and which core competencies you'll keep in house.

In the long run, give your engineers and designers the right tools to decrease tool time and increase skill time (nice article from CMS industry guru, Gerry McGovern).

Designing These Experiences

Companies and their engineering/design teams will also want to avoid customer experience management creepiness through transparency and end-user control.

Be clear where and how you learned about the user’s context and giving them control to say it’s not true (even if it is) or to change their preferences. Reality is much more interesting than the most fine-grained contextual segment you can try to craft. For example, with "Ramirez" and "Reyes" in my name, I'll get product offers and letters in Spanish (via snail mail). We might be interested in French products because of an immersion program my daughter is in, but the advertisement should be in English since, as a second (2.5) generation Filipino-America, we speak English instead of Tagalog at home. Even if your company could decipher all of that, I recycle junk mail sent with Standard postage, no matter how official it looks and the movies my daughter might appreciate already come dubbed in French.

In terms of end-user control, let users ignore all of your contextual experiences. They may insist on the full experience, but that’s not the desktop experience nor the mobile one. It’s them experiencing your content model, application, and perhaps real-world experience in a way that works for them.

In other words make it easy for me to do what I do often in a contextually-aware way and then let me tell you when you’re wrong for that instance, a certain device, or all time.

Not All Digital. Users Still Appreciate the Real World. 

My BSMSO doesn’t like my parody vision of the future. The one where she speaks to her daughter in the real world, then a mediated experience kicks off:

1. Daughter will be doing something “online,” maybe gesturing and talking to an invisible entity
2. Her device(s), through an AI assistant will tell her that someone nearby is trying to communicate with her
3. She may respond through her device or possibly in person
4. When BSMSO is satisfied, daughter will go back to that very-important-thing she was working on and proceed to type, swipe, and talk furiously at an invisible interface

Yeah, we’re working out rules I’m sure other parents are struggling with:

• No devices at the dining table, especially when we’re eating together
• Only 1, okay 2 more episodes of My Little Pony at night for Dad, Daughter can watch 3.

A user's experience with your brand goes beyond mobile and responsive design. It's not all digital, though there may be nearly always be a digital footprint. I suspect we'll resist having all interactions digitally mediated and people will still want and maybe even appreciate genuine, RL (gaming lingo for real life or non-virtual) interactions.

At some point, ignore the insights, do a little bit less orchestration of all this contextuality, and let people enjoy what you offer or ignore you completely. They'll come back to your brand, your product, or your service if you're responsible and respectful of their wants, preferences, and needs.

Customer Expectations will Go Beyond (Just) Mobile

Take big data, commoditized analytics/campaign/data aggregation tools, a growing user base (and employees) that are used to the Google/Amazon/Netflix/Facebook experience, and maybe some robots and the future of the "web" is more than just responsive or even responsible Web design.

Create sites using responsive/responsible design, but don't stop there. Take the paradoxical approach of adding more structure (see KnewKnow's post on the future of content) to let your content fit more designs, across more channels, in more contexts. If you already have SDL Tridion, let your engineers and designers work with SDL Tridion's ambient data framework, optionally using the Context Engine Cartridge. Then see what the Footprint Feature and mobile device previews in Experience Manager offer your content management organization.

Get a peak at the nuts-and-bolts in KnewKnow's post on Responsible Web Design.

In a few years, some AI will know I blogged about content management, bronies, and multiple languages. When the perfectly customized promotional content comes my way, I'll be looking for the "that's not true!" button and then come back to comment that the contextually-aware future has arrived. Let's get there responsibly.

Contextually Aware Content Part 2

In my last post, we consider "Mobile" with SDL Tridion. The mobile part, if you're just thinking of screen sizes and a few devices is relatively easy--companies everywhere are addressing it with a mix of content strategy, mobile apps, responsive design. But let's look at some use cases to expand our thoughts, giggle, and cringe at what mobile means to some hypothetical customers.

Consider Use Cases Beyond Mobile

Here are some hypothetical, contextual content use cases that might be plausible for your end users in the near future.

• Content users want to share or experience with the person next they're next to either by showing them or letting their device and apps communicate (well you can already share pictures with certain phones and video games recognize multiple players)
• Content users don’t want others to know they're enjoying in places they shouldn't be enjoying them in

  

  "Hey, no peeking!"

  
  
• Content about an application as they're trying to learn it, and the experiences of others trying to do the same in the context of the software. Think video game in-context, configurable on-boarding "tutorial."
• Content for "Generation 2020" users expect TV screens and museum signs to be “touch-friendly” -- ("back in my day, we had signs and posters!")
  
• Content for users that get upset that you messed with their Netflix stream by watching something on the same account on another device
  
• Content that warns users they're doing something dangerous before they commit said dangerous activity (and the option to ignore such danger)
• Content users think they own and control, but might possibly be influenced by companies (with repercussions)
• Content possibly aggregated from other sources and displayed in a non-typical interface (a light bulb instead of a dashboard, a floor-to-ceiling touch screen or wall-to-wall touch floor, or maybe even through a smell... wait let me confirm if generated smells are plausible... yep!)

What's needed here is content, application, and "experience" design. Content-producing companies (aren't we all?) need to craft flexible experiences across more and more screen sizes and eventually multiple interaction methods.

We conclude in part 3.

Contextually Aware Content Part 1

Prompted by my colleague by a question about mobile with Tridion, I'm predicting what my (enterprise SDL Tridion-using) clients will be facing as they take on the challenge of SDL Tridion with their "mobile" sites. With some humor, parental anecdotes, and the not-quite-obvious we'll see the future will be interesting, unpredictable, and in some cases, already here.

First some background. SDL Tridion can handle already handle the content for any desktop, mobile, or tablet site you can come up with. You don't even need to change your BluePrint (much). Usually the question "what about mobile?" isn't about Tridion, it's about what you want to do. But that's primarily a problem with strategy and business needs. From a CMS perspective, Tridion Strategist Manuel Garrido describes the key decision are what you'd like to re-use in terms of content, functionality, and structure.

The Web design community considered the difference between a focus between devices and features two years ago but the W3C was already promoting One Web back in 2008 with Mobile Web Best Practices.  The Responsive Design term was born out of this community (you've read the A List Apart article, right?). Stephen Hay promoted Structured Content First and suggested there's No Mobile Web. UK designer and author Mark Boulton penned a post distilling these points into four words: "Structure First. Content Always." He also advocates to, "Start designing from the content out, rather than the canvas in" (I'll have to stop acting like my use of "desktop, fridge, car" is a new thing). For good review and thoughts at a better future, read Is it really a mobile Web or a 320px-wide one?

The Web design community recognizes the significance of structure, content out, and contextual experiences. Your content strategy and content model are key here.

Some of my best content modeling training-in-disguise was as a Internet Research Analyst. I had some 26 months where my job was to evaluate some site, summarize its features, then craft a report. Report sizes ranged from a quick memo to 9 binders-worth of material. Add research prompts for Accessibility (and Section 508 in the US) and CMS vendors along with several manual updates in SQL, HTML, and XML, I had absorbed the significance of content structure.

As a content management consultant and aspiring thought-leader in my niche industry, my role is to help customers identify what they need to build and how that maps to SDL product functionality. I can't dictate your business or content strategy, but I can definitely help navigate the catches and pitfalls on creating a manageable content model.

Two big SDL Tridion with mobile "gotchas" are in some of Tridion's strongest features, one well-known and established with the other new, powerful, and more under-the-radar than I'd prefer.

1. BluePrinting. Avoid assuming there's a mobile layer somewhere in your SDL Tridion BluePrint. The content explosion is bad enough without adding publication proliferation to your challenges. Go ahead and create publications to help with mobile or a mobile-specific website, but localization is not personalization.

2. Mobile is more than mobile, it's contextual. Don't believe the hype, mobile solutions (especially with a capital "M") shouldn't be about solving mobile challenges, it's about contextual experiences built on knowing about your user's real-world context. It's about making it easier for your implementation teams to create experiences based on the information surrounding your user. The details in the background are no longer ambient noise, they're ambient data relevant to your customer's interaction with your site, brand, or dare I say, experience.

In terms of content management, the term experience simply recognizes that we're not dealing with just pages anymore. We're looking at multiple pages and the paths through them, possibly including information you already have about the visitor, but also session-based information during their duration, and real-world information like geo-location and type of device.

What SDL Tridion gives you is an SDL Context Engine Cartridge to let your engineers build around this ambient data. The open source Tridion Context Engine wrapper gives you more tangible detection and the ability to create device families. Read more about these tools from Nuno Linhares.

Let Authors Author.

Part of the confusion is what do these developer tools mean to your authors. We have to remember that authors are not managing the design of your sites, they're working and hopefully collaborating within your content management organization, specifically crafting the content experience. They need enough flexibility to structure their content formally and informally (in rich text) and should be able to work with a selection of themes, options, and layout choices that fit your brand.

Authoring and content strategy decisions will determine what pages, content, and functionality are shared across different experiences (or simply types of devices for now). But your authors aren't designing a mobile experience. Your entire team is, from strategy to concept, design, code, architecture, and content. The team has to research, design, and build those experiences. And some experiences you won't know about until you measure across channels, interview users, and run experiments.

"So will there be a mobile check box?" If up to me, no, not in general. I'd start with content types and what they mean to your users in a way that's manageable for your authors. You might need a specific device-specific component (e.g. "buy this app"). But I'm sold on what the Responsive Design community thought leadership is recognizing and suggesting, and that the mobile experience is more than mobile and will need to be more than the current techniques.

Yes, add more features as they're available across devices but don't assume what users will want or need. Let's focus on user attributes, ambient data, and things that might stay the same in the next 3-5 years. Did you ever have checkboxes for "IE" or "Firefox" in your content forms? 

Use things like "geo-aware and touch-enabled" when adding features and group specific devices into families such as "mobile and tablet." Maybe consider user-context like "holding the device" or "in the bathroom" for when it's possible to detect these things. But be careful with assumption, knowing about others and acting on it can backfire.

We continue in part 2.