I’m a neat person, but I’ve always had a cluttered desk. Growing up, my mother would frequently remind me to make it neat and tidy.
Not much has changed, except now my desk has less room for paper clutter as much of it is taken up by dual monitors and various gadgets. My clutter has taken on digital forms as a disorganized file system and a giant, flat inbox.
As a knowledge worker, I’ve spent years amassing information in digital form. I don’t like to delete anything even remotely useful, lest I find a need for it in the future. Cheap disk space has encouraged this proclivity, so now, I have gigabytes of files and email.
Years ago, I used to keep my inbox and file system organized. Creating folders for projects and incessantly filing emails and files. This created a sense of accomplishment, like Paul’s empty inbox theory, but inevitably, the goal of neatness overwhelmed the usefulness of filing. I found myself wasting time deciding on where to file an email, just to reach that empty inbox goal.
So, several years ago, I abandoned filing and went with a flat inbox, which is now around 25,000 emails. I still file documents, but only in the biggest buckets I can manage. Now, my biggest challenge is search.
The only reason to file objects is to expedite recovering them when needed. Search used to be so rudimentary that finding emails or documents took forever, if it worked at all. Fast forward to the present, and Google has raised the search ante for all things digital.
For me, search should replace organization. My ability to find something is only as good as my memory of where I put it. Search needs to augment my memory.
As information proliferates, knowledge workers waste more time trying to find it. If you’re paid to analyze information, but you spend more time collecting information, you’ve got a problem.
The problem for search is that it’s as attractive as a bag of hammers. Very few application designers think about search first, trust me, and this is primarily because users don’t see search as a requirement. So, search gets bolted at the end of the design process.
Google designs some of its products with search in mind, e.g. GMail’s threading makes it so much easier to find related mail without even using a search box. This is an example of building search into the product as a core requirement. Interestingly, Paul Buchheit, the first developer on GMail, is one of the founders of early adopter darling FriendFeed, which launched without any search at all. They added it recenlty, leading me to wonder about the design process.
You’d think Google would have the whole “search as a core requirement” piece down by now, but why then did it take so long to get search in Google Reader?
I’ve come to think that after you have a product idea that your focus should be: 1) on making the UI simple, fast and optimally functional and 2) on fast search and recovery of objects. All the other stuff should work within those design paradigms.
The single search box has become the paradigm for all search, thanks to Google, even if it’s not always the best way to find objects within a product. Take GMail for example. If I remember correctly, GMail didn’t initially have a search box, but it’s always has the threading feature. I wonder if they bolted on the search box later. Users have come to expect a single search box
Good search is awesome. I use the search in Reader all the time to find old content, and FriendFeed’s search is equally useful. I use Google Desktop to search my mail and files on Windows and Apple’s Spotlight for this on Mac. All of these are effective instances of the good old search box.
By the way, I know building products is hard. I do that for a living.
So, after a rambling post, what do you think about search as a design principle?