17 September 2005

Tridion review and experiences

Those who visit Waterscape.com regularly will have noticed that, this summer, it went through the biggest change in its two-year history. The navigation structure, search facility, mapping, and many other things were overhauled to produce a much friendlier and much more usable site.

Behind this outward-facing change was a decision to switch off Tridion, the content management system we'd used since the site's inception. Today's Waterscape is no longer beholden to it as a content management system, nor to the original implementers-cum-developers-cum-hosts. Everything you now see was developed by three-and-a-half programmers in the Willow Grange office.

We didn't replace Tridion with Microsoft CMS, Vignette, Documentum, or another well-known CMS. Rather, we redeveloped the site from the ground up, based on Apache, PHP, and a few libraries where necessary - QuickForm, Ming, PDFlib. The total cost of software was £300.

CMS vendors proudly tell you how their product will "transform the way you do business". For this, read "you'll have to change the way you work to fit in with our inflexible product".

There are plenty of reasons why an off-the-shelf CMS sounds an appealing prospect, and I've identified four below. But, for us, Tridion didn't cut it in any of these areas. Here's why.

(Brief background and disclaimer: This is based on my 18 months of experience using Tridion as the sole CMS for Waterscape. During that time, I've seen it as a editor (my real job), a programmer (requiring some fairly hairy use of the Tridion object model), and as someone who tried to 'evangelise' take-up of our CMS throughout the organisation. I personally stand by everything written below, but needless to say, it's not an official opinion of Waterscape or its parent company, British Waterways.)

1: Ease of implementation

The first advantage of a CMS should be that it speeds development and implementation. If you're writing your site from scratch, you have to spend a good few weeks building the basics of page interaction and database structure. A CMS could take you a long way along this road.

Tridion Object Model

Let's take links as an example, which are kind of fundamental to the web. The underlying principle of Tridion is the distinction between a component and a page. Components are where the content lives - they're essentially database records implemented in XML (Tridion is big on XML. I'm not, but that's another story). And you all know what a page is.

So we have a River Severn component, which contains most of our static information about the Severn. This is displayed on a River Severn page. In our write-up, we want to link to the Thames & Severn Canal page, because we're explaining that the canal was built to link England's two greatest rivers. How do we do this?

The logical way would be to click the 'link' tool within Tridion's RTF editor, and then use the GUI to select the Thames & Severn page. But the tool doesn't let you select pages, just static URLs or Tridion components.

This means we have to manually hardcode the link by typing the URL. This, to me, kind of defeats the point of a database-driven CMS. If we rename the page URL, the link breaks with no warning. In fact, we can't even use a relative URL like /waterwaysguide/subdir/page.html - because next time we edit the RTF field, Tridion resolves it to the base URL of the CMS (tridion.waterscape.com), not of the site (www.waterscape.com).

So we can't do it for an RTF field. Instead, we need to implement the links in the page logic - either in the Page Template or the Component Template. These are pieces of code which take a set of components attached to a page, and write out the HTML to be displayed on the site.

