Released last week – the first step on a path to lower the barriers (time, cost, knowledge, lack of standardization) of implementing SDL Tridion. In this post I aim to give a short introduction, by highlighting what you should and should not expect from the Reference Implementation.

What is it, and how is that useful for me?

The SDL Tridion Reference Implementation, is exactly what it says on the tin – its an install-able implementation of the SDL Tridion CMS, which you can use as a learning tool to get to know the software, but also as a basis to jump-start development of new sites.

What NOT to expect

Tridion being Tridion, there are of course many ways to bake the cakes, so lets manage expectations and start with what not to expect from the Reference Implementation:

‘Classic’ CMS templates

The example site uses ASP.NET MVC, which means that rendering happens in the web application. There are of course templates in the CMS, and these are used in the normal way – to allow Editors to change the layout of content, however these templates simply spit out XML (we are using DD4T for this) and the HTML code and display logic is in Views in the web app. If you are looking at CM-side rendering, or Dreamweaver TBB examples, you should look elsewhere.

Integration with all SDL Products and modules

The aim of the first release was to get something out there as soon as possible, to allow people to start learning, and get feedback from the community. As such we limited the scope to the core CMS, which includes Experience Manager and SDL Mobile, but does not include Media Manager, Smart Target, Audience Manager, Outbound Email or other such separately licensed add-ons. This is coming, but be patient. Rome was not built in a day.

A one-size fits all blueprint and set of universal schemas

Guess what, if there was a single blueprint which worked for everyone, or a set of universal schemas for all customer content, you would have heard of it by now. Don’t expect anything else from the Reference Implementation. It is deliberately simple to aid understanding. That said, there are some useful content types to get things started and the blueprint can be altered to cater for different scenarios.

Documentation on advanced development scenarios

The docs contain some good stuff on getting started developing new Views, however there is still a bit of a technical knowledge gap if you want to go crazy and build some real CMS-driven MVC application functionality. In the coming months the team will be posting some stuff in the blogosphere, to address some real life implementation development scenarios.

Perfection

Its release 1.0, what do you expect? However, if there is something that doesn’t work the way you want it, or just doesn’t work, don’t sit there cursing the idiot developers who knocked this up in less than four months on a diet of roti-rolls and diet coke – give us some feedback. Tridion Stack Exchange is probably the best way to do this, although if you know how to find us, you can always contact Bart and myself directly. Plus all the source code is available, in the download, and/or on github

So what should you expect?

OK – lets get positive, what can I look forward to getting my hands on then?

A good way to learn Tridion

You are new to Tridion, you install it, or more likely someone installs it for you, and then what? Nothing… Emptiness, not a single publication to grab hold of. Gingerly you create you first publication… but where do you put the pages? Oh… you need a root structure group. A couple of days later you might have published a Hello World page.

When you install the Reference Implementation you have publications, with schemas, templates, pages and content, which you can publish to view a real website, which you can then edit with Experience Manager. Nothing is easier than learning by example, and this is what the Reference Implementation gives you – an example

A Customizable, Responsive HTML5 Web Design

The example site is responsive – its designed to ‘work’ and look good on devices with display widths of 320 pixels and up. Design assets (CSS, JS etc) can be published from the CMS, or separately deployed to your web application, whichever you prefer. When publishing from the CMS, non-technical users can customize some basic fonts and colours in a structured component, or web developers can add some lines of CSS/LESS code to a configuration component. Finally, if you are into using Bootstrap, LESS, Grunt and Bower – go crazy and build your own set of design assets. If these words mean nothing to you, you could do a lot worse than dig a little into the example we provide to help you learn more. Want to have a peek at what the design looks like without downloading or installing anything? Look here.

The stuff you always need

• Dynamically generated navigation elements? CHECK
• Separately managed header/footer and other ‘includes’? CHECK
• Publishable and localizable configuration and resources? CHECK
• Multi-language support? CHECK
• Configurable Social site and sharing links (including Open Graph metadata)? CHECK
• Integrations with Google Maps, Google Analytics and YouTube? CHECK
• …And more – check the list of features.

And some really cool stuff

To keep things interesting for those already in the know, we did throw in a few pretty cool things too. You can expect some more explanation on these subjects to come, but here’s a teaser:

• Dynamic Image re-sizing. You want images re-sized for two reasons: Firstly you need to crop, so you can use the same image in your banners (wide and short), thumbnails (square), teasers (smaller) and gallery (normal). Secondly you want to serve a image whose size makes sense on the device they are using (smartphone/tablet/computer/TV, high-res(“retina”) display or not). Editors upload a single high-res image and link it into the appropriate content, the Reference Implementation takes care of the rest. Read more here.
• Automagic Model Mapping. If you look at one of the example views, you could be forgiven for wondering where Tridion fits in to all of this. There is no mention of Component Presentations or fields, just a strongly typed view model which may, or may not bare a resemblance to the underlying content schema. We use semantic attributes to allow you to wire up your schemas to the view models, so there is no need for custom mapping code and view developers don’t really need to understand anything about the underlying content model, or indeed Tridion in general. There is some explanation in the docs, but expect more on this subject.
• Support for the Semantic web.. That sounds grand doesn’t it? Its quite simple: using the same semantic attributes on your view models, you can ensure that the HTML output contains schema.org semantic markup. This means that machines have a deeper understanding of your content. If you don’t get why this is important – Google it ;o). We piggy back on this mechanism to inject XPM markup on the staging site (which in the end, is just another kind of semantic markup) which means that our view code is gloriously free of any XPM gobbledygook.

So what are you waiting for?

Get stuck in, set it up! You will need Tridion 2013 SP1 -thats the official platform (although an advanced user with a bit of Content Porter knowledge could shoehorn it in GA or even 2011). If you missed the links above, here they are again:

• Download it on SDL Tridion World
• Get the sourcecode on Github (note: Some source code, like the raw HTML design is in the download)
• Follow the documentation
• Browse the Web site design