STRI, DXA, Jumpstart, TBD Bootcamp

One of my earliest SDL bootcamps was for SiteEdit User Interface Update for SDL Tridion 2011 Experience Manager. The session was great and the product renames were also quite fun.

This week some of the team had a short two-day internal session covering the Standard Tridion Reference Implementation (STRI), also called the Digital Experience Accelerator (DXA), and possibly soon-to-be-called something-else-yet-to-be-determined. Check the now open SDL Documentation Center for the latest-and-greatest official name.

At a high-level, without giving away trade secrets on this open source project, we had a few familiar names and topics:

• Peter Joles described the Customer Experience Cloud (and gathered the team together, much appreciated!).
• Bart Koopman and Will Price went over STRI.
• Eric Huiza explained SDL Mobile with STRI.
• Angel Puntero and Jan Horsman covered some setups, examples, and code.
• I also presented on a "jumpstart" guide that would help us use the guide.

Unfortunately, I had to catch a flight and missed most of the last presentation from our CXC Web team. I won't add too much to these topics so I won't take away anything else these sharers might share or have already shared (see below). These were internal sessions after all. In this post I will:

• Comment on how TRI is different than past "in-a-box" implementations
• Share some functional tidbits I noted during the workshops along with screens of how I made a diamond BluePrint (exciting I know), and
• Give you 50 ways you might share about STRI.

This Time is Different

For long-time Tridionauts, you might recognize this as the latest incarnation of previous versions of the-One-implementation.

[Insert witty comment about past incarnations of The One Tridion Box Implementation]

Box-Making is Hard

The concept of an example implementation for Tridion or any other system is not new. I even came up with the idea before joining SDL in a class assignment. The challenge with any example is confirming what kind of box you really want.

• Partial or full box? Is it (just) an example that others can learn from? Should it be feature-complete and include every possible example? Or maybe it should be familiar and accessible for those new to the box? Can you tell I'm suggested one approach is better and probably more practical than the other?
• Alice-in-Wonderland, self-documented box? For a document or system that stores content, are the instructions in the system itself like WordPress's Hello World example starter page? To you put "open here" on the box or in the nice little guide that comes with it? Once you have an example, people will ask how to get rid of it. Though you should probably still have the example.
• Box maker or box example? For something as simple as a Word Template, is it the actual Style Set and Word Template, or is it an example Word Document? Does everyone know what a Style Set is?
• Instructions included with the box? Maybe you need both the template as well as a guide on how to use the template? Does such a style guide go in the box? And do you have a style guide on how to build and extend the box?
• Free box? Do you sell the box? Or do you sell services on how to use the box? Or maybe the box is free when you buy the box parts? Do you license the box? To partners? Directly to customers?
• Caveat emptor in-a-box. What's the warranty? What actions invalidate your warranty and need the label "no serviceable parts?" How can users extend the box? What if the box gets wet but customers try to hide the water indicator?
• Partner-friendly box? If your services help people set up their own boxes, is your box an accelerator of sorts? Or maybe you'd call it a toolkit?
• Engineered box. Who makes the box? Would you want Microsoft engineers making the ultimate Word template? Not that they're not qualified or have the skills, but engineers might not use Word in the same way, depth, or pace as typical users use Word.
• Box personas? Who's the typical user? Power User? Word guru? Do you need box personas?

Omni-Box?

The One True Box needs to address all of the above. It needs to be familiar and accessible to new box owners while following "best practices." It can't be everything and you probably want the box out quickly, with the ability to reconfigure the box as fast as people start using the box.

As a customer circa 2008, I might have seen references to Editions and Foundations, but honestly there was so much to learn and implement with Tridion that checking these out was the last thing on my mind. I don't know exactly who was involved, but I'm sure the approaches and code live on in today's customers and now out in the community. Looking back, I'm partial to the names.

WayBack Machine can find all sorts of interesting things. Two Editions of Tridion?

