How many search apps do you need on your phone?

When I go searching the web from a desktop browser, I'm lazy. I head straight to a search engine and type a short query: I can get away with a short query because the ease of browsing through a large set of results often outweighs the effort involved in coming up with a better query or visiting a specific site to search there. In those cases where the results are too far from what I want, it's pretty easy to reformulate the query because I have an easy to use physical keyboard.

Switch focus to a phone: here I'd like my query to be as specific as possible because browsing results is a chore, but typing a specific query is also a complete pain.

One de facto solution is to have an application for the specific search I want. There are a lot of phone applications that include tailored search facilities - for example, use the IMDB app to search the IMDB database, or the Wikipedia one to, well you get the idea. It's true that many of these applications do a lot more but, in the main, I don't really care - I'm interested in the search and the rest is sometimes a bonus, more often a nuisance. What's happening here is that my search is now a two or three step operation: pick the right search app, find the search box if it's not on the entry page, and then do the search. Whether that's better than dealing with generic search or not, I really don't like a cluttered start screen - it's a nuisance to scan through dozens of app icons to find the right one, so I wondered if there might be a better way...

Flipping back to the desktop for a moment, if you look at the "advanced search" facilities of the main search engines (see, for example, Bing's help pages), you see there are ways to restrict a search to one or more sites, which gets pretty close to the app specific searches - eg, a search on Wikipedia gives fairly similar results to a Bing search when you append "site:wikipedia.org" to your query. When you look at web search results, you're sure to have spotted your search query in the address bar - while not all search engines work this way, an awful lot do, as a little experimentation will show. As an example, the URL https://www.imdb.com/find?q=john+cleese gives you the results of a search for John Cleese on IMDB, from which you can deduce that issuing a query on that site can be done by appending your query to "https://www.imdb.com/find?q=" - there is a bit of URL encoding magic there, spaces become pluses, etc, which we'll come to in a little bit, but you can usually even get away with ignoring that if you want to be really lazy.

I combined those ideas and created AppNap for Windows Phone 7 to provide a single search entry point which lets you type the significant part of your query, then hit one of a set of buttons to append some user-defined text before sending the lot to an appropriate search engine. Now I've got a single entry point for my site, etc. specific searches - it's still two operations, but my start screen isn't cluttered up with lots of apps that I want only for search. The main screen looks like:

Query box at the top, and a list of user definable search buttons below. The core of the application is the list of text items to add to the user specified query, which come in two forms. If they start with "http:" or "https:" they're assumed to be site specific searches, like the IMDB example above, and cause the phone's web browser to be invoked with:

 var uri = new Uri(extraText + HttpUtility.UrlEncode(text), UriKind.Absolute);
var webTask = new WebBrowserTask { Uri = uri };
webTask.Show();

The HttpUtility.UrlEncode takes care of the character translation mentioned earlier.

If the additional text is not a URL, then I use the phone's search task:

 var query = text + ' ' + extraText;
var searchTask = new SearchTask { SearchQuery = query };
searchTask.Show();

I admit that the results pages, in either case, aren't usually as attractive as the specific applications I'm trying to avoid, but they're good enough for me. Something to explore in the future would be programmatic access to search, getting back a set of XML or JSON results and rendering them myself, instead of relying on built in search or plain old HTML pages.

The next couple of blog posts will take a closer look at the implementation...