Filters

The two most common filters used in any UI are “Begins With” and “Contains” substring. However, both of these filters are non optimal because they tend to fail to find what the user wants in a few scenarios.

“Begins With”, is usually a very poor choice, it’s no doubt the fastest, but with the ease at which a search can be threaded in .Net and the number of cores on machines these days it’s really not a big plus. The filter itself only works well when users always know how the items they are looking for start, which is pretty rare.

“Contains”, is a much better choice but it fails to deal well with the situation where the string in question actually contains 3 or more unique words, the order of which is not known to the user or consistent. For example, lets say you have the following list of search-able strings:

LargeRedDragon01
LargeBlueDragon01
LargeOgre01
SmallOgre01
RedDragonCaptain01

Assume there’s hundreds more entities in this list, now using “Contains” the user could search for “Red” or “RedDragon” and will likely find the red dragons he is after. But what if the user wants to find all the large dragons? The “Contains” filter starts to fall down.

There’s always RegEx, but only your power users will use that and unless they do it often they may need to look-up a few things. This option would be good to have in a text editor, but a lot less useful for searching things like entity names, or properties or other fairly short multi-word strings.

You could use wildcard searches that just use ‘*’ to support for any number of characters separating two words, but this isn’t as natural of a filtering mechanism as I’d like.

So what would I do?

“Contains Ordered Characters”, instead of searching for a single substring, imagine attempting to match each character in order with an implied wildcard between every character.

So taking that same example again I could find the large dragons by just searching for LargeDragon, now you may ask, why is this that any better than “Large*Dragon”? Well it’s more natural, by which I mean I don’t need to be told about the existence of wildcard capability, I just enter LargeDragon expecting to find any and all large dragons, I don’t care if they are red or blue. It’s also valuable for things like intellisense where you don’t want your users entering characters that are not part of the standard syntax.

Another enhancement might be to treat capital letters as separators for searching for words. So in addition to matching a list of characters in order, you also match each word denoted by a capital letter inside the word you’re parsing in any order. This would solve problems with users who don’t know large comes before the color, so I could search LargeRedDragon or RedLargeDragon and still get the same result.

Now with a much more natural input style, the user is free to quickly add and remove characters to quickly filter, for example, I know there’s some large red dragons in the world, so I type, redrag or laredrag, which of course just looks like a mass of nonsense but it’s a more natural input mechanism for looking for red dragons or large red dragons, where with wild cards I would have had to type re_drag or la_re*drag to find what I’m looking for.