我知道"业务应用程序"有点宽泛，请允许我缩小一下范围：

例如，假设我们正在开发一套会计工具。搜索要求通常涉及帐号，用户名，街道地址，欠款额等。

是实现"搜索引擎样式"的单个文本框搜索的首选选项，还是应该使用与我的应用程序中的每个工具相关的特定搜索查询？

解决方案

为什么不。现在，QuickBooks会计软件包已与Google集成捆绑在一起。我们可以立即从供应商或者客户记录中调出Google地图。

如果要将这些参数中的几个组合到一个查询中(即"我希望所有帐户都欠此金额，但不欠这些帐户号")，则创建"参数选择器"更有意义。另一种选择是，用户必须写一些"欠款> 100，而不是帐户134141"。否则，如果我们要进行简单而快速的搜索，那么从用户体验的角度来看，仅Google样式的文本字段就可以很好地工作。

我们也可以考虑根据要搜索的字段，根据当前可用数据预填充参数选择器。这样，当我们搜索所有帐户类型时，例如，选择器中唯一可用的内容实际上是数据库中的内容。

对于基于数据的应用程序，自然路径是基于数据的搜索。

基于单词及其关联的文本搜索与基于数据的搜索有很大的不同。很难构建一个有效且对基于数据的应用程序有用的"谷歌风格"搜索功能。

但是，如果我们可以正确构建它，那么"谷歌风格"搜索功能将感觉非常自然和强大。

更高的成本，更高的收益。

我在大型系统上进行全系统搜索时发现的主要问题是遵循有关可见性的所有规则。

例如，仅看到应付账款而不是HR的用户不应获得某些搜索结果，而控制者应获得一切。

即使在内部用户使用与外部用户相同的工具的相对简单的购买系统中，某些内部用户可能也无法搜索未得到主管批准的产品，但可以看到某些外部用户无法搜索的停产产品。

我可以肯定地说，如今，它正越来越成为一种期望的用户体验，并且它是一种易于理解的，易于理解的范例。

嗨，吉姆，我为自己编写的应用程序开发了"谷歌风格"搜索，并选择了该方法，这是因为它几乎是任何在线用户都知道的。我喜欢它，因为它比我设计的替代方案更容易清洁。

我喜欢单一文本框搜索的一件事是UI干净，如果我们需要在以后搜索新内容，则可以避免完全修改View。我们可能需要做更多(或者很多)工作，但是谁真正在乎编码的难度呢？一般来说，用户不会。我喜欢简单的搜索，单一文本框方法将对我有吸引力。无论如何，这是我的看法。

我认为答案取决于最终用户。如果受众特征比较年轻，那么他们可能会更习惯于仅用一个框构成自己的搜索查询的Google样式搜索。但是，如果受众特征比较老，则可能习惯于每个搜索选项(帐户编号，地址等)都有一个单独的字段。

也许有一个中间立场，那就是我们可以在一个搜索框中添加一个下拉列表，以查找可能要搜索的字段。我们可以在搜索框中输入" account：0123456789"，也可以从下拉菜单" account"中进行选择，然后弹出式窗口会询问要搜索的帐号。一旦他们在文本框中输入" 0123456789"，它将在搜索框中添加" account：0123456789"。如果用户不习惯正确的搜索语法，则可以将其调整为正确的搜索语法。

如果我们可以使搜索足够聪明以从搜索词中得出上下文，那么我认为任何将选项从用户手中夺走的界面都将更加有用。

这取决于精确用例，但是我最近使用过多次的一种模式是单个搜索字段，并结合一些可选参数以在需要时缩小搜索范围。搜索将尽力得出上下文，但是用户仍然可以说"我正在寻找帐号"。

我们可以滑动界面以隐藏这些选项(在某种"高级"面板中)和/或者记住用户的首选项(不是使用配置设置，而是基于其实际使用情况，因此如果用户使用高级选项，则默认可见)。

在很大程度上取决于用户。除非他们是技术用户，否则请选择Google。如果这意味着复杂且难以使用，则大多数用户不希望其功能强大。他们想要简单有效。如果我们必须培训人们使用它，他们不会。

如果我们选择Google路线，并且有足够的资源/时间可以节省时间，请尝试通过使其能够识别常见模式来使搜索变得智能。帐号，地址，美元价值等。Google会进行这种模式匹配。键入咖啡斯普林菲尔德，麻将它命名为"斯普林菲尔德，麻"是一个城镇名称，并在搜索的上下文中返回所有可以在斯普林菲尔德站立的星巴克。

我会说..花一些时间研究用户如何在应用程序上下文中实际使用搜索。

• 例如，如果有一棵巨大的树具有巨大的嵌套层次结构，并且用户花了80％的时间从那里开始。可以快速输入一些字符并快速找到该节点，而无需记住该节点的整个路径。
• 另一方面，如果搜索框只是混乱的用户界面，并且在典型情况下没有太多信息可筛选。

因此，搜索标签.. google style searchbox很好。如果我们有多个用户要搜索的位置，请在右上角的搜索栏中插入(如浏览器)，并确保它始终与活动/上次使用的窗口一起使用。
但是，如果我们有复杂的查询，并且必须始终显示活动过滤器(以使用户知道上下文)，那么我们需要更大的内容。

为什么不为两者提供选择？我敢肯定，在某些情况下，其中一种可能是合适的。

提供特定/字段驱动的搜索选项(例如，将使用传统的SQL匹配)和Google样式的选项(将使用全文本搜索功能运行)。我相信顾客会很感激的。

如果我们不确定这样做是否值得，请坚持使用旧的领域驱动方法。

真的要看使用单个文本框样式，我们将需要解析输入并基于该输入开始搜索。例如，如果所有帐号的长度均为8，发票，12等，则检查输入，如果所有帐号和长度为8，则执行对帐号的搜索...等等。

这有点像混合控件...我要做的是在带有选项的文本框前添加一个组合框，然后用户选择"发票"，然后输入发票号...更多的用户友好界面，但我的一些同龄人说这是额外的点击。

应该有可选的复选框来缩小搜索范围。当我输入一本书的完整确切标题并获得5页结果时，我的公共图书馆的系统确实让我感到恼火。我需要选中"搜索书名"框。

Google可以很简单，因为它们确实很聪明。除非我们可以正确地排序结果，否则我们不会用简单的文本框使用户满意。我们必须查看常见的用例，并真正弄清楚是否可以根据要拥有的输入维数构造算法。