Bruce “Tog” Tognazzini on the difficult design decisions of search:
The Mail search for iOS is hopeless. You have to specify which folder the message is in. If I knew that, I probably could have just pawed through that particular folder and found it. Strangely, the Spotlight search at the Springboard level in the exact same iOS has no problem searching across all mail folders. Why should you have to know to avoid the built in search and, instead, leave Mail, go to the desktop, then to Spotlight, in order to look for an email? It makes no sense.
Search caused me an interesting problem with Instapaper. In the 3.0 app, I added a local search feature: it would search your articles, but only the ones that were downloaded into the app.
This was a terrible half-solution that I shouldn’t have shipped, because it didn’t match people’s expectations: most customers expected the search box to search everything in their account, regardless of what’s downloaded in the app at that moment. No amount of interface massaging or explanatory text would fix that.1
The only good fix2 was to replace it in Instapaper 4.0 with a search that worked properly: a server-side index that searched everything they’ve ever saved. Server-side search is expensive and I couldn’t afford to do it for everyone, so I limited it to the $1/month Subscribers, and provided the Subscription as an in-app purchase.
Most customers never used the local search in 3.0, so they didn’t notice the feature switch, but a few people have been very angry and very vocal about it. It’s by far the only widespread problem that 4.0 has caused me. I’ve gotten tons of 1-star reviews from the sliver of people that I’ve angered by “charging for a feature that used to be free”. They don’t realize (or don’t care) that it’s much better for many reasons now, and it’s really not “the same” feature at all.
To most customers, search is just expected to be there, and it’s expected to search everything all the time. They don’t realize and don’t care how much complexity is behind the scenes to make it happen. The best designs hide as much of that as possible and just present the customer with a single search box that works.
The local-only search sucked for a lot of other reasons, too. It doubled the size of the code, dramatically slowed down updates and launch times, and didn’t support any advanced linguistic processing or operators. ↩︎
I tried a hybrid approach that kept both local and server-side search, like Mail’s, but it sucked even more (…like Mail’s): the interface was awful and confusing, it still didn’t “just work” for most people, and the app still had to include and run all of the big, slow search code. ↩︎