This site has been archived. To learn more about our current products Ibexa Content, Ibexa Experience, Ibexa Commerce head over to the Ibexa Developer Portal

eZ Community » Blogs » eZ Publish Next UI » Adaptive, Context-aware Content...


Adaptive, Context-aware Content Management #2 - Content Variations at the Object and Field Level.

Saturday 19 July 2014 1:47:51 am

  • Currently 5 out of 5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

In a previous blog post, I started to introduce a concept of an adaptive content repository that would be “context aware”. The purpose is to explore future features of the eZ Platform. In this post, I’ll focus on one way to apply this context to the content repository. We think it could be useful to content marketers and could enable smart content strategy. If you are lazy and don't want to read, jump to the end of the post, there is a slideshow showing the suggested feature.

The Use Case illustrating the Feature

The use case I’ll use is one where Joe, an editor, will want to slightly adapt an existing article for a specific audience. I picked a dummy website, with an article entitled “Is the Football Fever Still on?” after the German victory at the recent FIFA World Cup. Let’s imagine Joe wants to simply adapt this story to make it more appealing and relevant to the North American audience. Typically, he would like to tweak the title into “Did you Feel the Soccer Fever?” for the simple reason that the “football” term doesn’t mean the same on each side of the atlantic. He would also like to adapt the picture and the summary of the article. The rest should remain the same, and the last thing our editor want is to make a duplicate (which means further editing should be done twice…)

Joe is looking for something as follow:

This is of course not a real use case but will illustrate the concepts in a simple way. Of course this is simplified for the sake of this article. Actually one could want to do a targeting based on more complex context that could include also elements such as user profile, behavior, interaction history, time, or many other elements… and different context could be combined.

Take this as a simple example for the sake of discussing the feature.

Suggestion for a User Interface 

Joe, the editor, will simply log in his favorite content management system, the eZ Platform. He will search and find the original article he planned to work on - “Is the Football Fever Still on?” - in the new editorial interface. From here Joe will click in the right toolbar to create a new variation as below - the version that he will use for its north-american readers.

Clicking on “Create a variation”, he will get a very similar screen as the usual edit screens but first, he will be asked to define the user target by specifying a context, combining different elements such as location, segmentation, timing....

He will target users in the “US”, and will add users known as american, whereever they can be when browsing the site. Also, as he is not so sure about his change, he will first test this content variation on a subset (60% of the potential targeted users) in order to A/B test compared to the original content. He will always be able to come back and adjust to 100% once he get the right combination of content variations.

Done with the target, he will then define the variation in content. This will be done with an interface very similar to the normal editorial interface. He will see the main content and will be able to edit fields in order to override them for this specific variation. Right after initialising a new content variation, no content has been edited yet. He will rollover on fields, and will just have to click on the fields he want to adapt. When doing this, a new field will unfold, ready to be edited.

In our case, he will first create a new variation for the “copy” field.

And then a new variation of the Name field which is used as title:

And finally also change the image. After all, why not using their new social media idol?

This way, Joe will end up with those 3 changes. The object edit & view screens of the variation will clearly highlight this with an icon.

Once Joe hits “publish” (potentially through a workflow), then the content variation will be applied whenever the context of the request matches the context defined above: visitors located in the US or visitors identified from anywhere but known as American. In the editorial interface, the variation will be available and visible from the right action bar when browsing the main content, clearly highliting the fields which have been overrided.

Time to pick your brain, a few questions hereafter?

We decided first to bind very closely the content variation with the definition of context.

This could be done in another way: letting the editor create variations, identified by an ID (independently from any definition of the context when to apply it) and creating another interface to define the business rules that would say when should each variation apply:

  • a: create a variation, save it
  • b: define business rules for context and which variation(s) to apply

Question 1: Should we tackle both context and content variation in one U.I. step (like above) or should we disconnect?

Question 1: Should we tackle both context and content variation in one U.I. step (like above) or should we disconnect?

Question 2: If we stick to the approach of combining both the context declaration and the content edition, would it make more sens to first edit the content variation, and then, before publishing, defining the target?

Finally, and this is a very hot topic, from an implementation standpoint, how would you see the concept of variations managed, from a URL perspective?

A way to do it is to keep one single URL and to dynamically alter the rendering when the context match a variation. 

Another way to tackle it is to have two totally different URLs and to have a redirection when processing the request, with the risk to end up with a lot of duplicate content. Here, most probably, it could make sens to do a proper use of the rel=”alternate” tag combined with hreflang,

<link rel="alternate" href="" hreflang="en-us" />

or simply a canonical relation

<link rel="canonical" href="http://<span style="font-size: 0.8em;">"/></span>

This will for sure insure proper and clean SEO and Semantic behaviors, and it is the 3rd topic I'd love feedback on: 

Question 3: what is your preferred option when it comes to the URL topic in this case? single URL, Alternate, Canonical?

As ever, I would love to hear from you on all this. this is a feature we are looking at not immediately but after the 1st GA release of eZ Platform. We are looking at this feature together with the improvements we are bringing to our A/B testing capabilities. We think it could bring a lot of value. Feel free to jump on the slideshare version of the use case:



Proudly Developed with from