Recipe app link: recipe.comperiosearch.com

Responsive design test done in HTML5, CSS3 and JavaScript. A discovery engine in the making?

We have gotten a lot of knowledge, both tech and UX. Latest of many findings was the custom scoring function in elasticsearch. Hopefully, we’ll learn something within the business of food recipes, and we’ve received a lot of info from Christopher Sjuve at Klikk.no, the site we crawl for content to our search index. All blog posts on the app available under the “recipe app” tag.

Takeaways

The main intent of the app, when the idea was born back in 2011 or 2010, was to discover recipes or more general: To make a real content discovery engine based on search. Recipes that you didn’t know of or think of when planning a meal. And recipes that uses ingredients in season, thus making it relevant. In other words, the best, cheapest and most tasteful ingredients. While we continue to discover a lot of issues with how we thought the app should work technically, it really seems it can work for the end user.

A general and common issue with search solved

Mostly, with search, you get no real discovery. You rediscover stuff you already knew where there, or you find stuff you anticipated where there. But what with all the content unknown or not anticipated by the user? Nowhere in that process will regular search find stuff suitable for you that you initially didn’t think of. That’s a problem because you never touch a vast majority of possibly valuable content in your search index.

A real content discovery engine

So, what does this have to do with our recipe app? By picking the app, we know two facts upfront: The user wants food recipes, or make/serve food, to be more specific. And we know the time of year. This puts us in the position to make do a real instant search. The first screen you see is a search query already executed. The questions (search query) asked by the app to the index are then “recipes with the most in season ingredients for this month found on i.e. a farm”. We choose the farm since this is what resembles a supermarket the most. After that we let the user play with known constraints like type of meals and preparation time in addition to change place where ingredients are found and time of year.

More playfull approach. People swipe (when they understand that they can swipe, yes one of the UX issues) a lot from what we have seen. We’ll add some Google Analytics to the app soon, so we can track actual use.

Testing on a Sony Xperia Tab Z. A lot of small bugs and a bit noisy.

We’d love your feedback!

So, what do you think of our recipe discovery engine? Is it just that, a discovery engine? Are we on to something? Do you think it would work? What should we change? Don’t be shy, give us a real uppercut feedback in the comment field below!

Instant search is widely known as «the way Google do it» – in fact they were the ones who started this trend and now everyone are used to it. What if you could give your SharePoint users the same experience they are already familiar with?

To begin with you must have in mind that instant search will produce a lot more queries and that your search performance will get worse if you have too many users hammering your SSA (Search Service Application). So, yes – there is a risk. The trade-off is high if you can increase the search experience to your users, but there’s also a risk of damaging the search experience totally if things start to go slow and people end up getting zero-hits.

Anyways, for the proof of concept you don’t need to think about this now :-)

Before moving on please check that you can meet these prerequisites:

Prerequisites

• Administrator Access to a SharePoint 2013 site
• SharePoint Designer 2013 or a way of mapping your site’s directory
• A text editor such as Sublime Text or Notepad++ (doesn’t really matter, but I recommend an editor with some code highlighting / intellisense)
• Basic understanding of the concept regarding DisplayTemplate in SharePoint 2013 (You can read more about it here and here :-) )

What we are going to do is that we are simply going to create a new DisplayTemplate for the SearchBox Control based on the original DisplayTemplate and edit the OnKeyUpEvent.

Changing the DisplayTemplate

1. Open SharePoint Designer 2013 and open your site
2. Browse to http://SPSite/_catalogs/masterpage/Display Template/Search
3. Create a copy of the DisplayTemplate named Control_SearchBox.html and name it Control_InstantSearchBox.html and open it and edit the <title>-tag to something else (you’ll need it do identify the template later)
4.  Go to the javascript section in the template and create a function called  doInstantSearch(clientControl, value, event) that only executes the normal query request.

It should look something like this:

1. Edit the searchbox-control’s ‘onkeyup’-event by replacing the attribute’s value with: ‘doInstantSearch($getClientControl(this), this.value, event);’ and save your template. Now you can go to your SearchBox web part and change the template to your new one (look for the title you set in step 3.) and test it yourself.
2. Now you have a one-to-one relationship between each key you press and query that you send to your SSA. However, as you will probably notice, the whole thing feels a little bit slow and not so smooth. This is because you are hammering your SSA and re-rendering your template each time you press a key – even if it’s not a real character – not so funny right? Let’s fix it.
3. In order to fix this we need to add a character-filter and a timeout to our function. We will get the character from the keyCode and try to match the character using a regular expression. In this example we will operate with a RegEx matching all alphanumeric-characters including special norwegian characters like «æ ø å». If the character matches it we will reset the timeout function and start over with a new 300 ms delay. When we hit a non-alphanumeric character or the delay times out we will execute the search request.

This is what we end up with:

And now you have an instant search with a 300 ms delay for each legal character that the user enters in the search box.

Try it yourself :)