Add a small line of JavaScript in your template’s document ready function:

$("#MySearchBox").focus();

This will do two things for the user:

1. It’ll be easier to see the search box .
2. The user can start typing without having to click inside the search box.

Next issue is that most intranet and websites are more than just a search solution. Maybe you don’t want that much attention on the search box on your homepage. The solution is then to do this on your search result page.

This will make it easier for your users to enhance their search query when they’re not happy with the search result at hand.

Do you have any other examples on other quick fixes that could make an even better user experience for your search solution?

The empty search box by Google

The problem with an empty search box

So, what’s the biggest problem with the empty search box? In my mind it doesn’t give a hint about what’s the possible outcome of asking a question to the search engine. Think about these five questions being different search boxes:

1. Soooo…?
2. What would you like?
3. What would you like for desert?
4. Do you like ice cream for desert?
5. Do you like pistachio ice cream for desert?

The first question is the most open ended, and is the equivalent of the empty search box in a general search engine. The one with all of the worlds knowledge at hand. Second one hints that the answers of your request lies within your likings. Third, the questions get semi-concrete, and fourth and fifth, you’re asked a yes/no-question.

A search without search box working quite well

The recipe app asks you if you like any of these recipes based on two variables (time of year + place you harvest the food). We know the date and make an assumption about place and tell you that we’ve chosen these variables. Then we give you a couple of extra variables to play with to refine the search a bit more.

So far, the content seems to trigger peoples imagination and the swipe interaction is easy enough to do many times, although not very well communicated so far. When I normally give people a working search prototype, they do 2 – 5 search queries. Now I see between 5 – 15. That’s great stuff, and maybe a search without search box is actually a good idea?

A screenshot of the Recipe App search solution without a search box

Known bugs and weaknesses

• URL stays the same
  No way of sharing a specific search (month+place+filters)
• Buggy visual relevance
  For desktop and pad, all recipes with match on three ingredients or more should have full width result view.
• Not all recipes indexed
  HTML for the recipes has changed. We didn’t have time to figure out all the new characteristics of the new HTML, so a lot of recipes were not indexed.
• Visual snag on time navigator
  When selecting “short”, “medium” or “long” time to prepare recipe it should collapse as with the type navigator.
• Swipe hangs every now and then
  The swipe library is either not tuned perfectly or a little fragile. Easy to get into a state where it stops working.
• All ingredients equally important
  “Oregano” and “Chicken wings” equally important. That results in some not-so-desired search results.
• Google Analytics and single page app not fixed
  We log one pageview per user since it’s a single page app. With a rewriting of the URL this can be easily fixed.
• Design and UX
  It’s just a makeshift design to communicate the idea. It should better explain interaction and season+place.

Any comments? We’d love to get your input! Check out the solution, the actual recipe app, or you can check out the other blog posts about the Recipe App. There’s a lot of both search domain-, tech- and UX-stuff.

Main recipe app user interface

First off I’ll just make a clickable test, doing some modulo stuff so that the edge-cases will wrap (December -> January). Then try Awwwards Touch Swipe library. It has the ability to register both horizontal and vertical swipe motion. They also have a image gallery swipe demo. It only shows horizontal swiping, but I’m guessing it will be possible to expand that to vertical swiping as well.

When we have a swipe navigation that works good enough it’s time to build that in to our Angular app and use it to change the search query. Then we have to do some front end code on the actual search results and search result items.

That’s all for today. Happy 17th of May. Sounds nice? This is work in progress, so check back every now and then for new blog posts.

Any comments? Feedback on the recipe app user interface is more than welcome!

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.

For the recipe app I want to do something slightly different, showing the absolute search result quality for each result. In other words: If the best search result in a result set is not very good, make it smaller than if it has higher value, thus showing an absolute value for each result. The dialogue equivalent comparing i.e. two movies would be to define the best of them better than the other, but not the best you’d seen.

Absolute search result quality

aka. Absolute visual relevance hierarchy

How do we then measure absolute quality? In an earlier post I described what would be our relevancy hierarchy. The more in-season ingredients in a recipe, the better quality.

I’ve defined three quality groups for absolute search result quality so far (number of ingredients: n):

1. n >= 4
2. 1 < n < 4
3. n = 1

Here are three different examples on search results set. First has two results with four or more in-season ingredients and second has only one. Third has none, typically something that would happen during the winter months in Norway:

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

Download the presentations:

• Leveraging Search Based Applications on new Intranet
  (David Wright, Lead SharePoint Architect, Coutts)
• Searching Internally Using Enterprise Social Networks
  (Zane Freame, Technical Sales Professional, Microsoft UK)
• Enterprise Search Strategy by Comperio Search
  (Job Maelane, John Thompson, Comperio Search)

Some pictures from the event…

Comperio Search welcomes its guests...

Zane Freame, Technical Sales Professional, Microsoft UK

David Wright, Lead SharePoint Architect, Coutts

Trond Renshuslokken, Comperio CEO

Last ned presentasjonene:

• Søkemarkedet i 2014 (PDF)

  Trond Renshusløkken og Espen Klem, Comperio
• Bruk av søketeknologi i rettsdata.no (PDF)

  Kristian Skeie, Forlagsdirektør, Gyldendal Rettsdata
• Om Postens Tilbudssøk.no (PDF)
  Live Marstein, Prosjektleder, Posten Norge
• Hvordan kan du være innovativ i din virksomhet med Google-teknologi? (kommer)

  Christopher Conradi, Enterprise Sales Manager, Google

