A look into the new Keele University website search
The new Keele University website launched in April 2018 and we’re currently moving along transforming deeper areas of the site. I thought I’d take a little time to give a technical overview of some of the new features. I’ll cover a few areas, giving a surface overview of how they’re implemented and some of the business decisions around how they fit into the overall web project. This post in particular will cover Keele’s new search solution.
Aside: You can find out more about the Keele University web project on our team blog.
As part of the launch we implemented a new site search. We wanted to have the flexibility to develop new search solutions in house and were recommended the popular ‘search as a service’ called Algolia. A trial was up and running within a day and it looked very positive so I continued building various proof of concepts. Algolia has a very clear API https://www.algolia.com/doc/api-reference , an open, approachable and helpful team on Github and since the service is cloud based it took away the need for us to maintain and upgrade our local servers and databases. Once we’d cleared Algolia’s terms and conditions with our legal team, we were set to continue.
How does Algolia work and how was it implemented at Keele University?
In essence, Algolia lets you push/sync data from your website, have them index it and then it’s immediately available to access via their API along with a templating language. For Keele that meant using the PHP API to collect and format the data as JSON, push that to Algolia and then use a mix of their JavaScript API and InstantSearch.js library on the frontend to display results. So once the initial data sync and connection was made, mixing result data with our design components was straightforward. For example, referencing the url and title value would be
<a href="{{ urlPath }}">{{{ _highlightResult.courseTitle.value }}}</a>
Using the service has allowed us to cherry pick searchable fields/snippets rather than have a traditional engine crawl pages across the entire site. Using templating, we can also choose which bits of the returned JSON we want to show in the search result. We can also feed data that can be searched against, but only display the fields we like in the search result. Here’s a JSON snippet for an undergraduate course:
There were other options such as having a text search field built in vanilla JS using .filter
's however Algolia gave us the advantage of out of the box typo tolerance, maintained instant ‘as you type’ results, quick and intuitive synonym configuration, an analytics dashboard and also the ability to easily create facets. For the facets we simply fed e.g. course levels as ‘_tags’ in the JSON.
We’re using the JavaScript framework VueJS on the new site but at the time we rolled the site out, Algolia Vue InstantSearch was in beta. It worked just fine but didn’t yet have url sync (a history of search terms in the url/slug). So to ensure users could bookmark/share searches and use the back button, we stuck with the vanilla JS library. We may move over now that Vue InstantSearch is out of beta.
Each search box instance (styled as a Keele shield on the site) comes from a single Vue component. CMS editors can pass in simple flags (Vue props) to configure various defaults. The original pattern library was created in Laravel however maintenance and development now runs in Laravel Mix and webpack. I had to break down the HTML output into various fragments in order to add it to our CMS and so using Laravel Mix was a perfect way to separate the JS dev workflow and content from the static html layouts held in the CMS.
Beyond course search
Usage of the new search has been high and feedback has been very good. Many users of our old search have commented on how the new one brings back more relevant results.
We don’t use Algolia for the main site search although I believe it’s possible to feed Algolia with entire site data so long as it’s in a uniform format but for Keele, the simple Google Custom Search is effective and meets requirements for now.
In future posts I hope to go into more detail on how we used Algolia for our Events search.