Intuitive interface for Composing Boolean Logic?

Question

I'm interested to know how people have, or would construct an interface which simplifies constructing logical boolean conditions? (Yes, it's a database query builder) In my mind a bad interface has them typing lots of AND, NOT IN, OR keywords etc. Or else has a million combo boxes.

I'm wondering if anyone has a good example I could glean ideas from? Or some suggestions?

At the moment I'm considering a split screen with a grid for composing the query and a canvas to display a visual representation of the sets of conditions and how they overlap etc. Like a Venn Diagram. This still gives me a problem with the usability/intuitiveness of the controls on the grid.

EDIT: I'm very interested in ideas which simplify it for less technical users. However, ideas for a version of the UI for advanced users are very helpful as well.

Answer 1

See also iTunes 9 or later. It adds the ability to do "nested" AND / OR expressions, akin to how a programmer would do it with parenthesis:

Answer 2

This one tested well with both the technical and non-technical users and can generate pretty much any possible database query...

The benefits are that it's very clear and a user can drag and drop (or delete) any expression or group of expressions in the tree.

The down side is how much space it consumes.

Answer 3

The main problem non-technical users have with Boolean logic is understanding the difference between AND and OR because it doesn’t always correspond to natural language (e.g., “show me orders from New York and New Jersey” almost certainly means Location = NY OR Location = NJ). Often users tend to interpret "or" to be an an exclusive OR. Then there’s the issue of losing track of nested parentheses.

One solution that avoids both of these issues is to represent the logic graphically with a plumbing or electrical metaphor. There have been a couple lines of work taking this approach:

Shneiderman, B (1991). Visual User Interfaces for Information Exploration. Proceedings of the 54th Annual Meeting of The American Society for Information Sciences, 28, 379-384.

Murray NS, Paton NW, Goble CA, Bryce J (2000) Kaleidoquery—a flow-based visual language and its evaluation. Journal of Visual Languages & Computing, 11(2), 151-189.

Query builders are one of the few places where it makes sense to have separate Basic and Advanced modes. You’ll probably find that 90% of your users' queries fit only a few patterns (e.g., “Customers with name beginning with Xxxx,” “Accounts I’m responsible for with outstanding bills,” “Orders made between date a and b”). It makes sense to have these as canned or semi-canned queries that can be selected and specified easily while putting something like Kaleidoquery under Advanced for the rarer ad hoc querying.

Answer 4

There is a jquery plugin to do this, called QueryBuilder, which do this in an interesting way : http://mistic100.github.io/jQuery-QueryBuilder/

Answer 5

