Is AOL’s New All In One Mobile Search an Improvement?

AOL has released a new version of AOL Mobile Search (wap.aol.com/portal/searchindex.do). All the major search engines have revamped their mobile search pages in the last 11 months. They all basically did the same thing too. Instead of separate searches for news, local, images, the web, etc., the new fashion in mobile search design is a single search box which delivers results from several of these categories in a single results page. AOL result

Microsoft did it first with a revamped Live Search for Mobile last September which combined the formerly separate local, web, maps, news, images, movie show times, weather forecasts, stock quotes and Spaces searches into one. Not every query returns all those types of results of course, there’s an algorithm that is supposed to analyze the query and return the types of results most likely to be relevant. Another innovation was that weather forecasts and stock quotes appear right on the results page without any need to follow a link.

In March, Yahoo (review) and Google (review) released their own variations on the all in one theme. Yahoo even came up with a catchy name for the new style of search – oneSearch.

AOL’s new search is essentially similar to the other three in concept and layout. There are some nice details; AOL taps Moviefone, MapQuest and CityGuide (all of which AOL owns) to provide the movie listings, maps and local results respectively. The quality and relevance of those results is quite good which isn’t surprising as all three AOL properties have their own well established mobile web sites. AOL has a slick JavaScript driven tabbed result page for Windows Mobile devices only (image below). AOL Windows Mobile Version

AOL’s web and news searches rely on transcoded web pages which is sub-optimal at best and it doesn’t help that AOL’s transcoder is frankly not very good. I’m ashamed to say that I gave the AOL transcoder a rave review when it first came out mainly because it did a really good job of maintaining the colors and overall look of the original web pages. Something bad has happened since then. The colors are gone and the transcoder frequently returns the wrong page or an error message. When it works it vastly underestimates the capabilities of many browsers. A Motorola i850, whose built-in Openwave browser can easily handle 20 KB of text and images, gets tiny pages containing only one or two lines (about 2 KB) of text plus another 2 KB for the AOL logo image. Opera Mini, which can handle pages of virtually unlimited size, gets pages with only 5 KB of text! The crazy thing is that the “one size fits all” AOL search results page that contains the links to the transcoded pages is from 20 to 30 KB for most queries. AOL does let you turn off transcoding which works great with Opera Mini – So why can AOL just detect Mini and other full web browsers and turn off transcoding by default for them? There are also options to turn off images and specify the page size in bytes, unfortunately these options do not seem to have any effect!

I’m surprised to see all four top web search engines embracing this new design style. I’m not convinced it’s an improvement particularly as images are included in almost every search. If I want to find the nearest ATM why should I have wait for (and possibly pay data charges for) an extra 10KB of stock images of ATM machines. Why can’t I check the ball game’s score without having to load the team’s logo, star slugger’s photo and an aerial view of the ballpark?

It might be different if mobile bandwidth was free, consistently speedy and all phones had browsers that could render image heavy pages quickly and smoothly. Networks and browsers are getting better – but the majority of mobile web users today still pay for data by the KB on slow GRPS, Edge, 1RTT and iDEN networks. And they are using feature phone browsers that can’t handle more than 10 to 20 KB per page and render and scroll images in a leisurely fashion.

I’m not against “all in one search” just the bandwidth intensive way it’s being implemented. I like being able to type a query like “ATM 94103”, “SF Giants” or “NOK” to find the nearest ATM, baseball score or Nokia’s stock price. But just give me that result and maybe a few links to news stories and web sites. Oh and a link labeled, images. Unless the query specifically requests images like say “surfing picture”, image results should be off to the side on their own page.

When it comes to speed and bandwidth use, Google and Live Search are better than Yahoo and AOL because they tailor mobile page and image size and the number of images to match the varying capabilities of different mobile browsers. Here’s a comparison of the page sizes (text + images, uncompressed) and number of ATM locations listed on the front page by each of the “all in one search” engines for a search for “ATM” when my location is set to zipcode 94103

  1. Google: 9 KB 1 ATM location and no images
  2. Live: 13 KB 2 ATMs and 2 images
  3. Yahoo: 21 KB no ATMs! and 3 images
  4. AOL: 27 KB 3 ATMs and 3 images

These queries also return links to news stories and web pages about ATMs which isn’t what I need. A dedicated local search would return at least six ATM listing in a page under 20 KB – much more useful given that I’m really only interested in finding an ATM.
For a different perspective on AOL’s new search read Treo Today’s nice comparison with lots of screenshots. And Peggy Ann Saltz at msearchgroove has a scoop, AOL is going to create their own mobile web index – very good news indeed especially if it results in AOL dumping the transcoder and delivering real mobile web results.

Rating: Content: **** Usability: XXX

AOL Mobile Search wap.aol.com/portal/searchindex.do

One thought on “Is AOL’s New All In One Mobile Search an Improvement?

  1. AOL assumes a low page capacity for terminals, but this just might not be AOL’s entire fault.

    Few companies can afford to acquire many terminals or a comprehensive subscription to DeviceAnywhere, and few have the time and resources to test thoroughly all the features of all the phones they intend to support. As a consequence, developers of mobile applications largely rely upon information about devices provided by handset manufacturers, operators, or browser vendors: UAProf, official technical documentation, developers’ handbooks, etc.

    It is common knowledge that this information is not entirely faithful (especially UAProf), incomplete (especially operators’ documentation), or sometimes out of date because of software upgrades (especially device and browser vendors). As an example, the official SprintPCS developers’ site indicates that the maximum deck size for a Motorola i850 with a native browser is 3 KB; and there is no information about whether a larger page is possible for XHTML…

Comments are closed.