Real content management
Monday, April 30th, 2007Lately I’ve been working with Vlad on designing a proper website for use on an upcoming project.
In the past I’ve used PHP for various different things, including hacking together a simple blog site of my own. This blog included the classic blog pages, as well as static pages and (theoretically) interchangeable themes. I built this on top of PEAR and Smarty for PHP.
Never before have I been faced with designing a website that really /matters/. By this I mean a site that, I hope, lots of people will be visiting. The website will be an integral part of a greater project.
This website must have a number of different content types: static pages, a ‘blog’ (or similar), a Wiki-style section for easy Wiki-linking, a photo gallery and a rather specialist/custom mapping section. There’s no big deal here… until you start actually trying to design how these fundamentally different blocks fit together in a seamless and logical way.
We’re coming close to a draft specification and there are a few key points we’ve identified:
- Once implemented, the site has to be low maintenance. We really can’t afford something full of security holes, or even something that requires any but the most basic maintenance. We don’t want to have to deal with spam of any form, maintaining links, categories, etc.
- The project as a whole involves travel and so physical locations are interesting to us. We want/need the ability to provide a geo-reference for every item of content (and potentially categories too) on the site. This means at the very least a latitude and longitude, but also an altitude where at all possible.
- Latitude and longitude is all very well and good… but what does it really mean? The website needs to have a fundamental understanding of ‘reverse geocoding’. Geocoding is the term given to translating a “man-made” location into a latitude/longitudinal value… for example a post code, city name, etc. Reverse geocoding is a slightly more specialist application of geocoding, and involves (surprisingly) geocoding in reverse. i.e. converting a latitude/longitude into a readable location.
- Access to the data must be trivial for any visitor. This largely boils down to search, and manipulation of a structure. For example a user might want to view all content related to a given physical location… this should be straightforward.
Having identified these problems we’ve come up with a few ideas that we hope to implement:
- We will provide a basic rigid content structure. This will be at a country name level, e.g. England, Scotland, Wales, etc.
- Further categorisation of data will be done on a ‘free tagging’ basis. i.e. we will not extend the rigid structure in a hierarchical manner to include, for example, England->Manchester. In some ways this is desirable but maintenance is non-trivial and the rewards don’t fully match the effort to maintain such a structure. In terms of the end user, if an entry has been tagged correctly it should be trivial to locate it by tag-based search.
- We will provide two different views on data: ordered by time and ordered by location. By default the user will see both but more specific views will be available. These will be as natural as possible.
The things that have really got me stumped are what format we will use for the URLs. There are many different ways of expressing useful information in URLs but ultimately we will pick just one way. In the meantime I’m enjoying* writing out URL schemes and considering their various benefits/drawbacks.