There's quite a few good ideas/references here, especially to some existing approaches. Often, though not always, Apple's approach is a good place to start - but perhaps in your case it may not be. I get the impression (though you haven't actually said it) that you're working with an awful lot of data comprised of many many fields/variables.

I agree that trying to find a way to simplify it for less technical users is a good idea, so long as you expect to have less technical users using the system. Otherwise developing a less complicated interface may be a lot of work for little gain. I also like the idea of a Venn diagram - would be interesting to see how that pans out.

However, in terms of actual suggestions on how to simplify this, another approach would be to just create some sort of "Wizard" process that steps the user through the process with a combination of natural language and a familiar 'web' look and feel. Below is a mockup of how this could work, using an example of a motor vehicle database:

The above shows how Step 1 could work, giving users a number of options they can select by ticking the relevant checkbox. They can select one or more checkboxes as necessary (or maybe not any?!). If they select a checkbox for an option that requires further info then the relevant words are hyperlinked. Clicking on the hyperlinked words would present the user with something like the example below:

So, the example above shows what a user may see if they've selected the "Vehicle is produced by particular manufacturers" checkbox and then clicked on the hyperlinked text to select the manufacturer(s) they want included in the search results. Of course your approach may differ depending on whether they should see a free text field, a drop-down list of options, etc.

Now, to deal with any "exceptions" to the search criteria, you would basically recreate the first window again, but with different wording, like:

So, after selecting the fuel exception above, the user clicks on the hyperlinked words "particular fuel" to choose the exception as below:

Once again, this could be a drop-down list, radio buttons, etc depending on what best suits the condition. They would also go through the same process to select the country they didn't want the vehicle to be manufactured in.

Of course, I see this "Wizard" approach as being for less technical users. You would also offer an "Advanced" option for users comfortable with a more complicated approach that may be streamlined compared to the Wizard approach.

ADDENDUM

Okay, this kept me up last night. I actually see this Wizard approach as being quite a good way to go, so thought it worth coming back to improve on my answer as it may help someone else if not you.

I've updated the mockup images above and wanted to expand on your idea of using a split screen.

Originally I thought that after the last step was complete, then something like your Venn diagram idea could be used to visually indicate what the user has chosen. But then I thought about my original assertion that there should also be a way for the user to go back and forth to amend their criteria. So now I'm thinking that using your split screen you could achieve both. Below is a new image to illustrate what I'm thinking:

So, the above is an example of what could appear in the second part of your split screen. As the user selects their criteria, this updates to indicate what their selections have been. This approach also uses the familiar web look and feel of highlighting their choices with hyperlinks and, if they wanted to, they could change their criteria by clicking on the hyperlinks within this screen, rather than having to go back and forth between screens to redo their steps. Of course, if they wanted to select a new condition, they would need to perhaps go back to the relevant step. But you get the idea.

The only other thing I'd like to mention is that without knowing the complexity of your data, you may need to refine this Wizard approach. My simple vehicle database only needs two steps, but a complicated one may need more steps. The point of this approach though, is not so much in the number of steps, but in the fact that the Wizard 'talks' people through the steps using natural language as much as possible.

Anyway, I hope this, along with the other answers provided, gives you some food for thought. And perhaps some others. This is a good topic and one which I think will be relevant to many users.

Good luck!

Answer 6

I like the way Apple Mail's rules work:

Answer 7

It depends on the level of sophistication of your users. We have something similar in the current version of the interface have left out grouping and fixed the conjunction between to terms to OR. Each term can be negated. Most users are fine with that kind of querying and most of them would not be able to formulate more advanced queries correctly. We are now implementing a two step process in which the result of a query can be used to limit the population in a following query (still leaving out explicit grouping in the UI).

The UI for this is a basic list of constraints that can be added, removed, activated and deactivated and negated. This has been sufficient for most queries that users want to create. We had a design for a new version that was based on a dataflow concept (taking strong inspiration from vistrails, see below) but that got never executed. Vistrails is a product that can be used to created VTK pipelines. If you want to go the route of lots of pieces of UI, dataflow works for formulating queries, but also works for formulating output formatting.

Look for inspiration in

• Yahoo Pipes
• Apple Finder
• Thunderbird search
• Vistrails

Answer 8

It's an old question, but I thought I'd contribute in case anyone is interested. Although a lot of interesting answers have already been provided, I designed for our app the following:

Initially there's just the first group expression and one rule. Clicking on the 'Add condition' adds a new condition above it, while the 'Add group' adds a new group directly below it; additional groups from the parent group are siblings while you can create infinite nesting using the 'Add group' button from within a nested group.

On mobile devices the conditions stack, along with the 'remove' action button - which now changes its text to 'Remove condition'.

The design works well, looks good, is responsive and doesn't consume too much space either.

Added bonus: Above the group a single line shows the end produced condition, eg

[ Date greater than XXX AND (Name equal to Nick) ]

edit: In order to make it more approachable by non-technical people, I would follow what was said by others in this thread - follow Apple's path. Instead of AND/OR I would use ALL/ANY + context.

Answer 9

Here's an interface for composing boolean logic.

A Few Thoughts

• The interface starts out simple
• If it gets complicated, it's because the user built it step by step
• No editing or drag/drop - just creating and deleting branches
• Conditions are a simple dropdown in this example, but could be more complicated or possibly negated

Ambiguity

As an aside, I've also been concerned with the ambiguity of "show me red and blue" shirts since the user might technically means "red or blue" shirts.

I think if you ask them describe the singular version (a "shirt") then the problem is somewhat reduced. For example, they wouldn't say "Show me a red and blue shirt" if they mean "red or blue".

Answer 10

Microsoft Access had a reasonable attempt at a simple database query UI by producing a visual version of "Query by Example"

It has a more natural language that avoids need for nested UI, at the expense of occasionally slightly more redundant entries in lines.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 11

As opposed to re-using pivot tables as I previously answered, this is an experimental UI that I thought of to handle the repetitive need for writing AND or OR.

It relies on one element you must learn that ANDs are horizontal and ORs are vertical. It manages to deal with fairly complex Boolean logic though.

Overview

Assume that A, B, C, D, and E are Boolean expressions.

For testing the concept here is how you would draw the two different sides of a standard Boolean equivalence:

(A and B) or C === (A or C) and (B or C)

This extends to more complex queries:

((A and B and C) or D) and E

Actual UI

For this table of data:

The screen is split in two:

1. A set of filters (effectively AND queries)
2. A combination of the filters

You set the filters (these are just typed with basic conditional log) and then drag that across to 'merge' it with the full query.

After dragging the new set of filters across, the left-hand side returns to an unfiltered list and the right-hand side shows the 'merged' data set:

You should then be able to drag around and edit the expressions on the right-hand side - but that needs a lot more work.

Answer 12

If your users are advanced enough to know the hierarchy of a query, any graphical interface you give them has to be fluid enough not to get in their way. I think an interface based on dragging and dropping elements to create an implicit hierarchy is ideal. Here's an extended annotated visual example of how a user might construct the query (A and B) or ((not C) or D):

Drop A onto panel.
+---+
| A |
+---+

Drop "and" after A.
+-------------------+
| +---+     +-----+ |
| | A | and | ... | |
| +---+     +-----+ |
+-------------------+

Drop B onto "...".
+-----------------+
| +---+     +---+ |
| | A | and | B | |
| +---+     +---+ |
+-----------------+

Drop "or" after "and".
+--------------------------------+
| +-----------------+            |
| | +---+     +---+ |    +-----+ |
| | | A | and | B | | or | ... | |
| | +---+     +---+ |    +-----+ |
| +-----------------+            |
+--------------------------------+

Drop C onto "...".
+------------------------------+
| +-----------------+          |
| | +---+     +---+ |    +---+ |
| | | A | and | B | | or | C | |
| | +---+     +---+ |    +---+ |
| +-----------------+          |
+------------------------------+

Drop "not" onto C.
+--------------------------------------+
| +-----------------+    +-----------+ |
| | +---+     +---+ |    |     +---+ | |
| | | A | and | B | | or | not | C | | |
| | +---+     +---+ |    |     +---+ | |
| +-----------------+    +-----------+ |
+--------------------------------------+

Drop "or" after "not C".
+-----------------------------------------------------+
|                        +--------------------------+ |
| +-----------------+    | +-----------+            | |
| | +---+     +---+ |    | |     +---+ |    +-----+ | |
| | | A | and | B | | or | | not | C | | or | ... | | |
| | +---+     +---+ |    | |     +---+ |    +-----+ | |
| +-----------------+    | +-----------+            | |
|                        +--------------------------+ |
+-----------------------------------------------------+

Drop D onto "...".
+---------------------------------------------------+
|                        +------------------------+ |
| +-----------------+    | +-----------+          | |
| | +---+     +---+ |    | |     +---+ |    +---+ | |
| | | A | and | B | | or | | not | C | | or | D | | |
| | +---+     +---+ |    | |     +---+ |    +---+ | |
| +-----------------+    | +-----------+          | |
|                        +------------------------+ |
+---------------------------------------------------+

Individual query elements (A, B, etc.) are constructed before being dropped into the panel, using combo boxes or whatever elements are necessary. Small margins and alternating colours could make this very readable, as well as display rules that make, for example, a chain of ors display at a single level:

+-------------------------+
| +---+    +---+    +---+ |
| | A | or | B | or | C | |
| +---+    +---+    +---+ |
+-------------------------+

Naturally, query elements could be expanded, collapsed, re-ordered, and edited after being dropped into the composing panel.

I'm not saying this is the easiest way to construct a system for this purpose. In fact, from a development standpoint, it's probably about as difficult as it can be. But it's the most efficient and intuitive thing I can come up with, and anyway it's basically just a clone of the Apple Mail rule UI but with more emphasis on hierarchy.

Hope this proves useful in your search for what's right.

Answer 13

CognitoForms has the most intuitive AND/OR solution I've come across

Answer 14

Adding example from the ticketing app we developed.

Instead of grouping "AND / OR" we settled on an "all / any / none" dropdown at the top. Exactly because of the above mentioned example: when non-technical people say "gimme orders from New York and New Jersey" tit actually means "logical OR".

We also decided against grouping multiple complex AND/OR combinations, since people got confused. We offer them a "recursion" instead, offering to "trigger another rule" (at the bottom of the screenshot).

Answer 15

My favourite UI for rule building is ATG's Scenario server. Check this out:

Answer 16

I am working on a redesign of a web app which uses Boolean and the image below shows how it is currently being done. The user can delete the brackets where needed or add them back in. I am struggling to find a better way to do this so may end up keeping this part which users seem to be using quite well.

Answer 17

For creating relatively complex single table queries, pivot tables are very useful.

Good stuff

1. You can get SUM, AVG and GROUP with relatively little knowledge.
2. By splitting fields across columns vs rows you get AND queries
3. The totals give you OR queries
4. You can properly 'build' queries - i.e. you can quickly see a master set, then add rows / columns and then add in filters which shows you which data is available to filter out

Bad stuff

1. I guess you'll hit limits for if you try to combine more than one table / data set.
2. Depending on how deeply nested you want your AND / OR queries you might have problems

But at least you don't have a ton of combo boxes, and the combo boxes you do have are more intutive.

Here's one I made earlier with some lovely fantasy football stats to go with it.

Answer 18

another option is separating the conditions and their operators, like this:

i also liked the way Smart Html Elements handled it

Answer 19

It is hard to pin down exactly what is intuitive for something that has traditionally been dealt with by technical users (that won't necessarily find interfaces more user-friend compared to command prompts). There is a particular reason for this efficiency, as queries can be unambiguously specified and executed in a command-line prompt. Also, it probably won't surprise anyone that traditional interface design will probably break when it comes to more complex queries.

Nevertheless, I think it is probably safe to say that when it comes to Boolean logic, the most common/familiar theme has to be the Venn diagram. So the question might be how to take the precise statements of database queries and combine it with the simplicity of a Venn diagram like interface?

I think conceptually a possible solution would be to combine both spatial layout with user interactions that reflect the nature of the operations that is being performed. This way you will get the concept of the Venn diagram across to the users while making the operations 'intuitive' enough to understand. So that is effectively taking what @bendytree and @sboye suggested for doing the actual data entry but also outputting the result of those operations in the form of a Venn diagram so that the user can see immediately whether they have performed the right type of boolean operation. But you might want to make the input even easier by implementing some drag'n'drop for the boolean operators and datasets/fields that you want to display, taking inspirations from some of the interactive Venn diagrams that you can find on Google searches.

Answer 20

If it's mobile, have a button for each operation that simply enters it into a text box. Provide a link to help on boolean algebra and the like. That would be both easy and flexible.