How can we visually improve the nested rule/predicate builder?

Question

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.

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.

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.

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

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.

Answer 1

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:

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}

Answer 2

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.

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.

Answer 3

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

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