This is the third post about filtering. In this post we will look at different kinds of filtering.
Filtering is usually a good way to help people work with large data sets and depending on the kind of data and the goal there are at least the following kinds of filtering:
Indexing such as tag clouds or alphanumeric filtering can be used as a simple way for people to narrow down the data set to a more manageable chunk and to help people focus on what they are interested in. Indexing is defined as only allowing you to filter by one tag/letter and is only really useful if people already know something about the data or what the tag/indexer means.
Multiple Tag Filtering
In Multiple Tag filtering you get to select more than one tag to narrow down the result set. Del.icio.us provides a great example of this kind of filtering:
There is always an implied AND between the tags meaning that only results that have all the chosen tags will be shown. Del.icio.us implementation where you can remove any tag from your filter lends itself well to exploration of the data. In the above example for instance you could remove ‘ux’ and the explore what other topics there are articles about.
Faceted navigation is one of my own personal favorite kinds of filtering because it encourages exploration and does not require you to know the data very well beforehand. To get faceted search to work it is crucial that the facets are only showing existing data i.e. if you are searching for MP3 players the price ranges should be derived from the actual price ranges and not let you select $1000 when the top price is under $500 (yes, seriously, $500).
Though it is a best practice to only show criteria that will lead to results you could get faceted search to work with links to empty results as long as you can predict the possible links. In other words, if you know that the display size for MP3 players come in 1.0”, 1.8”, 1.9” and so on and you don’t currently have any with 1.9” in stock you could still include the link and let people save that query as an agent, but you should not include 1.1”, 1.2” and so on, just because that is the logical numbering. In other words you should never allow people to get to a meaningless query.
The strength of faceted navigation is also its weakness. In domains where you don’t know the possible data values which is often the case in for instance computer management, you need a way to allow people to search for possible rather than actual values.
Attribute Based Filtering
Attribute Based Filtering is in its raw form really easy to program, because it really just exposes the database, and is hence seen in way too many applications. It is also really hard to make usable because it normally requires people to not only know the data but also understand AND, OR, and groupings. Having seen enough Development Mangers get Boolean queries wrong in Microsoft’s bug database has let me to believe that there really is no reason to expose the horrors of Boolean logic to anyone but maybe programmers.
Interestingly attribute based filtering is the defacto standard way of making auto playlists in all the media players I have used. In many ways, I think this is a bit lazy and that those applications should really work towards faceted navigation based on your music collection. When I say ‘lazy’ it is because faceted navigation not only requires a design, but also that the application constantly monitors the data set and creates the facets. That requires a lot of programming.
From a design perspective, making faceted navigation work also requires a way to OR criteria together that is typically absent i.e. Artist is Dire Straits OR Mark Knopfler. Normally you would only be able to pick one facet from each category but to get playlist to be really valuable you want to be able to pick more than one genre or artist.
Rule Based Filtering
Rule Based filtering is best known from Microsoft Outlook and is a way of making attribute based filtering easier. Essentially rules are pre-made queries where people are only asked to fill out the operands.
If you for instance create a rule like: “with specific words in the subject” this gets translated to “with Word1 OR Word2 or Wordn in the subject” which means you cannot change the logic, the attributes or the operators.
Rule based filtering is both usable and powerful because it takes away much of the complexity of writing queries by pre-packaging the most likely used queries in the right format and can cover a large set of different cases. There will however always be cases that the pre-canned rules do not cover and for that you typically need attribute based queries.
Next we will dive into some existing implementations of attribute based filtering.