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?
Best Answer
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?