Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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:

enter image description here

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:

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:

enter image description here

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.

share|improve this question
    
Could you give some more info: what kind of conditions are you building (the area of use), who are your target audience, how complicated the expressions might be? –  Pasha S Mar 28 '13 at 2:02
    
Updated, thank you. –  Renat Gilmanov Mar 28 '13 at 2:32
    
It's not a solution but a tip... The naming of AND / OR is for newbies (not only for newbies) not intuitive. In my company we discuss regulary about the meaning. Better solution is to use natural speaking e.g. "Contains all". See the post from Michael Zuschlag ux.stackexchange.com/q/1737/21423 –  sysscore Mar 28 '13 at 10:06
    
Valuable point, thank you. –  Renat Gilmanov Mar 28 '13 at 11:18
add comment

2 Answers

up vote 1 down vote accepted

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:

mockup

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.

share|improve this answer
    
Although I agree with your remark that the "and" and "or" in the question seem out of place, I personally think they are a bit in yours as well. I would expect that "and"'s and "or"'s at the beginning of a line (so not on the first line, but at the beginning from the second onwards). Would be interesting to test this on users at various levels of familiarity with conditions and boolean expressions, whether in SQL or in any programming language. –  Marjan Venema Mar 28 '13 at 18:14
    
I think the point of these editors is to make them readable for people who are not too familiar with such expression languages. Putting the and before the lines would work, but would also make the editor look more technical, I think. Note that I, as a programmer in my day job, usually put the operators at the end of the line if I break conditions over multiple lines, not the beginning. –  André Mar 29 '13 at 8:02
    
The are not exclusively for inexperienced users. These builders come in handy for experienced expression language users as well, if only to expedite the selection of attribute and criteria names. And these builders should also address the intricacies of AND, OR, and NOT combinations there of because even experienced expression language users get these wrong on a daily basis. Yes putting the And/Or at the beginning makes it look more technical, but will enable more consistency when dealing with compound conditions. –  Marjan Venema Mar 29 '13 at 11:44
add comment

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:

mathematical-boolean formula

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.