We built Algolia to make search easier for everyone, and a lot of our customers implement search within already existing websites or mobile applications.

But then we also have customers like AppApp.

AppApp, an independent search engine for the iOS App Store, was actually conceived after its founders realized the potential of Algolia while building solutions for existing clients. Based on faceting, grouping search results into categories, AppApp lets you search within the official App Store in ways the native search does not allow. AppApp immediately saw an opportunity to bring this faceting functionality to their mobile interface and reached out to us to share their process. Dan Singerman, its founder, explains.

---

 

Faceting with Algolia

With a typical desktop faceted search design, the instant nature of Algolia’s faceting allows you to quickly see the breadth of data, understand the results of your actions and know whether you have applied overly specific criteria. Toggling a filter takes fractions of a second, so there is very little perceived cost to experimenting with filter combinations to produce the desired results.

Algolia obviously offers a great faceting experience, but the wheels were in motion—how do you fit it into a mobile design?

Making it work for mobile

From the beginning, we wanted the search results to visibly change as the faceting was taking place. This is, after all, the essence of instant search. Most mobile faceting interfaces take you to a separate page when refinements are applied, and you lose the instant feedback you get with a desktop design.

A good example of this is Amazon.com. While they have a beautiful interface, a user would be unlikely to experiment with a large number of different faceting criteria. Who wants to keep navigating back and forth between the search categories and the results?

Building AppApp.io for mobile

Our first mobile implementation was a naive attempt to replicate the desktop approach with facets vertically aligned alongside results.

It was immediately obvious that this was not going to be successful. The touch targets for the facets were far too small, and the design would not extend to support the large number of facet categories and values we were planning to have. We realized that showing the facet categories and their values simultaneously with the results was just not going to be possible on a mobile screen.

Our next iteration moved the facet values into a modal while leaving the facet categories vertically aligned with the results.

This iteration allowed facet selection to instantly update the search results, even if it was occurring in the background. Given that we didn’t have the space of a desktop, we felt this was a good compromise. The more pressing issue with this approach was that on a mobile device, the result set was very narrow and did not make good use of space.

With apps, text descriptions alone do not give a good sense of whether an app is what you’re searching for. We like the official App Store’s approach of showing screen shots in line with results and wanted to replicate that in our design. Because of this, we felt that constraining the search results to only two thirds the width of a mobile screen was not optimal. We wanted to make use of the full width available whilst also having an effective faceting interface.

So our next iteration did just that.

We floated the faceting component over the results and moved it below the default title position for the first result so the title wasn’t hidden. Now we had full width results alongside facets. In retrospect, this was a bad idea. Nobody wants components to sit permanently on top of each other. What were we thinking? But trying this on a real device very quickly told us that.

So, our next evolution allowed the floating facet component to be hidden.

This was definitely an improvement in that the facet controls could be hidden so as not to obscure the result set, but it felt unnatural. You had to actively decide to hide the facets when scrolling through the results if you wanted to be unencumbered by the floating facet component. Weren’t facets the whole point of this project? This wasn’t going to work, but it did take us another step toward our current design.

We figured it out—our current design

We wanted facets (filters) that would appear consistently when activated by the user but naturally disappear as the user focused on the results. We moved the facet control below the search box and added a tab so it can be opened in a drawer-like fashion.

We chose to label the tab instead of assigning it an icon because we felt an icon alone would not be a strong or clear enough call to action. We decided on the label ‘filters’ because we thought this would be much more meaningful to users than ‘facets’ or ‘refinements’. We also made the tab bright orange so it would stand out to users and could not be easily overlooked.

The facet drawer also naturally closes as you start to scroll, which gives the results more screen real estate.

Does it work?

The initial evidence is positive for this approach. Since launching a month ago, our analytics tell us that 61% of users on mobile interact with the facet controls via this interface. While we’d definitely like to increase that number, this is a good start. The analytics also show that users who interact with this control do indeed try many different combinations of facets. Ultimately, we’re pleased with the results, even though it took several iterations to get here, and continue to be impressed by the faceting capabilities of Algolia that inspired this project.

Illustration by Martin David