Saturday 19 July 2014 1:47:54 am - 8 replies
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.
Monday 21 July 2014 7:34:24 pm
Wow. What an interesting topic. Some questions before trying to give my POV on the questions you made.
How Content Variations plays with Content Versions? I mean, as far i see, variations are, well, variations of a content version. am i right or do i missing something here?
If so, when creating a new version of the content what will happen with the variations created for the previous one?
Or I missunderstanding something here and variations will be versions?
Or maybe asked with an example. Suppose a multilingual site with let's say two siteaccess. At first, i create the "Is the footbal still on" article in english maybe. I also create the variation for the us audience. What will be the process if i need to create the same article in spanish? Will i need to create new variations for the spanish version too?
Also, i guess the api will take care of it, but wondering how this will play with listing contents, search contents or maybe ezflow based contents.
I mean, if i create a variation for the us audience of the article, will i be able to search for the variation title? and will the blocks having the content reflect the variation if the conditions defined for the variation are met?
Now, about your questions:
1.- One step looks ok to me.
2.- Maybe creating content varition first will be better thinking in a situation with several targets could be met and probably modifiying that conditions after. Maybe could be cool a place where you only want to modify that targets and no need to modify the content variation at all
3.- Maybe i'm gonna be quite pragmatic here, but what about let the users to decide? As you say, two approach are good but also has his pitfalls. Problem here is we don't know how this could be used. Indeed we think in a variation where the body has little changes and that could lead to content duplications, but we can also thuink that the editor has totally change the body of the content for a target and he also need to have that variation indexed by search engines...
Going for a only url won't allow the users to index that variations, right?
So, as the two cases are quite probable, i would go for letting the editors decide with the help of the seo experts. A radio group having "create new url" and "use same url as master and add canonical to it" or something like that could be.
Easy to say and probably not easy to implement though...
Monday 21 July 2014 8:22:56 pm
Thanks Carlos, great feedback!
To your questions in the beginning, I actually see variations as something totally separated from versions. They are closer to two distinct objects tied by a very special link < is a variation of >. We went through that case when dealing with A/B testing.
Still you raise very valid points:
- how should variations behave when there is a new version of the master, how is the master impacted if there is a new version of a variation?
Well I actually think there shall be no specific business rules, may be just an informative message "You are about to edit the master, be aware that there are variations of this article that you might want to review as well" or something like this...
About URL, I understand you vote for distinct urls, with a checkbox allowing to mark the master as the canonical url. I can agree with that, though technically, I think it would more be the "rel='alternate" tag, that really semantically shall mean variation better than the canonical relation.. At least I understand you don't vote for 1 single url for all!
Wednesday 23 July 2014 12:07:51 am
A better use case should be to implement a recommendation block build with pure ajax, so avoiding cache/SEO issues, that would recommend a certain set of articles according to the current user information and following certain rules, those rules could be automated by using machine learning algorithms that would try to maximize the CTR.
Wednesday 23 July 2014 12:16:56 am
Thanks for the comment!
This said, what you mention is "another" use case. I am not sure to see why it would be "better", it is just a different thing that you want to do. Isn'it?
As a side note, it is more or less what eZ Recommendation provides, looking at the visitor's behavior.
Friday 08 August 2014 5:59:00 pm
> 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?
URLs shall not change based the variation. Though if the variation based on clients language a different URL shall be offered for the user.
Friday 08 August 2014 6:16:39 pm
Thanks Bjorn for the reply.
So you don't think alternate or canonical link would be a good way to refer to the main url
How would two different urls hurt?
Lately it seems most of the feedback I got were in favor of multiple urls so I am curious about your motivation.
You must be logged in to post messages in this topic!