If you were to develop a federated search product for mobile phones, what characteristics would the product have?

I’ve been noticing quite a buzz on the web about the federated mobile search market so I’m curious to know how this niche is being served and how it could be better served. To be honest, I know very little about the intersection of mobile phones and federated search; I’ll be learning along with, or from, readers of this blog.

I started my exploration of the subject with this blog article. The article reminds us what federated search is, then compares the offerings of two companies that have invested in serving the mobile phone industry, Medio and MCN, although MCN is really doing crawling and indexing. Here’s what I gleaned and interpreted from the article to be of particular importance when doing federated search on your phone.

  1. Speed is important. While desktop federated search applications that search scholarly sources can get away with waiting 30 seconds or longer for all the sources to return their results, the mobile phone generation won’t wait very long. Guaranteeing fast response means investing in infrastructure to process queries quickly and carefully picking individual sources that can handle the query load.

  2. Relevance rank is of particular importance. If desktop federated search users won’t frequently look at more than a page or two of results, then can you imagine a cell phone user scrolling for very long to find good results? Which leads me to …

  3. The user interface had better be really good. This is more than easy navigation; it means, according to the article:

    … that MCN is also able to provide operators with advanced services – from recommendation engines to cross-promote push and sell services – that will make the solution richer and get users what they want faster.

A second blog article gave me a different perspective on what matters, and what will matter in the future, to mobile phone users. Again, my gleanings and interpretation:

  1. Access to the deep web, which is generally done with federated search engines, will matter tremendously to business users because that’s where the bulk of web content lives, in particular, much of the scientific and technical content.

  2. Because cell phones don’t have much compute power as compared to desktop computers, federated search offerings for phones will need to perform most of their computing at the server, and little on the phone itself. Think “thin client.”

  3. The Web 2.0 paradigm will continue to influence enterprises, who rely on collaboration. Large mobile companies will have to figure out how to provide collaboration services to mobile phone users; processing data from different sources (federated search) will be an important component of such an offering.

The market is obviously an important one as Google, Yahoo!, and Microsoft all have offerings. From a superficial browse of the web-sites for Google Mobile, Yahoo! oneSearch, and Microsoft Live Search Mobile, I can make some observations:

  1. All three companies provide a mix of federated and crawled/indexed content.

  2. The federated offerings are things like weather, maps, navigation, and finding local businesses. In other words, the companies are catering to the public needing quick “facts and figures” type information.

  3. The big three search engine companies aren’t, as far as I can tell, addressing the collaboration and information analysis needs of business people.

It seems that mobile federated search can only grow as an industry, with a unique blend of ever-increasing complexity and simplicity.

What have I missed? What do mobile phone service providers need to consider in the context of federated search?

If you enjoyed this post, make sure you subscribe to the RSS feed!


This entry was posted on Thursday, April 24th, 2008 at 5:19 pm and is filed under technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or TrackBack URI from your own site.

4 Responses so far to "Federated search for your mobile phone"

  1. 1 Brinxmat
    April 24th, 2008 at 11:24 pm  

    I’m currently working on a web-app for iPhone that presents our Metalib in a suitable format (using X-Server).

    Given the particular interface restrictions that touchscreen mobile devices present, I’ve been trying out various concepts. One of the things I think may be sensible is presenting — where relevant — cluster facets first, before the results. This might sound like madness, but the interface of the device doesn’t lend itself well to long lists.

  2. 2 Leo Klein
    April 26th, 2008 at 8:28 am  

    Well, this is great but has anyone evaluated whether people would actually use their cell phones for this?

    The possibility that they could, doesn’t mean they will. I use my smart phone all the time to surf the web (on the bus going home from work).

    But it would kill me to use it as a ‘research tool’.

    I think the intended audience have better alternatives as far as hardware is concerned.

  3. 3 Brinxmat
    April 27th, 2008 at 4:26 am  

    @Leo Klein: Funnily enough, I couldn’t agree more, but then again the development overheads are small, and the market is untested.

    How will we ever know if FS on mobile is interesting or uninteresting for users if there is no product on offer?

    Originally, the idea was to present results from our OPAC, so that a user with a compatible mobile could search for literature while among the open shelves. Is that interesting for users? I’ll be honest, I don’t know, but I don’t mind spending a couple of hours finding out.

    I don’t think that it’s worth pouring massive resources into these projects, but I’m sure that libraries need to pay attention to what is happening in the world of mobiles.

  4. 4 Kate Noerr
    April 28th, 2008 at 3:46 pm  

    MuseGlobal produced a mobile metasearch product a year ago for UpSNAP - it federates and pops up several panels, across ringtones, games, wallpapers, videos, etc. (www.upsnap.com). We’re also working with other mobile content providers.

Leave a reply

Name (*)
Mail (*)