[GSoC2012] How to personalize content

75 views
Skip to first unread message

Yuki Awano

unread,
May 14, 2012, 12:53:34 AM5/14/12
to silverst...@googlegroups.com
Hi,

I'm Yuki. We are currently designing content personalization module.
In how to personalize contents, we've identified the following approaches and seek input what people would expect / think is useful to them.

1. Template Engine
Personalize contents with template engine. Just like

<% if AudienceType('NewYoker') %>
<!-- Content for NewYoker -->
<% elseif AudienceType('NewComer') %>
<!-- Content for NewComer -->
<% else %>
<!-- Content for OtherUsers -->
<% end %>

Pros: This can provide many kinds of personalizations.
Cons: Hard to use and maintain. If you want to change contents which are personalized, you need to edit the template for that.

2. Widgets / ShortCode
Provide widgets for certain personalization, such as banner rotator.
In banner rotator widget, user can add images with specifing which
image will be shown to certain audience type.

Pros: Easy to use and maintain.
Cons: Area which can be personalized is limited.

3. Full SiteTree / DataObject
We add an column to annotate data object for personalization. This means that having distinct database rows per customization.

For example:
SiteTree Table [Size = 3]
Row1: AudienceTypeA and AudienceTypeB
Row2: AudienceTypeB
Row3: Everyone

SiteTree for AudienceTypeA
Row1, Row3
SiteTree for AudienceTypeB
Row1, Row2, Row3

Pros: Be able to customize overall site
Cons: Hard to maintain, and also hard to implement

Finally, I will introduce some use cases that we assume and my opinion. I thinks there will be some needs for personalizing navigations and banners for visitors. Especially in commercial sites, they would like to personalize banners of sales or products. And in some sites, for example, silverstripe, there are many kind of visitors, such as developers, web administrators, new comers, and so on. And personalizing navigation for each kind of users would be useful. IMHO, I think template engine would be good choice for such personalization. However, this is just my opinion. We are really welcome to any input.

If you needed, you can check overview of this module from the link below.

*Design

And please feel free to ask any question.
Thanks in advance.

Regards,
Yuki

wolfv

unread,
May 14, 2012, 12:29:25 PM5/14/12
to silverst...@googlegroups.com
What would be the drawbacks of a globally accessible object like SiteConfig? 

You could use it in the Template like <% if PersonalizationModule.Type == Newcomer %>
And in some function: public function getContent() { if(PersonalizationModule.Type == "NewVisitor") { return "Hi, great to see you!" }
One could also spice up the DataObject with needed content-variations depending on the type of user and use the getContent or similar function to determine which user is there and which Data to return ...

You then could use the same object in widgets as well.

I'd think that would be much more flexible ...

Have a great day!

Nicolaas Thiemen Francken - Sunny Side Up

unread,
May 14, 2012, 8:09:16 PM5/14/12
to silverst...@googlegroups.com
Hi Yuki

Cool ideas and easy to understand.

You may want to look at the translatable and the subsite functionality / modules.  Both of these basically implement option 3.

Translatable allows you to translate any row in a dataobject (by default the SiteTree is "translatable"). Translatable also taps into the hard-coded translatable text ( _t function)

The subsite module is basically the same thing, but rather than languages, data is separated by site (e.g. club 1, club 2, club 3). Depending on how you enter the site - e.g. www.myclub.com or www.yourclub.com you see different data... Some data can also be shared among clubs. Here you can even have different members (users) per site - something that would not be useful for the language module. 

In an ideal world we should look at merging these two system into one "relevant data selector" with three implementations:

1. languages
2. sub sites
3. personal data

This "relevant data selector" would alter SQL statements to ensure the selection of only one language or one subsite's content. After that the individual modules would use it in the best way. 

Also, I would recommend that the template language is as simple as possible, that is moving the logic out of the template. 

My notes are probably going to confuse you more than help you (press CTRL + z in that case)  ... sorry.... :-)   I hope it is of some help.

