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

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’ve 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 the 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 3

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 4

I like the way Apple Mail's rules work:

Answer 5

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

Answer 6

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 7

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.