Sunday, March 27, 2011

Rants on Tridion implementations

Those of you who know me, and work/worked with me, know that my job is not always an easy or necessarily happy one. In a nutshell, I tend to tell customers that "if you see me walk into your project, it means you're in trouble".

So, if you're about to start implementing Tridion, and you don't want to see me walk into your project to fix it, here's a few things to remember:

Before you try to do XYZ with Tridion, try to do it without Tridion. Seriously, if you don't know what the expected output of a page is, how do you expect to write a template that "does" it?

If you think you know WCM and therefore learning Tridion is a non-issue, think again. Then re-think. And a year later re-evaluate what you know about WCM. If there is one thing I can tell about Tridion and the other WCM packages available, is that Tridion IS different - and customers buy the software for those EXACT reasons that make it different. If you're planning to implement Tridion just like you would [insert random WCM package here], then why don't you go implement [random WCM package] instead? Many times I've heard things like "We're not planning to use BluePrinting", "why can't I just create pages" and "feature XYZ should be out of the box" (this last one is my favourite, since everyone wants XYZ done differently, but out of the box anyway). The higher-up people that made the decision to buy Tridion were likely triggered to do it based on Blueprinting, Component-based content and the extensibility points offered - not because they thought the implementation team likes those concepts.

Stop being a language zealot. So what if you need to understand Java for deployer extensions? And so what if you need to use c# for Event Systems? It's not as if programmers care about that? You should care functionality and complete API, not what language. If language _really_ is an issue for you, then write your own mediator, there's even a sample for that in the documentation.

Make sure you understand that you will always need 2 types of people in your development team: Web designers and programmers. Web designers will not do a good job writing templates, and programmers are typically bad web designers. It is one of the best features of the product that both teams can work together by focusing on different template building blocks. So use it.

Think before you do anything. This should be a no-brainer, right? Some examples...
Everyone wants to implement SmartTarget, but it is OH-SO-RARE that people actually know what they want to do with it. Developers don't get it, they think they could have done everything themselves through code (missing the point that this is exactly what SmartTarget is about).
Audience Segmentation? You need to know the _current_ audience before you start segmenting it.

And I could go on ranting, but enough negativity for today. Here's how I tell people to learn Tridion.
  1. Get yourself a development environment to play with.
  2. Find your way into the Tridion Developer Forum (via Customer Support).
  3. Get yourself enrolled into a Technical Training. Really. It will open your eyes and save you a lot of time.
  4. Read the template implementation guide. I am not kidding, RTFM can do miracles for you.
  5. Now implement a simple, one-page site. Make sure all content is translatable via blueprinting, and editable via SiteEdit.
  6. Once that's working, implement the multiple language versions of that site.
I tend to tell people to start with something really simple (crawling before walking). Like the Google home page, for instance.

OK, enough ranting for the day, happy thoughts and enjoy implementing Tridion. It is an amazing piece of software, and once you get it, you will think differently about WCM systems.


Ron said...

Enjoy your Sunday. :)

Jaime Santos Alcón said...

Great thoughts Nuno, and if this all is not enough there is a good training portfolio that could help too.

IngmarU said...

Amen! I guess thats why we never did a project together, we both tend to get projects to 'save the day' after bad implementations :) I specially like the 'That should be Out Of The Box' or 'that should be default, why didn't they implement that?' :D and every client has a different representation of it :P

Sonja said...

Well said, Nuno! Well said!

Mario said...

Could not have said it better myself.

hbeenker said...

Very recognizable, yet also a bit of "hind sight is 20/20". Going back to your own old implementations you would have done things differently again.

What I find odd is that Tridion allows so many implementations to be done by people who have never had a Tridion course. Who, don't even understand the basics.

Some of the questions on the Forum being asked are so incredible basic, that 75% could be answered with RTFM!

I think a lot of those crappy implementations have undeservedly given Tridion a bad reputation, and turned many customers away from continuation of Tridion. A shame...

