Well, I can add another entry to the catalogue of trivial victories that this blog has become. As I’ve previously noted, each month, SIteMorse publish a report examining the performance of all local authority web sites across the UK, providing the obligatory competitive edge by ranking each site against each other for overall performance against the various criteria:
- Accessibility (WAI-A)
- eGMS metadata compliance, and general metadata provision
- Number of errors and warnings, including HTML validation problems, server errors and broken links
- Acceptable download times, for 56k dialup, 512k ADSL and 1m broadband connections
The Woking site has achieved 100% accessibility compliance in the report for a few months now, although next month’s report will include accessibility scores against WAI level AA — so we’ll have to see if we’re still OK there. But we’ve persistently been in the doldrums with respect to our metadata compliance, despite a number of attempts to correct the situation.
After last month’s report, we made some enquiries to see just where we were going wrong. The main problem was that my CMS was only providing “description” metadata where the relevant (optional) field contained data. So, we changed this to duplicate the title of the page in the description metadata in the absence of anything more specific.
Voila — 100% eGMS metadata compliance, and an “OK” for general-purpose metadata provision. We’re now one of only 14 local government sites to have achieved that, and our overall rank has increased from 148 to 85 (out of 461).
Of course, whilst we’re now obeying the letter of the law, we bend the rules to get the grades, as do many of the other “metadata compliant” sites. For starters, duplicating the title in the absence of a specified description, whilst better than nothing, isn’t ideal. I did experiment with providing an automated summary instead, but the results weren’t good.
Furthermore, one of the principal tenets of the eGMS is that each resource should include metadata indicating a category chosen from the Government Category List (GCL). A site may additionally choose a category from a separate taxonomy, as long as the taxonomy is indicated.
The Woking CMS insists on a category taken from the list designed for local authority use as part of the APLAWS project. This list (as far as I can tell) doesn’t have an explicit mapping to the main GCL, so it’s not possible to derive a GCL category automatically from the one(s) chosen for a resource from the APLAWS list.
Other problems with the original APLAWS list have resulted in the creation of a somewhat expanded category list for local government, known as the LGCL, through the LAWS project. The LGCL does have a mapping to the main GCL, so if you choose a category from the LGCL, you can easily automatically derive a category from the GCL and display that.
But upgrading to the LGCL is a problem for us, because we’ve taken the unusual step of piggybacking part of the CMS workflow onto the APLAWS list. The service heads in the Council have each signed up to be responsible for a number of categories from the APLAWS list. When a publisher makes an amendment to a resource, the relevant service head is contacted to approve that change for publication to the live site on the basis of the primary APLAWS category that was chosen.
The system works really well, but of course upgrading to the LAWS list would mean that we have to go through the new list and reassign service heads to it. That would be mildly burdensome, but rumours are now flowing that a further revision is in the offing, based on an integration of LAWS with other alternative taxonomies, which would mean that we’d have to do it again in the near future.
I’m actually inclined to believe that the near future wouldn’t really be so near, and I suspect that we’ll do the work to change over to LAWS before very long anyway. In the meantime, we do what most other “metadata compliant” sites do, and that’s publish a metadata category from the list we’re using, and blindly stick on the “local government” category from the GCL for all pages. Consequently, even though we’re 100% compliant, there’s still room for improvement.
- In Geekery/CMS