This has been discussed a bit here: Building logical criteria (with AND , OR, etc) - but we felt the examples left a lot to be desired.

Apple (with their hidden nested rules/predicate builder) in iTunes and Mail came closest - but while it's great for putting a rule set together, I don't think it is easy to digest and easy to follow.

We experimented with how we can make a nested rules/clause set more readable and more obvious in terms of groupings and how they relate to each other.

Concept 1

We first tried a simple hierarchical rule set, with vertical bars to better show how the groups relate to each other and where the nestings are, rather than relying on indentation.

Concept 2

Then rather than using vertical bars, we tried using the indentation and displaying the actual logical relationships between each. We're not entire happy with this, because those AND and ORs seem to add a lot of visual noise.

Concept 3

Then we tried the best of both worlds; use of indentation and shading and the AND and ORs.

Concept 4

And then we took out the AND and ORs. This makes things less explicit, but we have a cleaner interface.

We are somewhat split on whether to include AND/ORs. On one hand we cannot be more explicit about the logic that will result from the rule set. On the other hand, AND and OR is not going to be intuitive to non-so-technical users.

Welcome your thoughts on that and the concepts.

  • 1
    While the 'And' and 'Or' may seem to add visual noice, the actually make it much clearer for me what is going on. Don't leave them out, but do de-emphasize them as in your third image. That one is actually going on my example's list! – Marjan Venema May 10 '13 at 10:49

Boolean logic is definitly not user oriented

For instance it is very hard to understand that :


download bmml source – Wireframes created with Balsamiq Mockups

You should reconsider your approach if you do not want confusion. I know you do not want confusion. The thing with nests is that they do not act like Venn diagrams. They are not visually self explanatory.

Does it have to be nested?

Basically what the user can do is search and filter.

  • Search: she wants this, this and this. What is hard to tell is if she wants this and also this and also this or this or maybe this or maybe this or maybe this.

  • Filter: within this search she does not want this, this and this.

Nested make it very hard to understand

Mamals that can Fly and Flying animals that are Mamals is the same things.

Within Animals that can Fly, Animals that can Swim and Animals that can walk, I want to find animals that are Hairy is the same thing as searching for Animals that are Hairy, that can Swim and animals that Hairy that can Fly

It makes the user overthink because of the multiple possibilities. Let the user search first and then filter.

Here an example from Google with lots of inputs and criterias, it could have been nested but its not:

enter image description here

As you can see:

Boolean [or] becomes [any of these words]

Boolean [and] becomes [all this words]

It makes much more sense.

You can use something like this in your interface:


download bmml source

  • 1
    Thanks for your comprehensive reply, Gildas. However, perhaps I missed out a bit of crucial information; this isn't just about search. In fact, in the example we are building for, we are creating 'business rules' in a helpdesk/CRM application - it is quite essential for the user to be able (using your example above) to say [Region = X OR Region = Y OR ...]. If this was for a simple search or filter, I would agree. – Jamie Edwards May 10 '13 at 12:36
  • 1
    I suspected that the answer was not going to fit the problem. It is worth trying though. You should really keep in mind that boolean logic is not familiar at all for most customers. – Gildas Frémont May 10 '13 at 13:07

I've struggled with this same problem with multiple projects across multiple domains, and I'm struggling with it again today (and I found your WONDERFUL breakdown of the problem!)

I really like your final solution direction - it's where I ended up too, so there's some validation there.

The one thing I've got in my solution that might help with your "and/or/any/all" text overload issue is something I discovered a few years ago when beating my head against this: AND/OR gates.

Logic Gates

So...lots going on there, and it's hyper-technical, but where it got us was thinking symbology for AND and OR.

So, the common symbols for AND and OR, aren't really "common" at all to your basic user. But that leaves you free to use the existing ones, or invent your own using these as inspiration. I've mocked up a little example using your screen. Something to consider.

sample and or with gate symbols


Thank you for your responses. We are going to adopt concept 4 in Kayako: Concept 4

We are going to limit the depth the 3 nested groups.

The reasons are:

  1. OR and AND (boolean terminology) causes our users to ask more questions then they actually answer (thank you to @gildas-fremont for the same insights)
  2. Everyone seemed comfortable with the 'Any of' and 'All of' terminology and what that meant for the proceeding criteria (the shading helped here)
  3. For our users' requirements (and our product's best practices), they shouldn't really be going beyond three nested groups anyway - so we're trying to save them from making a mess for the next person
  • We are facing the same issue, would be great to hear what users thought of this solution. Tnx! – YaDa Jul 2 '18 at 11:20
  • @YaDa sign up for a trial on Kayako.com and go to the admin area -> triggers -> add new. You can see it in action there. Feedback has generally been positive. – Jamie Edwards Jul 2 '18 at 14:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.