Slashdot Mirror
Google Suggest Dissected
sammykrupa writes "Google suggest Javascript code dissected and rewritten for all of you web developers out there. Cool piece of web reverse-engineering!" Joel Spolsky astutely notes that this will raise the bar in terms of how people expect the "internets" to work.
I think it is such a great idea. With google suggest people can find things with less strife. The way it works is that you start typing and it suggests things for you to search for. These entrys pop up directly under the search bar. I can help when that brain just isn't working to full potential!
Here's what he was talking about:
Google with Auto Complete on Just start typing in the search field.
It's a beta feature.
I don't know how happy google is about this, but there is already a FF extension to put suggest in the toolbar. Great plugin and also amazing how fast somebody implemented it!
Typing "cstruct" gives one suggestion. Now type "c$%#$%#$%#^struct". It gives the same single suggestion.
I'm not sure exactly which characters it ignores, because it does recognize ".net"
There are quite a few Flash RSS readers.
Also, (seeing the link in your sig) parts of the BBC site use it - News for timelines (example) and CBBC used XML to pass data around flash games/apps
The best one I've seen yet it the US Election tracker
Actually, it's not a new lookup in the google main databse for each keypress. It's a lookup in a pre-generated table of results.
It's pretty easy to spot, as the number of results shown in the preview doesn't match the number of results when you hit enter.
This makes perfect sense, since a "real" lookup would generate way too much heat. But, it's also dangerous, because people are led to believe that what they're typing would'nt yield a result. This is wrong. A simple proof of concept. Type sex. It says 0 results. But if you hit enter, you get a godzillion.
Mozilla has its own implementation of XmlHttpRequest.
There are ways of providing this kind of functionality without the serverside hit.
Actually, Mozilla has had support for XMLHTTPRequest for a long time, the API is almost the same, the difference is in maybe two lines of code when you initialize it...
We have something called the disability discrimination act here in the UK, which pretty much rules out many interesting uses of Javascript if things like screen readers can't process them, and if there's no other way of providing that enhanced functionality to disabled users.
As others have commented here, I'm not convinced that the Google feature is in fact much more than eye-candy; and thus, since it doesn't really add any functionality, isn't really covered by the DDA. However, as soon as it actually becomes useful for something, then it will be covered; and I don't fancy the job of getting JAWS or something like that to interpret the JS in a meaningful way!
Microsoft implemented it as an Active-X object you could invoke from Javascript - Mozilla implemented it as a native Javascript object. Microsoft calls it "Msxml2.XMLHTTP" or "Microsoft.XMLHTTP" depending on which version of IE you are running - Mozillah has a cleaner "XMLHttpRequest" naming (soon to be in the standards I guess).
So on IE it needs ActiveX enabled to use it . Mozilla version is therfore much safer to use and easier to program with in connectionVisit simple example for a quick and dirty example :)
Quidquid latine dictum sit, altum videtur
I think you missed the point. The "massive array" lives on the server, and when the client requests suggestions for a particular string, it is looked up in this array. Only the portion of the array that has been grabbed from prior strings is cached on the client.
In a naive, client-side caching system, if you DID manage to request all the suggestion strings in the client, eventually you would have the entire array client side, but you'd probably start throwing away the old data at some point.
Number two is correct and I don't think it suggets a lot of computing power. It's a simple table lookup. It's like a cache.
Just steal the Google code for finding out what XmlHttpRequest object the client has... it's not hard, just a bunch of try-catch clauses.
What I think is cool about the Google implementation of XmlHttp is that it's run asynchronously so it won't lock up the page.
1. Google performs several possible searches for each key you press
Very unlikely.
2. Google already knows the estimated number of results for millions of queries
More likely....and they already "know" those numbers because they use it in their normal search. It doesn't require computatioinal power to get those numbers, just time. And the lookup for those numbers should be reasonable fast (hash lookup or whatever).
Mozilla has had this (IE compatible) object since Mozilla 1.0 (Netscape 7), and Safari has it too. In the native implementations, you use new XMLHttpRequest() instead, and you can test for window.XMLHttpRequest to see if it is there. It is just a few lines of code extra.
;)
Furthermore, you can use asyncronous requests to avoid lockups. Having the Google server farm and bandwidth wouldn't hurt either, of course.
Spine World
Doesn't work. It will still strip out most non alpha-numeric characters. A + sign directly in front of the character might work... but I doubt it
Even that will not work, because even in a quoted string, all punctuation is interchangeable with a space.
so "/tmp/foo/bar" is the same as "tmp foo bar", which are very different.
If I have nothing to hide, don't search me
This is incorrect, DOM 3 Load and Save was finalised back in April, and it has been implemented by multiple browsers already. You still have to mollycoddle Internet Explorer of course, so you may not think that it's worth your while to implement the W3C approach, but that's your call.