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.

• This has been posted earlier on lab.klemespen.com.
• Even though some of these ideas are not what you’d normally implement in a business environment, some of the concepts can obviously be transferred over to businesses trying to provide an efficient workplace for its employees.
• Norch is developed by Fergus McDowall, an employee of Comerio.

What if you could index your whole life and make this lifeindex available through search? What would that look like, and how could it help you? Refinding information is obviously one of the use case for this type of search. I’m guessing there’s a lot more, and I’m curious to figure them out.

Actions and reactions instead of web pages

I had the lifeindex idea for a little while now. Originally the idea was to index everything I browsed. From what I know and where Norch is, it would take a while before I was anywhere close to achieving that goal. Then I thought of IFTTT, and saw it as a ‘next best thing’. But then it hit me that now I’m indexing actions, and that’s way better than pages. But what I’m missing from most sources now are the reactions to my actions. If I have a question, I also want to crawl and index the answer. If I have a statement, I want to get the critique indexed.

IFTTT and similar services (like Zapier) is quite limiting in their choice of triggers. Not sure if this is because of choices done by those services or limitations from the sites they crawl/pull information from.

A quick fix for this, and a generally good idea for Search Engines, would be to switch from a preview of your content to the actual content in the form of an embed-view. Here exemplified:

Will embed-view of your content replace the preview-pane in modern #search #engine solutions? Why preview when you can have the real deal?

— Espen Klem (@eklem) November 24, 2014

Technology: Hello IFTTT, Google SpreadSheet and Norch

IFTTT is triggered by my actions, and stores some data to a series of spreadsheets on Google Drive. These spreadsheets can deliver JSON. After a little document processing these JSON-files can be fed to the Norch-indexer.

Why hasn’t this idea popped up earlier?

Search engines used to be hardware guzzling technology. With Norch, the “NOde seaRCH” engine, that has changed. Elasticsearch and Solr are easy and small compared to i.e. SharePoint Search, but still it needs a lot of hardware. Norch can run on a Raspberry Pi, and soon it will be able to run in your browser. Maybe data sets closer to small data is more interesting than big data?

Norch running on a Raspberry Pi

Why using a search engine?

It’s cheap and quick. I’m not a developer, and I’ll still be able to glue all these sources together. Search engines are often a good choice when you have multiple sources. IFTTT and Google SpreadSheet makes it even easier, normalising the input and delivering it as JSON.

How far in the process have I come?

So far, I’ve set up a lot of triggers/sources at IFTTT.com:

• Instagram: When posting or liking both photos and videos.
• Flickr: When posting an image, creating a set or linking a photo.
• Google Calendar: When adding something to one of my calendars.
• Facebook: When i post a link, is tagged, post a status message.
• Twitter: When I tweet, retweet, reply or if somebody mentions me.
• Youtube: When I post or like a video.
• GitHub: When I create an issue, gets assigned to an issue or any issues that I part take in is closed.
• WordPress: When new posts or comments on posts.
• Android location tracking: When I enter and exit certain areas.
• Android phone log: Placed, received and missed calls.
• Gmail: Starred emails.

And gotten a good chunk of data. Indexing my SMS’es felt a bit creepy, so I stopped doing that. And storing email just sounded too excessive, but I think starred emails would suit the purpose of the project.

Those Google Drive documents are giving me JSON. Not JSON that I can feed directly Norch-indexer, it needs a little trimming.

Issues discovered so far

Manual work

This search solution needs a lot of manual setup. Every trigger needs to be set up manually. Everytime a new trigger is triggered, I get a new spreadsheet that needs a title row added. Or else, the JSON variables will look funny, since first row is used for variable names.

The spreadsheets only accepts 2000 rows. After that a new file is created. Either I need to delete content, rename the file or reconfigure some stuff.

Level of maturity

IFTTT is a really nice service, and they treat their users well. But, for now, it’s not something you can trust fully.

Cleaning up duplicates and obsolete stuff

I have no way of removing stuff from the index automatically at this point. If I delete something I’ve added/written/created, it will not be reflected in the index.

Missing sources

