I was recently contracted by the Open University to experiment with a solution to record and display evidence for the research hypotheses. Speaking to the project team a number of options were discussed from simple spreadsheet based approaches to re-purposing software versioning systems like Github. In the end it was decided to develop a WordPress plugin. There were a couple of reasons for going down this route:
- WordPress is a one of the most popular open source platforms with a well documented codex and active developer community
- It’s existing plugin and theme architecture make it easy to customise
- There are already over 27,000 open source plugins in the official plugin repository allowing easy feature extension
As part of the conversations with the team and having reviewed existing documentation the following relationship diagram was used to identify the structure and nature of the data that needed to be stored:
Having established this a the wireframe (shown below) was created to illustrate how data could be entered building upon the existing WordPress Custom Post Types:
Fortunately rather than creating the custom post type templates from scratch Francis Yaconiello’s has published a plugin template to do this. For this project we need three custom post types to enter data for hypothesis, evidence and location mapping to the relationship diagram shown above. To avoid duplication these templates use additional templating to make it easier to add custom fields. The result is shown below with the current ‘Add New Evidence’ screen.
Location, location, location
One particular challenge was to find an easy way for users to attach location data to evidence. Rather than getting users to select a location name from a long list a simple location lookup which queried the existing location custom post types. This component uses, in part, the Pronamic Google Maps plugin which is included in this plugin as a software library. This route has been chosen to remove the dependency on other plugins being installed on the site which could be an issue for multisite deployment. The downside is that this component has become orphaned from the Pronamic updates. This comes with an increased risk given the dependency on the Google Maps API. The mitigating factor is the Pronamic’s plugin stores the geodata in a way that it can be used by other plugins and mapping services.
Another reason for choosing to ‘bake in’ the Pronamic’s plugin is that with a line of code we can include geo options within the location custom post type. This option includes the geo-encoding and reverse geo-encoding of addresses making data entry easier.
With some infrastructure in place for recording data the next challenge is to present this in a useful way. The current tack I’m going to take is expose the data as JSON (there’s a plugin for that) and try out some d3js examples, like a Reingold–Tilford Tree (H/T Tony Hirst @psychemedia)