Building an Anti-CMS

Editor's Notes

• #4: So a little bit of background information about me and where I work.
• #6: Not in Birmingham
• #8: We train lots of these (teachers)
• #9: And these (nurses)
• #14: corporate website
• #15: portal
• #16: student communities. And of course attending lots of meetings.
• #17: So what is an Anti-CMS?
• #20: Allow non-technical users to update content
• #21: Provide a uniform template across the site
• #22: Keep sites up to date
• #23: Whole bunch of other stuff.
• #24: Because everyone else has one! In the higher education sector, most institutions went through this process in the last five or six years. Many are now on their second or third CMS.
• #25: The reality of many CMS deployments is:
• #26: The wrong people are given access to create content
• #27: Given training on how to use the system,
• #28: not how to write for the web
• #29: CMS inhibit creativity
• #30: Slow to adapt to new technologies
• #31: Little access to internals meaning often you need to go back to the vendor for extensions
• #38: They built the /programmes website and more recently /music and it turns out we did a similar kind of thing but without knowing it and obviously not as well!
• #39: They explained how they get a domain expert to sketch their world.  Ignore what the resulting website is going to look like and concentrate on real things.  In their case TV or radio programmes, channels, series and so on.
• #42: Course information was a trickier proposition but fortunately around the time we were redeveloping this area of the website another project did all the hard work for us.
• #43: An XML format called XCRI-CAP defines course information for marketing purposes quite neatly and we were able to convert that into a database.
• #45: To get a little bit technical, we use a web framework called Symfony.
• #46: The Propel ORM is built into this making defining database models a piece of cake.  
• #47: From these models an "admin generator" can automagically create an interface to create and manage records in the database.
• #48: Editing a few YAML configuration files and customising some templates results in a nice interface to the database.
• #50: With some test data in the database we can start to work on how the front end should work.  This is often done from two directions simultaneously by developer and designer.  The designer is creating Photoshop mock-ups of how these would ideally look
• #52: while the developer outputs nice, hopefully semantic HTML representing the data we want to display.  Through several iterations these come together to the final working design.
• #53: Where there’s an established structured way of presenting information like a microformat
• #54: We can use that as the basis of our code so here’s an example of a vCard we can create from the database.
• #55: Which can then be styled to look pretty.
• #56: This can be a delicate balancing act.  Pay too much attention to designs and you end up making horrible hacks to the code while we all know what happens when you leave a developer to design websites!
• #57: Hopefully we end up with some nice looking, usable and accessible designs for each area of the site but we can do more than this.  Now that we’re managing our data in a structured way we can start to reuse it across our sites.
• #58: So as well as a central news site
• #59: we can show stories from the stakeholder magazine
• #60: or those related to a particular department on their website just a little extra coding and tagging stories correctly.
• #62: In our Anti-CMS we use tags
• #63: or more specifically machine tags to say how different types of data is linked.
• #71: We can also do things that regular CMSs do but more customised to our requirements.
• #73: So when searching for courses you can see useful details rather than a random snippet of text from the page.
• #74: Likewise event search results have things like embedded microformats. Stefan is doing a session on how Zend and Symfony can be used together and I think Lucene might be one of the things he talks about.
• #76: Recently we were able to add search as you type to course searches in just a few minutes using a jQueryplugin hooked up to a JSON feed.
• #80: The talk title also promised to tell you how it changed our web team.
• #85: Part of our approach to this is questioning whether publishing to the corporate website is the best place for everything or if a blog or an area on our extranet wiki would be a more appropriate place for their content.
• #86: Ask me at PHPNW10 how it works out.