The volatile search engine as a use case
Or how personal search solutions will actually be a thing.
Search engines are often considered to be memory and CPU-hogging beasts. They can be hard to install and set up properly, and even harder to maintain. You don’t do it if you do not really, really want it. And it takes time to integrate all the sources, so you have to really, really want it for a long time before you have your search solution processing user queries and spitting out results.
This means that the benefit of the search solution you want, has to be big before somebody gives it a green light.
Fraction of a fraction of a fraction…
The cost of having a search engine is going down. And when the cost is low enough, maybe the cognitive load of setting one up is the last threshold before you look at a search engine as a Swiss army knife. A tool to fix a lot of every day life challenges.
But first, the costs, and some reasons why they are going down
I’ve long thought that JavaScript search engines will change part of the search market, and also create new search markets.
They are light weight and better geared towards small search indexes. That means they are not overkill for smaller data-sets. That’s the first fraction.
Norch/search-index can run both on the server and in the browser. Or if you want, a combination. That means they can use hardware resources that you already possess: Your laptop, your phone, or maybe your TV. That’s your fraction of a fraction. You don’t have to invest anything else than integrating the sources you want to have searchable.
The cognitive cost
But what could be a good move to lower the threshold so that having your own search engine would be something for everybody? Looking into a bookmarklet that adds the page you are looking at, to your search engine, it struck me that we’ve may be there soon. The click of a bookmarklet eases the process of adding content to a search engine from a lot of different sources. But the search engine still needs to be set up every time you want a search solution running.
Separating the tool from the data
What if the choice to use and set up a search engine is a choice you do only once? It’s like installing or subscribing to a spreadsheet engine or a word processor. When installed or subscribed to, it is there to be used in a million different ways.
You could pay for a service that is one (1) search engine. It’s the only one you’ll need. You may have a lot of separate search indexes (or separate data-sets if you want). One use-case could be researching where to go on vacation. Every interesting place, vendor or blog post you find, you add to your newly created search index. Next day, you want to continue researching something job related, i.e. “user experience on cellphones”. You open that search index, add to it whenever you find something interesting and search in it to find stuff already added. If you want to continue the vacation research when you get home, you open that one and continue on your vacation search index. Searching for earlier added documents, and adding new ones (or maybe deleting some old ones).
Maybe you would want to join two older search indexes, delete one that isn’t needed anymore and split up a really big one into two more distinct data-sets? All soon possible.
I think the cognitive load of owning a search engine, or more specifically, a search index (the actual data) will be a lot lower with this. It’s more like handling documents, and less like 1 million dollar development project. And maybe low enough for everyone to have one?
