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.

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.