Ah, R5.3. I miss you. Mostly.

More recently, my peers worked on an accelerator package called Spark. Built by professional services, it reflected approaches and examples from several of my colleagues.

As we worked on it, I wondered if we could do two things with Spark:

1. Could we maybe open source some aspect of the implementation? We couldn't at the time, but we started it internally and got a nice setup started rather quickly. I might ask Team Spark to "reinvest" some of that Spark goodness as Tridion Reference Implementation modules.
2. Could we run a contest for the front-end design? Our technical specialties have historically been Content Manager and Web application code related to it (XML, XSLT, C#, Java, etc.). One of the selling points for "enterprise" content management is that the generated output is flexible: historially you can (should) bring your own HTML.

For those wondering (Paceaux), I did get approval for the contest, but we had changes in staff and the Standard Reference Implementation was released.

The challenge for a professional services organization is our main goal is services. So though we have the skills and motivation to make awesome boxes, it almost takes a different type of organization to make a widely adoptable box.

So with different past iterations of the One True Box, what makes the Standard Reference Implementation (4 Tridion) different?

• Good defaults, with the option to change, including a Content Provider (the MVC setup piece that well, provides your content model) that has community parts (DD4T) to two options for Navigation (localizable titles or titles-from-item names). With the freedom to change or build upon parts you don't need, Will Price recommended keeping the original parts for reference. It's like modifying a toy or car, you probably want to keep the original parts or an example, just in case.
• Current roadmap-friendly, practices. This reflects what Tridion will be like in 2015 and beyond. Even back at SDL Innovate 2013, Product and Technical Account management (and a few others) recognized a Web-developer-friendly, current-practices approach is needed. There was even a tech demo with a mutant Tridion cloud setup with no CD API, just a MongoDB backing an MVC application where templating was as easy as Article.Heading.
• Sponsorship shift. You know "Knewknow?" Rather than building STRI, he leveraged his background, reputation, and current title to assemble the right team to build (hopefully) the right project, at the right time. 

  

  Credit to past "box sponsors" but organizational changes can bring a different perspective. 

• The Cloud, I rarely mention the Cloud, but in this case, the cloud has some interesting implications for what you can do with STRI in terms of support and maintenance (see sponsorship).
• Open Source*. STRI feedback and changes come at the speed of the Midas Rule. Like other Tridion open source projects, STRI can evolve as fast as customers and consultants need, rather than based on SDL Tridion releases or Professional Services availability.

*I've been following the community awhile now and I missed Foundations and Edition and we barely shared anything on Spark. The Open Source change is a big deal as I've had customers cite our community as a selling point (and was even stopped while waiting for a taxi at a customer's office). Compare the few 2012 bootcamp posts for Experience Manager with the dozen or so shares at the end of this post including blog posts, code, a screencast, and several announcements and impressions from internals and externals.

In my Tridion Sandbox post, I explored the shortcomings in my proposal, which likely echo any organization whose main charter is not Tridion-in-a-box-making:

Though maybe not in scope for a "Web Design" course, there was no plan for change management and socializing such a project. Something like [my school project] would have needed to be built "for fun" or come with an executive project sponsor. This would have been a better fit as an open source project (four years later in 2014).

I don't have delusions that my ideas for needing an open source example shaped STRI. The point is STRI validates some of my past suspicions and that STRI needed more than just code or a strong example (I would have loved to work with Editions and Foundations or share some of Spark's goodness)--it's the result of organizational changes and a process that's difficult to bring together, especially in a service-based organization like Professional Services.

So I think STRI has all the right things, but you can't guarantee success. As the inventor of the Midas Rule, I've found you can still have a say. :-)

Notes (to Self)

The SDL Tridion Reference Implementation uses a Structure Group-based main navigation approach, but it also has Tridion pages that are added as includes on pages for things like the footer (in Structure Group  _System\include).