Nicolaas


xeraa

unread,
May 14, 2012, 8:28:39 PM5/14/12
to silverst...@googlegroups.com
What would be the drawbacks of a globally accessible object like SiteConfig? 

You mean for defining customizations?
Interesting idea, thanks for bringing that up. Actually, the plan is to use a YAML configuration for that - basically the same thing SS3 uses for its configuration.
 
You could use it in the Template like <% if PersonalizationModule.Type == Newcomer %>
And in some function: public function getContent() { if(PersonalizationModule.Type == "NewVisitor") { return "Hi, great to see you!" }
One could also spice up the DataObject with needed content-variations depending on the type of user and use the getContent or similar function to determine which user is there and which Data to return ...
 
That should be possible with the YAML approach as well. The idea to limit the customizations to the template (I assume you're referring to the first option) was just done for keeping it simple. You could then add this kind of hard-coded customizations pretty easily to the Controller as well.
 
You then could use the same object in widgets as well.

The general configuration would be the same in all three approaches - only the scope on how / where to use it would differ. So we could implement all three, but not within one single GSoC project. Therefore, we're planning to go for the most desired one - hence the question :-).

Cheers,
Philipp

xeraa

unread,
May 14, 2012, 8:40:01 PM5/14/12
to silverst...@googlegroups.com, n...@sunnysideup.co.nz
Hi Nicolaas,
 
You may want to look at the translatable and the subsite functionality / modules.  Both of these basically implement option 3.

Actually, the translatable module is where we got the idea from ;-). IMHO the customization is a superset of translations, that is: Translations are one possible customization.
What I like about that idea is that we could reuse quite a lot. We'd have to add customizable categories and add a default behavior (probably 90% of the content would be for every visitor and only 10% would be customized - or so I'd imagine). The major downside is that this is the "heaviest" and most complex approach - both in terms of developing it, customizing your own site, and for content authors.

Translatable allows you to translate any row in a dataobject (by default the SiteTree is "translatable"). Translatable also taps into the hard-coded translatable text ( _t function)

Yeah we could either reuse the _t function or provide our own _c (customization) function.
 
The subsite module is basically the same thing, but rather than languages, data is separated by site (e.g. club 1, club 2, club 3). Depending on how you enter the site - e.g. www.myclub.com or www.yourclub.com you see different data... Some data can also be shared among clubs. Here you can even have different members (users) per site - something that would not be useful for the language module. 

Thanks for bringing this up. I've never worked with the subsite module, but sounds interesting for our use case.
 
In an ideal world we should look at merging these two system into one "relevant data selector" with three implementations:

1. languages
2. sub sites
3. personal data

This "relevant data selector" would alter SQL statements to ensure the selection of only one language or one subsite's content. After that the individual modules would use it in the best way. 

Also, I would recommend that the template language is as simple as possible, that is moving the logic out of the template. 

My notes are probably going to confuse you more than help you (press CTRL + z in that case)  ... sorry.... :-)   I hope it is of some help.

No, great feedback thanks!

The only question is: Do we want / need such a heavy and complex approach or would the community expect something simpler but lighter and easier to handle?

And all of this might get way too much for a single GSoC project, so we'd need to limit the scope in one way or another. That's something we'll need to discuss after selecting the desired approach...


Cheers,
Philipp

Nicolaas Thiemen Francken - Sunny Side Up

unread,
May 14, 2012, 9:50:39 PM5/14/12
to silverst...@googlegroups.com
yeah - that is why I thought my comment might not be very useful.  But I actually think it would be easier than you may think to extract subsite / translation code and make it to a new module... It will be easier to do it today than doing it tomorrow ;-)
 

And all of this might get way too much for a single GSoC project, so we'd need to limit the scope in one way or another. That's something we'll need to discuss after selecting the desired approach...

absolutely agreed. 

Sigurd Magnusson