Noen utvalgte bilder fra arrangementet:

Takket være oppussing på Continental fikk alle frokostdeltakerne starte dagen med litt trappetrim.

Daglig leder i Comperio Trond Renshusløkken ønsker velkommen.

Trond Renshusløkken, Comperio

Espen Klem, Comperio

Kristian Skeie, Gyldendal Rettsdata

Live Marstein, Bring/Posten

Christopher Conradi

Følg oss på Twitter så du ikke går glipp av neste frokostseminar.

One generic tool for getting the right results on top is the “term frequency–inverse document frequency“, or tf-idf for short. It’s a combination of how often a term is mentioned in a document compared to how often it’s mentioned in all of your documents in the index. So, rare terms within the whole index used often in one document makes it a good search result when searching for that term. But most likely, not good enough. You need to figure out what’s the characteristics of your content, and what are the most characteristic use cases and user stories for your users. Only then can you achieve great relevancy, …  I mean get the right result on top of your search result.

Model for relevance tuning

We’ll use our Recipe app as an example…

So, for our food recipe app, we have some obvious content characteristics:

• The more ingredients in-season for one recipe is good. We’re doing an OR-search on all ingredients in-season so this comes out-of-the-box … almost.
• Quite a lot of recipes doesn’t stand the test of time. We know that most of the recipes at oppskrift.klikk.no from 2008 or newer are quite good and have nice photos.
• We’re not sure if we need this, but we know whom of the writers to trust. This may be an overkill when we already have a boosting on newer recipes.

And we know a lot about our users as well:

• Most grown up people in Norway have a job, thus limited time to prepare a meal. This means that recipes that takes shorter preparations should be boosted from Monday through Thursday. The verdict on Friday is still not decided.
• During the weekend people have more time to make dinner. The recipes that takes a short time to prepare most probably cut some corners, and are not that good compared to recipes that takes a little longer time. So for the weekends, we should do a demotion of really quick recipes, at least for dinners.

This is the info we’re going to use to sort our search result. But we have more knowledge about our users that we can use to auto-set filters for certain times of the day:

• Most work days, people don’t plan a breakfast meal or lunch. The whole day we can auto-set the main “course” filter.
• During the weekend, people may also plan a lunch. We’ve decided to auto-set the “light meal”-filter during weekends up until lunch time. After that the “main course” filter is auto-set. We’ll log if the first thing our users do is to set another filter.
• On Friday and Saturday a lot of Norwegians drink beer, wine or liquor. After some hours of drinking, they get hungry. Maybe we should have an “afterparty, quick and greasy and tasty-meal”-filter auto-set for late Fridays and Saturdays?

So, what’s the filters we’ve decided on:

• Light meals
• Starters
• Main courses
• Deserts
• … and maybe the Afterparty-thingy

What do you think?

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

1. Learn more about search, both tech and UX.
2. Show that a nice search user experience doesn’t need a search input box.
3. Show a search that is light weight.
4. Generally, build something nice, quickly, to show off.

“But what is it?” you ask again. The second answer is that it’s a search application for recipes containing the most in-season vegetables, fruits, mushrooms, fish, shellfish, poultry and meat. So, a search without a search box giving you the recipes that will make you pick the freshest, most tasty food available at any given time of the year. In Norway, you can get strawberries the whole year around, but it’s only a month or two during the summer that they taste really good. and are cheap. This goes for a lot of different foods.

We’ll blog every step of the journey. First small hackathon is this Friday, January 7th. To test our ideas we’ve already crawled food recipes from Klikk.no, and transformed them into JSON-format by using Forage Document Processor from Fergus McDowell’s excellent Forage Search Engine.

Next step is to get an Amazon EC2-server up and running, install Elasticsearch, and feed it recipes in JSON-format. We’ll also make some rough mockups of how the user interface is going to be, and maybe, hopefully get a simple version of the Seasonal Food Recipe Web Application up and running. If we after a while get enough traffic, we’ll try to do some machine learning. And we’ll definitely test out different ways of doing relevancy tuning.

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

But very often a small aspect of search is neglected: The zero result page, or the zero results strategy (There are many reasons for this, I’ll explain one later*). Yesterday I came across a search that I think could benefit greatly from zero result strategy. I was reading an article about some really good Norwegian authors, and decided to buy some of the books at a Norwegian E-book store called ebok.no.  The E-book market in Norway is not very big, even if the general book market is. Few books are published as E-books and you often have to wait a while before a book is available as an E-book. I was lucky and found two out of the three books I wanted. The last one: “Bergeners” by Tomas Espedal I misspelled a couple of times before I got it right. Even then I had to check a regular bookstore to see if it was actually correctly spelled.

Solution: Monetize search

What if ebok.no, every time a user got a zero result, did a lookup in a database to check if the search query matched an actual book. If yes, say the following:

Sorry, we don’t have the book “[title]” by [author] available as an E-book.

Would you like us to send an email when/if it is available as an E-book at ebok.no?

It the user agrees, you have achieved one and maybe two things. Firstly, you’ve made your users do a one time subscription to pay you money even if you slapped them with a zero result. Secondly, if the user wasn’t a registered user already, you may have convinced him or her to become a registered user later on because of good customer service.

*One reason a zero result strategy often is neglected is that you need the search to be in production for a while before you have enough data to analyse your zero results. In most cases, by that time, the project has ended.