What Makes a Good Autocomplete?
A thoughtful discussion about what to consider for an optimal autocomplete ...
"We've been working on a problem for the past couple of weeks: an optimal autocomplete algorithm.
Many of our users have said that while Enso is great, it requires a bit too much typing. We're inclined to agree. Yet, figuring out the best solution is tricky: there are more autocomplete algorithms than bones in a school of lionfish. There are straightforward algorithms, too-clever-for-their-own-good algorithms, standard command-line-style autocomplete algorithms, and the list goes on. A lot of the algorithms seem to go down fairly easily when you first start playing with them, but they end up getting stuck in your throat due to some unforeseen edge-case. This post explains our thought process in evaluating the algorithms given the (g)astronomical number of possibilities.
The Problem
Let's start by defining the problem. Autocomplete asks the question of how ones maps a series of user keystrokes to one command name among a thousand possibilities.
Enso currently uses a slightly modified version of the "Obvious Solution". The obvious solution requires that the keystrokes entered match the beginning of the command name, then picks the alphabetically first among all such command names. This is exactly what the Windows command prompt uses (at least the NT prompt; the old DOS prompt doesn't have this autocomplete feature). Other systems use variations of this; most URL bars, for instance, require that what is typed be the beginning of some URL (not including the http:// bit). Enso improves on the obvious solution by allowing the user to entirely skip words during entry. Thus, Enso lets "open firefox" complete to "open mozilla firefox".
Unfortunately, this solution has much more typing than necessary. In Enso, typing "open " before typing the name of the application is frustrating; especially since there are keystroke launchers out there that don't have any such requirement. However, Enso can do a whole lot more than launching — and in the future Enso will do vastly more than it does today — so we can't simply drop the prefix. The prefix is what makes it clear that the user is launching something rather than any of the hundred other things they could possibility be doing (like printing it, deleting it, compressing it, or sending it as an attachment). The number of commands that Enso might have is just too large to eliminate the need for verb prefixes and structured name spaces.
So we come to the question: how can we implement an autocomplete solution that allows Enso users to use fewer keystrokes, without losing the memorability of semantic language that makes Enso powerful?" (Continued via Humanized) [Usability Resources]
"We've been working on a problem for the past couple of weeks: an optimal autocomplete algorithm.
Many of our users have said that while Enso is great, it requires a bit too much typing. We're inclined to agree. Yet, figuring out the best solution is tricky: there are more autocomplete algorithms than bones in a school of lionfish. There are straightforward algorithms, too-clever-for-their-own-good algorithms, standard command-line-style autocomplete algorithms, and the list goes on. A lot of the algorithms seem to go down fairly easily when you first start playing with them, but they end up getting stuck in your throat due to some unforeseen edge-case. This post explains our thought process in evaluating the algorithms given the (g)astronomical number of possibilities.
The Problem
Let's start by defining the problem. Autocomplete asks the question of how ones maps a series of user keystrokes to one command name among a thousand possibilities.
Enso currently uses a slightly modified version of the "Obvious Solution". The obvious solution requires that the keystrokes entered match the beginning of the command name, then picks the alphabetically first among all such command names. This is exactly what the Windows command prompt uses (at least the NT prompt; the old DOS prompt doesn't have this autocomplete feature). Other systems use variations of this; most URL bars, for instance, require that what is typed be the beginning of some URL (not including the http:// bit). Enso improves on the obvious solution by allowing the user to entirely skip words during entry. Thus, Enso lets "open firefox" complete to "open mozilla firefox".
Unfortunately, this solution has much more typing than necessary. In Enso, typing "open " before typing the name of the application is frustrating; especially since there are keystroke launchers out there that don't have any such requirement. However, Enso can do a whole lot more than launching — and in the future Enso will do vastly more than it does today — so we can't simply drop the prefix. The prefix is what makes it clear that the user is launching something rather than any of the hundred other things they could possibility be doing (like printing it, deleting it, compressing it, or sending it as an attachment). The number of commands that Enso might have is just too large to eliminate the need for verb prefixes and structured name spaces.
So we come to the question: how can we implement an autocomplete solution that allows Enso users to use fewer keystrokes, without losing the memorability of semantic language that makes Enso powerful?" (Continued via Humanized) [Usability Resources]
