While the new crop of "Instance [website] Search" projects are cool, I feel like most are missing the key feature of Google Instant: predictions. Without predictions, the user never knows what search returned the current results. Instead of instant search, these examples feel like instant filtering.
I'd love that. They'd need to significantly speed Search YC up for that to work though. A search that doesn't require hitting enter but takes 5 seconds to give results isn't very satisfying.
I really love Search YC, but it's so slow. I wonder if we could do some kind of kickstarter campaign to get them better infrastructure (assuming better infrastructure would fix it without significant code optimizations). Or maybe someone could donate servers? Maybe lsc, since he runs a hosting company, though his margins are probably fairly low even without giving away hosting.
And even if it needs optimizations, if they OSSed it, I bet HN users could make that happen too.
It is slow sometimes, but their query logs would be useful for query suggestions. Query suggestions should be based on what searches are popular. Not sure if you want to go through the effort of making suggestions yourself though.
Had a little play with that site, its nice that it has a JSON service but whenever it made a query it hanged like hell. So like jackowayed said, they'd have to get faster results. One thing you cant fault with using Google search, its fast.
Rather than wiping the results and re-inserting the new ones after each character is added it would look better if individual results were pulled out and inserted in the correct location. Some times the results don't change between key presses yet there is still a momentary flash where they're removed and re-added.
It would also be nice if it degraded gracefully for non-js browsers. Like Google search does.
Also, you should try to force the browser vertical scroll bar to be on permanently. When typing using Firefox just now the scrollbar kept appearing and disappearing which made the position of various on screen elements jump from side to side as the viewport size changed.
This is the best one yet - I can actually see myself using this. It's hard to know what terms people have used on HN when searching for something. The Ask HN archives are a brilliant resource.
I like the idea to, but querying searchyc.com for 'ask hn' ends up being much more effective. The concept is great, and I'm sure the execution will keep improving.
The thing I'm most impressed with is the awesome domain name.
I don't like how the results are refreshed ... it should load the results in a hidden div or something, then swap, and it should put a delta between refreshes ... I would have a second elapsed between 2 result sets displayed.
Hey guys, author here, thanks all for the kind words. It's nice to see it reaching the front page of HN when someone with decent karma submits it.
Just to let you all know I've only spent about 6 hours on this and plan to polish it up somewhat as it's still quite rough. I've also got a bunch of other developers requesting inclusion into the site swell, which I'll also add.
Things on the todo list are visual polish, adding other services, new menu, adding the suggest feature, perhaps changing from just using the google search to better apis etc.
Next step, grab a corpus of HN posts and do some text crunching to generate suggestions.
(or you could 'borrow' Feross' code, which is not condoned by Google - posts on the Interwebs say Google Suggest's "API" is not for public use - and not specific to this domain.)
Hi. I took two scripts and combined wich give fill-in words and to get direct results (still just 5) on the page with google instant. What do you guys think of the results?
url = www.googled.eu
My hat is off to you. It works in Opera and now I can get a glimpse of what Google Instant -- and other Instants that don't play nice with Opera -- is like. Thanks.
Cute idea, but it doesn't have predictions and the results are quite bad. Typing in "NoSQL" doesn't come up with the recent Heroku blog post about NoSQL.
you should adjust it so searching for "lisp" does not end up with a chunk of code w/ multiple li tags in it as being more relevant than articles that actually have the word "lisp" in them. I noticed this with a few other phrases too such as "vegan" - there are multiple "vega" chip comments that take precedence over the fully matched word.
