Recipe App User Experience on Ipads and Androids

How to sort the result set

The relevance model is now down to two variables:

1. Amount of in-season ingredients in a recipe
2. Date (year) that recipe was published.

Date will only be used to rank recipes with same amount of in-season ingredients.

Filters and drill-down possibilities

Main filters will be:

1. Light meal
2. Dinner
3. Desert

On these three filters you will be able to do a second filtering based on how short the recipe preparation time is:

1. Quick (40 minutes or less)
2. Slow/Thorough (more than 40 minutes)

Auto selected filters

The actual search is done without the user needing to do or type anything. An OR search for the current months ingredients is done when you enter the page. Default place will be “The Farm”, since that’s the closest thing to what you find in the supermarket.

The filters will also be automatically picked. During work days the “Dinner” and “Quick” filters will be set. Late Friday the meal type filter will change to “Light meal” and “Slow/Thorough”. Sometime after 12 o’clock on Saturday, the meal type will change to “Dinner”.

Based on the ideas for visualization of the search result, this is how I imagine the UX for our Seasonal Food Recipe App. To the left you have a search result for “The Sea” in May, to the right “The Sea” in January. We’ll have a new prototype running soon. Next task will be to make the navigation sprite with a combination of the five places and 12 months (sun in different position for each month). Then HTML-prototype the three different search result types: Large (full width), medium and small.

Thanks to Qbox for letting us use one of their Elasticsearch instances!

The recipe app is work in progress. Check back every now and then for new blog posts on the subject.

Search templates is a brand new feature  added to elasticsearch version 1.1. 0. It allows potentially complex search logic to be stored as templates. The user sends a query with the parameters that matters for him, along with the name of a search template, and the supplied parameters will be inserted at the proper place on execution.  The template format is moustache, a widely used javascript templating tool.

Cool stuff, you say. How can I use it? And does it really work?

In the current implentation of search templates, you create a JSON request specifying both the template and the parameters.

You can save the templates in the config/scripts folder of your elasticsearch installation, and use the saved query.
The template is saved as config/scripts/ingredientsquery.moustache. This is how my template looked like:

And here is a sample query using this template

To make changes to the template effective, you need to restart elasticsearch.

You would perhaps expect it to be possible to upload a search template using the REST API.  Unfortunately,  that hasn’t been implemented yet.  At the moment, you have to store the search templates in the  config/scripts folder in your elasticsearch node.  There is an issue registered to add this feature, but in the mean time, our friends over at qbox are helpful as always and offer to manually place the templates where they belong while we wait for elasticsearch version 1.1.1 (or something).

Using this awesome feature, the only reason we still need some middleware between our elasticsearch installation and our browser is to protect the search service from malicious requests. As it so happens, Qbox have recently added a feature that enables public read only access to the elasticsearch query _search endpoint.

This enables us to use the Qbox elasticsearch service directly from the angularjs client for elasticsearch.

Thus we eliminate the need for the searchclient in ruby, and one less server component to care about.

Sounds nice? This is work in progress, so check back every now and then for new blog posts.

Tapping into the mental model

Each variable combination will do an OR-search containing a lot of ingredients for that particular place and time of year. Our relevancy model so far:

1. Recipes with the highest amount of ingredients hits
2. Newest recipes
3. Recipes written by Christopher Sjuve

Number one on the list is given, but why number two and three? A lot of the older recipes doesn’t stand the test of time, and we know we trust Christopher Sjuve’s recipes.

The places we’ve chosen:

1. The sea
2. The farm
3. The garden
4. The forest
5. The mountain

It’s an odd bunch of places, but so far we think it will work. Logs and usability testing will tell us later if we’re hitting the target or not. The farm doesn’t fit that well with the others, since you don’t normally enter a farm and steal a cow or some potatoes. But it will be what’s closest in content to your average supermarket, and will be the default choice. Almost all of the places will have some overlapping ingredients. Each search is a combination of a place and a month. 5 places x 12 months means a sprite of 60 images where you swipe horizontal to select a place. Month will be selected for you, but to open up for exploration we think it will be valuable to  have a vertical swipe to select month.

Here’s the first wireframes on the UX concept.

First version of the query matrix. So far not organized by places, but types of ingredients.

The search is already up and running, but lack every sign of graphical user interface.

Thanks to Qbox.io for letting us use a Hosted Elasticsearch instance for this project!

Sounds nice? This is work in progress, so check back every now and then for new blog posts.