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.
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.
Extensions to the main Tridion GUI have been supported as far back as Tridion 5.2. First you were allowed to add tabs to the “item type edit windows” and scripts to any window. Limited first steps, but the Communication Statistics add-on made good use of them.
Then in Tridion 5.3 you were given the option to add menu items, toolbar buttons and top-level tree nodes. These extension points were highlighted by the Translation Manager add-on.
In Tridion 2009 additional extension points were added for many other parts of the GUI. Essentially: anything Outbound Email added to the GUI, you could add to the GUI.
Of course in Tridion 2011 the extension points have been much better designed and more publicized. But (as Yoav and Jeremy often proved at the time): extending the Tridion Web GUI in a way that doesn’t invalidate support on your system has been possible since way before Tridion 2011.
Frank – you’re absolutely correct. I blame too much time in the sun and my old age for forgetting the days of pre-2011 extensions. Or maybe it was the fact that they seemed very difficult to create and a super-niche area.
I quickly found a list of the pre-2011 extensions on TridionWorld and Yoav’s great jQuery example in Tridion 2009.
Which leads me to the question – how many people were actually creating extensions in their projects before Tridion 2011? Now when I recall the pre-2011 extensions my feeling is, yes, it is there, but where do I start and what is possible? Where is the documentation and help? Generally it felt like we were allowed to use the GUI extension points R&D did – but were not lucky enough to have any information about how to do it – or community support as we do today when playing with them. At that time it seemed too much of a dark art to dive in and the learning curve too steep.
However, with Tridion 2011 the GUI Extensions are part of the excellent Tridion 2011 Delta Training course – Tridion is embracing and encouraging developers to gain knowledge in this new area of the system. We also see official information in the Tridion documentation about extensions and steps to create one. The documentation was not extensive and the training course provided only one exercise – but this was a huge improvement and publicly showed support from Tridion for this old dark art.
And here is my point for this article – to be completely comfortable in writing extensions (or using other new technologies) requires documentation and support of the community – something we did not see so much pre-2011. Maybe the very active StackOverflow community helpes – but we also had a very active forum prior to StackOverflow. So, this is more of a tribute and thanks for the excellent community involvement that has grown up around GUI extensions – in a large part because we needed it – but also because we all spent extra hours to help others and provide key information to make it all possible. And this is not to take away from the hard work required for proper Schema Design, Blueprint architecture, or developing great templates. 90% of an implementation is all about the basics – but sometimes the last 10% (GUI Extensions, Event System, etc) make such a strong impact they change the implementation from a good one to a great one.
+1! I love the Pareto Principle (80-20 rule) point on the value of the right extensions and completely agree with you. I’m glad I posted things aren’t always an extension and not something like “extensions suck” (whew).
Pre-SDL Tridion 2011 I think we had a kind of Web 1.0 view of extensions (I first used R5.3) — I saw lots of great code examples on TridionWorld, but my colleagues at the time and I were reluctant to “mess” with the CMS itself, especially with technology stacks we weren’t familiar with.
Frank makes a point in your recent TridionTalk podcast (yeah, we didn’t have podcasts back then either!) that customers that create extensions need to be able to support the code they develop. I get the impression that customers were _using_ extensions, but maybe they were mostly created by PS?
More recently StackOverflow hints that internals, externals, small/large partners are working on extensions. It’s definitely changed it’s great to find examples, code, and approaches with a simple online search. I really appreciate your guides and examples–you don’t know how many times I’ve Googled “rcweb” (oops) then “robert curlette tridion” to find something you’ve posted. 🙂