Julian Wraith

Menu Close

Tag: wcm

SDL Tridion 2011 Visual highlights

Recently I attended the bootcamp of the 2011 Community Technology Preview, a preview for existing partners and customers of the latest version of SDL’s WCMS, SDL Tridion 2011.

What has changed the most – or rather the most obvious change – is the Content Manager Explorer also known as the Tridion GUI. In 2011, apart from running on all the major browsers and also an iPad, it features a redesign that will be familiar to existing users but also taking on board lots of new usability features.

One of the nicest features of the new interface is the ribbon toolbar. On the current version of Tridion, the buttons on the toolbar are somewhat hard to see and can make it difficult to see what the particular button is supposed to do. The ribbon features a big icon and some text as well which should make finding the function you want easy.

If you don’t like the ribbon you can always collapse the ribbon down to the more traditional row of icons.

Two more features I would like to highlight. Gone are the tabs on the publishing queue and it now shows you all options in the same area. It’s common for me to forget that I have other options on the other tab, so having them all in one place is better for the old folk like myself.

And then lastly I want to show you another nice feature. Error messages in-line to the interface, so now the option to feed more back to the user about what is going on. If you missed a message, you can also get a list back of the message history.

Fall in love with SDL Tridion publishing

I try never to write about SDL Tridion related topics and whilst it is useful to the SDL Tridion Community, I want to write about other things. However, it has been too long since I have written and I had to do something soon…  so here I am again and I decided to look into publishing with SDL Tridion.

What is publishing?

In short, Publishing is the mechanism SDL Tridion uses to put content on a presentation environment. Content and Templates are rendered together and HTML, XML, JSP etc. comes out the other side. When you chose to publish something, you start a chain reaction that sees your content successfully published on your website. During that process SDL Tridion makes sure all your dependencies are taken care of. That single item you chose to publish might lead to a few more items being published so that the website has no errors or inconsistencies in the content.
There are a number of factors that influence how publishing behaves and how you, as a user, can get along with it. The basic factors are:

  • The implementation
  • The content
  • The hardware

So what do we want from publishing?

Mostly you want content there as soon as possible so you can move onto the next task. However, there are allot of other people doing the same thing and on large scale environments or environments with challenges on performance you might have to queue up.

So what can you do?

You need to publish content in a way that ensures the least stress and maximizes the available time for publishing. So I have gathered here some tips that might help you.

Publish Structure Groups

When you publish anything in SDL Tridion, the number of items you select in the Content Management Explorer equals the number of jobs in the publishing queue. Each job in the queue must be completed separately and therefore has all the overhead of being treated as a separate job. However, if you want to publish allot of pages, for example; part of your site, then it makes sense to publish the Structure Group rather than all the individual pages. It will take just as long to get the task done, just with less overhead. If you are worried about failures then use the failure tolerance setting on the Advanced tab of the publishing dialog.

Use priority publishing

Most users have found the priority option in the publishing dialog. It allows you to change the standard priority to change how the publisher will pick up your publishing job. High = it goes first, Low = it goes last. Normal is everything in between. Using Low priority is handy to be able to use the available publishing time of your servers without getting in the way of normal work. So for example, you need to roll out a future site to Staging; then use low priority publishing. It will get there as soon as the publishers have time to deal with it.

Publish on off peak hours

I looked at the number of items published per day for one of my customers recently. It went like this.

  • Wednesday: 16952
  • Thursday: 21829
  • Friday: 13279
  • Saturday: 1
  • Sunday: 14
  • Monday: 1527
  • Tuesday: 2681
  • Wednesday: 357

Notice anything? Many items that could have been published were not because they did not use the weekend. The servers were not turned off; they sat there wasting that publishing time for nothing. So, scheduling a task for the weekend (or even evening) could make better use of the time available.

Publish to staging or live but not to both

Too often I see publishing jobs in a queue that are the same item but going to two different places and those two places are often Staging and Live. The staging site does need to be up to date, but Live is much more important and the process should be that once you are satisfied with your content you publish it to live, so why republish it to staging? If you must publish to staging then make it low priority or maybe schedule a complete republish to Staging in the weekend (see above). To enable low priority publishing all the time you can set the default priority to low on a Publication Target. That way all jobs going to Staging would be low priority and you never need to remember to set it.

