Decoupling content management


Published on

A short presentation on separating content from navigation to transform the way you manage your website. Delivered by Stephen Pope, Technical Architect, Eduserv at Internet World on 12th May 2011

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Just to make your website editable you need to accept the web framework imposed by the system, the templating engine used by the system, and the editing tools used by the system. Want to have a better user interface? Be prepared to rewrite your whole website, and to the pain of having to migrate content between different storage systems.But none of this should be necessary. When web editing tools were more immature, it made sense for the same people to build the whole stack from database content models to web page generation and editing tools. But that was ten years ago, now we can do better.
  • There is a content repository that manages content models and how to store them.Then there is a web framework, responsible of matching URL requests to particular content and generating corresponding data.The view engine then decides how that data is transformed and presented to the user.Many CMS’s have tackled the first two, content is separate from presentation. They have decoupled the code and data elements from the view engine.This is good but we need to go one step further. Lets look at a typical site structure.
  • Content is traditionally held under the site structure nodes (landing pages etc.)What we did was take the content and truly separate it from the navigation by pulling all content into the content repository.Content type data structures ( what fields constitute a press notice etc ) are kept in the repository along with the instances of those types (the actual press notices).Editors work only with the content repository using the set content typesWeb administrators deal with the structure of the site, organising landing pages and promotional parts.So what brings these two elements together ?
  • Content editors once they have finished tag their articles with tags.Customer has a thesaurus so they can describe their universe. (exposing as SKOS RDF later on)(Automated in the future OpenCalais,TSO etc)
  • Syndicate and share your data any way you like.
  • Make them addressable: give them URLs. For example, if it’s a course, mint a URL which points to a unique resource representing that course.Using readable URLs: make the URL intelligible to an end user. If it’s a URL pointing to a course, then a URL which has the word ‘course’ in it will help.Using reliable URLs: manage the URLs you mint, and ensure that they are persistent.Using “hackable” URLs: make the URLs predictable and consistent, such that a developer can figure out the logical structure of the URLs and the underlying information architecture. As with ‘readable URLs’ above, do not be cryptic in URLs if this can be avoided
  • Decoupling content management

    1. 1. Decoupling Content Management<br />Separating content from navigation<br />Stephen Pope – Technical Architect<br />
    2. 2. Client Problem<br />Lots of disparate content<br />Multiple content types<br />Multiple overlapping audiences<br />Multiple domains and campaigns<br />Consolidate sites yet retain content<br />Offer the user greater connection with the data<br />Site likely to change name or structure<br />
    3. 3. Tackling the monolith<br />Content Management System<br />Database<br />
    4. 4. Decoupled approach<br />View / Presentation Engine<br />Web Framework<br />Pluggable Component Modules<br />Content Repository<br />
    5. 5. One step further<br />Web Administration<br />Content Repository<br />
    6. 6. Tagging<br />French<br />Exams<br />Other metadata<br />
    7. 7. Mapping (The glue!)<br />Content Repository<br />Exams<br />French<br />/Area1/Languages/<br />
    8. 8. Advantages of this approach<br />Central store of content types<br />Navigation nodes deal with structure not content<br />Articles pulled into navigation using article metadata<br />Navigation can be reworked at any point without large migration exercise.<br />
    9. 9. Advantages of this approach<br />Articles can appear in multiple places<br />Articles can appear across multiple domains<br />Option to open the store via feeds and API’s<br />Web Services<br />Content Repository<br />
    10. 10. Considerations for a better web<br />Identify the important entities<br />Make them addressable<br />Using readable URLs<br />Using “hackable” URLs<br />(<br />
    11. 11. Multi-Surfacing<br />Keep each section’s look and feel<br />Maintain “Google Juice”<br />Persistent URIs<br />We had to take full control of the URLs in the system<br />
    12. 12.<br /><br /><br /><br />
    13. 13.<br /><br /><br /><br />
    14. 14. Keeping search engines happy<br />Canonical Link<br /><link rel="canonical" href="" /><br />Add to <head> tag of pages that are derivatives<br />Preserves “Google Juice” – Fully supported by Google / Bing / Yahoo! etc.<br />
    15. 15. Hackable URL’s (The website IS the API)<br /><br /><br />…/area1/languages.rss?p=1<br /><br /><br />
    16. 16. Difficulties<br />Letting go – site is dynamic and evolving.<br />Default context – when an item can exist anywhere where is its default home ?<br />Editor education – writing content that is self contained.<br />Strong taxonomy – enough depth and breadth to ensure good quality tagging.<br />
    17. 17. Successes<br />True multi-surfacing.<br />Already had its first restructuring test.<br />Sitecore is our Swiss army knife.<br />Multi-surfacing is only part of the solution.<br />Leveraging open source the right way.<br />
    18. 18. Thank you<br />Enjoy the remaining 15 minutes of Internet World.<br />