Preparing for Your Internal Demo with SDL Tridion (SDL Web)

Don't wait for the requested internal demo to prepare for the demo.

With SDL Web (Tridion), there are a few things you can prepare from project start for any and all internal demos in the future.

This post has four points:

1. Think with +1 more in mind
2. Use the Digital Experience Accelerator (formerly known as the Standard Reference Implementation)
3. Go for quick wins
4. Build the demo into your development process

Note: I wrote most of this post while I was still consulting, so read it from an implementation perspective.

+1 More in Mind

With BluePrinting, you can re-use and apply CMS functionality you've already implemented in another site, template, site section, or page. When developing the following types of functionality, you'll likely get a request for yet another version of the same thing.

• Classify content. If you dynamically display tagged content by classification (Taxonomy), you'll likely need to also display other types of content by tags as well and will want to make the content type (Schema) configurable.
• Translate content. If you allow translation for a given site, new sites may need translation. Even if it's "not in scope," a proper BluePrint design can support the request for translation when it comes.
• Control website functionality from the CMS. If you let content editors present a form or other "widget" (CMS-controlled website functionality), you'll likely need a similar form with different content on a different page. Make the content editable and translatable.
• Create a site. If asked to create a microsite, you'll likely have more requests. Consider sharing web application functionality within the CMS.

Be careful to avoid gold plating in any development process, but within reason consider how content management will evolve and take advantage of the tools..

One More Item or Feature. Not More Types.

Assume +1 more as in "we'll likely apply this functionality again." But avoid cluttering your content model and CMS entry forms with functionality that isn't ready yet. For example, if you need to display an image, assume you'll display more images but don't add video or audio options to your content forms until they're actually ready to be used.

Do this:

• Category for "features" with a single keyword for "mandatory." This lets you add additional options later, but keep the forms specific to today's available options.
• Have a field for images used in the current content model.
• Design a scalable BluePrint and folder structure, starting with the Publications and folders you need.

Not this:

• Add potential fields, Keywords, folders, or other items before they're needed. Or at least only use them in non-Production environments.
• Add a field for video "just in case."
• Add Publications and folders, "just in case"

Accelerate Your Implementation

Years of practical experience and expertise went into the Standard Reference Implementation, most recently released as the Digital Experience Accelerator (DXA). Use it. Learn from it. Know what Tridion is capable of. After seeing familiar patterns in the DXA, read about or even contribute to SDL's other open source initiatives.

DXA modules continue to evolve, but so far include:

• .NET and Java versions
• Modules for:
• ECL
• Media Manager
• SmartTarget
• Search (with both Solr and AWS CloudSearch support)

Quick Wins

You're busy installing, implementing, and developing but save a few moments each sprint or day to go for quick wins. The following take little or no development work:

• User interface integration such as:
• Consolidating related web systems (as links) or custom areas in the Slide Out Navigation 
• Custom Pages, as iframed pages within the CMS
• Custom URLs with links for content field descriptions
• Sites setup (quick links to the sites for each Publication)
• Translation, if already set up (for either Translation Management or just new Publications)
• Sharing CM-side functionality through BluePrinting
• Experience manager visual hints
• Page type example url
• Template icons
• Component Presentation borders
• Even the border colors themselves
• Moving items up or down a BluePrint (only in SDL Web 8 and later)

Development Process

I've made the mistake of asking, "is Experience Manager in scope?" The response varies from, "I'm not sure" to "we're just going to get this done for now."

Whether you're a partner, customer, or colleague in SDL professional services, I'm explicitly telling you, as someone that's worked with Tridion since 2008, was part of SDL Professional Services from 2011 through 2015, and now in Product Management, that "yes, Experience Manager is in scope for all new SDL Web projects."

You want Experience Manager for SmartTarget, for mobile setups, for easy page creation. Don't go for inline editing without first starting with in-context creation. The best parts are the easiest.

In other words, in-context beats inline.

At the minimum, you should include the page button (via the page bootstrap script tag) for Staging sites. Regardless of templating approach, you can and should generate XPM markup for Component Presentations.

Now back to your development process. For any SDL Web-related code or functionality you deliver, you should expect the following:

1. Experience Manager is enabled for this page
2. There's at least one page type
3. There's at least one (possibly custom) content type for each Component Template
4. If you have a demo in your DTAP setup, your code and functionality should work on the demo environments.

*DTAP has long stood for Dev, Test, Acceptance, and Production. With the announcement that SDL Web 8 brings free developer licenses and if you maintain a separate demo setup, you might have DDDTAP. 

Let me end with some observations and warnings.

A demonstration of what you've built should be a demonstration of what you've built.

Good:

