Filters UI improvements

[admin]

With another user we identified 3 ergonomic issues on filters:

Issue #1: When adding a new filter to the queries, one must also click on it to open its settings panel.
Solution: As this is an always repeated action, we could automatically open the filter panel as soon as it is added to the queries.

Issue #2: Parameters are read-only values. This can confuse someone working directly with the tree.
Solution: Writable parameters

Issue #3: Working with several partitions is not easy with the current UI: each partition has to be selected or unselected, so if someone wants to see all the partitions but one, he has to individually select nearly all of them. And he has to manually unselect each one if he wants to see only one after that.
Solution: A button to select or unselect all partitions in one click.

This thread is to discuss on these issues and possible solutions

[mbastian]

#1: Yes I agree, you can add it to the Ideas

#2: Not so easy, writable parameters need to have the proper editor, which assure to have correct data. That is the purpose of the UI panel so it would be redundant.

#3: A 'Select All' and 'Unselect All' option is available when you right click on the panel.

[admin]

#3: A 'Select All' and 'Unselect All' option is available when you right click on the panel.

The big challenge of 2011 will be to write the manual.

[admin]

Another use case:

Expanding a selection/filter to the direct neighbors. This way one can for instance:
- select a partition and the in/out connections.
- select two partitions and see the paths linking these partitions at a distance 1

[mbastian]

Yes neighbors would a nice addition for filters. However you can already achieve many things using the new MASK operators. That would let you get the nodes connected to a set of other nodes (the partition nodes) and therefore get the neighbors.

For a neighbor filter, one can get inspired from the ego filter code. It wouldn't be difficult to modify it in that way. Follow the tutorial HowTo write a filter.

[admin]

Done in rev #1995!

The HowTo is really easy to handle! Figuring out the difference of merging two set of nodes from the local and main view is more tricky.

[mbastian]

Hehe congratulations, neighbors filter is very useful, and it's even better than just neighbors as one can set the depth.

Yes it's tricky because you have to add nodes...Removing nodes is a more natural use-case for filters and is easier to handle. But with existing filters as example I think it's okay

[admin]

Continuing this post (my future todo list I guess...), we could add two actions on right-clicking a query or sub-query:

Duplicate
Sometime we want to change more than one sub-query parameter, and would like to switch easily between the two configurations to see what's going on. This action would not be possible for sub-queries.

Replace by
Example: you create a UNION query, and you just want to see what happens with an INTERSECTION. For the moment you need to build another query in 4 clicks: 1/add the new operator as query, 2/ expand it, 3/ drag the first sub-query, 4/ drag the second one. By selecting "Replace by", a window with the list of possible filter appears.

An alternative is to drag the replacing filter from the library to the _name_ of the replaced filter, holding a key like "Ctrl" to avoid mistakes.

Dragging sub-filters
By the way, when adding a filter as a sub-query, the root must be expanded to drag the filter to the line "Drag subfilter here". I'd prefer to drag it to the name of the root, and see it automatically expanded.

Settings Panel
Finally, the settings panel remains open after removing a query. It should be closed automatically to avoid confusion.

All of this are proposals to discuss of course

[mbastian]

That sounds good improvements,

Besides this, have you watched people using Filters? I'm sure we could learn a lot

And what having icons for filters? The SPI allows itm but we don't use it

[admin]

No but I crawl myself with it

Another improvement:

Adding the parameter name + filter name as a query title, for instance "Label Equal" instead of "Equal", "Modularity Class Partition" instead of "Partition". It is really useful when you have 5 filters with the same kind of root, but executed with different parameters!