Books I buy, music I listen to, movies and TV-series I watch. Or Amazon, Spotify, Netflix and HBO. Apart from that, there are no Norwegian services available through IFTTT.

History

The crawling is triggered by my actions. That leaves me without history. So, i.e. new contacts on LinkedIn is meaningless when I don’t get to index the existing ones.

Next steps

JSON clean-up

I need to make a document processing step. Norch-document-processor would be nice if it had handled JSON in addition to HTML. Not yet, but maybe in the future? Anyway, there’s just a small amount of JSON clean-up before I got my data in and index.

When this step is done, a first version can be demoed.

UX and front-end code

To show the full potential, I need some interaction design of the idea. For now they’re all in my head. And these sketches needs to be converted to HTML, CSS and Angular view.

Embed codes

Figure out how to embed Instagram, Flickr, Facebook and LinkedIn-posts, Google Maps, federated phonebook search etc.

OAUTH configuration

Set up OAUTH NPM package to access non-public spreadsheets on Google Drive. Then I can add some of the less open information I have stored.

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!

Crawl interfaces, suggested

Initial Crawl-window

To crawl most pages elegantly and easily, you need five information elements:

1. Somewhere to start. Which place do you want your crawler to start. You don’t have to specify the domain, we pick the domain name  from the page you’re visiting.
2. Which links to follow. This is not necessarily the pages you want to crawl. Typically these pages have lists of pages you want to crawl.
3. Which links not to follow. To not make the crawler go wild, you set some boundaries. Often a page has several URLs.
4. Which links to crawl. These are the actual pages you’re looking for.
5. Which links not to crawl.

A simple illustration on the above rules. Forage Fetch doesn’t have all these features yet, but they’re suggested as enhancements.

Selecting which rule type to add

To ensure you’re adding valid rules, it’s a good ting to test first.

Start URL added

The minimum amount of rules needed to start the crawler

Next tasks will be to make a clickable prototype in HTML/CSS and read up on HTML5 local storage/web storage.

All comments on the idea are welcome! Here’s what we’ve blogged about Forage so far.

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.

Forage could then be added with a bookmarklet to any page (A bookmark adding a javascript to the page you’re on). With some simple UI-stuff you could define the Forage Document Processor Adapter, set up rules for Forage Crawler, crawl, process, index and then search within your indexed documents. All without using any servers, on premises or in the cloud. When the user is satisfied she or he could download the JSON-file with processed documents + scripts for adding a search box,  search result and navigators to a page.

Possible use cases for search server running inside browser:

• Easy site search setup
  One real benefit, and the initial idea, would be that the user would not need any server to test Forage and actually crawl a site. When page crawled the user can download JSON ready to be indexed + setup-files for a search box, navigators and search result. Or add it to a cloud service and there continue the work you started in your browser.
• A easy and modern search solution behind the firewall
  Behind the firewall, almost all software looks a bit duller, more beige and basically not modern. But through the browser you could easily combine the strength of  Forage and all the hidden gems behind a firewall. There would be some big issues with security, but for intranet and people search it could be a great solution.
• Ad hoc search on a site that is not yours
  Say you’re looking for something on a site. How about ad hock index it and then search it. Yes, it’s a bandwidth abuse waiting to happen, but could make a good tool for a lot of situations.
• Your life, searchable
  This may need a browser add on, but then again, maybe not. Anyway: How about your whole online life, searchable. Today you have your browser history. It shows you page title and page link. What if all the text and images was searchable?

Some UX sketches of the idea:

The user finds a page to crawl …

… clicks the bookmarklet …

... that adds Forage JavaScript-stuff to the page …

… much like a browser plugin or add on …

… tests a jQuery selector statement …

… and adds the field to the item when satisfied. Repeated until a full item is defined.

Here’s the feature suggestion at the Forage GitHub page. Ideas or comments are more than welcome! Want to know more about Forage? Check out the Forage GitHub-pages or stuff we’ve written about Forage.

EDIT: Drawn some new mock ups on the crawler part: Forage Fetch and written about the killer combo Lebron and what it will mean for search.

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.