Thick Clients and CMS
If you have worked with any of the systems, you would know that the typical design and implementation lifecycle of these projects has been and remains to be:
- Site Developers write the HTML
- Handover the HTML to the CMS developers
- CMS developers then use the HTML and integrate with backend code (JSPs in AEM)
- Take assistance from Site Developers to fix integration issues mostly JS/CSS
This is nothing new; we have been doing this for years, but as the technologies have progressed I have started to see that the time we now need to take the HTMLs and put them into AEM is increasing significantly compared to when I used to do SpringMVC/Struts based applications. The integrations weren’t issues, but only tasks that the developers would do over the course of story implementation. Some of these did need SMEs to go and fix the finer details but thats about it.
A typical CMS based site is such where we push content out for consumption of our readers, the content could be simple (text, articles, etc.) or rich (images, videos, etc.). However, in the current world the nature of consumer based sites is changing rapidly and they are getting to a point when we need a dynamic element to the content as well. This dynamic element can be in several shapes and forms as in Omni-channel (responsive is one way of doing it), feeds from external systems (social networks or internal feeds on fan engagement sites like NASCAR.com for Live Leaderboard). Barring a few areas where we have to introduce dynamic content, not a lot of content management websites need to be built on principles of a thick client. Good looking old school models of server taking care of presentation tier should work fine and it works very well as well. Those few dynamic areas can be handled very well using the jQuery (AJAX) sort of frameworks that bring together the two worlds and provide a final view to our consumers. So where does the problem lies or why dow e have to change anything if all this works so very well for us?
This is not a technical problem that we have to solve for; as I said that technical integrations are well addressed in these products as they provide their templating languages and ways to integrate with them. If we look at Adobe they had a good way of making this happen (I am not going to talk about the patterns implemented), but their component architecture is actually nice that allow you write templates and what not very effectively. The problem we have on our hands is that of a process as I defined earlier. As we have moved to this product philosophy and as the technology landscape has expanded we have reached a point where I believe we have felt a need to have specializations in our domains. Once where there were no boundaries, now there are BOLD lines drawn as to who is going to be responsible of doing what job in a story implementation. A Site Developer will only work on HTML/JS/CSS (and there can be further divisions based on what skills we need), while a CQ developer will only be responsible writing Java/JSP, Dialogs (and again there are further divisions). While we have strived to achieve specializations in technology domains, we have not progressed on the process side of the things – we still want to do it that exact same way as we were doing it several years ago.
As we move to achieve specialization on technology (which is a different matter); we are creating a big Gap between how the 2 worlds come together. The world of Agency where we have HTML/JS/CSS being coded doesn’t understand what the server side world is and vice versa. The marketing world starts conceptualizing the idea and the code even before the backend technology comes into play and by the time it reached the backend it’s already too late as the agency will do whatever they would find fit. This results in that problem – where we now need a mammoth effort to make the client work in a product like AEM. The developers to begin with have little clue what HTML is and how to fragment this into components that we will have to build as part of CMS; but the bigger problem is that HTML and JS to begin with is not conducive to such development. In cases/projects where we have the knowledge of backend systems available to us, we do little justice to that knowledge as the specialization pushed our site developers not to care about the server side technology. Some take care, but there are hardly anything that comes together as a symphony. As a result – we see increasing efforts to bring the two world together and making the projects more expensive than they ever need to be.
The Solution / The Dilemma
Recently there has been some flirtation around the idea of using thick clients within the mix of a CMS world. The idea of using technologies like Angular, Handlebar, Backbone, etc. to build a client which knows nothing about the backend solution. The content should be then exposed as “services” (CaaS) as XML or JSON feeds that then gets consumed by these clients to show the final presentation to the user. When I started to search about this, I was actually surprised that people have already tried this HippoCMS is one such example (at least 6 months old).
Other things that came up while reading on this topic is http://wisdomofganesh.blogspot.in/2007/10/life-above-service-tier.html where they have explained the challenged as described above and a specification to help solve for it. Without diving into merits and demerits of the solution, the idea we have been flirting around is something very similar – of course the technologies being looked upon are different (I am looking at Angular to fit in this space). What I don’t know if CMS world is really the world to apply this pattern. This pattern will absolutely fix the problem if people are willing to unlearn and learn about this new methodology, but the real challenge I have with is CMS and thick clients and if that technology is really something that should be used.
At this point – I don’t know if that is the answer, but it seems a wrong variable is being used to solve for the problem we have on hand.