Google Desktop Search is a neat app. The integration of local and global results is brilliant. But it’s not the future of desktop search.
David Galbraith said something interesting in a post titled “Google lock in”:
“Whatever Microsoft do, Google have shown the way forward, their desktop search makes your desktop just one more search tab. It brings your desktop to the web rather than the web to the desktop and this seems like a much more logical UI experience.”
Maybe. I’m not sure I totally disagree with that point, given Google’s dominance of web search. But one thing I do believe is that a native application user interface always has the potential to be better than a web-based one. If you buy into that opinion, it means that we aren’t done. In fact, it means Google’s monopoly as it currently exists is vulnerable.
Let’s take a step back. In general, there were three things that allowed web-based apps to win out in the late 90s:
- Ease of development. Building interfaces in HTML is fast and very flexible.
- Speed and storage. Fast databases, lots of memory, and load-balanced web servers.
- Cross-platform. New companies put their resources on web-based apps instead of traditional ones. (Also see Joel Spolsky’s “How Microsoft Lost the API War”.)
Native apps can’t compete on those points. Instead, they can win with thoughtful interfaces constructed to fit on the platform alongside other native apps. As an example, lately I’ve been using Ranchero Software’s MarsEdit for weblog writing, and it’s a huge step forward from the Movable Type web interface. And that’s not because the Movable Type interface is particularly bad (it’s actually slightly above average). It’s just that a web-based app, even running locally, is a black box that cannot play nice with the rest of the system.
Tim O’Reilly likes to talk about how little apps such as Apple’s Address Book and iChat provide base features that other apps can build upon (a Friendster-like social app should hook into your buddy list). That kind of integration is difficult with web-based apps because user data tends to be stored locally, and if published to the web, it could be to one of any number of services. Instead of two platforms (Mac OS X and Windows), you may have dozens of individual web-based platforms (Yahoo!, MSN, AOL, Friendster, Mapquest, Fandango, and more). Those services are designed to take your data and keep it; there is not likely to be a standard API to share information between them anytime soon.
The potential of a native app is even stronger in this era of web services. Web developers are going back to their roots, building REST design into their applications from the ground app instead of exposing complex SOAP calls on the top as an afterthought. A recent example of this is Del.icio.us, it’s API, and the still-evolving Cocoalicious client, which already has hooks from PulpFiction and NetNewsWire. Another example is 1001, a Flickr client.
To bring this back to search, Google rose to the top because they were fast, accurate, and valued the user enough to know when to get out of his or her way. Google is still all of those things, because they had unique leadership that recognized those strengths from the very beginning.
So why, especially given Google’s strong brand, are there still new competitors investing in search? Because there is room for improvement. Users will move to new applications for the same reason they moved to the iPod: it was that much better. Snap adds sorting, for example. Teoma added a refine feature.
But unfortunately for the competition, they are trying to do things that are simply best left for outside the browser. Gmail was widely acknowledged as a breakthrough app that could hold it’s own against native email apps, but that’s only because native email apps are so notoriously bad. With the limited number of emails most people have, the “speed and storage” advantage of most web applications was not a critical factor.
Enter Apple’s spotlight technology. It integrates with the Finder or any application that wants to play. It’s extensible by third-party developers to accommodate file types that Apple does not support out of the box (this was a quick complaint from Dave Winer about Google Desktop Search). It has a fast, polished user interface that is built around finding local files and dealing with their metadata in an appropriate way. It’s just better.
This won’t be the first time Apple has stepped into search and metadata (remember R.V. Guha’s MCF and the HotSauce fly-through browser? Remember Sherlock?). But it will be the first time it’s really clicked in the UI.
As Wes Felter said: “If I just had the Web browser UI I would feel totally crippled.”
And at some level, Google gets this fully. Take for example their Picasa photo application. Or the Google Deskbar.
Don park sees the problem in terms of metadata and less about user interface:
“The core problem here is that search engines like Google throws everything into one pot. For web search, all the web pages on the Net gets thrown into that pot. Thankfully, hyperlink-based pageranking pulls the good stuff to surface with minimal hassle. With desktop search, all of your documents gets thrown into the pot without an equivalent of page ranking to measure relevance. IMHO, there aren’t enough metadata on the desktop to achieve the same level of utility Google web search offers.”
More to the point, Dan Wood commented on the accidental integration between Watson and Delicious Library:
“In fact, I recently read that Watson’s Amazon.com tool integrates quite nicely with Delicious Library via drag and drop. A lot of this has to do with the support we had put into Watson for integrating with other applications, including your browser and Spring. If Delicious Library hooks up with PriceGrabber, we may find similar compatibility between the two applications as well, either through luck or through design.”
Two simple things made this possible: Apple providing a recommendation for how drag-and-drop of URLs should work, and the REST-style URLs of a traditional web app like Amazon.
A final conclusion, to a post that’s already too long. Newsfire is a lightweight news reader with a clean interface that is a hybrid of native controls and HTML, backed by useful metadata (RSS). And Delicious Library is more than a book catalog app, it’s an Amazon UI stripped to just the essentials. Both these applications are at the peak of a shift that has been a couple years in the making — the convergence of web services, post-iTunes UI design, and system services such as Address Book, drag-and-drop, and metadata. Future apps will be judged by these standards.
