Transcending Search-as-You-Type Stickiness

Recently I have been working on a desktop application where searching is a core feature, and made an important step towards search-field nirvana. Lets take a brief moment to consider the hierarchy of search fields.

A Box and A Button

The lowest formof the search field is one we are extremely familiar with: a textfield and a button labeled搜索也许走！如果作者是特别敢于冒险when he created it.

此实现以几种方式失败。首先，它要求您使用键盘和鼠标进行搜索，从而减慢您的速度。其次，它不提供关于搜索质量的任何反馈。

四分之一的一步是相同的搜索字段，除了它创新允许您击中return而不是使用鼠标。

一个盒子，一个按钮, A History

踩着我们的游戏一个档次，我们可以给出我们的文本菲尔德某种历史。这让用户轻松返回以前的搜索，并帮助他们记住他们的搜索是什么，所以他们可以将它们改进到更好的东西 - 尽管你仍然有很难改善他们的搜索，因为你没有给他们快速的反馈。

一个神奇的盒子

将我们的游戏踩到一个档次，我们扔掉了按钮，而是实时将搜索结果显示为用户类型。这是一个重要的一步，因为它允许用户在响应返回的结果时快速地改进他们的查询并快速改进结果。

然而，在这个模型中出现了一个小缺陷。当搜索需要长于键入字母的时间时，此类搜索可能导致粘性或滞后的用户界面，其中键入的字母不会瞬间出现。

滞后可能会分散足以挑起这样的想法，就像“如果我刚刚让他们新闻怎么办？进入反而？这仍然很容易......“甚至甚至引起了一些可怜的灵魂来恢复悲惨一个盒子，一个按钮strategy.

好朋友，这不是结束。

一个神奇和滞后的 - 盒子

滞后问题有两个解决方案。首先，我们不会考虑，是要更快地进行搜索。第二个是延迟搜索，直到搜索变得可管理，或者用户慢速打字。

第二个是我认为成为制作不显着和有用的搜索框的关键。

为了帮助澄清，让我们想象我们正在使用这些特征搜索数据库（如果您在违反索引的情况下使用完整的文本模糊匹配搜索，此模式相对逼真 - Ala喜欢in SQLite--but even if these numbers were quite different, the discussed technique will still improve UI responsiveness).

Number of Characters	搜索秒数
1	0.5
2	0.3
3.	0.2
4.	0.1
> 4.	0.05

If you naively searched as you went, it would pause for 0.5 seconds after you typed the first character, 0.3 after the second (for a total of 0.8 seconds), 0.2 after typing the third (total 1.0 seconds) and so on.

相反，考虑这个策略：在键入一个字符之后，我们将在执行搜索前等待0.5秒。如果在此期间键入了第二个字符，则会使第一个搜索无效，然后开始第二个搜索的计时器（延迟0.3秒）。等等。

在这种情况下，它需要0.6秒（0.3等待+ 0.3的搜索）来执行2个字符的搜索（与Naive实现中的0.8相比），但仅执行0.2才能执行4个字符的搜索（1.1在Naive中）和0.1搜索大于四个字符（> = 1.15）。但是，如果用户慢下来，则搜索将通过并显示指导数据以帮助用户改进搜索。此外，一旦结果变得充分快速，我们可能会恢复到非延迟搜索的搜索原理策略，以确保UI指导用户尽可能地实现。

We can actually improve on this a bit, because it isn't necessary to wait for a full 0.5 seconds before performing a 1 character search, we simply need to wait a reasonable amount of time (a bit more time than it would take to type another character). If that amount of time was 0.2 seconds, then the time to search in the worst case (a one character search) improves from 1.0 seconds (in first non-naive implementation) to 0.7 seconds, while retaining the excellent performance in the normal (3+ characters) cases.

另一种类似的方法to averting lag, which isn't practical in all environments (especially in the browser), is to perform searches in a separate thread and update the results as the searches complete. This approach can theoretically have the best of both worlds (return data as soon as possible, with no user interface lag), but is the least trivial of the solutions to implement.

至于其“最小琐碎的”状态，考虑此方案：当您键入一个字符时，启动搜索线程（将需要0.5秒才能完成），然后在0.1秒内键入第二个字符（其将在0.3秒内完成）。或在第一个搜索线程完成之前0.1秒）。然后，您将首先显示两个字符搜索的结果，并稍后将通知您的一个字符搜索已完成的0.1秒。据推测，您可以通过拒绝在当前显示结果开始之前开始的更新来解决此问题 - 这只是一些额外的记录保存 - 但出现了其他问题。

其中一个问题是，根据您搜索的后端，您可能会导致所有搜索通过同时执行多个查询（最多N个同步查询，其中n是n是长度来执行更慢的搜索词）。您可以避免在创建新搜索时终止所有正在进行的搜索，但最终是我的经验，我使用上面详述的策略（非线性延迟开始搜索），您可以创建一个非常引人注目的用户界面体验，而无需复杂将搜索移动到单独的线程。

我的想法和改善我会更加好奇。