I have a design challenge for allowing users to create unions, intersections, and subtractions of groups. The end goal of this is to create a subset of the different group contents, which can be cumbersome for a user to decipher without a strong understanding of the system.

As challenging as it is for the user to read these strings, I have found it equally (if not more so) challenging to find a pattern that makes the interaction of a union, an intersection and/or a subtraction clear to the user.

Take, for example, the following.

  • The user "allows" two groups. The end result is a boolean "or" state: "allow the contents of P1 or P2".
  • The user "requires" a third, which is interpreted as a boolean "and": "allow the contents that are part of P1+P2 and P3".

enter image description here

There could be any number of groups added to either "allow" or "require", and one could be left blank as well.

Another option to the user is to "exclude" the contents of another group. Combing the example above with a 4th group, we end up with: "allow the contents that are part of P1+P2 and P3, minus those items in P4".

enter image description here

The combinations could be much simpler, or could group more complicated depending on the desired results.

The interactions between the groups is not building up a boolean logic set to a final "true" or "false" statement. The result of these interactions is a subset of P1, P2, P3 and P4 -- this could be nothing, something or a lot of somethings.

How can represent the construction of this complex interaction to users, allowing them to understand the final subset of items which results?

List Examples:

Some original wireframes I put together for discussion show the items in a list form. Language next to each grouping would need to indicate how the different items interact with each other.

enter image description here

An alternative to the above was to combine the "allow" and "require" lists, to make the the "require" a subset of the complete set.

enter image description here

  • possible duplicate of Intuitive interface for Composing Boolean Logic? – Vitaly Mijiritsky Apr 13 '15 at 18:37
  • @VitalyMijiritsky - not a duplicate in this case. This is not a rule builder of ifs/ands/buts, as your link describes. I actually have a boolean rule editor elsewhere in the GUI, and would have reused it if I could (am still thinking how I might). This is an interaction between groups. P2 is a group of items, and applying logic to it results in a combination/reduction of those items based on another set of items. This is not "if this, and this" - it is "what's in here, that's also in this, but not in this". – Nicholas Pappas Apr 13 '15 at 18:47
  • To be honest I don't really see the difference, but I'll retract the close vote in any case :). – Vitaly Mijiritsky Apr 13 '15 at 18:54
  • what's the content of the groups? – Alejandro Veltri Apr 13 '15 at 19:02
  • @VitalyMijiritsky - I am currently not seeing the overlap, which may be one of my hangups. As mentioned, I do have a boolean rule editor designed but just don't see it working here. If you have suggestions on how the break out of that, it would be appreciated. The lack of a "true/false" end result is (I think) a primary stumbling block for me. – Nicholas Pappas Apr 13 '15 at 19:06

The examples you give are all achievable using first order set logic without the need for nested operations.

They can be described using a form with 3 simple fields: form

Using this interface, the set operations you describe can be created as follows (click image to expand):

enter image description here

If you also need nested operations, this is also doable...leave a comment and I can sketch it out.

  • I've think about the same thing. Would you change colours of require tags (green) and exclude tags (red) to add scannability or you consider it counterproductive? PS: I'm glad you're participating in this community, the level of your answers is always really good!. – Alejandro Veltri Apr 13 '15 at 20:02
  • 1
    No nesting in this case (thank goodness). This isn't far from one of my wireframes. My hangup is the external memory load of all these groups, but I don't think it can be overcome as elegantly as I would like. – Nicholas Pappas Apr 13 '15 at 20:04
  • 1
    @rewobs - I think color would hinder. Color has meaning, even when we don't want it to. So a red require (for example) might imply "bad" to a particular user. – Nicholas Pappas Apr 13 '15 at 20:06
  • 1
    hi @rewobs i'd be inclined to keep the tag colors the same because there are only 3 fields in this approach, and sematically a tag might appear in any of the fields so it can be disorienting to users to see mammals in green in one field, and then have it change color to red when she moves it to another field. But this isn't something i feel strongly about. – tohster Apr 13 '15 at 20:06
  • 1
    @tohster Good observation, I missed that detail. – Alejandro Veltri Apr 13 '15 at 20:14

I can't really see the difference between this and a boolean rule/query builder, e.g. like the one described here. Let's use cars and look at your examples:

  1. Include red trucks.
  2. Include red cars and trucks as long as they're of Chevrolet make.
  3. Include red Chevrolets and Chevrolet trucks, but exclude vintage cars.


download bmml source – Wireframes created with Balsamiq Mockups

It seems pretty much the same type of task to me.

  • 1
    You've got me thinking about this pattern again, I really like the idea of reusing the rule editor pattern but I am reminded of another hurdle. The issue of "and"/"or" here can be very confusing - for example: "get me all the participants who are 15 and 30 years old" makes sense in when read out, but fails the logical test. – Nicholas Pappas Apr 13 '15 at 20:07

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.