Nuno said...

Thanks for the comments guys.

Ah, the benefits of hindsight. Regarding unprepared people doing implementations, it's an unfortunate side-effect of Tridion's success, and (in some cases) under-investment in people's skills from partners, customers and SDL.

Customers decide on who does the implementation, and reality is that price is usually the biggest reason for a partner choice...

Marjolein Mosmans (HintTech) said...

Hi Nuno,

I think you’re right: prize is absolutely an important factor for customers, however if you know that some customers need 2 (!) failed implementations (also with Tridion partners) to get it right it really makes you wonder.
Next to that I feel like the expectations of WHAT Tridion can do are very high at some customers. And they are right; you can do an awful lot with the product, however more important questions are; ‘is this what you really want and need?’ ‘what is the effort to realize it?’ ‘what is technically the best solution to achieve this’

wolf said...

Good post.
Several things from peresonal experience with Tridion 2009 SP1, without getting any trainings:
- horrible interface
- scant documentation especially for TOM.NET
- bad implementation of TOM.NET
- lack of samples how to work with TOM.NET
- shamanic settings for browser (support only IE)
- dancing with a tambourine while moving data to another instance (using Content Porter) for translated content (Category/Keywords)
+ cool idea with BluePrint
+ good implementation with separation content from Presentation on different layers
Most of those problem appear cause Tridion is not tested properly. Tridion have good architectural design, but implementation is so bad. To decrease misunderstandings must be clear documentation with reasonably samples.
Also customers think that Tridion can do everything, it is true in most cases, but it require additional developing.

Nivlong said...

I also vote for training! I've seen programmers wonder how end-users would be able to enter the exact HTML to match the layout of the old page ("no, you don't create the page, you make a component and use a template").

I think we haven't adopted SmartTarget partly because our business isn't consumer-focused. We rely a lot on broker sales and afaik marketing doesn't track online campaigns.

Our existing dynamic navigation and site features have already been "baked in" and there's no motivation to change it. I also suspect for some devs adopting SmartTarget is an even scarier proposition than allowing a CMS in the first place. It might take away too much from the "I could have done better" type devs.

From a business project and operational perspective, if content management, publishing, permissions, etc is not your team's core competency -- get an appropriate 3rd-party tool. Multiple sites, localization, shared content, lots of editors, and an in-house development staff? Tridion's an excellent choice.

Brent said...

Just found your blog, enjoyed reading and plan to follow!

Anand said...

I agree with Nuno, with SDL tridion, every page should be worked with Web designer and programmer too, One more missing component is backend logic, with tridion you can integrate that too. But every page should be given a thought and planned on how it can be optimized for performance. Product has lot of flexiblity, and it should be used in a right way.

Anonymous said...

Get yourself a development environment to play with.

That's a great idea, but how can that be accomplished without a license?

Nuno said...

>>That's a great idea, but how can that be accomplished without a license?

Good question.

As far as I know, here's how you can get a "free" Tridion license:

1. You are a SDL Tridion MVP
2. You work for SDL WCMS
3. You work for a SDL WCMS customer
4. You work for a SDL WCMS Partner

Any of these apply to you?

Unknown said...

I think I disagree with you on a point here: "Web designers will not do a good job writing templates, and programmers are typically bad web designers"

I believe you've missed an intermediate job title, "Web Developer"

You're absolutely right that web designers will not do a good job writing templates, and that they're bad programmers.

HTML and CSS are not programming languages. They're a markup and stylesheet language, respectively. The distinction between a designer and a developer is JavaScript. Not jQuery...JavaScript. Designers use jQuery plugins, developers write jQuery plugins.

In a CMS implementation, a web developer provides a complementary skillset to the programmer. The web developer is capable of templating (Especially in razor) - and can work with MVC frameworks. In addition, the web developer is able to debug browser issues and create solutions that a designer couldn't do. said...

This rant is the best piece of advice/feedback on a Tridion implementation I have seen.