Content Management Case Study: Magicalia

Below is a case study on a company that has successfully developed its own content management system by evolving its content model over time. Thanks to Magicalia for this one...

# Case Study #
Developing and Evolving a Content Model

# Company #
Magicalia
http://www.magicalia.com

# Company Overview #
Magicalia is a specialist internet publisher operating six websites in participation sports markets as well as licensing their publishing platform to magazine publishers. The platform is a flexible and sophisticated content management system with a strong focus on community features.

# 1. Background to Case Study & Objectives #
We always knew that we needed to develop an architecture which could support multiple specialist community sites. The original aim was to differentiate our offering by providing a high level of localisation and personalization. To do this we needed to build a central member profile database underpinning the whole site..

The specialised sports and leisure pursuits we deal with have strong communities and a lot of the activities are localised, around clubs or shops for example. So our content model had to have users and locality at its core.

We also believed, and still do, that the Web is not the same as print. To make the most of the Web medium you must exploit its powers of interactivity and relationship building (between content and people). We knew that without an underpinning content model you cannot deliver or maintain the levels of inter-relationship and interactivity required to create a compelling Web proposition.

# 2. Process & Practice #
The entire process has been iterative and organic. Importantly, it has also always involved a team representing all areas of our business: commercial, marketing, creative and technology. It is almost four years since we launched with the original content model and architecture. It has since evolved, morphed and coalesced in many ways and directions in reaction to user needs and requests as well as for commercial reasons.

What has not changed over this time is the fact that our user profile database, containing site members’ details, preferences and so on, remains the engine that drives everything else. Over time we have added further databases (articles, forums, shops, clubs, picture galleries, product reviews, classified ads and so on) as required and ‘stitched’ them together so that everything inter-relates. The whole is genuinely an organic system – everything relates to everything else in one way or another. This includes the business-to-business applications that we run, so, for example, an advertising client of ours might also be a shop which sells particular brands which have associated products which have associated user reviews which have associated user profiles which have associated nearest shops etc.

At each stage of development it has been a matter of getting the team together to discuss the requirements, sketching out the top level architecture ramifications before detailing the data elements and inter-relations and then finally creating the database schemas.

There is nothing on any of our sites that is not stored in a database. Every piece of content is an object with associated metadata that enables the system to manage and publish that piece of content appropriately. That metadata includes standard data elements (create dates, author, last update and so on) as well keywords (to improve searching), cross-referencing to other related content (including ‘smart’ referencing), and personalization ‘bins’ – the interest categories that users select so that we can target content accordingly.

Currently we are concentrating on building ‘bridges’ between our own systems and those of our retail partners, thereby extending our inter-relational architecture externally. As we are starting to build these XML gateways with partners, we are defining our content and data structures more rigorously to facilitate communication and integration. We also continue to ‘stitch’ together various nodes within our own architecture allowing new ways of serving and inter-relating content. This is driven primarily by user feedback and requests.

# 3. Results #
It is clear to us that without our content model and information architecture we just could not deliver what we need to in order to acquire users, keep them happy and keep them coming back. On one of our sites alone we often have over 2,000 forum posts a day, not to mention the articles, reviews, product updates and so on that must appear on the site every day – and all of them are inter-related. It would be an impossible, and impossibly expensive, task to do this ‘manually’ rather than exploit the power and ‘intelligence’ of our architecture. So in many ways a good content model delivers huge operational efficiencies whilst improving the quality of the user experience.

Furthermore, the more intelligently we have been able to exploit the inter-relationships of our content model, the more we have seen direct revenue benefits in the form of increased user loyalty, increased viral activity (users referring other users) and increased page impressions per visit.

Finally, although the architecture itself is now complex, after many years evolution, it is robust and very easily replicable. This means that we have a tried and tested platform which we can use to develop and deploy new sites, for us and for clients, in next to no time and at minimal cost. The content model is thus a hugely valuable intellectual property asset that embeds our learnings and experience over the years into a form of ‘DNA.’

# 4. Lessons Learnt #
Our experience would lead us to the following recommendations:

- Put the users at the centre of your model. The one-to-one, interactive nature of the Web means that whatever the site the user is the most important element in the equation – the ‘unique key’ off which all other data, content and information hangs.

- Don’t think you can predict the architecture at the beginning. The only way is to iterate and evolve organically over time in response to user and business requirements.

- Development and ownership of the model must be done by a senior, mixed-skill, cross-departmental team. It is important that the conceptual integrity and homogeneity of the architecture is cascaded from the top down to suffuse all elements of work on the site.

- Listen to your users. The best way to develop and evolve the model is to listen to suggestions and feedback from real users. Technical smartness and complexity is one thing but the end experience must be ‘user simple’ and user relevant.

- Treat all content as objects with certain qualities and attributes (defined by good metadata) that allow you to manipulate and milk the value of that content.

- Whilst we still believe that localisation and personalisation will be differentiators in the long term, they have not been as important and differentiating in the short term as we thought. However, having good content inter-relations has proved to be incredibly important. Another reason to make sure you spend quality time on getting your architecture and content model right.

- The front end (design, look and feel, user interface etc.) and back end (databases, applications etc.) should be developed in parallel and by teams working in close collaboration. The end experience should be driven by the user, no doubt, but the back end must also be considered and, realistically, sets certain parameters.

Finally, it is clear to us as a relatively small company, how much harder all this is for a very large company. As stated, a lot rides on the conceptual integrity and homogeneity of the ‘organism’ you are creating. With the attendant decisions by committee, changes in direction etc. that are more typical of a large company with many departments it is very hard to hold the model together.

Jeremy Tapp
CTO
Magicalia

[NB the above is taken from my forthcoming book: “Maintaining and Evolving Successful Commercial Web Sites: Managing Change, Content, Customer Relationships and Site Measurement” (pub. Dec 2002) - Ashley Friedlein]