选择选项卡栏项目后激活 UISearchBar - 帮助还是阻碍?

发布于 2024-08-03 18:08:16 字数 1930 浏览 5 评论 0原文

我正在开发一个应用程序,要求我将 UITabBarItem 添加到我们应用程序的 标签栏拥有自己的专用搜索功能。这是对整个应用程序中已有的内置搜索的补充(通过点击其他 UITabBarItem 并搜索其他 UITableView)。

现在,我首先想到的是 Apple 人机界面指南 (HIG),其中规定:

“避免使用选项卡进行搜索,除非 这是您的主要功能 应用程序应具有以下特点: 独特的模式。”

。尽管如此,我还是向客户提出了这一点。他们回答说:“我们担心人们不知道要寻找搜索在其他 UITabBarItemUITableView 中。” 我的回答:“Apple 自己的应用程序提供了这种搜索体验。任何已经使用过这些应用程序的人都会知道如何使用您的应用程序。这就是为什么我们希望 UE 保持一致并努力遵循 HIG。”(更不用说这是应用程序商店批准的要求,但我离题了。)

好吧..他们的第二个回应是:“好的,这是有道理的,但我们也希望人们能够搜索所有内容,而不仅仅是不同表格视图中的特定主题。”

很好。全局搜索。:)

寻找专用搜索的示例UITabBarItem,我遵循 iPhone 自己的 App Store 模型,我对最终的 UI 非常满意。在 UISearchBar 中输入内容时,您会得到一个简单的纯文本搜索。 - 输入时建议名称列表(以最短的输入时间延迟完成,以免压垮搜索服务器)您可以调整搜索文本,点击要使用的建议之一来代替您的搜索词,或者。只需直接点击“搜索”按钮,结果列表就会被替换为一组更精美的结果,以更全文的方式进行搜索,每个单元格中都有图标和有用的元数据。通常的成分。点击UISearchBar会返回纯文本建议。取消搜索会删除所有内容。不理会它会保留最后一个查询(结果列表)可用于显示。

所以我向客户展示了这个这个...并且...他们喜欢它!他们只有最后一个请求:“当我们选择专用搜索UITabBarItem时,键盘是否可以立即弹出?现在我们必须点击UISearchBar,但这也只是一击许多。”

(大概他们希望只有在没有预先存在的搜索的情况下才会发生这种情况。)

起初我认为这是合理的......但后来我查看了其他应用程序。我找不到任何可以做到这一点的。即使是 App Store 应用程序也要求您点击 UISearchBar 来调出键盘。另外,HIG 也说了同样的话:

“当用户点击搜索栏时, 键盘出现。”

不是“当用户点击搜索 UITabBarItem 时,键盘出现。”

此外,UI 应该是宽容的。如果您犯了一个错误并打算在 UITabBarItem 中选择另一个项目怎么办? strong>更多列表?(或者如果它在标签栏上,如果您想选择不同的UITabBarItem怎么办?)现在您必须停止并取消 em> 关闭键盘的搜索,尽管你并不是有意提起它。

总之,我有点困惑,希望了解最佳实践和其他 POV。 >你在这种情况下会做什么?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

心房敞 2024-08-10 18:08:16

有人刚刚给我发了一个有趣的想法。如果您点击并按住搜索选项的时间比平时长一点,或者双击它,这可能是我们自动调出键盘的提示。除此之外,它的行为方式与 iPhone UI 生态系统的其他部分相同。

只要能够检测到 UITabBarItemUITableViewCell 的点击并瞬时按住或双击,这听起来似乎是合理的。 iPhone 相当于按住 Option 或 Cmd。

还有一个建议:如果“搜索”选项位于更多列表中,请调出键盘。如果它位于标签栏右侧(因为用户将其放在那里),则首先不要显示键盘。 (嗯。这似乎有点不一致,但我在这里提到它是为了完整性。)

想法?

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?

无远思近则忧 2024-08-10 18:08:16

一些答案,大多忽略您是否应该实际执行此操作:

您可以通过将搜索字段设置为第一响应者来自动显示键盘:

[mySearchField becomeFirstResponder];

选项卡栏上可以拥有的最多项目是五个,如果您有更多项目超过 5 个时,您实际上只会得到 4 个,因为“更多”项占用了一个空间。 items 属性的 UITabBar 文档指出:

选项卡栏上可见的项目(UITabBarItem 的实例)按照它们在此数组中出现的顺序排列。

因此,您可以像这样确定搜索项是否在栏中(而不是“更多”部分)(代码假设它位于搜索视图控制器中):

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

我个人认为,当您首先转到搜索页面,因为这就是您要做的全部事情。当然,问题是,如果您只是单击随机内容来查看它的作用,那么取消搜索以便您可以恢复随机单击会很痛苦。

编辑:该死,我误读了你的问题 - 我以为你在寻找技术建议。嗯...这可能对某人有用!

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!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文