TreeTable as a flexible condition/filter editor

Question

I face the task to create condition/filter editor every time I need to develop a data/request/event processing system. As usual, there is no universal one and only solution.

Google shows a lot of various examples:

Some solutions are designed to handle only short logical operations and will explode with longer functions (example 1). Other solutions are ugly because of the layout and information noise. Frankly speaking any approach with some custom layout and default controls seems to be a little big ugly and artificial.

So can universal editor be created?

My answer was: yes, sure. Simple TextArea with syntax highlighting can be used as a universal and flexible editor. It does provide natural support for all operations including copy/paste, free editing, infix notation, simplified navigation, etc. Templates and error highlighting will make such approach user-friendly and simple to start with.

This approach was not fully approved, because free text editing sounds complex almost for everyone.

By the way, I've also spend some time searching for similar questions. My results are:

• Intuitive interface for Composing Boolean Logic?
• Good solutions for boolean filter with sub conditions

First suggests to use a form with tree-like layout and default components. Second invents Lisp. Don't get me wrong, I like Lisp quite a lot, but parenthesized Polish prefix notation will drive crazy any ordinary user in 5 minutes max. So I decided to keep strict hierarchy, infix notation, provide some tweaks and make free text editing available in parallel.

Early implementation I can show looks like the following:

So the questions are:

• Do you think this is good approach?
• What will you suggest for condition editing?

Examples

Wireshark filters can be used as an example of the task being solved:

(ip.src >= 192.168.1.0 && ip.src <= 192.168.1.255) || (ip.dst >= 192.168.1.0 && ip.dst <= 192.168.1.255)

Please note, expressions can be complex (4,8 .. 16 lines in C-like form) and some specific functions (COMPARE_ALL for example) sometimes can be used instead of simple AND/OR.

Target audience

The idea is to satisfy experienced users and also let newbies to find their way.

Answer 1

I find none of the suggested solutions from your question very intuitive. The main problem, IMHO, is the very unnatural ordering of the operators and the components. Everywhere, the 'AND' is the first thing you see. That doesn't fit a users' model how how the components belong together.

As a solution, I'd suggest something like this:

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

Clicking on a split icon, would allow selecting the split type: and, or, or either...or (exclusive or).

In this solution, you can read the whole structure like you would natural language.

Answer 2

Remove the chrome. People don't like living in houses with scaffolding. Similarly, it's hard to read an expression where everything is surrounded by a box and has several buttons attached.

Generally you want to start by asking "What is the most understandable format that I can write this expression in?" Use a whiteboard, and imagine you're trying to explain your condition to a 10-year old, or to your boss.

Instead of making trees, I would probably use the time-tested standard mathematical notation: { joins conditions with AND, and [ means OR:

Obviously this representation is optimized for reading, not for editing. But this is the intention: when a complicated condition is easy to read, you're less likely to make mistakes. Note also that whenever possible you want to allow chaining of inequalities, because this reflects the way people think about them. For example, you must allow A ≤ B < C ≤ D, and A > B > C ≥ D, and A = B ≠ C = D. However the expression A ≠ B ≠ C is already ambiguous (from a user's perspective A ≠ C is also implied).

Editing can be performed in an environment very similar to a text editor, only with braces / brackets automatically expanding as you add more conditions. It could be similar to how MathType UI works. You can also allow users to "resize" braces with a mouse, adding placeholders for new conditions. Also assist newbies with tooltips for each bracket stating which logical condition is implied.

One last boolean condition that you didn't mention is XOR. For a series of operators it means "one and only one of conditions must be true". There is no standard math notation for that, so just invent your own. Angle bracket 〈 maybe? Just make sure to provide a tooltip, because this will confuse your users the first time they see it.