Check the details of what you are about to publish

Before you publish, take a look at what will publish and make sure it is what you expect. You can do this using the “See items to Publish” button in the bottom left of the publishing dialog.

Plan your roll outs

When rolling out websites, plan how you are going to do it and leave enough time to get everything done without impacting regular business.

A watched pot never boils

Refreshing the publishing queue frequently might give us the satisfaction that we know that the job was completed as soon as its status is changed to “success”, but in reality it does not make the job go quicker. You might also want to change the filtering options so you only see your own successful tasks.  And do not forget, if it is in the queue, it will get published; it just has to wait its turn.

SDL Tridion MVP award

It has been a while since this really happened but I have been so busy that I have not had time to post anything about it. Since I last wrote, I was awarded an SDL Tridion MVP award for my work for SDL Tridion in and around the community. Next to me there 9 other individuals who also received the award. These 9 together with me were selected by a panel formed from SDL employees, partners and freelancers.

I extend my congratulations to my fellow MVPs and hope for good things in the future…

You can learn more about the MVP awards for SDL Tridion and see the full list of recipients on SDL Tridion World.

Warming up to Content Management in 2010

dilbert_futureYesterday I decided it was about time I worked my way into a new year of WCM and the madness that surrounds it. Towards the end of last year my interest in blogging slowed and I had no inspiration to write anything. This year however, I am full of hope so off I went to see what people are predicting for 2010 and the world of WCM. After a bit of reading I decided to highlight some of the things that interested me.

First up, the mighty CMS Watch in the form of Jarrod Gingras’ post on 2010 Technology Predictions. If anyone can do a prediction it should be these guys, right?

CMS Watch prediction #1 “Multi-lingual requirements will rise to the fore”
Good news for SDL Tridion and anyone else the handles Multi-lingual well! “Many firms are now recognizing the need to localize applications and content across cultural and geographic boundaries“, hmmm weren’t firms supposed to have done this in already? But I agree, if they did not do this in 2009 they should do this in 2010. In fact they should have done this in 2008 but lets not split hairs. Factors such as economic crisis as well as growing competition from abroad will all factor and influence this. What is more, these organizations need to invest more heavily in efficient translation.

CMS Watch prediction #2 “Cloud alternatives will become pervasive”
Any talk of the cloud and I think of Jon Marks as in this I agree. And I think the CMS vendors should better read this too before declaring cloud capability. For most large organizations I deal with, this is not an option and I am certainly not a believer in the cloud for my customers. It is nice to think of everything being in a cloud but in reality it is not actually cloud based, it just is not in your network; the two things are not the same.

Next CMS Outlook and Matthew Johnson’s article.

CMS Outlook prediction #1 “Cloud Options”
There is the “c” word again! Both CMS Outlook and CMS Watch both cite economic downturn as the reason for using the cloud as a way of saving costs. If this is going to be the case only CMS Watch gets it right saying that vendors will invest in this area, but only towards the end of the year will customers and implementers actually take up the option of implementing it.

CMS Outlook prediction #2 “WCM + Analytics + Targeting + Testing”
I am looking forward to real advances in this. The technology is there to be integrated but the customers are not up to speed to the fact that they can actually do this, it is our job to teach them. Hopefully, 2010 will indeed see a massive increase in powerful targeting of content.

Next, the personal blog of John Newton.

John Newton prediction #1 “ECM in the developing world”
For some US vendors I feel that the developing world also includes Europe. There are literally tonnes of CMS vendors we have never heard of that operate in the developing world (and the developed for that matter). As their clients outgrow them we will see a move towards larger European and US vendors with their highly developed Content Management applications.

John Newton prediction #2 “CMIS”
I guess I have been talking about this longer and louder than anyone else out there, so you wouldn’t be surprised to see me say I think CMIS will have a significant impact in 2010.” With CMIS coming of age in Spring 2010 it will now be chance for CMS vendors to get their hands dirty and start releasing implementations with CMIS capabilities. How well this will be adopted by vendors remains to be seen, there are often long development cycles to go through before something is in a product. However, there will be allot of widget, plug-ins and extensions to satisfy the RFPs in the meantime.

