MemeCode - Blog

Graphical Filter Editor

Date: 6/9/2005

The problem with modern applications is that they have to be both simple to use for beginners AND powerful for advanced users. One of the areas in Scribe where this clashes is the user defined filter conditions interface. Currently it kinda borrows from databases where it allows you to create a number of condition records, of which you can only see one at a time, and lets you edit the fields of each condition record using standard controls. However you are limited to either AND'ing or OR'ing all these conditions together. So you can't write powerful filters with combinations of AND and OR operators, or have any form of nested conditions.

So I'm playing around with a prototype user interface to replace the conditions editor tab. And this is what I've got so far:

This improves on the old UI in a number of ways. Firstly you can see all the conditions at once. You can now nest operators and conditions with ease. But hopefully it still remains easy to use for beginners. The short 3 button field allows you to create new conditions, AND or OR operators. The condition entries have editable fields and drop down helper menus. A nice legend at the top means the meaning of the icons will never be in doubt.

So what do you think? Any good?

The icons are rendered using the built in vector renderer in Lgi. They should scale to any size should the need arise. I had to fix a number of bugs in the vector renderer to get all this to display, but it was worth the effort.

Comments:

SnappyCrunch
06/09/2005 1:38pm

Working out bugs is always appreciated. New features are always appreciated. There's nothing to not love here.

I like the new filter ui. The color coding is good, and the nesting is clean; I like it. The buttons also look very pretty; I think the Aqua UI is rubbing off on you. Not a bad thing at all...

Benjamin
06/09/2005 3:53pm

I like it a lot, and if you accept some proposition,
I modify (with i.mage :P) the screenshot to show you some of the ideas that
came to my mind:

- first, make the "or" (and "and") bar the same size as their brother item.
see: http://www.hollow.be/scribe/filterui2.png
I think this help to see which level is the "or/and" and facilitate the ordering of conditions

- second, to emphasis the indent, and to visualy group all condition under an "or/and", do like in the following screenshot:
http://www.hollow.be/scribe/filterui4.png

In this scenario, the "or" group would collapse by clicking in an empty green area of the or line.

But these are just my thoughts.

Otherwise, I have a question, what is the initial state, when you start editing an empty filter? an "and" line? an "or" line? a condition?
Should we have a button to change from a "and" to an "or" line (and the other way around)?

nevertheless, this would be a great inprovement in its actual state, good job!

Benjamin

Benjamin
06/09/2005 3:56pm

Something else i forgot,
does it realy make sens to have a button to add and "And" line in a set of "And" conditions? the same goes for "Or".

Carlos Rocha
06/09/2005 7:35pm

I like it :)

fret
06/09/2005 10:17pm

Benjamin: I couldn't see your pictures, the site their hosted on is not accessible.

Also I think it is useful to be able to create any type of condition or operator even AND under AND and OR under OR. The user may change the type of the parent operator later on. And yes I will make a way to change AND to OR and visa versa.

fret
07/09/2005 12:57am

Ben: I just had a look at your screen shots and they're nice! I like the grouping in the second one but I'm building on the existing tree control and it'd be a fair bit of work to get that look. But it's certainly nice.

The initial state of the control is a single "new entry" where you can create a condition, an AND node or an OR node.

Someone I was discussing this with offline mentioned that there is no way to NOT any of the conditions or operator nodes. I'm not sure what the best UI for NOT is. Either you have another little button on each node for "NOT" or you have a completely new operator node called "NOT". I feel the first is more logical and user's would be more comfortable with it, the second method would be fine for math heads and possibly more correct. Thoughts?

Benjamin
07/09/2005 7:07am

I knew it would mean more work for the second one, this is the reason of the first one, easier to implement and already add something.

For the initial state, it makes sens to have the three choices line. And in the scenario I firstly add a condition. When I want to add a second condition, the program would dynamicaly create an "AND" rootlevel and move my first and second condition as a child of it?

About the NOT, I thought about it to.
For a condition, I would just set all NOT conditions in the operator list.
curently you have in scribe

=, !=, <, <=, >, >=, Like, Contains, Start With, End With

I would change it to :

=, !=, <, <=, >, >=, Like, Not Like, Contains, Does Not Contains, Start With, Does Not Start With, End With, Does Not End With

But to negate a group (AND or OR) this is something else, you need a graphical button to change its state AND -> NOT AND, OR -> NOT OR.

You said you would have a way to change a AND to OR. We could mix it with negation in one drop down button.

You would have one more round button in the AND/OR line (on the left of the three right most buttons), when you clic on it you would have a drop down list.
ie. for an AND node :
OR
NOT AND
NOT OR

But I don't know if everybody would understand what a NOT AND node is.
Because I think some people would understand it like an OR, which is not the case...

So for me (maybe too math headed) in the end, I would prefere a new NOT node ;-)

fret
07/09/2005 7:15am

Hmmm, I like hearing your thoughts Ben. I've been thinking of making the NOT operation a new button, say orange in the colour scheme and putting it at the start of every node (except 'new'). Although I'm also beginning to think it's going to scare away anyone except advanced users. So I'm also thinking of adding an 'advanced' mode and a 'simple' mode that hides all the move up/down and 'not' buttons. Generally making it look simpler.

Currently you can only create one top level element. It can be any of the condition, AND or OR. If you create a single condition to get more you have to delete that and create an 'and' or 'or' node. I think however that the 'new' line at the root level should just have the options for 'and' and 'or' and no option for a condition.

Ben
07/09/2005 9:06am

Good idea about the two modes, but when your at it, why not enable in advanced mode a new "NOT" node instead of a "not" button.
Since it is for advanced user (which should know what they are doing with a NOT on an AND/OR), its complexity would be acceptable.
In fact, I still think it is a bit confusing having a "NOT AND" node...

The NOT node would only allow one child.

Speaking of the root, your right it should just have the AND and OR button,
but for the initial state (at least in simple mode) you should prefill with a root AND node and an empty (ready to be filled) condition.
Most 'simple' user only want one condition (or a set of "AND"ed conditions).
But for that to be valid, you need to expose to the 'simple' user the button "switch AND/OR".

I don't know if it is the right way to do it, but I know that in the end, you will take the right choice as usual :-)

I don't know why I'm taking concern in this feature, I barely never use filter in inscribe. Only maybe in very 'simple' mode.
But I like usability and it's fun trying to solve this kind of problems.

While thinking of the way I use filter at work (where I had to work with outlook), I have an other request for scribe. I will suggest it to you when I'll take the time to write it down.

cheers

From:

Email (optional):

(Will be HTML encoded to evade harvesting)

Message:

Remember username and/or email in a cookie. Notify me of new posts in this thread via email.	BBcode: [q]text[/q] [url=link]description[/url] [img]url_to_image[/img] [pre]some_code[/pre] [b]bold_text[/b]

Sitemap