Recently, one of our favorite clients reached out to us because they were facing some significant issues with their online eCommerce search experience.  Searches were irrelevant and non-performant, faceting worked sometimes, but slowly, and simple things like exporting or paginating results failed miserably. 

The previous technology stack that was implemented included 3-4 disparate systems (WordPress / WooCommerce, FacetWP, DataTables), none of which effectively communicated to each other. The result was an experience that felt like a Frankenstein-mismatched-mashup of components and the overall UX (user experience) was sub-par, to say the least. Our technical challenges were not insignificant:

1. Research and determine the best technical platform to act as a single source of truth for the entire search experience.
2. Document existing functionality and prioritize feature parity.
3. Implement and test new system against feature parity matrix, measuring for key heuristics like speed, search relevance, and the experience feeling fully internally integrated. 

The Best Technical Platform

Arguably the most important decision – this was also the easiest decision. Because of the fact that our client wisely chose to host their eCommerce site at Liquid Web with their new Managed WooCommerce product, we already had tight integration with Algolia for their site search results. Carrying that over to the faceted search experience was a natural evolution of this feature. Not everyone who uses Algolia is aware of this, but they provide more than just insanely fast search (via their Autocomplete and InstantSearch libraries, which Liquid Web leverages). In fact, their faceted search experience is just as fast as their normal autocomplete search – and it’s so much more powerful. Because they provide all of this power, and it was already available to us – using Algolia was a no-brainer.

What Exactly is Faceting?

Great question! You’ve likely already used a faceted search experience if you’ve ever shopped at Amazon. When you search for something, and it shows you different prices, review, categories, or other areas to “drill down” by? That’s faceting. Here’s a simple example:

Choosing the Right Framework

Having decided upon Algolia as our platform of choice – we had another important choice to make. We were completely replacing the entire user experience here, so there was a strong case to be made in replacing the existing patchwork with something built upon a more maintainable framework. Already set on leveraging the InstantSearch.js library from Algolia, using a JavaScript framework for the new interface made a lot of sense to us. Having worked with most modern JavaScript UI libraries – we settled on using Vue.JS. We found it to be more opinionated than Backbone.JS, more progressive than Ember and Angular, and easier to work with than React. We were delighted to find that Algolia already had great support for Vue.JS via their GitHub repos.

Well-Tested or Robust?

Our final platform-level challenge came after reviewing the aforementioned Vue.JS + Algolia starter interface. We realized quickly that the level of integration between Algolia and Vue.JS in their v1 public release was insufficient. Upon some quick investigation of open branches and pull requests against the repo, we realized that they were deep into active development on v2 of their integration – and v2 was much more powerful. Making a difficult decision between using something more battle-tested, but not nearly robust enough – or something that was still in active development, but potentially a much better long-term foundation – we made the tough call of investing in the future, potential bugs and all – we went with v2.

Finally, after making our way through the foundational project decisions, we were ready to get into the weeds and tackle building out a new interface. The first step for us here was not writing code, but writing lots and lots of words to document existing functionality.

Feature Parity

When you’re completely rebuilding something from scratch, it’s easy to sometimes miss the forest for the trees. As developers, we can become so enamored with the new and shiny that we forget that our only goal is to solve our client’s problems. If we’re not doing that, we’re failing. While much of the existing interface was broken in a lot of interesting ways – there was a lot that it was doing effectively. 

In order to make sure that we not only fixed what was broken, but didn’t break what worked well – we need to document every feature of a system that was completely undocumented, and which we had very little initial involvement in building. Due to our collaborative approach to technical partnership with our clients, we were able to work together with our client to identify everything the existing system was doing, prioritize the features, and ensure that we were able to execute everything that existed previously in the new system.

Our only goal is to solve our client’s problems. If we’re not doing that, we’re failing.

While it may sound like a simple experiment to document existing features – this exercise exposed areas of potential complexity that were hidden in plain sight. One great example of this was sorting the table of product results. Each category of products had a default sorting algorithm applied to the results that were unique to that category. In the previous system, driven by a MySQL database, sorting was a fairly straight-forward (although, in this instance, a very broken) process.

A Different Paradigm

With Algolia – while it’s tempting to carry over database-driven paradigms – it’s not a database. It’s a search index. While there is some overlap carried into this paradigm – sorting is not one of those. Where we could sort by a given column in a table in the previous interface, in the new interface, we had to create a new replica index for every column we wanted to sort by. This meant creating over 30 replica indexes and using Algolia’s API to determine which index to use when sorting. 

In the end, we ended up with a task list of nearly one hundred features to maintain parity with. This included (but was definitely not limited to):