And finally the personal blog of Stephane Croisier.

Stephane Croisier predicition #1 Standardized CM infrastructure, Content Composites Applications and Content Solutions are the three layers of next generation of CMS”
I like the sound of this but I got confused. As a specialist in infrastructure I am all for standardization of the infrastructure and anything that can be done in 2010 will be great. Standards, even as simple as inbuilt SNMP monitoring or standardized logging, can help massively when implementing large scale implementations. Sadly the infrastructure is often neglected both by vendors and by customers.

Stephane Croisier predicition #2 “The Semantic Web is NOT for 2010 but Semantic Lifting will become hot”
Both CMS Watch and Stephane picked up on this one. We know what we want but not we need a way to find it, show me the internet *I* want to see!

Do you have a nice Content Management 2010 prediction? I would love to hear it…

Getting the Infrastructure ROI

roi1There has been much written on CMS vendor websites by marketing gurus on how to get the best Return On Investment, or ROI, on Content Management Software. There are also a number of good articles that give good coverage on the various aspects of your investment that you should consider. From my mostly infrastructure viewpoint I see allot of areas where the ROI impact is diminished because certain aspects are not considered fully when selecting the CMS or supporting software. Most papers on your ROI mention things like maintenance and hardware costs, but there are a number of other areas where you can look to make sure that you are not overlooking a drain on your ROI.

Hardware and Software

Hardware is often mentioned, it makes sense that the more servers you need to use the more the total hardware costs and their future maintenance will be. Also to be considered is the complexity of the implementation through having more servers in it and the impact on how you manage that. Consider what it will take to make your application perform within your requirements and more importantly to what hardware you really require with regard to your organizations Service Level Agreements.

When it comes to software, most Content Management Systems require some 3rd party software. Each item of 3rd party software that is required has a cost associated with it, Oracle or SQL Server? Windows or Linux? Each one has a cost not only in the purchase of a license, but also in configuration and maintenance. For instance, in my experience, Oracle is much harder to get performing correctly than say SQL Server. Having worked for Oracle in the past, I know an Oracle database can perform well within what you need for a CMS, but you will need the DBA to set it up for you and DBAs are expensive.

After such obvious 3rd party software as the operating system there are other things like file replication software, small custom solutions, scripts, utilities etc. Each one will effect the money you need to spend on the solution. Your IT team is often used to finding technical solutions to a problem without thinking about the ROI of what they are doing. Does the solution they need to solve the problem prove to be complex, costly to maintain and unreliable or can the CMS do it for you?

Installation & Upgrades

Specialist software often requires specialists to install the software for you, but some specialist software does not require specialists to do it all or even anything at all. Costs of installation and upgrades are in people and time. Who needs to complete it, what do they cost and how much time will they take. Consider the amount of people available in the market to undertake the upgrade or install tasks and the quality that they can deliver. I would rather have a consultant take two days to do a job that another can do in one day, but actually do a really quality install. Make a trade off in the resources you will need to get the job done and to the level you require.


Two points on this; complexity and re-usability… Too often configuration of complex applications is in itself complex, but that does not have to be so. Be sure that configuration is as straight-forward as it can be, it will lower costs of maintaining servers and increase good things like uptime (people will make fewer mistakes). Re-usability is key to deploying large applications; lack of re-usability in configuration (e.g. hard-coded paths) will mean an increase in configuration mistakes between servers and an overall higher cost of maintaining large sets of differing configuration.


I mentioned about the extra cost of having complex configuration, but the complexity of the implementation will affect more cost. All the 3rd party software you needed for your implementation has to be maintained, all the connections between servers, all the interfaces etc. We can reduce the cost of all these through effective IT procedures and you should look if the CMS software that provides solutions for helping with those procedures. Monitoring through SNMP is one way a CMS application can help you maintain it, using standard technologies that integrate well with existing tools an IT team might already have is another.