unread,
May 14, 2012, 10:00:06 PM5/14/12
to silverst...@googlegroups.com, n...@sunnysideup.co.nz
Yuki, and others, thanks for raising this thread. I hadn't thought of personalisation being achieved at a template or database row level, but those are very valid ideas and well worth discussing. The issue is that I'd expect the CMS content author (i.e. a marketing person) to be able to define what is presented to different users, and template-based approaches therefore might be an additional but not primary means to do that because they'd require involvement of developers. Likewise, full page-by-page personalisation would be extremely useful in some situations, but, perhaps overkill in others.

I had more thought of personalising content that has a 1-many relationship with a page. If nothing else, it provides an easy place to start. For example, a CMS user adds 6 graphical banners to the main image shown on the homepage, and some of these are given tags so that they are only shown to certain users. Likewise, you could add news items to a website, tag them, and the homepage only displays the few that are relevant to that user. I am aware of an organization I deal with that is curious about this sort of functionality and we can use them as an example. They may be open to trailing the module once built and being a beta-user.

Examples of content that could be personalised, e.g. geographicallly

Current CMS interface used to manage site homepage banners:

Current CMS interface used to manage site homepage banners, and where the idea of personalisation could be added in the CMS:

The above screenshots do not give thought to how to personalize content on a page (e.g. $Title or $Content) and how to create various audience groups. (E.g. "Londoners", "Windows 8 PC users".)

Finally, I'm aware of some other people with thoughts on this topic and will invite them personally to contribute their thoughts here :)

Sigurd


Yuki Awano

unread,
May 14, 2012, 10:59:46 PM5/14/12
to silverst...@googlegroups.com, n...@sunnysideup.co.nz
Hi Sigurd, and others,

I really appreciate for your great inputs! I got many ideas and opinions for this module.

The issue is that I'd expect the CMS content author (i.e. a marketing person) to be able to define what is presented to different users, 
 
I think this point is our biggest challenge in this project. I want to make this module for people who are not good at programming.
So template would not be the best approach for this. However, widgets may be too limited, and providing only widgets may make this module useless.
I want to know the meeting point.

IMHO, I think there are two kinds of personalizations.
One is a personalization which users would change settings of personalization frequently. (e.g. Banner Personalization)
And the another is a personalization which users would rarely change settings of personalization. (e.g. Navigation Personalization)

For the first personalization, widgets should be needed.
And for the second personalization, template customization would fit.

I think providing templates and one or two widgets for customization would be good.

In addition, we cannot create all modules that would be needed for all kinds of content personalizations. 
So, I want to provide APIs for third party developers to make their own widgets for their personalizations.
Developers can create their own widgets easily by using content personalization APIs.

What kind of widgets do you think would be useful?
As Sigurd pointed out in screenshots, banner widgets would be needed. And is there other widgets that many people would need?

Thanks again,
Yuki



2012年5月15日火曜日 11時00分06秒 UTC+9 Sigurd Magnusson:
2012年5月15日火曜日 11時00分06秒 UTC+9 Sigurd Magnusson:

Uncle Cheese

unread,
May 15, 2012, 4:28:24 PM5/15/12
to SilverStripe Core Development
Hi, Yuki,

I did t a huge project on this last year for a company that sells a
database of information associated with every IP address. The module
allows them to create rules, variables and target content blocks on
each template to define at a very granular level what the user should
see.

If you're looking for ideas, I think there's a lot in here for you:

http://demandbase.carlinowebdesign.com

user: root
pass: root

Most of the magic happens on the "Page Rules" tab of each page.

