We are struggling with how to incorporate AND/OR logic amongst a list of filters in our user interface. I know this question has been asked many times, but I'm trying to fit the logic addition into an existing UI without making too many changes.

Here is what we currently have:

A user can build a chain of filters by selecting a filter from a list of filters, and then specifying a range or possible values for it. The user then sees their filter chain as follows: - Filter1 between 0 and 0.5 - Filter2 in (value1, value2, value3) - Filter3 not in (valueX, valueY) - Filter4 in (Present)

These filters are all AND-ed by default. Now, we want to support more complex logical operations amongst the filters, such as ((Filter1 OR Filter2) AND (Filter3 OR Filter4)).

The idea I've come up with is that most users might not use this advanced query functionality, and so this grouping operation should be hidden under an Advanced tab or modal. When the user builds their filter chain and sees the 4 filters, they can then click on 'Advanced', which will open up a query box for them with the 4 filter names preloaded (the box will only show Filter1, Filter2, Filter3, Filter4, without their constraints). The user will then be able to type around these text tokens to introduce (, ), AND, or OR, to group them in any way they like.

Is what I proposed intuitive at all? Are there sites that have already tackled this problem, and what solutions have they come up with? Thanks for all your help!

  • How advanced are your users? The compound ((F1 OR F2) AND (F3 OR F4)) statement is quite complex and boolean logic is not that intuitive to non-programmers. Are you sure you are not overbuilding this relative to the user base? The perspective would help me think about the design. – tohster Mar 3 '15 at 18:44
  • Sure. This is a bioinformatics application, and the user base is scientists, so they should be fairly comfortable with building such operations. That said, many of the users might not care to think through this and just with the basic filter chain operations. This would be advanced functionality for some of the users who want to build these chains differently. – PS376 Mar 3 '15 at 21:31

I would stop using the term filter as it means reduce.
Or is going to add.
Maybe refer to them as search terms (or search fields).

In advanced you need to open it up to a lot more than introduce tokens.
They may want to change the order of the terms.
They may want to use terms twice.

Many of the legal industry document products use this type of syntax.
It is loosely referred at as the Westlaw syntax.

It is easier to drop the between and let the user do Date1 >= 1/1/2000 and Date1 < 1/2/2000
The may even want an outside

Trust me start with a minimum number of operators

Need auto complete for field name and let them hit tab to just go through the list

When the come to an operator then let them auto complete and tab through operator

For a value parse it then - if they enter a date value that is not valid date then color is up and make them fix it there

A good syntax parser is a lot of work.
But it is very powerful.
That is how all or most of the databases do it Structured Query Language (SQL)

  • The fields as a whole would be filter. But you are right, each individual field does not filter (reduce). – slicedtoad Mar 3 '15 at 18:30
  • @slicedtoad Field as a whole is a search – paparazzo Mar 3 '15 at 18:36
  • If there were no filter/search functionality, you would expect to see all the data, no? – slicedtoad Mar 3 '15 at 18:40
  • @slicedtoad However you want to implement no/empty search conditions then do so. I call it a search - if you want to call it something else then fine. – paparazzo Mar 3 '15 at 18:45
