views:

765

answers:

2

I'm working on an app where I've been asked to add a UITabBarItem to our app's Tab Bar with its own dedicated Search function. This is in addition to the built-in searches already throughout the app (by tapping other UITabBarItems and searching other UITableViews).

Now, the first thing that comes to mind is the Apple Human Interface Guidelines (HIG), which states:

"Avoid using a tab for search unless it is a primary function in your application that should be featured as a distinct mode."

So the prevailing thought is to avoid, but it's not a hard and fast rule. Still, I brought this to the client's attention. They responded: "We're concerned that folks won't know to look for search in those other UITabBarItems and UITableViews." My answer: "Apple's own apps offer this kind of search experience. Anyone who already uses those apps will know how to use yours. That's why we want the UE to be consistent and strive to follow the HIG." (Not to mention it's a requirement for app store approval, but I digress.)

Well .. their second response was: "OK, that makes sense, but we also want folks to be able to search across all content, not just in particular topics within the different table views."

Very well. Global search it is. :)

Looking for an example with a dedicated search UITabBarItem, I followed the iPhone's own App Store model. I'm very pleased with the resultant UI. When typing in the UISearchBar, you get a simple text-only, search-as-you-type suggestion list of names (complete with a minimal typing time delay so as to not overwhelm the search server). You can adjust the search text, tap one of the suggestions to use in place of your search term, or just tap the Search button outright. The result list is then replaced with a fancier set of results, searched for in a more full-text fashion, with icons and bits of helpful metadata in each cell. The usual ingredients. Tapping the UISearchBar brings back the text-only suggestions. Canceling search removes everything. Leaving it alone keeps the last query (result list) available for display.

So I presented this to the client ... and ... they love it!! They only have one last request: "Can the keyboard pop up immediately when we pick the dedicated Search UITabBarItem? Right now we have to tap the UISearchBar, but that's one tap too many."

(Presumably they'd want this to happen only if no pre-existing search is in play.)

At first I thought this was plausible ... but then I looked at other apps. I couldn't find any that do this. Even the App Store app requires that you tap the UISearchBar to bring up the keyboard. Plus, the HIG says as much:

"When the user taps a search bar, a keyboard appears."

Not "when the user taps a search UITabBarItem, a keyboard appears."

Furthermore, UIs are supposed to be forgiving. What if you made a mistake and meant to pick another item in the More list? (Or if it was on the tab bar proper, what if you meant to pick a different UITabBarItem?) Now you have to stop and cancel the search to dismiss the keyboard, even though you didn't mean to bring it up.

In conclusion, I'm a bit torn, and wish to get an idea of best practices and other POVs out there. What would you do in this situation?

A: 

Someone just IM'ed me with an interesting idea. If you were to tap-and-hold the search option for just a wee bit longer than usual, or if you double-tapped it, that could be our cue to bring up the keyboard automagically. Otherwise, it behaves the same way as the rest of the iPhone UI ecosystem.

So long as it's possible to detect a tap-and-momentary-hold or double-tap of a UITabBarItem and UITableViewCell, it sounds plausible. The iPhone equivalent of holding down Option or Cmd.

Yet another suggestion: If the Search option is in the More list, bring up the keyboard. If it's on the Tab Bar proper (because the user put it there), do not show the keyboard at first. (Hmm. That seems a bit inconsistent, but I'm mentioning it here for completeness.)

Thoughts?

Joe D'Andrea
Argument against tap-and-hold: Already used for edit toggling in table views. Argument against double-tap: Can't subclass or use a category in the moreNavigationController's table view, since it's out-of-reach. So either we diverge from what Apple does with the App Store's search UE, or we stay consistent.
Joe D'Andrea
A: 

A few answers, mostly ignoring whether you should actually do this or not:

You can make the keyboard appear automatically by setting the search field as the first responder:

[mySearchField becomeFirstResponder];

The most items you can have on a tab bar is five, and if you have more than five you actually only get four, since the More item takes up a space. The UITabBar documentation for the items property states:

The items, instances of UITabBarItem, that are visible on the tab bar in the order they appear in this array.

Therefore, you can determine if the search item is in the bar (rather than the More section) like this (code assumes it's in the search view controller):

UITabBarItem *item = [self tabBarItem];
NSInteger indexOfTabBarItem = [[tabBar items] indexOfObject:item];
BOOL isInMainTabBar = (indexOfTabBarItem > -1) && (indexOfTabBarItem < 4);

I personally think that it isn't too bad to show the keyboard automatically when you first go to the search page, since that's all you're going to do. Of course, the problem is that if you're just clicking on random stuff to see what it does, it's a pain to cancel the search so you can resume your random clicking.

Edit: Damnit, I misread your question - I thought you were looking for technical advice. Well... this might be useful to someone!

iKenndac
Thanks! Yup, from a technical POV, I'm covered, but it's great to see that your advice matches up. Plus, others reading this might not know, so it's appreciated regardless! Part of me wants to avoid confusing the ecosystem already in place, but another part understands the desire to have that keyboard show up. (See my answer about double-tapping as an alternative ... only how do you do that in the moreNavigationController of a UITabBar? Can't subclass, and can't use categories!)
Joe D'Andrea