Ahh search, we meet again! Not every website requires search, but when they do, they never have the same requirements! That’s because there’s no two projects that are exactly the same. Whether it is the amount of data that needs to be searched, the quality of the results, the prioritisation of certain content, or privacy and financial concerns that mean third party services can’t be utilised – no two projects are the same.
Depending on the project, search can make or break the experience the user has. Over the last few years we have worked on various projects with varying search requirements. IFEX and Article 19 both use Elasticsearch, powered by Algolia, to index and filter through over 70,000 and 3,000 pieces respectively. Our own site and Ecover use core WordPress search layered with technical improvements to refine and filter results. The search I want to talk about today though is the search we created for Rights 4 Children, a charity that “fights for the rights of children and young people (under 18 years old) who live in children’s homes, hospitals and other health places, immigration detention, prisons, schools and secure children’s homes”.
Understanding the domain
The first thing to understand about Rights 4 Children, is that the users of the site were not to be the average consumer who has access to high speed internet and a reasonably modern device. Our target audience was children in disadvantaged scenarios, where internet connectivity might be slow or costly to access.
Carolyne & Rights 4 Children
Carolyne is a social worker who specialises in helping children and young adults (in public institutions such as prisons, asylums etc) make their voice heard. The charity, Article 39, is run by Carolyne and Rights 4 children is a campaign that aims to help children find the information they need quickly.
To get to know the audience, we sat with Carolyne, who helped us to understand how children would use the site, how search needed to support them, and what the potential problems were. Being a small charity, we knew the solution needed to be cost effective, that it should scale without significant impact on the charity itself, that the user was kept engaged and informed of what was happening, and that no matter the search query, no matter the spelling, at least one search result would be shown, ensuring the user would always feel they had a way forward and that help was available.
With this in mind, we agreed on the following attributes that the search needed to embody:
- Immediate feedback for the user
- Fault tolerant for spelling mistakes
- Defined costs that aren’t attributed to utilisation
- Help the user in knowing what to search for
So what were the options?
In fact, there are quite a few of them. WordPress being the open, customisable platform that it is, there are no shortage of solutions to various problems, and search is no different. Without digging in to specific implementations of search, we identified the following three types of search that could solve our problem, each in their own way.
Core WordPress search
Core WordPress search (being built in to the core of WordPress) has its advantages, with the primary being that the heavy lifting of searching through the content for applicable results is handled for you, and that displaying the results is the same as developing any other page in WordPress.
Elasticsearch
Elasticsearch (a relatively modern technology at the time) is capable of consuming, indexing, filtering, and returning high quality search results. Also important is that it is capable of achieving this in real time, with high levels of accuracy as the user is inputting their query. To achieve this high degree of performance and accuracy, it (most of the time) relies on a third party implementing the Elasticsearch technology.
In-browser search
An in-browser search search relies entirely on the device or browser implementing the search through the content, with no reliance on a server to communicate with. It also is most likely the least implemented option in this list for two reasons: It requires implementing all of the search logic yourself, and it most likely will not scale well to thousands of pieces of content.
In reviewing the options available, we set out to create pros and cons for each and find the best option, which in this case, would be what matched the requirements we set out earlier.
| WordPress | Elastic | In browser | |
| Immediate feedback | Depends | Yes | Yes |
| Fault tolerant | No | Depends | Depends |
| Costs | None | Scales with usage | None |
| What to search for | Depends | No | Depends |
| Risks | Performance Core modifications Network utilisation | Third party dependency Costs Network utilisation | Performance |
What did we go with?
When considering the pros and cons for each, we opted for a custom, in-browser search as it has the capacity to best match the requirements with the lowest risk to the project outside of our control. Right out of the gate, this means that we have already addressed one of the requirements. By choosing a technology that does not depend on a third party service, we know that there will be no ongoing costs.
During the wireframing and design phase, we set out to address as many of the requirements as early as possible. This included providing the user with immediate feedback, and helping the user know what to search for. In the wireframe below, we can see several components that play a part in facilitating our desired search experience.
Based on the wireframe, we discussed and concluded that as the user provides a search query, the cards can hide and show to highlight relevant results, and that the cards also help the user in knowing what to search for.
This left us with one requirement unaddressed, and this is of being fault tolerant for spelling mistakes. Being fault tolerant wasn’t just a nice to have, it was a make or break feature as the expected target audience might not get everything right.
The technical term for implementing fault tolerant search is a fuzzy search. Fuzzy search is defined as a “technique of finding strings that match a pattern approximately (rather than exactly)”. Like most things, we weren’t the first to need to implement a fuzzy search algorithm. Reviewing our options, we concluded that integrating the Fuse.js library as part of our search would allow for spelling mistakes to happen and still show relevant results.
With all the pieces in place, we implemented the code that would search through the possible results and show only the ones that matched the search term, of course, accounting for spelling mistakes. In the end, we delivered a search experience that was considerate towards the end user, engaging, helpful, and considerate of costs towards the client.
To see it in action, visit https://rights4children.org.uk/a-to-z/.
Is your search solution right for your users?
Search is a term most people understand, but when we start defining the attributes that we would like search to have, it’s rare that a common solution is applicable to the majority of scenarios. Search has to be discussed and understood, only then can the right solution be chosen and then implemented.
Over the years we have worked with many clients requiring us to craft the right solution for their site. Whether it’s core WordPress search, Elasticsearch, or a custom in-browser approach, it always begins with a conversation to understand the requirements.
If you’d like to have a conversation about how search could help your website users, get in touch. We’d love to help..