Also, understand that they had the word "DataObject" already in their
lexicon, so don't be fooled by all the references to "DataObject" --
it does not refer to the silverstripe class, but rather a block of
customized content.
> >https://skitch.com/sigurdmagnusson/8ajep/screen-shot-2012-05-02-at-10...
>
> > Current CMS interface used to manage site homepage banners:
> >https://skitch.com/sigurdmagnusson/83cmb/personalisation-plunket
>
> > Current CMS interface used to manage site homepage banners, and where the
> > idea of personalisation could be added in the CMS:
> >https://skitch.com/sigurdmagnusson/83cp9/personalisation-plunket-popup
>
> > The above screenshots do not give thought to how to personalize content on
> > a page (e.g. $Title or $Content) and how to create various audience groups.
> > (E.g. "Londoners", "Windows 8 PC users".)
>
> > Finally, I'm aware of some other people with thoughts on this topic and
> > will invite them personally to contribute their thoughts here :)
>
> > Sigurd
>
> > PS: Also refer my original GSoC idea formation:
> >https://github.com/silverstripe/gsoc-wiki/wiki/Project-Idea:-Create-C...
>
> 2012年5月15日火曜日 11時00分06秒 UTC+9 Sigurd Magnusson:
>
>
>
>
>
>
>
>
>
> > Yuki, and others, thanks for raising this thread. I hadn't thought of
> > personalisation being achieved at a template or database row level, but
> > those are very valid ideas and well worth discussing. The issue is that I'd
> > expect the CMS content author (i.e. a marketing person) to be able to
> > define what is presented to different users, and template-based approaches
> > therefore might be an additional but not primary means to do that because
> > they'd require involvement of developers. Likewise, full page-by-page
> > personalisation would be extremely useful in some situations, but, perhaps
> > overkill in others.
>
> > I had more thought of personalising content that has a 1-many relationship
> > with a page. If nothing else, it provides an easy place to start. For
> > example, a CMS user adds 6 graphical banners to the main image shown on the
> > homepage, and some of these are given tags so that they are only shown to
> > certain users. Likewise, you could add news items to a website, tag them,
> > and the homepage only displays the few that are relevant to that user. I am
> > aware of an organization I deal with that is curious about this sort of
> > functionality and we can use them as an example. They may be open to
> > trailing the module once built and being a beta-user.
>
> > Examples of content that could be personalised, e.g. geographicallly
>
> >https://skitch.com/sigurdmagnusson/8ajep/screen-shot-2012-05-02-at-10...
>
> > Current CMS interface used to manage site homepage banners:
> >https://skitch.com/sigurdmagnusson/83cmb/personalisation-plunket
>
> > Current CMS interface used to manage site homepage banners, and where the
> > idea of personalisation could be added in the CMS:
> >https://skitch.com/sigurdmagnusson/83cp9/personalisation-plunket-popup
>
> > The above screenshots do not give thought to how to personalize content on
> > a page (e.g. $Title or $Content) and how to create various audience groups.
> > (E.g. "Londoners", "Windows 8 PC users".)
>
> > Finally, I'm aware of some other people with thoughts on this topic and
> > will invite them personally to contribute their thoughts here :)
>
> > Sigurd
>
> > PS: Also refer my original GSoC idea formation:
> >https://github.com/silverstripe/gsoc-wiki/wiki/Project-Idea:-Create-C...

Sigurd Magnusson

unread,
May 15, 2012, 6:48:52 PM5/15/12
to silverst...@googlegroups.com
That's great. 

See attached - assuming google groups permits me to attach a PDF.

I've taken screenshots explaining how it seems to work, and made observations relating to this GSoC project.

Cheers,
Sigurd.


Personalisation Carlino Screenshots and Thoughts by Sig.pdf

xeraa

unread,
May 15, 2012, 9:12:46 PM5/15/12
to silverst...@googlegroups.com
That's very cool Uncle Cheese - didn't know something like that already existed.
And thanks for the detailed description Sigurd!

While I like the approach of predefined "data objects" (great for reuse), the two step approach (creating it and then linking it) might be a bit tedious. Or what's your experience with the content authors?
I assume that code isn't open source so we could only reuse the general approach?

