Searching Local Government
The development of a website is almost always an iterative process. Once the core functionality is in place improvements tend to be incremental, either by extending the range of functions, or by improving existing functions. For example, last week I installed the latest version of mnoGoSearch , the search engine software I use for ClacksWeb. For tasks like this I always try to programme in time to have a look at other UK local authorities to see what they're up to in the same area. It helps me to get ideas for future developments, and often ideas I can implement at the same time as fulfilling the task in hand.
In this instance I reviewed the search functions of the websites of Clackmannanshire Council and 18 other UK local authorities, looking for examples of good practice and novel ideas which might improve user experience. In this first piece I'll present some of the findings, concentrating on two aspects of search that impact upon the user:
- The search results data itself - how relevant it is (does it answer the user's query?), how comprehensive (does it include results from files in formats other than HTML?), what visible metadata it includes (does it provide file size, date last modified, file type, etc?).
- The presentation of the results - the validity of HTML, the structure and accessibility of the results, what help was provided for users, and so on.
In two future posts I'll cover some of the interesting and novel features I found, and some tips for maintaining and developing a site search function.
For want of a better method I took the top ten sites from the latest (seriously flawed, but that's another matter) UK local government website rankings, plus the sites ranked 50, 100, 150 and so on, up to site 450. A full list of the sites reviewed is provided at the end of this article.
I searched each site using the search function provided on the front page, except in the one case where search was not available on the front page. Since local authorities serve different functions I needed to use neutral search queries. The two I used were:
- make a complaint - I wanted information on making a general complaint to the Council;
- accessibility - I was interested in the Council's web accessibility policy and provision.
I recorded a range of information about the search results, including the product or package used (where known).
In terms of finding what I was looking for it was an encouraging experience, at least for me as an able-bodied, sighted user. I rated nine of the sites as providing 'good' results, and only three as 'poor'. On all except one of the sites I found the required information for query one. Query two was more problematic, with many superfluous results.
Here's a quick summary of some basic indicators:
- Query one produced between 0 and 6510 results, query two between 1 and 21700 results;
- Three of the nineteen sites had error-free HTML, tested with the W3C validator;
- The most common HTML errors were unclosed tags, unencoded characters (especially ampersands) and lack of doctype declaration;
- Only two sites presented results using structured, semantic HTML, where a relationship between results and their metadata was explicit (see below for more detail);
- Eight sites used CSS for page layout;
- Five sites used the POST method for form submission, meaning that users cannot bookmark results;
- Ten sites did not implement stopwords, meaning that the 'a' in query one produced a high noise to signal ratio on these sites;
- Four sites implemented a minimum query length, two of 2 characters and two of 3 characters;
- Only ten sites provided help for search users;
- The longest search took 47 seconds (and had the courtesy to tell me so!).
Presentation of results
One of the more disappointing aspects was the quality of the mark-up used for the results themselves. In only two cases were results provided with any explicit relationship between the result title and the metadata. In the first case the title was presented as a level 2 heading, with the metadata (the first x characters of the page in question) a paragraph beneath. In the second case the results were presented as a definition list, with the title as definition term and metadata as definition data.
All the other sites used either various table-based layouts, none with table header cells or other assistive mark-up, or simply a paragraph per result. I'm sure none of these would have made for a comfortable experience for a screenreader user - the lack of structure between and within results being a real barrier to accessibility.
It's good practice to provide users with as much information about the destination you're sending them to with any hyperlink, and in my opinion essential with search results. When users follow links from within a content page of a site, they will be able to take some context from the other information on the page. With search results they don't have that context to inform their judgement, and so must rely on the information the search results provide.
Ideally I'd want to know the type of file I'm heading to (is it HTML, a PDF, a Microsoft Word document, etc), the size of that file, and when it was last updated. Here's what I found:
- Nine sites provided the file type, either explicitly or via a graphical icon;
- Only three sites provided the file size;
- Seven sites provided the last modified date.
This lack of metadata surprised me. It's hard to understand why an organisation would consider purchasing or adopting a search package without support for these functions.
It was possible to identify the search engine used by fourteen of the sites:
- Open Objects Kbroker (3 sites)
- Semaphore (3 sites)
- Verity Ultraseek (2 sites)
- Google Mini
- Mambo (CMS)
- Jadu (CMS)
- dotEditor (CMS)
In my unscientific tests the dedicated search packages did seem to produce more relevant results than the CMS searches, but did not necessarily present them in a better fashion. In reality this is far too small a sample to draw any valid conclusions about the value of individual or groups of products.
Search is a critical function on a local government site - the search engine results page (SERP) will without exception feature in the top ten most visited pages. Even ClacksWeb, catering for the smallest Council in Scotland, processes more than 10,000 queries in an average month. Given that it would be reasonable to expect it to be a lovingly crafted, finely-honed page, with relevance of results, validity of mark-up and accessibility all prime considerations. Clearly this isn't the case, with many of the sites reviewed failing to provide what could be described as a high quality site search.
Although I found what I was looking for on most sites, I was largely disappointed with the technical quality of the SERPs. I did get some good ideas for enhancing our search function, which will be implemented in the near future, but I also picked up a number of examples of how not to approach search. I'll post more about both at a later date, plus some tips for creating and maintaining a top-notch site search facility.
Appendix - the review sites
- Aylesbury Vale District Council
- Cannock Chase District Council
- Clackmannanshire Council
- Dorset For You
- East Riding of Yorkshire Council
- Hambleton District Council
- Hastings Borough Council
- Isle of Wight
- Lewes District Council
- Oldham Council
- Portsmouth City Council
- St. Edmundsbury Borough Council
- Scottish Borders Council
- Sefton Council
- Shepway District Council
- South Bucks District Council
- South Lakeland District Council
- Thurrock Council
- Trafford Metropolitan Borough Council