Wednesday 11 June 2014 1:27:41 pm
Since the early days, eZ Publish has been implementing some key ingredients of what it takes to build efficient content strategies. Talk with UX experts, content strategists and other information architects, they will often tell you about the war between chunks and bytes, about the importance of separating presentation from content, about how valuable it can be to model your content to your own needs and business and about other benefits from very adaptive and flexible content repositories. That is all true.
It's striking how eZ Publish was, since day one, a good fit to implement those concepts and processes. This is not eZ Systems' self-proclaimed statement, it comes from our users. Our community tells us, eZ Publish was certainly one of the very pioneer in that battle - a modern content platform that could be used by content strategists to implement their strategy more efficiently than others. Of course, with time passing, other solutions gained some more flexibility and also followed this path: as of today, it would be a lie to say that eZ Publish is “the only platform” to make these dreams come true.
Now, this by no means tells us we have reached the goal. We have clearly not. There is much more to do, in many directions, to help streamline the way one can turn content into value. The key improvements we look for are:
We believe user is at the center of all things and it is where we want to bring our next generations of the platform. The goal is not anymore to only make sure content strategist can implement the most sophisticated strategy, but much more operational: that business users can execute them in an extremely handy, easy, fast & simple way.
This means things must be simple for them first, and that is probably where we have the most room for improvement. As an example: we - the industry people - have been doing and talking about personalization and targeting of content to users for years. This is not a new topic at all, and was already hot 10 years ago. There are effective solutions for that. What's new is that we realized this must be done in a very manageable & flexible way - yet not achieved - ortherwise it won't work. Till now, it always required a good chunk of development and technical assistance to make it real. It has never been intuitive and always quite disconnected from the content repository. Customers failed most of the time when they tried to implement the concepts, and I am not speaking about eZ Publish implementations, but about all kind of implementations using all kind of technology. It is where we need to change a lot of things.
As we said, one of the main things we want to achieve is to make it possible and simple for CMS users (not developers) to adapt the content being delivered to the users based on the user itself, behaviors, history and context (when consuming the content): where, when, on which channel, with which device. This is also a learning process: we must also provide the CMS users a way to track this and learn what works and what doesn't. This means testing content strategies and tactics. This is what A/B testing and multivariate testing can provide when done in a very intuitive way.
This brings about a lot of business rules of different natures: user-centric, content-centric, channel-centric... and we think this is not something that should be done using a standalone platform on top of the CMS platform or on the side. It has to be a core component of the CMS platform. Having it at the core means that, whether it is about one-to-one personalization, profiling, context-based adaptation of content, testing campaigns, the mechanic and the experience for the delivery of content to the user should be the same - consistent.
In other words, this means editors need a simple way to create variations of content, and those variations should not duplicate content. The editor must be able to "adapt" part of a piece of content to a specific audience, still relying on the default piece of content at the very least for fallback (if not aware of any context). Concretely, given an article "A", the editor should be able to make a variation where, for instance, the title and the main picture changes, but not the body of the article, variation that shall be used when the context matches conditions defined by the editor.
Some would say this is about making the content repository really "object oriented" and there is something about that as there is a concept of inheritance of content.
Implementing this kind of solution is possible now, more than it was 10 years ago, because technology made progress. Because distributed systems and APIs are now a reality that makes it possible to design comprehensive experiences made of assembled services. But at this stage, jumping on the implementation topics right now would be a mistake. We need to fine tune the use-cases and refine the user flow to better understand the solution we want to build.
In the following part of this series of blog posts, I will present how we envision this in a couple of use-cases. It will be about how it could very concretely look like from the CMS user perspective. I will illustrate this with wireframes. The goal is to collect feedback and shape the best UX for that. Please bear in mind this is only prospective UX design work, one of the goals being to collect your feedback and thoughts. We have not engineered the solution yet. Of course, we will have to take into account technical constraints when crafting the real solution, which might create limitations.
Interested? Please comment and share your view on the overall topic below or wait for the next post. Stay tuned and follow this page, 1st example of user-stories to be shared here in a few days!