• Default sort order for results, per category
• Custom facets and facet order per category
• Custom columns in the tabular results, per category
• Integrated CSV export (we used the great json2csv package for this)
• A built-from-scratch mobile/responsive experience, imitating the existing experience driven by WooCommerce Product Tables and dataTables.js. We used Vue-MQ for this.

Risk Assessment 

Finally, the fact that we used alpha software was ultimately a net win, but that doesn’t mean it wasn’t without challenges. The v1 package was well-documented – while the v2 package was mature in many ways, documentation was not one of them. In recent days (and even hours), they’ve made great progress on documentation – but we were flying blind for a good amount of the work we completed.

This introduced a number of roadblocks along the way – but we can’t possibly say enough wonderful things about the developer support from the folks at Algolia. They were massively helpful – with every documentation question, issue logged, support request, etc – they went above and beyond to help and even improve their alpha releases based on our feedback.

Implementation

Now that we had a clear technical specification to build from; we had to take the decisions we made, the knowledge we had, and the risks we were assuming — and put them all into practice. A project of this magnitude is bound to produce no small amount of hills to climb. Rather than outline every step of the implementation, I’ll share a couple of the challenges we faced and how we overcame them.

Numeric Indexing

I mentioned this briefly earlier: Algolia has a very different architectural paradigm than a MySQL database. It’s a search index, which means it works differently than a standard RDBS. One of the things Algolia is very good at, which the existing implementation was not executing well at all, is sorting by just about anything in the dataset.

“Anything” – in our case, often meant large datasets, sorted by a number. Unfortunately, the way that the existing WooCommerce Algolia plugin works, it’s not possible to have a taxonomy that is comprised entirely of numeric terms to be indexed numerically. In laymen’s terms, that means that where you might expect results to be sorted naturally like 1, 5, 12, 18, 25, 32, 85, 100 – they would instead be sorted like so:1, 12, 18, 100, 25, 32, 5, 85 Not exactly helpful.

In order to fix this, we were able to use an existing filter within the WooCommerce / Algolia plugin to ensure that numeric strings were sent to Algolia as numbers, rather than strings:

function algolia_numeric_index( array $attributes, WP_Post $post ) {
    $product = wc_get_product( $post );

    if ( ! $product ) {
        return $attributes;
    }

	foreach ( $attributes['taxonomies'] as $taxonomy => $terms ) {
		foreach ( $terms as $index => $term ) {
			if ( is_numeric( $term ) ) {
				$attributes['taxonomies'][ $taxonomy ][ $index ] = (float) $attributes['taxonomies'][ $taxonomy ][ $index ];
			}
		}
	}

    return $attributes;
}

add_filter( 'algolia_post_product_shared_attributes'           , 'algolia_numeric_index', 10, 2 );
add_filter( 'algolia_searchable_post_product_shared_attributes', 'algolia_numeric_index', 10, 2 );

This simple fix allowed us to fix a number of broken indexes, ensuring the sorting experience for users and for our client worked really smoothly. 

Integrating with WooCommerce…and everything else

While this new experience was being built as its own self-contained Vue.JS app – we still needed it to integrate to other parts of the site. The site navigation, driven by WordPress, needed to dictate to the Algolia facets which category should be shown. The app needed to be able to add items to the cart via WooCommerce. Thankfully, these problems were fairly easy to solve.

For integrating the menu items, and specifically clicking them, into the Vue app – we assigned the app to a global variable and emitted events against that scope when the menu items were clicked:

window.zaoAlgoliaApp = new Vue({
  el: '#zao-algolia-app',
  render: h => h(App)
});

var menuItems = document.querySelectorAll( '#top-category-menu .items' );

for (var i = 0; i < menuItems.length; i++) {
	menuItems[i].addEventListener('click', function(event) {
		event.preventDefault();
		window.zaoAlgoliaApp.$emit( 'menuItemClicked', this.href );
	});
}

This simple approach made it relatively straight-forward to listen for these events within the app and route the requests and refine the facets accordingly. 

For the ability to add results to the WooCommerce cart, we created a small Add to Cart component that mimicked the standard WooCommerce Add to Cart button. Passing the Algolia item along as a property made this effort fairly inconsequential:

<template>
	<form autocomplete="off" v-if="this.item.in_stock" :action="formActionUrl" class="cart" method="post" enctype="multipart/form-data">
		<div class="quantity">
			<label class="screen-reader-text" :for="getPostId">Quantity</label>
			<input autocomplete="off" type="number" :id="getPostId" class="input-text qty text" step="1" min="0" max="" name="quantity" value="1" title="Qty" size="4" pattern="[0-9]*" inputmode="numeric" aria-labelledby="">
		</div>
		<button type="submit" @click="addToCart( $event )" class="button alt add_to_cart_button ajax_add_to_cart" style="outline: none;">Add</button>
	</form>
	<span v-else>Out of stock</span>
