2004.12.11 12:30 AM

Google Suggest, and an Exercise

It's not revolutionary, but it is nice to see a widely used public site like Google finally utilizing background round-trips directly from the browser. There's so much opportunity for improving browser apps with this technique, it's great to see someone of import finally taking advantage of it. Like a lot of web developers, I've been doing this for years in intranet apps where I knew what browser I could count on, and I even did it once in a desktop (nay, smart client) app way back in 1998, but it's not something I've ever utilized in a web app facing the general public. Kudos to Google for raising the bar.

Of course, I just had to see what they were up to, so I grabbed the JavaScript backing the page and poked around a bit. What I found, besides some pretty obscure code, was that they've tried pretty hard to support just about every possible browser. At the high-end, they're using Microsoft's MSXML.XMLHTTP ActiveX object or the Mozilla-standard XMLHttpRequest object, depending on your browser, to perform HTTP GETs. The search address they use in this case is:

http://www.google.com/complete/search?hl=en&js=true&qu=[search value here]

The "hl=xx" parameter defines the language and the "js=true" parameter causes them to return a single line of JavaScript, which looks something like this:

sendRPCDone(
  frameElement, 
  "[search value]", 
  new Array("[search results]", ...), 
  new Array("[search result counts]", ...), 
  new Array(""));

They then eval this line of code to process the results and update the UI.

When the XMLHTTP objects aren't available, they use a dynamically generated IFRAME element. I would guess that this is the technique most developers are familiar with. The search address is the same, except they leave off the "js=true" parameter, but the results are very different. Instead of a single line of JavaScript, they send back a complete HTML page with some code that executes onload to check the parent and then execute the line of JavaScript above.

You can try it yourself by clicking the following link and viewing the source:

http://www.google.com/complete/search?hl=en&qu=google%20suggest

The end result of all this is a very nice textbox- and div-based auto-complete list that works great (at least as far as I've seen) in both IE and FireFox. They've pulled off some truly tricky cross-browser development. What's really interesting about this, though, is the part we can't see -- the server-side code. They're producing some fantastic response times.

Unfortunately, the data they're returning isn't so good. I'm not sure how they're creating their lists, but for many things I type there just seem to be infinitely more appropriate responses. On top of that, the list you get back is not sorted alphabetically or by the hit count, and some of the results have no count associated with them at all.

So, as an exercise, I whipped out a little Google Suggest front-end of my own. The initial idea was to reproduce their interface, but with the results sorted descending by hit count. However, for lack of energy (I just couldn't bring myself to write the cross-browser auto-complete logic), what it mostly does is provide an example of yet another technique for performing browser-based background round-trips. In this case, instead of using the XMLHTTP objects or an IFRAME, I use a dynamically generated SCRIPT element with a qualified src attribute. Google Suggest is well suited to this approach, because the end result of their GET (with the "js=true" parameter) is a single line of JavaScript code that must be executed anyway.

No guarantees about what browsers this will work in or what affect it will have on your newsreader. I've tried it in IE 6.0 SP1 and FireFox 1.0, both on Windows XP SP1, without much trouble. Note that you can occasionally out-run the onkeyup event timer. If you do, just back up or press another key. Remember, it's only an exercise.

The trickiest thing about this technique, particularly in IE, is timing. You do not want to remove the SCRIPT element while you're executing code housed in the SCRIPT element (or executing code executed by code in the SCRIPT element; hence, the setTimeout to remove it). Also, IE is fairly touchy about where you put the SCRIPT element (at least it is if you later plan to remove it). I've found that it's best to append it as a child to the BODY element, rather than try to stick it in some other element within the BODY. Also, seat the new SCRIPT element in the document before setting its src attribute.

Btw, I'm assuming that Google doesn't have a problem with everyone tearing into their new offering. I mean, it is clear-text and they haven't even bothered to turn away HTTP referrers from outside of their domain. So, I'm assuming that as long as one doesn't explicitly copy and/or distribute their code (which does include a copyright), everything's kosher. Hope so, anyway.


Comments


TrackBack

TrackBack URL:  https://www.typepad.com/services/trackback/6a00d8341c7bd453ef00d8342145ee53ef

Listed below are links to weblogs that reference Google Suggest, and an Exercise:

» Google Suggest from Ian Nelson
[Read More]

Tracked on Dec 12, 2004 12:15:08 PM

» Google Suggest from Ian Nelson
For anyone who's been away from civilization for the past few days, the big news is that Google have... [Read More]

Tracked on Jul 30, 2006 10:58:49 AM