(Having to do it this way is braindead, because only the Thames and the Severn are "England's two greatest rivers", and I shouldn't have to recode for a unique instance of content. But hey.)

At the very least, the Tridion object model should let me get the URL of the first page containing the component in some way like this:

dim url
url = Component.AssociatedPages(1).PublishPath

(Yeah, it's VBscript.)

Ideally, it should allow me to specify what type of page I want:

url = Component.AssociatedPagesByPageTemplate("Waterways Guide",1).PublishPath

which would return the first Waterways Guide page containing this component.

It doesn't.

What the Tridion object model does let me do is get a big flabby XML list of all pages using this component (including, by default, old versions of pages - a truly moronic default). I can then interrogate each node to get the page ID, and from there, play around with the object model until I can get the URL. This is not just a PITA to implement, it's really, really slow.

This method of linking is one of the reasons why Tridion took an entire weekend to republish Waterscape's 10,000 pages, every time we made a template change. It's also why the River Thames page actually timed out every time we tried to publish it, and why, as a result, we were still showing 2004 events on the Thames page in mid-2005. Fine for glossy brochureware sites with a limited amount of content, but no good for content-rich transactional sites like Waterscape.

(Incidentally, while I'm trying to write this accursed code, I can't use tabs to indent my beautifully-formed VBscript. Not without copying and pasting them from another app, anyway. This is because the GUI code editor interprets TAB in the traditional web sense of "move to the next field". It's things like this that make me wonder whether Tridion ever use their own product for any serious development.)

Pages, Components and the Event System

Let's move on.

Let's say you've got to the stage where the core site is built and now you've got to add the content. To make Tridion at all usable for the end user, you have to rely heavily on a feature called the 'event system'. This enables you to run scripts when the user performs a particular action (e.g. clicking Save).

Without automating frequently-used processes in this way, you have to go through the Tridion Rumba just to publish one paragraph of text:

1. Create component
2. Create page
3. Associate page with component
4. Preview page to check it works
5. Publish page

(For the sake of simplicity, I won't document 1a, 2a, 3a, which generally involve some form of self-immolation due to repeated crashes of the Tridion GUI.)

This takes upwards of five minutes. In other words, it has to be automated, making the event system just as crucial to a successful Tridion implementation as the Page Templates or Component Templates.

But the event system isn't exposed to developers through the GUI. You have to go to the server and manually edit the files, which means that much-vaunted Tridion GUI features like versioning just aren't present. (This was particularly bad news for us, because our contract didn't give us access to the box other than through the GUI.) This smacks of 'hack' to me, not of a professional CMS.

Publishing

Finally, let's assume you've finally got all your content on the site, and you're ready to publish. You can do this for an individual page by right-clicking it in the GUI and selecting 'Publish'. You can publish all the pages within a directory ('structure group' in Tridion parlance) by simply publishing the directory. And it's recursive, so by publishing the 'publication' (the root directory), you can theoretically publish the entire site out.

Er no, you can't.

You can if you've got a brochureware site with three directories and a handful of pages. If you've got 10,000 pages like us, then you've inevitably got some pretty deep paths. Tridion chokes on these.

We've been told this is a limitation of Windows Server, which Tridion runs on, in that it truncates filepaths to a maximum of n characters. Fine. As an editor, I don't care whether it's a limitation of Windows Server, or an HTML issue, or something to do with the phases of the moon. Whenever I make a global template change, I need to be able to republish my site en masse, and I don't think it's unreasonable to expect that of a big-ticket CMS like Tridion.

But as a programmer, I can't quite believe what I'm hearing.

So Windows won't let you specify a long path? So what? Why don't Tridion change their code to traverse the file tree one step at a time, and then publish out each page from there? It works - because our implementers had to write a small app to do exactly that. I managed it, too, in about 10 lines of Perl.

2: Ease of operation for end-users

The second advantage of a CMS should be that users can add content quickly, easily and efficiently.

Tridion's GUI is browser-based. That's not quite accurate. Tridion's GUI is WinIE-based.

Actually, that's not quite accurate either. Tridion's GUI is WinIE 6-based, assuming you have a fast Internet connection, and add the GUI's URL to your 'Trusted Sites'.

This is not helpful.

Large corporations traditionally have conservative IT policies: British Waterways was on IE 5.0 for most of the lifetime of our Tridion implementation, only switching to 6.0 in October 2004. These policies often won't permit any messing with the Internet Options dialogue, quite understandably. In addition, large corporations, particularly in the public sector, often have slow connections. (We didn't, but some of our partners did.)

As for a less compromised browser like Firefox, let alone one on a secure OS such as Mac OS X or any other flavour of Unix... forget it.

(Incidentally, it's reassuring to see that Richard Lemmens, one of Tridion's chief developers, agrees that "of course you don't want the leaky, all-pervasive Ms Internet Explorer". Although 'leaky' is a bit rich coming from the man who developed the embarrassingly crash-prone Content Porter, for which see below.)

All of this makes it difficult to deploy over a wider organisation. But assuming that you can get the GUI to work on your machine, it doesn't get any easier.

First of all, it's just slow. Drawing the elaborate layout, toolbar icons, and downloading the ActiveX controls takes time. When I opened our River Thames component, for example, the editing window took 35 seconds to render (exclusive use of ADSL connection, reasonably fast laptop, IE 6). This is simply unacceptable for any web form.

Secondly, the interface is too complex. There are a mass of toolbar icons, which tend to follow their own logic rather than borrowing established conventions from (say) Word. The designs are too similar, so the 'New Component' icon (crucial for all users) is almost identical to the 'New Component Template' one (useful for developers only).

And it crashes. Frequently. The latest Tridion Service Pack is more stable than earlier releases, but Ctrl-Alt-Del is still the essential Tridion keypress. When previewing a page, you'll often have to click 'Refresh' three times until you get the correctly-rendered page rather than an error message (like the delightful "'null' is null or not an object").

Some more annoyances:

It's too easy to select the window toolbar immediately after a save, so your keypresses go there, not to the form itself.
The logic to detect whether you've made changes is broken (besides, if I click 'Save', I want it saved, all right?).
Components aren't properly saved until you close the component for the first time.
The form layout of component editors is too inflexible.
There's no Publish button in the preview window.
If you launch a preview window from a page window, it won't work after you've closed the page window.

I could go on.

3: Exchanging content

Advantage three of a CMS is that you can readily reuse your content in other contexts. The content you developed for your website can be used in PDFs, Quark files, PowerPoints, DVDs and so on. Conversely, your CMS can bring in content from legacy sources and other systems.

Tridion describes itself as "Global Web Content Management", so it's not too surprising that it doesn't have in-built functions to publish to other media. Their sales spiel made great play of the way that Tridion content can be easily exported to PDF, but as far as I can tell, this is accomplished using a hack that someone once posted to the Tridion discussion forum. Said hack is an interface to someone else's PDF library. I think you could probably claim that GW-BASIC can export content to PDF under the same logic.

Instead, the Tridion logic goes that "it's all XML, so you can easily interchange with other platforms". Let's have a look at how you import content.

Business Connector and Content Porter

The Tridion brochure says that "Existing content can be imported, while existing data structures are converted directly to native XML". (Woo-hoo.) You can do it with the Tridion Business Connector, an interface to basic Tridion functionality that you can access over SOAP. But don't expect to do this in real-time, as and when the web user demands. It's very, very slow - once again, taking several seconds to get or put a single component.

So you need to do a bulk upload and get your content up in advance. Tridion provide a tool for this called Content Porter 2. It's the single least impressive part of the entire product... and that's some achievement.

Content Porter takes an ODBC data source and imports it into Tridion. A "simple-to-use Graphical User Interface" (I'm quoting from the brochure again) lets you map ODBC fields to Tridion component fields.

Except it crashes, too much. It's full of frankly thoughtless design, like the bit that will only let you map one ODBC field to each Tridion field. That probably seemed really clever in the Tridion office, where presumably they've never created a field with multiple-selection checkboxes. It has a completely different UI to the main GUI - this one's a Windows executable, not a web application. And because it ultimately talks to the Business Connector, it's still slow.

Worst of all is its inability to cope with dependencies in any sensible way. Because Waterscape isn't a brochureware site, it has quite a complex content model. Services are associated with waterways, which belong to regions. News items and events can also be associated with waterways. Waterways have subsections. Walking routes touch on the lot of them.

This, in short, means that if you try to export one folder from Tridion using Content Porter, you bring the entire site with it. As Content Porter crashes, without fail, after around 2000 items, this is a serious issue.

Toby Corkindale deserves to be canonified for developing a Perl interface to the Tridion BusinessConnector. It's fairly raw - just gets and puts content - but you can very quickly adapt it to send Publish messages and the like, as per this patched file which at some point I should submit to CPAN.

Anyway, we did a lot of serious work with this, not least sucking down all our content for use in the new, Tridion-free site. Toby's posting announcing its release begins with "For those unfortunate enough to work with Tridion...". Fittingly, I found it when searching Google for "tridion is crap" in a fit of frustration.

It's important for Waterscape to share information with partners who use Tridion, but the poor quality of Tridion's integration software means, paradoxically, there's no advantage in Waterscape using Tridion to do this. We could generate the necessary XML more easily using open-source libraries than we could using Tridion.

Publications

You can run several websites off a single installation of Tridion... which should be good for Waterscape, because web development is a significant part of its business.

In particular, we developed the concept of sites 'powered by Waterscape'. Sites such as the Kennet and Avon Canal Rural Transport Partnership, the Severn Way and Foxton Locks need to share Waterscape data, so that when a new walk or event is added to Waterscape.com, it appears in the right places on the other sites. They also need to share the codebase, because there's no point in rewriting the 'display a walk' template five times.

We couldn't do this.

Each item in Tridion (component, page, template code, whatever) has a URI. These URIs are distinct across publications, so the root directory in the Waterscape publication can easily be distinguished from that in the VisitKandA publication. Tough: one publication still can't access content and code from another. So we had to copy and paste.

Or rather, we would, if Tridion allowed you to paste a component from one publication into another.

To be fair, there is a Tridion feature that supposedly allows you to share content between publications. It's called Blueprinting, and you can read about it here. As early as page three, you'll read this threatening-sounding stuff about companies with a profusion of websites:

"In general, all these websites have one thing in common. They were created in a �stand-alone� and �ad-hoc� fashion. Consequently, they function as (local) information silos, which often fail to comply with corporate messaging and even threaten corporate brand equity." (People who use phrases like that should be taken outside and shot twice, but anyway.) "Overall, these unco-ordinated online initiatives represent a duplication of time and effort and make ineffective use of software, hardware, corporate infrastructure and manpower." Gosh. "This whitepaper explains why the Tridion R5 Enterprise Content Management (ECM) solution with its unique Tridion Blueprint Management functions is the most effective and cost efficient solution on the market for controlling your global website operation."

What it doesn't say is that Tridion-powered sites can be information silos, too. Since our Tridion-powered site wasn't built with Blueprinting aforethought, we'd have to completely reimplement it to take advantage of this great technology. Or, alternatively, we could move to another solution. Guess which we did.

4: Frequently-used functionality

The final advantage of a CMS is that it should provide a technical foundation for the kind of functions needed by every website in the world. Search is the most obvious example. User profile management is another. Secure e-commerce might be a bit further down the list.

Any convincing CMS should come with ready-built classes for all of this. Implementing a basic search function across the whole site (and believe me, the Waterscape search function for the past two years has been very basic) should be the work of an hour or two.

Tridion doesn't do this. There's not much more I can say. Only this: any proprietary solution now has to compete with an entire open-source ecosystem.

Why an extensible open-source platform beats a proprietary CMS

When the Tridion-powered Waterscape launched, all mapping functions (GIS and route-planning) were handled by a separate box running ArcIMS.

This isn't surprising. Although Tridion lists Travel and Transport as one of its four target markets, it doesn't have any dedicated GIS functionality for relating records to real-world objects. To be fair, I don't blame them for that. Non-specialist developers are (irrationally) scared of GIS, and I'd be very pleasantly surprised to find a CMS which overcame this fear. (This one, perhaps.)

All the same, we needed the records created in our CMS to appear on our maps. If we entered details for a new pub or attraction, or update the maximum boat length for the Middle Level, the maps and route-planner needed to reflect this. So we had to run a synchronisation script to interrogate the two and reconcile any new records.

This is a bodge. This is really, really risky for the integrity of your content. This inevitably involves some form of lag, especially given the slowness of the Tridion Business Connector. And, in fact, it never actually happened. The old site never did get icons on its maps. (If you grok the HTML from the old site you'll see that the intention was always there, but the controls were commented out, because they did nothing.)

Now go have a look at the new Waterscape. Every single attraction and pub listed on a webpage also appears on the map. They're both served from the same database - no syncing required. I would like to pretend that this is some dizzying technical achievement on our part, but it's not. Both the HTML webpage and the SWF map are dynamically generated by queries against the same SQL database, on the same server, using the same scripting language.

We can do this because PHP (and Perl, Python etc.) have the Ming extension. Tridion doesn't. You probably don't need Ming, but you may need something else. How about a forum for your users? An secure online shop? Every new open source development for Apache and PHP, Perl or Python is another reason for you not to use a proprietary CMS.

It's back to the brochureware thing again. If you're looking for a 100% templated, corporate site, where every press release appears in the same way as every other, Tridion might be the one for you. You can find a handful of these from Tridion's Customer Case Studies page. But for us, it simply wasn't good enough.

End-note

This is predominantly a technical assessment, so I won't go into the details of Tridion's customer service. That said, I think it's quite telling that, until a few months before we abandoned Tridion, the company only gave its customers read-only access to its discussion forum. (The forum isn't implemented in Tridion, either, but you guessed that.)

And I'm aware that, for many of the failings of the old site, there's an obvious rejoinder. "Well, Tridion is capable of doing this if you do x, y and z. It's not Tridion's fault if your implementers/developers didn't know that."

Sorry, but I think it is. For starters, you can't expect them to know about (say) the intricacies of the Business Connector when there simply isn't any formal documentation for the API. Secondly, if Tridion doesn't make the effort to train one of its biggest developer clients in how best to use the software, that's a pretty poor reflection on their attitude to customer care. And yes, maybe our site should have been Blueprinted from the off. But given that it wasn't (probably for reasons of getting it out the door asap), we should have been able to retrofit at a later date.

In the end, there's only one test that matters: the site. The new Waterscape is light-years ahead of the Tridion-powered one. Find out for yourself.

Comments

I'm glad I found this, we've been asked to pitch to develop a subsite for an organisation who use Tridion. Finding out how to actually use Tridion is nigh on impossible. I think I learnt more reading this post than I have from any other source. Now I'm worried as it'll be me implmenting the work! Thanks

Posted by Walt Buchan on 3.11.05 11:07

So you have bad experiences with Tridion and you were able to build a system yourself which is much better. Congratulations.
At least try to show some dignity by not directing your grievances to people like Richard Lemmens, who is an outstanding developer and consultant.

Posted by Carel on 23.11.05 07:06

I've got no grievance with Richard as a person - I've never met him. But Content Porter 2, for which he was project leader and lead developer (and which he cites on his CV), is a seriously unsatisfactory, crash-prone piece of software; I spent many late nights trying to work around its inadequacies. I would therefore expect him to be able to take the same criticism of his products that he dishes out to others' work.

Posted by Richard Fairhurst on 23.11.05 23:38

I wanted to write a rant here about the cms, but i keep it for myself. I just wanna confirm the story i read above. Think twice before buying.

-- Which strange errormessage do you want to receive today?

Posted by Herman on 15.3.06 02:18

I just stumbled on this text while surfing the web. Full of criticism, some of it on my work too. The author of the text remarks that I should not comment on other people's work if my own work deserves criticism too, which is a fair remark.
However he proceeds on making the same mistake himself, throughout the whole text actually. The writer shows a very limited knowledge of Tridion's capabilities, implements clumsy workarounds and then blames Tridion for the poor performance of those. I'd like to challenge him to post a real life content management task, combined with a proposed solution in Tridion. I'd be happy to follow up with an alternative solution, using standard Tridion tools and methods. Let's compare the results and judge from there.

Posted by Richard Lemmens on 21.4.06 13:54

...but that's exactly what I said in the penultimate and pre-penultimate paragraphs.

To reiterate, no doubt for some of the criticisms I've voiced, "Tridion is capable of doing this if you do x, y and z". But how is a non-Tridion fulltimer is meant to know that? Again, there is no formal documentation for the Business Connector API (or there wasn't at the time when I was using Tridion). And again, if Tridion don't choose to train one of their biggest developer clients (Netdecisions/Agilisys, who originally implemented Waterscape) in how to use the not-exactly-cheap product, you can't expect the company to escape criticism for the poor quality of the result.

FWIW, I didn't say that you "should not comment on other people's work if (your) own work deserves criticism too". What I actually said was that, if you criticise others, you should be prepared to accept criticism too. A subtle but important difference.

Posted by Richard Fairhurst on 25.4.06 23:17

Tridion is the myspace of the CMS world. It baffles me how they are as succesful as they are.

In a past life I used Tridion R4 and R5 on a number of projects and I completely understand your pains. In fact I'd say that without fail, every single one of the projects I worked on with Tridion could have been acomplished quicker, more reliably and less painfully if we'd just written a simple CMS ourselves.

I'd also like to make a point about the cost of the Tridion product - it basically costs whatever your budget is - once they establish what your budget is, they price the product accordingly. I find this particularly un-ethical though I suspect it's not exactly an unusual procedure.

null is null or not an object - I remember that one. LOL

Posted by Marcus on 25.8.07 16:56

i used this CMS daily and agree with some of the writers comments. Some i think can be forgiven - every CMS has its downside. Tridion is like your first child - what do you do when it wakes up at midnight crying? i find the never-ending work aounds annoying, the reformmating and coding in the GUI editor. Publishing can be a pain if you have a lot of pages. And yes, it it is very IE dependent.

Posted by Alex on 20.1.08 22:50

I can upload this pic as an avatar? Size is not big! I think it should work? Some help please?
a href=googlehlp.com/photo.jpg/Me in San Francisco2008/a

Posted by DrartySpall on 20.3.08 19:28

Posted by hairy nude mature woman women on 7.6.08 17:31

Posted by hentai war porn star z on 25.6.08 18:26

Posted by jenny facial amateur perfect on 30.6.08 01:46

You've got some pretty cheap programmers, or they're just extremely fast: building you a whole custom enterprise-grade CMS for just 300 quid?

Posted by Michiel on 30.6.08 10:12

Posted by can a dog you tell if pregnant is how washington on 5.7.08 01:54

Posted by movies movie sex machine on 6.7.08 05:14

Posted by poker-online free on 23.7.08 23:02

Posted by on sore white gum the on 21.8.08 23:27