My friend Zack noticed something "interesting" about TT's autocomplete function today. I think his words were, "Does this prioritize cards in Standard?" or something like that. In a sense, yes. A good search function should be able to predict what you're looking for and deliver the most relevant results.

Towards that end, the first optimization (the one Zack noticed) was to return search results sorted by the card's release date. When you query "Temple Garden", it's more probable that you are interested in the RTR version than the original. But what happens when you just type the word Temple? Your first result is Temple Garden (RTR) but the second was a lame-ass uncommon from Portal 2. The original RAV Temple Garden was way down the list, below cards that 99.99% of the population has never even heard of.

As a result of this minor annoyance, I tweaked the autocomplete's sorting function to prioritize cards by rarity, only using recency as a tie-breaker. Thus, when you search for "Temple", you'll see the first three results are Temple Garden (RTR), Temple Bell (M11) and Temple Garden (RAV). Much better than before.

I'm not shy to admit that I'm more than a little bit obsessive about user experience.

Taking a play out of Google's playbook, I've spent a non-zero amount of time figuring out how to prioritize search results in the autocomplete. My #1 goal with TT was to make it fast. Damned fast, especially on mobile devices. So far, so good. The first problem most sites have is they load way too much stuff. I think the technical term is "cruft". I'm constantly trying to remove elements, not add them. That keeps load times at a minimum.

The real enemy is at your fingertips, literally. The mouse click (or finger-tap on touch screens) is the single most time-consuming action after the page-load. I measure the efficiency of the software by the number of taps it takes to achieve a specific goal. In the instance of search, there's an easy way to solve that.

Get smarter.

Each letter a user must type to get the search result adds both time and potential error to the process. Reducing the number of letters the user needs to type can dramatically increase lookup time. The above improvements to autocomplete result matching should reduce the number of key presses by quite a few.

The shortest Magic card name I could find was 3 characters, Opt, and after 3 characters the universe of candidate results has been narrowed down dramatically from the ~15,000 unfiltered names. In such a limited world of options, a few smart (and dynamically-learning) filters should be able to predict, with a high degree of accuracy, which card you're searching for with as few letters as possible.

Rarity and recency are the two most obvious ways to filter results by relevance. A more advanced idea might be to use historical search volume (with a decaying recency-of-search weight) as well. This idea patches a major hole in the current algorithm. Cards like Force of Will, which are very old, and only Uncommon, will display far below a totally irrelevant card like Force of Nature. Of all cards beginning with the letters "For", Force of Will is likely the most important. Unfortunately "Forest" shows up first. Perhaps that might be a good tweak to make after all 🙂

UPDATE: Tuned the algorithm a bit more. NOW try searching "Force". Heck, try searching "For". See what card crops up first.

[insiderCard gid='4747' f='0']