One aspect to consider is who will maintain your application? Do you need a specialist or more than one? Do they have the time to maintain the application? Keeping it alive is one thing, making it work for you is another. To get a specialist, do they need training and who do they get that training from? And the training should not just include the CMS but also all the 3rd party software you needed too as well as training on the implementation you built; it will be different to all other implementations out there because it is the one that suits you.



Nearly all vendors offer Support contracts to help you with problems with the software. In any typical implementation there will be parts that you have built yourself. These might be as simple as a template but could be as complex as a custom CRM integration. Typically neither of these two things fall under what a vendor support team would support. They support that you can write templates and the API that you interact with but they probably won’t support you getting your template to work how you wanted (unless they are really nice). Product versus Implementation is important to consider. If you needed to make a custom part of the implementation you need to be able to support that yourself or via the implementation partner who created it for you. If you never had to make that custom part of the implementation because it already existed in your CMS product, it will be supported by the vendor support team.

And so what if you had to create a CRM integration? You should be able to feed that back to the vendor so that they can include it in the product. How close are you to the enhancement request process?

Agile Development with SDL Tridion

Last week I attended a seminar organized by Hinttech on Agile Tridion Development. The seminar and its participants discussed the use of Agile development methods when creating sites with SDL Tridion. Agile development is something more and more customers are asking for but then how does that fit into a Tridion project? Laurens Bonnema was on hand to give his view on Agile development and how it should and should not be used. Robert Quaedvlieg from SDL Tridion was also on hand to give a view on where Agile might fit into the SDL Tridion Implementation Methodology. The Implementation Methodology is essentially a SDL Tridion variant on the traditional Waterfall model. This is the traditional project methodology and lends itself very well to projects where we need to (or do) know what we are going to build up front. Agile tends towards situations where we do not know the requirements at the start. My aim here is not to explain Agile development – you need to read one of the many good books or even Wikipedia to get a good short explanation – However, I will lay down some very basic concepts so that the rest of this document is clear. Typically, you do not know the complete requirements up front and part of the Agile process is to define the requirements or backlog. These backlog items are organized into sprints and at the end of each sprint the development team has a working product (with the features worked on for that sprint). In theory that means you have something deliverable at the end of each sprint and, in my view more importantly, you are fully away of the progress you are making. There is more to it than that but the important factor is that the priority of development can be changed at anytime without having to go back and change a monolithic requirements document. At the end, you should have a product that is what you want at the time you want it. Rather than a product which you wanted when you made the requirements.

So how does a Tridion project fit into this?

Looking at any regular Tridion project, there are a number of things that look to fit well into an Agile process and others which do not. Some of the things that do not, I do not think every really could fit well into Agile development, probably because there is nothing to develop, more something to be worked upon. However, even those things can be injected with Agile juice to make them flow easily next to the sprints.

Ignoring the Tridion Implementation Methodology, I will outline some of the various parts of a Tridion project and whether or not I think you should approach them in an Agile (A), Semi-Agile (S) or Waterfall (W) way.

Organisational aspects of a Tridion implementation are key to ensuring a successful project in the long term. Like any organizational structure it should focus on the long term and will be the foundation on which this and future projects are built.

What How Why
BluePrint Design S The BluePrint is the corner stone of any Tridion Implementation and is key when you move forward past the end of your project. As such it needs to be fully understood before it is laid down. That said, you can change it to some degree as you go forward, so once the initial design is set you can add to it providing you are prepared to accept the impact from doing so.
Security Design S Security is who has access to what and what they can do with it. It can be decided in the basic form up front, but after that it should be flexible to be changed and grown upon.
Business Processes and Organization W This is a question of understanding the business and how it operates (or wants to operate).
Support and Maintenance W Defining the support and maintenance processes tie into the Business Processes quite tightly.

Content Management
There are two parts to any CMS implementation, the creation of a Content Management environment and then the application to consume the content. In creating our Content Management environment we decide how we are going to manage content both functionally and structurally.

What How Why
Schema Development A Will change frequently during the development cycle
Template Development A Will change frequently during the development cycle
Folder/ Structure Group Setup A This supports the template and schema development
Application Development A Building Blocks are what makes the application. These will change frequently during the development cycle
Event System Development A Will change frequently during the development cycle
Workflow Development A We already will have decided something about our business processes in a waterfall model. Workflow will change frequently as we add more and more content types
Migration of other systems S Often a risk area, migration can be treated semi agile with ease. We know some requirements from the start, however, knowing all requirements can be very complex.