Rather than just links in Components, we have Component Presentations, which is a nice fit for today's navigation approaches.

The white label STRI design reflects a familiar-looking footer. In STRI, each list is a Component Presentation, editable in Experience Manager.

Bart mentioned some of the configuration strings in the Page Template metadata could be selected using a picker instead of a string. One other idea I've suggested in implementations are Keywords so that selections are managed, but there are plenty of ways to accomplish the same thing.

There are some pages with an Alice-in-Wonderland naming convention (like the bottles that say "Drink Me"). These are:

• Publish HTML Design
• Publish Settings

Security tip: because the website is cached, there's an admin/refresh "web page" you can visit to refresh the site. Bart explained you probably want to remove access to this page on Production environments. It's currently a setting in global.ascx in STRI 1.0, but Bart is moving it to a configuration in the next version.

Notes on Navigation

The reference implementation includes pre-built navigation elements such as Top, Left, Breadcrumb, Sitemap, Google sitemap. Publish _Navigation. Since the navigation title fields are configurable, when you change schemas be sure to update the Navigation details in 100 Master > Building Blocks > Settings > Core > Site Manager.

For example, if you use a different embedded schema or change headline, you'll want to revisit these settings:

"standardMeta/name"

"headline"

The title, if using the "Localizable" Navigation option will come from the first Component on each page, looking for the fields configured above. 

Fun moment: When the Huizard Googled for one of his posts in his presentation.

Thank Google. Eric's blog is SEO friendly.

Alvin's Exercise: Make a Diamond BluePrint

This was a "trivial" exercise if you've done it before, though the actual Publication settings will appear backwards to how you draw a diamond BluePrint. In my bootcamp presentation I described the basic BluePrinting designs which matched the ones in training, but simplified for a business audience to make it easier for organizations to find a good fit. So by Midas Rule, my exercise was to make one of the BluePrint diagrams. 

You could skip the configuration if you wanted to use a script instead.

I like the context menu. We start a New Publication. The hardest part will be the name.

I've pondered BluePrinting naming conventions before. STRI uses 010 Schemas and Categories for the Publication that stores definitions. Schemas and Categories are explicit Tridion-specific terms rather than concepts. So should a diamond BluePrint for STRI have names like thse?

• 020 Components
• 020 Component Templates and Page Templates

It's philosophical questions like these that make me glad I wasn't part of the STRI build to slow down the process. ;-)

For the sake of time and to respect some familiar conventions, I used Global Content and Global Design.

Though we design a BluePrint top-down, we configure a Publication by adding parents. Here's the final step where we add Global Content and Design as well as remove 010 Schemas and Categories. What would happen if we tried to remove 010 first? ;-) Answer: It's like rock climbing. You can't let go of a Publication until you grab onto another one (plus some other constraints with items in use, but hopefully you get the idea and can remember the metaphor).

By adding Global Content and Design between Schemas and the example website, we get the "classic" Tridion diamond BluePrint. This was the easy part.

I ran out of time at the bootcamp, but the next part is to review the pieces to "split." You could start in the Modules or System folder...

But a more practical approach is to do a Where Used on the pages.

Each page will references content and design elements based on their Component Presentations. Manually (or programmatically) the next step is to make a copy of these elements in the correct Publication and then use the copies in the pages (or copies of the pages).

If you want to leave the originals untouched as recommended, just be sure to rename items otherwise you will have duplicates in certain lists like the Schema or Component Template drop-down selections.

One technical tip: I had a quick moment to add a new Publication Type so non-developers could hide the developer-specific Design publication.

Here's the small change. See Tridion Stack Exchange for what to restart.

    <publicationTypes>

      <add id="1" name="Content" titleResource="lblContentPublicationType" />

      <add id="2" name="Web" titleResource="lblWebPublicationType" />

      <add id="3" name="Email" titleResource="lblOutboundEmailPublicationType" />

      <add id="4" name="Mobile" titleResource="lblMobilePublicationType" />

 <add id="5" name="Design (Developer)" titleResource="" />

    </publicationTypes>