</template>

<script>
export default {
	props: [ 'item' ],
	name : 'WCAddToCart',
	methods : {
		deleteMessages() {
			jQuery( '.woocommerce-messages' ).fadeOut().remove();
		},
		addToCart( e ) {
			var $ = jQuery;
			var $thisbutton = $( e.target );
			var item = this;

			item.deleteMessages();

			e.preventDefault();

			$thisbutton.removeClass( 'added' );
			$thisbutton.addClass( 'loading' );

			var data = { sku : this.item.sku, product_id : this.item.post_id };

			// Trigger event.
			$( document.body ).trigger( 'adding_to_cart', [ $thisbutton, data ] );

			// Ajax action.
			$.post( wc_add_to_cart_params.wc_ajax_url.toString().replace( '%%endpoint%%', 'add_to_cart' ), data, function( response ) {

				if ( ! response ) {
					return;
				}

				document.querySelector( 'header.woocommerce-products-header' ).insertAdjacentHTML( 'afterend', response.fragments.messages.replace( 'Continue shopping', 'View Cart' ).replace( window.location.href, wc_add_to_cart_params.cart_url ));

				setTimeout( function() {
					item.deleteMessages();
				}, 5000 );

		});
	    }
	},
	computed: {
		formActionUrl() {
			return window.location.pathname + '?add-to-cart=' + this.item.post_id;
		},
		getPostId() {
			return 'quantity_' + this.item.post_id;
		}
	}
}
</script>

The Results

Remember – our metric of success is not about lines of code (~1,000), not about how much fun we had with development challenges (a lot) or how fancy and shiny the frameworks we used are (so fancy, so shiny) – it’s about solving the client’s problems.

To reiterate: 

1. Slowness – Pages would reload anytime categories were changed, anytime breakpoints were triggered (via portrait to landscape changes, browser resizing, etc.), any time searches were performed, or facets were selected. This added 1-2 seconds of load time for almost every interface interaction.
2. Accuracy – Pagination would always show links for pages for the entire dataset, and result counts for the entire dataset, not just for the filtered set. Sorting would only sort current page, not the entire set. Exports would not take into account filters or search queries. Filtering by one facet would inconsistently affect other facets. 
3. Overall experience – UX for facets was clunky, everything was slower than expected, the entire experience did not feel well-integrated.

So – did we fix it?

1. Slowness – the interactions in the previous experience would often take a minimum of 500ms, with an approximate upper boundary around 2500ms. With Algolia powering everything – from the export, to the searching, to the faceting, to the sorting and pagination – the average interaction is essentially imperceptible – between 1 and 80ms, averaging around 30-40ms. This represents a minimum improvement of around 10x – but comparing experiences, it feels like 100x. 
2. Accuracy – one of the more powerful elements of Algolia is just how accurate it can be. Not all accuracy is created equally.  For example – when a user searches for model numbers, we have little to no typo tolerance, as they’re searching for a very specific number, and any fuzziness would be likely to return irrelevant results. However, if they’re searching for a color or material – typing Blak or Sliver or Lether should return the relevant results – typos and all! Thanks to Algolia’s powerful customizable ranking algorithms, this is exactly how the new interface works. On top of all of that – the primary issues they were facing with exporting, searching, sorting and filtering were all easily resolved.
3. Overall UX – in any UX, it’s easy to get weighed down in numbers and metrics – but at the end of the day, how it feels is what matters most. The magic of a completely rebuilt app in a modern JavaScript framework, on top of a lightning-fast service like Algolia cannot be overstated. Taking a core user experience from being painful to powerful, from janky to joyful – this is why we do what we do ?

But Wait, There’s More!

In addition to these goals that were very much a matter of execution – we’re also very attuned to our client’s strategic goals. As a bootstrapped startup, two things are eminently important for this client: 1) Keeping expenses low 2) Getting as much actionable data as possible.

To this end, our client wanted a way to be able to gather some data around how people were searching, filtering, paginating, etc. For example – to be able to track when a person types a search into the search input. and they have to click a pagination link to find the result. That gives some helpful insights into how to make search results more relevant for users.

The only problem is that Algolia makes this type of insight available – but it’s at a pricing tier that costs more than ten times as much as they were already paying. Being aware of these conflicting constraints, we got creative.

We were already using Heap Analytics for tracking data on their site. Creating custom events for faceting, paginating, searching (and a small number of other actions) using Heap’s Event Visualizer established a quick, easy way to gather this actionable insight – at no additional cost to our client. Wins all around!

If you’re reading this, wondering to yourself, “Wow, I have some of the same problems with our website – can these folks help me?” – we’d be honored to hear how we can serve you. Fill out the form below and get in touch.