• You know you're presenting well in a demo when the audience starts daydreaming about cool new functionality or asking about new features. If aligned with your agile process, an informal review demo should elicit feedback (read about sprint demos here, here, and here).
• You're also doing well when your project manager wants to show the demo to the client, who wants to show it to the boss, who wants to show it to other stakeholders. I call this the Demo Onion because... layers.

Be careful:

• Be careful when you're being compared to the latest new website, the client's competitor, or worse--you're competitor. In the demo, defer to your leads or if you are the lead, address or diffuse any concerns appropriately. After the demo, work with your team and client on how to fix issues and build trust before the next demo.
• But be careful to manage expectations. A demo is not a requirements workshop and don't accept new requirements without validation from the implementation team or project manager.

When a project or program is going well, demos are exciting, well... demonstrations of what you've built. You'll hear, "hey, let me know you something!" rather than, "so, when can we have a demo?"

You Know You Travel A Lot When...

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:

1. 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!"
2. You know which airport seats to sit at by looking for the power cord rather than just power outlets.
3. 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).

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:

The Sixth Tridion Environment

Chris Summers coined the term The Fifth SDL Tridion Environment which is the implementer's sandbox, playground, or simply personal Tridion virtual machine. Getting the license for such an environment has its own challenges.

I want to describe the ultimate, elusive, and harder-than-you-would-assume Sixth SDL Tridion Environment, or the (custom) Training Environment (or simply Train). Often asked for, and seemingly innocent, this environment is harder-to-maintain than production.

Let's highlight typical business, functional, and technical requirements, then navigate the many implementation and project decisions.

Business Requirements

• For training content authors, developers, and partners working with SDL Tridion and/or a specific implementation
• Business users should be able to freely create, edit, delete, and publish content to learn Tridion
• Developers should be able to understand Tridion concepts and see how content manager (CM) and content delivery (CD) work together
• Architects, infrastructure consultants, and server administrators should see how the system works together

Because the people with the expertise to build such an environment have other pressing duties such as client-facing work for consultants or regular maintenance and builds for developers, there's typically a time and resource constraint.

You probably want to train people before going live, so your custom training environment might even need to be ready before Production, without insight from practical experience in a given organization.

Functional requirements

• Whatever needed to support the business requirement!
• I've seen this include the Content Manager Explorer, Experience Manager, a few page/content types, translation, and "Hello World" developer examples
• Ideally the environment has a "reset" option so the next set of trainees get the same environment. 

Technical Requirement and Questions

If the above doesn't make you uneasy, this part should.

In hopefully most Tridion setups, you have some version of the aforementioned DTAP setup, which means Development, Test, Acceptance, and Production.

A training environment, though non-customer facing, is harder than production in many ways.

In production, you typically have mix of in-progress and published content. Items will have history, may be intentionally locked, and will be appropriately localized in certain publications.

In Train, your content must be frozen in time. Though you could aim or a "clean" setup where no items have history or are locked, you might want exercises that look at history, explain check in/out, or see localization. This means we approach Heisenberg uncertainty here, especially with testing. Testing your exercises means your environment no longer matches the start of your exercises.

So before you add "custom training" to your project plan, consider and answer some questions.

Where will you split the Training materials off of your live systems?

• In Production CMS. Do you use production to use the latest and greatest definitions? Or another environment to minimize impact on your live sites? Where will you create your split in the BluePrint if using an existing environment? The higher the level, the easier it may be on trainees, but it may make maintenance more challenging. If you wanted to unpublish or delete something, you will have to account for how it's used in the Training publication.
• In a Separate environment. Will you create a completely separate environment? This of course requires functional, technical, and infrastructure support.
• Separate pages and/or components? This is an "easy" approach with less setup. But you may need separate users and also need to confirm if you're going to share items. For example, you can't simply copy the home page for ten trainees. You need to redo sets of component presentations including separate components.
• Folders? Do each user get their own set of folders or do you add subfolders to the existing tree? Tip: the earlier the branch the easier it is for users--they'd only have to remember their user and location once. Even better if you use permissions to limit access.

Which items? Do you use the actual schemas or copies of your schemas? If making a separate set, should you simplify the content model with less fields or keep it practical and "real world?" Are you using dummy content and pages?

How will you handle changes? Regardless of approach how will you handle changes? Should Train automatically get production changes? Does this mean would every release potentially require updates to the training exercises and are you ready to include this in every build?

Who will create the exercises? Will you need materials such as slides, documents, or videos? Can you automate anything?

After you've created everything, what happens when schemas change? If you change the components? Will you update screen shots? What happens when browsers, IDE, or your site changes? Does an update to IE mean your materials need an update? How about when Visual Studio changes?

Real-world recommendation: custom training should not be the first time one of your authors hears about or uses Tridion. You spend time researching, testing, and measuring your customer-facing applications.