I covered Tridion in-a-box history, how STRI is different, and some shared my notes from the bootcamp, The last part is for you.

Share More

The top three objections to sharing are:

1. I have no time.
2. I have no topic.
3. I'm not ready.

As long is it's "I am not interested," here are some ways past these objections:

1. Save time. Did you take notes? Did you present? Can you copy/paste and/or edit something? Did you ask a question? Did you have an answer?
   
   Note: Your circumstances are probably different, but I wrote most of this on the way home. ;-)
2. Brain storm or note topics as they come up. Or see below.
3. You're never ready. Trust me. I was a little nervous on my first few Tridion-related posts (like this one on a BluePrinting use case that actually helped my interview with SDL). 

Sharing for the first time can be a big deal but it's like any other change. You're never ready for the first day of school, that first date, moving away from home, having a child, or buying something really expensive. But it works out, there are people to support you, and most of the time you're better off just going for it. You'll learn some good lessons and get better at it either way.

So for #2, here's what others have done:

• Posted on TridionWorld (secret: TridionWorld shares STRI's BluePrint)
• Posted the code
• Introduced it
• Described the design
• Posted the design
• Confessed
• Described its product aspects
• Gave tips on troubleshooting installation
• Listed 10 favorite features
• Made a Vimeo screencast
• Made a prezi
• Managed its labels
• Announced it on Tridion Stack Exchange Meta (my small contribution, but it got 8 votes probably for STRI itself and not because of me)
• Thoughts on its version number

Was this enough sharing? No. Because we still needed a bootcamp to explain it.

If you're still not how you might share, consider one of these.

1. What did you learn at the Bootcamp?
2. What did you already know? What did you not know?
3. When did you first hear about STRI?
4. What surprised you?
5. What was missing?
6. How long have you been doing Tridion?
7. How many Tridion-in-a-box implementations have you seen?
8. How does Tridion compare to your last-favorite-CMS?
9. How does STRI compare?
10. Thoughts on its name? What would you call it?
11. Observations on STRI
12. Observations on the team?
13. What did you like about the SDL office ("omg, an SDL frog!")
14. Did you meet anyone new?
15. What did you like about Wakefield?
16. Were you able to find a drink after 11:00?
17. What's a Content Provider?
18. What's Content Delivery?
19. What's DD4T? Why does STRI use it?
20. How can I extend it?
21. How can I help?
22. How did you extend it (see this is a different topic)?
23. What will be easy for customers using STRI?
24. What will be hard?
25. What will projects be like?
26. Tell us the pros and cons of a reference implementation.
27. STRI and the Midas Rule
28. Why doesn't my colleague(s) wear a thicker jacket in freezing weather?
29. Draw a diagram of STRI.
30. Using three boxes.
31. Or just two.
32. One line?
33. Make a demonstration video on something else.
34. Make a podcast.
35. Make an STRI meme.
36. Start a contest...
37. ...Between the SDL offices.
38. ...with the community.
39. Host an STRI hack-a-thon.
40. Show it to a colleague and write about how explaining it helped you
41. Show it to a customer. What was the reaction?
42. Ask a question about it on Tridion Stack Exchange.
43. Ask a functional question about it on Tridion Stack Exchange.
44. Ask a technical question about it on Tridion Stack Exchange.
45. Ask an architectural question about it on Tridion Stack Exchange.
46. Answer the above questions about it on Tridion Stack Exchange.
47. Design or make a Schema for the first time.
48. Try Experience Manager.
49. Describe STRI with ten points.
50. Or come up with 50 ways for others to share about it.

Got thoughts, memories, or recommendations on any of the Tridion-in-a-box setups? Questions or comments about the bootcamp? Care to share what gets you to share? Leave a comment or better yet, make a follow-up post.