While I don't necessarily like it, the fact is that search is the navigation paradigm of our generation (and probably for several more to come). Blekko is doing some cool stuff for web searching in so far as blending verticalized, curated, search operators into the mix (though operators aren't great for ease of adoption... they're a further necessary evil to get us through this phase). While Blekko takes on the mess that is web search, a few companies have taken a stab at _search_ over the past year or so. The wasteland of companies that have tried broader search approaches over the years is vast, but the past few years have yielded some companies like Greplin. I'll admit I tend to ignore the space a bit because no-one ever comes very close to getting it right, but yesterday Greplin came across my tweet stream from a respected friend, so I dove in head first.
What you have got right so far:
- oAuth/oAuth equiv support. I need to be under the illusion of control, and oAuth models give me that warm and fuzzy feeling. Thank you for using technology as it was intended, rather than chumping out with lame credential storage weakness.
- Long list of services. I hesitate to mention this one, because the list I actually want is 100x bigger than the one you offer, but, nice job on coming out of the gate with a decent list. Other services I've tried give me a couple of options, and thus, the primary use case isn't satisfied. The goal is _search_ (across it all), not search across a couple of things.
- UI. Don't waste my time with a bunch of useless UI. Google got it right with the search box, and you're mirroring that well. Keep it up.
- Upgrade model. What you're building will take untold sums of CPU cycles and disk bytes. Charge me for it. Don't do some stupid thing where you think you can support this without billing me real money. You'll die. Charge me for specialized services, and resources. Feels like you're on the right path here.
- Native service URL resolution. Rather than building a copy of all the content and pointing me to that, when I click a search result, you take me to the native service. Beautiful. Don't lose track of this. There may be cases in which you don't have a choice but to point me to a local copy, but fight those hard.
What you need to do:
- Add all the other services all the users want. My personal short list: pogoplug, my local disks, my mounted disks, backpackit.com (notes), my curated RSS feeds.
- Build out operator support. Like everyone else, I have a lot of crap, and searching for "Boulder" across it yields too much data. I need to be able to apply the set of operators you'd expect in order to narrow things. "Boulder last week", "email: boulder", "work-email: boulder", "events: boulder from last month", "documents: boulder", "photos: > 5 stars from last year" "photos: Joe yesterday" "email: has:attachment utility bill" "home-computer: file-size > 1mb soccer flyer". I need the ability to go wide, and go very narrow in order to pull the needle out of the haystack. Giving me the Google equivalent of "first 1-10 out of 1,234,113,554,665,334 results" obviously doesn't help me.
- Operator documentation. If you support any operators at all today, I can't find them easily. Search operator usage is complex, and I need to read about how to drive yours.
- Native search box integration support. Apple'e working hard to get users to use Spotlight search on iOS and OSX operating systems. This is the right thing to do, and you need to follow suit, build the plugins accordingly, and do low-level native OS search box integration (complete with your syntax/operator support). You may think you have a better way to get users to change their navigation behavior, but you don't. Let the OS vendors fight that battle... ride their coattails. If you haven't dug into the API docs around Spotlight search... dig in... it's impressive stuff.
Looking forward to the progress.