When it came to adding a search feature to my iPhone application Harvest, I ended up choosing not to follow the usual (Apple exemplified) approach of placing a search bar above a table view and scrolling it with the content. This post explains this and other design decisions I made, even to the smallest detail, as I strived to create the most usable and polished search feature.

Providing a mechanism to search among a table view of items is a common element present in so many iPhone applications, in fact it’s almost unexpected to see a list of items without a way to filter through them. Even though the feature is generally the same across all of these applications, I feel it can be refined and highly polished through many seemingly minor details. I’d like to explain some of the characteristics which I put considerable thought into when designing Harvest’s search, ones I believe contribute significantly to the usability of the application.

One press away from a focused search field

As I mentioned above, I chose to deviate from the common search UI pattern of throwing a search bar on top of a table view, and scrolling it with the content as if it’s the first row. In many other applications, most significantly Apple’s own Contacts and iPod apps for instance, this is the approach.

I designed Harvest’s produce guide so that a focused search field, with the keyboard displayed and ready for input, will always be only one touch away. After all, if a user is searching, they want to find an item quickly.

 

Pressing the search icon, in the top right, from anywhere in the guide slides in a search bar and focuses the keyboard, all with one touch.

With the scrolling search bar approach, it becomes necessary to scroll all the way to the first row before touching again inside the search bar to start entering a query. Additionally, often times I’ve found myself having to tap multiple times to get the search field to focus, possibly because the scroll action was still causing the table content to bounce at the top boundary when I pressed the first time.

Even if the user is aware of the global iPhone shortcut of touching the status bar to scroll to the top, which I’m guessing many aren’t, it’s still a matter of two touches. With over 60 produce items in Harvest, I knew it is very more likely that the user will be somewhere other than at the top of the content.

Another consequence of scrolling the search bar is that when it moves out of view, there is no current on screen indication of the feature’s availability. Search is crucial in Harvest’s produce guide, and it is likely the standard way in which users will find themselves referencing items during daily use. I wanted it to always be evident that the feature exists and is readily available.

 

With a scrolling search bar, unless you are at the top of the table’s content, there is no search feature visible and accessible with one touch.

Having search always visible encourages the user to use it. Scrolling it offscreen makes it seem like a secondary, less important way to reference items. Leaving it visible at all times was my way of encouraging users to search, and in doing so I knew they’d find Harvest more practical to use frequently with every item they’re shopping for, making the overall experience in my application more satisfactory.

There’s nothing inherently incorrect about the scrolling search bar design, I just didn’t feel it was best for Harvest. The huge advantage of the approach is that saves screen real estate, while at the same time avoids requiring any further UI elements to access the search, such as a navigation button; you just scroll upwards.

I took advantage of the fact that I had a free right navigation bar button spot available. Offering a spotlight-like search button there, I was able to balance ease of access and feature visibility with screen real estate. I did not have to resort to taking away 44 points from the produce guide table view’s height, permanently displaying a search bar above the table view without scrolling it away, to achieve my design goals.

See all results without hiding the keyboard

Another portrayal of attention to detail when it comes to searching is to ensure that all results can be seen without dismissing the keyboard. By this I mean resizing the results table view when the keyboard is visible so that the user can scroll all the way to the bottom of the content (i.e. the last row appearing directly above the keyboard).

I’ve come across some applications in which the search results table view dimensions remained at the full-screen height even when the keyboard is displayed, so that the only way to see the bottom half of the table content was to dismiss the keyboard.

All search results should be accessible without having to dismiss the keyboard

Allowing the user to see all of the results enables them to further refine their search without having to call up the keyboard to do so.

Polish in the tiny details: The keyboard return key

I see two different modes of searching on the iPhone. The one used in Harvest, Contacts, and iPod, is actually better phrased as filtering. This mode shows results immediately, live as the user is entering or modifying the search query. The other mode of searching involves results that are not delivered immediately, but rather are obtained from a server after the query is sent out over a network connection. This latter approach is what you see in the App Store app.

Despite these two different modes, the keyboard displayed from a search bar always presents a return key labeled “Search.” When the search mode is a live filter, and results are already available, I view this button label as imprecise. There is no further searching action that will take place when pressing it, and button label verbs indicate that such an action will be performed when pressed. In a live filter, the search has already taken place and pressing search merely hides the keyboard, so the current results can be seen more visibly.

 

iPod and Harvest keyboard return buttons when searching (bottom right, in blue). In both apps, the search results are available instantly, making a button labeled “Search” seem odd.

Therefore, I aimed to relabel the button to better indicate the fact that pressing it will actually just get the keyboard out of the way. The “Done” key thus makes much more sense to me. The results are already there, so pressing “search” always felt backwards to me.

There’s no official supported way to customize the UIReturnKeyType of the search bar’s keyboard. The following block of code is my way of safely accomplishing this customization:

for (UIView *searchBarSubview in [searchBar subviews]) {
  if ([searchBarSubview conformsToProtocol:@protocol(UITextInputTraits)]) {
    @try {
      [(UITextField *)searchBarSubview setReturnKeyType:UIReturnKeyDone];
    }
    @catch (NSException * e) {
      // ignore exception
    }
  }
}

In the server-based search mode, the button labeled as “Search” does fit the behavior perfectly.

Conclusion

Through this writing, I wanted to demonstrate the attentiveness to detail that I strived to put into Harvest. One of the reasons I love developing for the iPhone and Mac platforms is that attention to detail is noticed, and even expected, by the users themselves. The best usability is expressed both in more obvious features, such as a persistently visible search, and minor ones as well such as resizing the results table view or changing a button label to better reflect its action.