I'd still be a fan of hooking into (SilverStripe's) data objects and providing a (dynamically populated) selection field for the customization of each DO. The selection would probably be tagging field so one could add no (=default, for everyone), one, or multiple tags.
The selection field would be automatically added to all SiteTree elements in the CMS and developers could add it to their custom DOs (in Sigurd's example on the image objects).
IMHO that should be fully customizable and decently easy to handle, but those are just my 2 €-cent...

Yuki, should I outline my approach further or what solution would you prefer? IMHO widgets alone are a bit too limited or what do you (or anyone else) think?

Cheers,
Philipp

Yuki Awano

unread,
May 16, 2012, 1:00:41 PM5/16/12
to silverst...@googlegroups.com
Hi Uncle, thank you for your great inputs. That's a really cool product!
And thank Sigurd and Philipp for the following ups.

I love the idea "Data Object". It is reusable and also flexible. In addition even people who can't write html tags can use it!

To get the idea that Phillip proposed in the previous reply, I chatted with him on Skype. And I got some inputs. I will write down here for anyone to know what's going on about this module.

In the approach, DataObject is the parent of everything. IMHO, there are two kinds of personalization. Part page personalization and whole page personalization.

The structure of classes would be like the below.

DataObject->SiteTree->Page : For whole page personalization.
DataObject->PageSnippet : For part of page personalization.

And we provide the ways of personalization as the below.

Whole page personlization
Users personalize whole page in the same way as the translatable module. (https://github.com/silverstripe/silverstripe-translatable)

Part of page personalization
We do this in the way which Uncle and Sigurd showed us.

Because this approach is general and abstract(These word may not proper to express what I am thinking...), I think this approach would be a little hard for users to understand. Therefore, designing easily understandable interfaces would be an important and challenging task.

On the other hand, this approach can provide a way of general personalization. Users can do many kinds of personalization.

There would be some points that is hard to understand because my English may be poor. Please feel free to ask anything.

We are really welcome to any feedback or comment.

Thanks,
Yuki

Sigurd Magnusson

unread,
May 16, 2012, 8:03:24 PM5/16/12
to silverst...@googlegroups.com

Part of page personalization
We do this in the way which Uncle and Sigurd showed us.

Because this approach is general and abstract(These word may not proper to express what I am thinking...), I think this approach would be a little hard for users to understand. Therefore, designing easily understandable interfaces would be an important and challenging task.

Yuki, I'm glad you've noted the interface as being important (and challenging) - I entirely agree. That's partly while I suggested to focus on building the UI and leaving some of the defining of logic at the code level, to begin with. That way, as people begin to experiment and use the code as you develop it, other elements of the GUI become more obvious as to how to implement.

I do suggest part of the goal here is to create something that is intuitive for marketing people to use, which is a challenge when building from the ground up which hasn't be done very simply elsewhere. Would you be interesting in researching other open source tools (and the demos or marketing info on closed source tools) for the first hours/days of your effort, as part of this? :)

Sig


Yuki Awano

unread,
May 17, 2012, 3:55:26 AM5/17/12
to silverst...@googlegroups.com
Hi Sigurd,

Currently I am not going to do more research for open or closed source tools of content personalization.

IMHO, basis of content personalization is common in all products that perform content personalization. In addition, I think more research would give me more complex image of content personalization. In my plan, I'm going to implement alpha version of this module ASAP and get some inputs.

I think UIs can be changed easily in the later phase.

But this is just based on my opinion. If there is some wrong points, I'm happy to be pointed out.

Thanks,
Yuki

Sigurd Magnusson

unread,
May 17, 2012, 4:48:09 AM5/17/12
to silverst...@googlegroups.com, silverst...@googlegroups.com
That's ok. My suggestion for research was mostly about evaluating user interfaces, not the complex inner workings....

Sigurd

--

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/Z0-UKj4yDSoJ.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
Reply all
Reply to author
Forward
0 new messages