Tridion 2011 brought us the ability to change the users experience in the GUI. This is something I wanted (and needed) to do for the last 10 years – but was not allowed to but was not comfortable doing with the lack of documentation and support. The ability to officially modify the Tridion GUI and modify the default experience for users arrived in Tridion 2011 Tridion 5.2 and was continually expanded on until fully embraced in 2011. Before 2011 it was possible, but the official response from Tridion was ‘It’s not supported’ and if a customer called Tridion with a modified GUI Tridion ASP system files and would not receive support.  Needless to say, we never modified the GUI as a general practice as part of an implementation – it felt too unsupported and undocumented.

This changed in Tridion 2011. One of the features added was to write our own ‘GUI Extensions’ and these new extensions were supported – and documented. Not only that, but we had a brand new javascript framework called Anguilla that we have available to use for extending the GUI. Next to the Anguilla framework we also have the ability to add buttons to the GUI, extra columns to the list view and even tabs to the Edit windows of item types. This is revolutionary in the Tridion world, where previously our GUI was locked down by R & D generally not open to edit except for specific extension points, and then not documented as in 2011, and I instantly fell in love with this new concept. After attempting to create my own extensions using existing blog posts and documentation I quickly got stuck – all guides showed how to add the buttons, etc – but what about functionality with Tridion? I found some great code samples on Tridion World – but no explanations. So, I decided to spend some serious quality time and dig into the Anguilla framework and GUI Extension technology. I was very lucky to have the full support of the Tridion Community and before too long I had a working GUI extension and started to make sense of the madness. I did it – and decided to share my newfound love with the world. What followed was a series of blog posts about creating GUI extensions. I tried to fill the gap between what documentation was available and what was possible. I tried to give a code sample and explanation for each type of new extension. I did this with the thought that everyone should be able to write this code, and do it with a good understanding of what it does.

Now Alvin wrote his post and it made me think – is it now understood as a common step in an implementation to modify the GUI? For me writing custom pages and modifying the GUI are always part of an implementation, but a small part with a big impact on daily usability, often saving users hours of time per week. Another way to save users time each week is to have a well-defined Schema, clear folder structure, solid Blueprint, and clear instructions. This is Alvin’s point and I 100% agree – this is the main goal of every implementation – clean, well-defined, and clear. These goals do not require GUI Extensions but they require a clear understanding of the business requirements and an architecture design that enables ease of use in the Tridion system. Indeed, Tridion is an open box and everything is possible- allowing customers and partners to misuse various features or not use them to full effect. An amazing GUI Extension will not compensate for this basic lack of a solid foundation.  GUI Extensions are the whipped cream on top. Not all implementations need it – but when it is there it gives a very nice finish to an already great product.