Mobile App Search: So Broken AltaVista Could Do It 86
waderoush writes "First-generation search engines such as AltaVista — built when the Web had only a few hundred thousand sites — produced notoriously goofy and spam-prone results. Well, when you search the Android Market for 'restaurant guide' and the top result is the U.S. Army Survival Guide, it begins to seem like we haven't come very far. San Francisco-based Chomp is one of the companies trying to fix mobile app search and discovery by leapfrogging Apple, Google, and the other app store providers. Founder and CEO Ben Keighran, creator of the once-hugely-popular Bluepulse text messaging system for Java phones, says the company plumbs the app stores, the Web, Twitter, and other sources to distill accurate keywords ('appwords') for each app. The top apps at Chomp for the search terms 'restaurant guide': Yelp, Urbanspoon, and Zagat, just as you'd expect."
Revisionist History (Score:5, Informative)
AltaVista, from 1995 to late 1998, provided perfectly acceptable search results that you would be unlikely to find substantially different than the quality of Google's results today. While the speed of the search was slower than Google's today, and it lacked the contextual searching that Google has integrated in the last several years (UPS tracking numbers, weather, calculator, Google Shopping, etc.) results could hardly have been described as goofy or spam-prone. AltaVista also provided a number of advanced search options (such as the NEAR boolean) that it took Google a decade to catch up with.
That all went away when AltaVista was sold to CMGI, and the quality of search degraded radically. AltaVista became a shadow of its former, Google-like self. While AltaVista at any time in the aughts was a laughable alternative to Google, the first few years of AltaVista - in terms of layout and quality of search - were in many ways more Googly than Google, and was clearly the service that Google was aspiring to be when they started.
King of Search (Score:5, Informative)
Google is the king of search, and Android can't search for files by filename.
If you have a ringtone named "smw.mp3" on your phone, you can't find it by searching for Mario.mp3.
You can't find it by searching for smw
You can't find it by searching for *.mp3.
You can find it by searching for certain metadata (ID3 tags in this case).
"Super Mario World" might return a hit. "Koji Kondo" might return a hit.
If you want to search for files by something as bizarre as their fucking file name, you have to use a 3rd party application, or just mount the fucking SD card in your computer.
Of course, MS isn't much better with Windows Vista and 7 - shit takes ages to search non-indexed locations even if you have a pair of SSDs in RAID 0 and specifically use the file: filter to search for a specific file name only. And it'll take about 8 years if you're searching a network location.
Same reason AltaVista sucked so much (Score:4, Informative)
Older web developers will remember meta tags for keywords and site description... use them anymore? Nah, they were from a more innocent age, were it was expected that site owners would limit the keywords and description to accurately describe their site so it would only be found by those really intending to find it.
Ah... happy days.
Google really doesn't have that much to search for in an app submission. They rely pretty much on app owner submitted information. Gosh, we better hope they file accurate keywords and description so only people really intending to find that app will find it... and pigs will fly.
The various app markets are rife with spammers and husslers trying to sell apps no-one needs at outragous prices. It would like trying to index that co.cc domain THAT google STOPPED indexing because it became an impossible job.
But they can't stop indexing their own site.
Their famous fix was to not just look at a site but see how it was linked to. That got rid of the meta tag spam BUT spammers worked around it and with apps, there is no in build linking (remember, the web is all about linking).