Thursday, February 26, 2009

Personalization in Magnolia for the Van Lanschot web site

(by guest author Edgar Vonk, software architect at Amsterdam-based full service internet agency Info.nl)

As described in the case study on the Magnolia web site Info.nl has recently created a new corporate and marketing web site for Van Lanschot Bankiers, the oldest independent bank in The Netherlands.

In this blog post we will shed some light on the technical realization of the personalization functionality that is part of this (Dutch) web site. The post will not cover details on the concept behind this functionality nor aspects concerning privacy.

The concept is based on Info.nl's model of Virtual Warmth where an online dialogue is sought with the potential client (prospect). The prospect can enter some details on his (or her) financial situation. The web site then displays topics (often concerning financial products) that are related to the prospect's situation. Also, any topics that are visited by the prospect during the active session are tracked and stored as part of the prospect's session. This way a 'personal file' is created on the fly:



Magnolia Enterprise

Info.nl has chosen Magnolia as its open source Java CMS of choice, which has resulted in Info.nl being a Magnolia implementation partner. In this case Magnolia Enterprise was chosen because of the extra features, guarantees and support that come with this edition. Info.nl deemed Magnolia Enterprise a good choice for the Van Lanschot case because of the openness of the product, the reliance on open standards, the extensibility (by means of custom modules) and the intuitive user interface.

Tracking visited topics

The visitor (prospect) is always anonymous. No personal data is stored by the system; hence there is no authentication mechanism. For each prospect a HTTP session is created in which the personal file is stored. Each time a topic is visited the ID (a JCR UUID) of this topic is stored in the personal file in 'last seen' order. Care is taken that topics are not stored twice. This online dialogue is implemented as a single-page-interface using AJAX technology. To realize this functionality a custom Magnolia Filter was written that was set to intercept all topic 'pages' using a virtual URI mapping. The screenshot below shows the filter in the Magnolia filter chain:



In our JSP templates the personal file data is then read from the HTTP session in order to show the list of topics visited by the prospect.

Storage and retrieval of the personal file

The prospect can also choose to save his personal file for later use. The prospect then receives an e-mail with a unique (machine-generated) link back to the stored personal file. The persistent storage of the file is implemented in a Magnolia Page (the Controller in the MVC pattern):



Using a virtual URI mapping this Page is activated upon a storage request. The visited topics are stored in the form of a comma separated list of unique IDs (taken from the current HTTP session of the prospect).

Retrieval of the personal file is done using the unique link that was sent in the e-mail. The associated page retrieves the corresponding personal file from the database and places this data in the current HTTP session. The web site then shows an overview page where the visitor can quickly navigate to any topics that were visited in his previous session.

During this process no sensitive data is stored that could be traced back to the visitor. The stored personal file does not contain any details about the visitor; the e-mail address and name of the prospect are not stored outside of the session.

User generated data and Magnolia

The hosting infrastructure consists of one Magnolia authoring and two Magnolia public instances. We thought about storing the personal files in the JCR repository (Jackrabbit) but decided on a simple custom database in the end. The reason why we chose this option is that using the JCR it would have been tricky to make sure that this 'user generated content' would be available to both public instances as well as to the authoring instance. A separate database that is shared by all three instances was easy to implement. I would be interested to hear from readers if they feel that JCR storage could have been a good option too, using Jackrabbit clustering as a way to synchronize this data across the Magnolia instances.

Result

Magnolia has turned out to be a good CMS for the realization of the new Van Lanschot Bankiers web site. Extending the product with custom functionality part of which was described in this blog post turned out to be relatively easy. This is due to the low learning curve of Magnolia, the openness and extensibility of the product and the reliance on open standards. And thanks to the intuitive interface of Magnolia the content editors of Van Lanschot have no problem in maintaining this dynamic web site.