Project Decisions

If the above are easy, then answer these six final project-related questions and you have my full support in making a custom training environment.

1. Who will users be? How will they get access? Who owns the environment? Who will make updates?
2. What is the scope for this environment? What is its relation to production in terms of maintenance and devlopent?
3. Where will you maintain or host this environment? Where will you document the details?
4. When will Train be updated?
5. How will you manage Train? Will you use source control?
6. Why are you doing this?

Final Recommendations

Consider a back up strategy, making your approach modular, and getting professional help.

If you're making something that needs to be tracked, must meet specific requirements, and will need to evolve with the rest of your technology stack, guess what? You probably want the same project approach and a similar source code approach. Consider some type of back up, even if it's just a periodic copy or instance on the cloud.

Ideally, your training modules are well, modular. To make independent exercises you'll need to repeat parts and "pre-bake" steps like celebrity chefs do on cooking shows. Consider making training modules separate, but understand this will increase your development and testing time. For example consider a Hello World setup:

1. Create schemas.
2. Create components based on schemas.
3. Create templates based on schemas (and components).
4. Create pages and use above components and templates.
5. Publish pages.

Five parts, easy, right? If you separated these so trainees could start at any step, then you'd also have:

1. A "backup" schema for 2 and on.
2. Example components based on this backup schema.
3. A working template in case someone's template doesn't work.
4. Example pages based on these separate schemas, components, and templates.
5. Separate folders and structure groups for the above.

You'll also want to be sure the backups don't confuse the regular exercises.

After you've figured all that out, time to get a trainer. Even your most experienced consultants don't know your content model without a tour. I can tell you how SDL Tridion functions, but really won't know what that one field in your component does unless you explain your setup.

There's Hope

Luckily, the groups that I've done custom training with gave me access to the system implementers, a direction and focus for training, and were flexible in evolving the approach together. We typically do well together and I've only had one person accuse me of not being a real trainer. :O)

If you are looking for a guide on your custom training journey, definitely reach out to SDL tridion education.

[shameless plug]You typically don't choose resources with working with any professional services organization, but if I'm on your project, know that I have some five years of explaining Tridion to anyone who'd listen to help and I've been tutoring or teaching in some form since junior high. Helping people learn this system is definitely a highlight of being part of this group.[/shameless plug]

If you're confident in your custom training project, consider some nice touches such as the following (which have been well-received at customers that really considered their staff's needs):

• Office hours to help anyone that needs more time with the system or has specific questions
• Trial runs to see if the format, material, and content fit the intended audience
• Videos and online learning materials to focus on specific scenarios
• Not always possible, but a "clone" option to create sandboxes for approved teams

Cautionary Warning on Sandboxes. You might be tempted to ask your trainer for a copy their environment. I know because I've asked and have been asked. You can always ask, but understand it's not up to the trainer. Have your manager ask your trainer's manager and understand that any Tridion environment has at least weeks worth of development or consulting time along with intellectual property and years of expertise built into it not to mention licenses you may not have access to (the operating system, IDEs, software, etc) and sensitive information. 

But if you find creating a complete custom training environment is a bit more than you expected, by all means create a few sandbox scenarios for your team.

In the end, it's tough getting a perfect run--everything from cloning to connectivity issues can cause technical difficulties--but unlike production your setup just needs to get the point across. It's okay to play with, learn from, and break the monster environment known as Train. It's meant to survive long enough to get you comfortable with the system.

In this sense, Train, the Sixth environment, can be as fun as your The Fifth Environment Unit,  more challenging than Production, but just as useful as any of them.

I'm New to This. Really.

Apparently I've previously shared enough about Tridion that (more than a few) of my current peers thought I was a consultant or with a firm before joining SDL.

Surprise! I didn't have the title of "consultant" until last month. Up until September, I was a 100% honest-to-goodness non-developer (at-the-time), non-partner, project manager that did business analysis and software purchases. And I worked as an employee of a Tridion customer.

If that makes your head spin, in an alternate universe I'm likely a ballroom dancer or martial artist.

I've enjoyed systems-related work that have included a mix of research, business analysis, and agile (or not-so-agile) development. I would have loved to do Tridion-related work on the side, but alas companies that buy this type of software don't have night and evening opportunities!

I was approached by a half-dozen "opportunities" from third-party recruiters--yes, it's a good market), but I had to apply (sorry, no glamorous come-work-for-us-offer) to my current job like anyone else (tip: an international call from California to SDL's HR office in Amsterdam aint cheap!).

So I'm a mix of someone who's...

• new-to-consulting, but familiar with giving advice and teaching
• new to having actual readers (hi Twitter bot and my dozen readers), but comfortable with informal, technical, and academic writing
• the "new guy" that happens to have been around since the R5.3 release