Content Consumption
Consuming the content is a very general topic; it can take any form from a simple .NET application to a MVC framework or webservice. The consuming application’s job is to take deployed content and present it to the user or another application. It is very much a technical coding exercise

What How Why
Deployment Extensions A Deployment Extensions, for example, a Google search integration, can easily be part of a sprint
Consuming Applications A Often the bulk of a development activity is here and this can easily be done in an Agile way

Infrastructural & Integrations
These sorts of activities tend to involve a large amount of people and a very rigid process model. It makes agile work in this area very difficult and you would generally meet stiff opposition.

What How Why
Infrastructure Design W Needs to take into account strict processes and design parameters. Often hardware cannot be purchased until a full design is in place.
Installation W This is an activity that can sometimes be done in sprints (e.g. hardware, OS, CMS, Modules etc), but that is more from practicalities than being designed to look like sprints
Configuration S Configuration of servers should be timed to be worked on post sprint. Configuration and setup adjustments from the sprint can be implemented directly so that the resulting product from a sprint can be put into production. To do this for every sprint would mean that the hardware & software installation should have been completed before the first sprint.
Integration Development A Most integrations are development activities and therefore can easily organized into sprints.

Additional Thoughts
Many standard engineering practices should be implemented that will help you in being agile. These practices stem from traditional development practices but are often overlooked. What is important in each sprint is that all the work you have done has broken nothing from any previous sprint, so structured testing can help you achieve this. Unit and UAT testing can both aid the development process and ensure a quality product. UAT testing can also ensure that the content management environment will work well for the content editors. Getting the editors in and letting them have a play early on might just ensure that they accept the application when the last sprint is complete.

Overall you need to use common sense (in this I very much agree with Laurens). Agile is not the way to solve all evils. Not only are some things just not possible to do Agile but some people cannot (yet) do agile.

When Should you Not Use a WCM System?

I recently picked up a copy of a book on Web Content Management with a certain “leading” brand of WCM software. Now, I shall skip who the book was by and even which software it is talking about, but I was happily flicking through and I came across the section “When should you not use a WCM system?.” Now, I was already a little shocked by this title, but then on second thoughts I would not use a WCM system to make a cup of tea or direct a light opera. But, in the context of a business website – and especially when written in a book about a WCM system – I just did not get why you would not use a WCM system.

After closer inspection of the reasons when not to use a WCM system, I found the reasons were:

  1. When most of the data on the website is fairly static and less prone to updates
  2. You have neither the time nor the money for training of the employees
  3. There is not much content to be displayed on the site

Now I *am* really shocked. Now in the section of “When you should use a WCM” it just describes the one reason why you should use a WCM system; “when you update content allot”.

From this point on I flicked back to the front of the book to see when it was published, I was thinking maybe 2000 or 1995 but no, 2006. Did we really think this way in 2006? It can’t be.

So, what are reasons to use a WCM system? And when not? I cannot think of any reason why you would not want to use a WCM of _some sort_. Maybe you do not want a massive WCM implementation when WordPress would do, a small WCM system maybe but WordPress still is a WCM System. A small scale WCM system won’t need massive training not like the larger players, will it?

OK, so when should you use a WCM system?  Here are some of my reasons that may be applied to one or more size of WCM system as I am not going to categorise them:

  1. When you have frequent updates to your website (OK, I was handed this one)
  2. When you want to use a single source of content for multiple channels (brand consistency)
  3. When you want to localise the same single source of content for multiple country websites (translation)
  4. When you want to manage content from a single location (maintainability)
  5. When you don’t want (your editors) to have to learn HTML
  6. When you want to seperate content from layout

Of course my list is not complete and leans towards large WCM implementations – it is my stomping ground afterall. So, I ask, are there more reasons why you would use a WCM system? Anyone?

© 2020 Julian Wraith. All rights reserved.

Theme by Anders Norén.