Windows Live image search makes strides beyond Google
It's a relief to finally see Ajax-based search pages moving beyond the limitations of vanilla HTML pages. A good example is the recent update to Windows Live Image Search, which allows you to browse an entire set of search results in a single scrolling region.
I use Google's image search a lot. The most time-consuming part of posting to this blog is often getting a decent screenshot, and while a good screen capture tool is invaluable, it's often faster to google for a screenshot. For certain types of UIs, such as cell phone UIs, this is sometimes the only reasonable way to get a good screenshot at all.
Google's image search tool is good but doesn't seem to have changed significantly in a year or so, whereas Microsoft's image search tool makes a number of important advances. Live's single scrolling region is much faster to navigate than Google's multiple pages, especially since Google insists on putting the Next button only at the bottom of the page (where it often ends up below the fold). Live also lets you scale the size of the thumbnails so you can either quickly scan lots of images or linger over more detail. Live makes good use of large ToolTip pop-ups that give you a decent preview of the image before you navigate. Finally, after you click a thumbnail, Live provides a filmstrip view of your search context down the left side of the page, allowing you to continue navigating without having to return to the main results page.
It must said that even though Live's virtualized image list box is faster in practice to navigate than browsing multiple pages, the scroll bar feels just slow enough to make the overall user experience seem unresponsive. Hopefully they haven't hit the upper bound of what's possible in Ajax yet, and we'll see some improvement in performance in Liveāand in Google as they play catch-up.
Hmm the image search is quite nice, although I have to say the other services are not quite so nice.
The web search in particular has a quite non-standard scrollbar, and issues with mousewheel scrolling, at least on Firefox. Google methinks still has some breathing time to get their house in order.
Posted by: Factory | March 12, 2006 at 08:03 PM
Normally, the height of the scrolling button gives some indication as to the length of the list: a nice visual cue. With this page however, the scrolling button is always the same height regardless of how many images there are.
Our company has toyed with doing a similar ajaxy type of loading of a list of items but since we couldn't get around the scrollbar height problem, we nixed it. What do you think? Is the loss of this mnemonic a big deal?
Posted by: Chris | March 12, 2006 at 10:17 PM
It seems to me the only reason for the non-standard scrollbar is MS's Live.com team insisting on reinventing the UI rule at every step: why use the browser's standard scrollbar control when you could invent your own graphical version, which doesn't work quite as well, using Javascript?
If the server-returned search results were simply placed in a div with overflow:scroll, there would be no problems with mouse wheels or anything else that standard scrollbars have no problems with.
It's always disappointing when any company (but especially one that actually builds the OS with the widgets developers and users are supposed to be familiar with) feels that it's time to re-invent certain UI widgets just because the standard ones have become too boring. It's even more disappointing when they fail to replicate all of the functionality of the standard widget!
Posted by: David | March 13, 2006 at 12:14 AM
I don't know about anyone else, but the image search results page is ungodly slow at rendering for me. The whole experience feels like I'm moving through putty. Mind you, this is on a P4 3Ghz with 1GB RAM and a GeForce FX video card with 128MB.
Oh, and not to mention that middle-click anchored scrolling totally doesn't work with this ajax interface.
Oh, and no immediately visible meta data at /all/ about the images found? You have to mouseover the image to get see any meta data, even the name of the image?
Big thumbs down on this one. Ugly as Google's image search pages are, I think they're still ahead on this front.
Posted by: Dylan Bennett | March 13, 2006 at 01:46 AM
The image search seems to be US-only -- when I follow that link I only get web results, and there's no "Images" button anywhere. I also don't like the way that on following that link Live first displays its front page and then switches to the search results -- it just wastes time and looks daft...
Posted by: Mat Hall | March 13, 2006 at 03:25 AM
I've been implementing an AJAX virtual list box at http://finditfast.scrapbook.com so this is an interesting discussion for me.
The only reason I can't use the built-in scrollbar is because I don't want the user to be able to scroll down past the results that have been downloaded so far. (This was a conscious UI decision, I thought it would be less confusing.) It looks like this site uses a virtual one for the same reason.
It seems like I've made mine faster than this one, but I'm obviously partial. And it's a different application so there may be different issues involved. If anyone wants to try it and give me feedback on the UI issues, I would be most grateful.
Posted by: Andrew | March 14, 2006 at 04:44 PM
I wonder why they need a scrollbar in AJAx when there is a perfectly good scrollbar in any browser. Engineers with too much time.
Posted by: qqq | March 17, 2006 at 04:16 PM
Does nobody here realise they need the "special" scrollbar because with a standard toolbar they couldn't dynamically load the results that should come into view? It has nothing to do with "the old scrollbar is boring" or "engineers with too much time"...
Posted by: nstlgc | March 30, 2006 at 04:38 AM
Andrew: Your scrollbar is much more responsive than MS's, but as you say, it's not necessarily a fair comparison. Yours looks better, too.
Why can't it be proportional, if you know up front how many results there are? Your "button" will stretch vertically without any distortion, except for the top and bottom borders, which you could do with CSS or a separate image or whatever.
But I'm also not clear on why you wouldn't use the standard scroll bar: You've got an onscroll event; when the user scrolls, you could (or so I imagine) just calculate what's now visible and start loading it, if it isn't loaded already.
I don't want to sound like I'm arguing; these are real questions. I haven't done AJAX.
(But at least I know better than to put tiny gray text on a black background.)
Posted by: Capt. Dirk Dandruff, Astronaut | April 03, 2006 at 06:23 AM
Hey, another good thing about Andrew's scroll bar: You can drag it faster than the contents can refresh. If you try to drag the Windows Live thing from the top to halfway down, it crawls through every image along the way. Andrew's just swoops right to where you want it and starts loading what's there (just as I was muttering about above). It's way betterer.
Another problem with the Windows Live one is that in Mozilla, the image-zoom/link popups stop working if you right click anywhere on the page. Once you've right-clicked, you get an "element.focus is not a function" error in the JS console every time you mouse over anything -- unless a different top-level window has focus. While that's true, it still works. When you focus the WL window again, it goes back to failing. In that failure mode the small thumbnail links don't work either.
Posted by: Capt. Dirk Dandruff, Astronaut | April 03, 2006 at 06:35 AM