RadDataFilter

[Kowal]

Hi,

Your new RadDataFilter is a very nice and useful addition to your collection of controls. Thank you.
However during very short tests I've found few issues:

1. Usability problems:
- Logical operator panel is too narrow. One can easily by mistake click 'remove/delete' button instead of 'operator-change':
http://i45.tinypic.com/2q0o710.jpg
- Add buttons on logical operator panel and filter descriptor panel are also easily mistaken. I've tested it with several people and everyone in order to add new filter condition used add button on filter descriptor panel not on logical operator panel (first one adds new group of filter conditions):
http://i50.tinypic.com/2pqosaa.jpg
- For all types of columns (DateTime, boolean) you use the same textbox to enter filter values - I think it's better to use other controls - DatePicker, ...

2. Bugs:
- member name (column name) isn't taken from Display attribute but is a property name
- poor binding to object properties. It's the same for default gridview filter - you need to implement IEquatable and IComparable interface and also override ToString() method, you can't set filter on child properties. Moreover, filtering on such column (with IEquatable, IComparable, ToString() doesn't work. Whatever you enter as a filter value, is ignored. At the same time default gridview filter works ok.
- if you enable gridview filters and add RadDataFilter there are problems with twoway binding between them:
 * when you use default column filter, it is parsed and similar RadDataFilter is automatically created, but not the other way round, that is, defining filter on RadDataFilter doesn't change gridview filter
 * when you use default column filter, it is parsed and similar RadDataFilter is automatically created but it is bloated and completely unreadable:
http://i48.tinypic.com/10rv7u0.jpg
* such automatically created datafilter throws exceptions when you try to change it:
http://i49.tinypic.com/2j29mra.jpg


I think it's all by now :)

Kowal

[Rossen Hristov]

Hello Kowal,

First of all, thanks for the great feedback. You can't imagine how much this helps us shape things up before releasing them officially.

1. Logical Operator: I will let our designers know about that. Valid point.

2. AddNew vs. ToComposite buttons: We will definitely think about that. Do you have any suggestions about how to change the layout so that it is more intuitive? We spend a lot of time on the drawing board thinking about the design and usability, but we can spend some more. So if you have any nice idea about how to rearrange things please tell us right away.

3. Editors: Definitely on the to-do list. Just could not make it for the beta.

4. "Member name (column name) isn't taken from Display attribute but is a property name": This is on my to-do list as well. Beta rush :)

5. Poor binding to object properties: Could you please elaborate and give me an example, since I could not quite catch what you mean. RadDataFilter is unaware of any columns. It does not know anything about RadGridView either. It is totally disconnected from it. The only thing it does is manage a collection of FilterDescriptors. These FilterDescriptors could be either simple ones (the leaf nodes) or  CompositeFilterDescriptors that allow a tree-like hierarchies.

Anyway, could you please prepare and and send me an example of this issue. Maybe a small dummy project or some code snippet. I would really like to know more about this.

6. The link between a RadGridView and RadDataFilter: Now that is a tough one. This is by design. Let me try to explain it. I hope I will manage to.

Before going on I would like you to take a look at my blog which describes the difference between a plain old IFilterDescriptor and its highly specialized sub-class called ColumnFilterDescirptor which has a very special meaning for RadGridView and RadGridView only.

Since RadDataFilter does not know anything about the grid-specific ColumnFilterDescriptors, it works with old plain FilterDescriptors. As described in the blog -- when you add a normal FilterDescriptor to the grid it will be filtered, but the UI would not be updated because the UI "understands" ColumnFilterDescriptors only. They carry the information about the parent column of the filter so that the respective filtering control can read the information and update its visuals.

So there is a two-way link between RadGridView and RadDataFilter, but RadGridView's UI will not pick this up. This is because RadDataFilter is totally unaware of and decoupled from RadGridView.

So when you add a filter to RadGridView through its UI, this will create an instance of the ColumnFilterDescirptor class. On the other end, RadDataFilter will display it correctly, but it will treat it as an IFilterDesciptor and nothing more. It is not a coincidence that the IFilterDescriptor interface resides in the Telerik.Windows.Data assembly which is used by all data controls. On the other hand the tightly specialized class ColumnFilterDescriptor class resides in the Telerik.Windows.Controls.RadGridView assembly and only RadGridView knows about its existence.

That is why, when you turn things the other way around and add a filter through RadDataFilter's UI, RadGridView will receive a good old plain IFilterDescirptor and will add it to its collection. This will definitely filter the data displayed in the grid, but the UI funnels will not be updated, because RadGridView is not sure which column was the filter meant for. I know what you are thinking right now, having the member name is not enough. I can provide examples about that.

Anyway, since RadDataFilter was designed as an alternative of the column filters, I guess that you should choose one approach or the other. In other words, when you decide to let the user use RadDataFilter, simply turn off the filtering UI of the grid. In this way there will be no confusion.

The intention was to make RadDataFilter totally independent. So you can use it to filter a MS DataGrid, a ListBox, or any other ItemsControl. Inserting RadGridView-specific logic in RadDataFilter's source code will break this decoupling.

I am not sure that I managed to explain all of this well, but I really hope it makes some sense.

7. The bloated issue: You are totally right here. This is on my list as well. The problem is that RadGridView creates some inactive filters well before they are needed and I will fix this as soon as possible. I will make RadGridView create a filter only at the moment it has been activated, i.e. the user types in something that makes sense. This will eliminate the huge tree of garbage filters. I will look into the exception being thrown as well. But once again, if you decide to use RadDataFilter, turn off RadGridView's Filtering UI. The next day you can decide to replace RadGridView with something else and you would still want things to work as before.

I am kidding -- do not replace RadGridView with anything else! :) :) :)

I mentioned three or four issues that are on my list. Now I would like to share that I have another 34 that I did not mention :)

Since this is a beta, I have still a lot of work to do until the control is ready to market. And your feedback is extremely valuable during this period, so I would like to thank you.

Please, keep it coming and thanks once again.

All the best,
Ross
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.

[Kowal]

Hello again,

2. AddNew vs. ToComposite buttons: I'll describe idea I have as soon as I have more time

5. Poor binding to object properties: I usually make simple things complicated :)
Just look at my model:

    public class Person
    {
        [Display(Name="FName", Order=10, ShortName="test name")]
        public string FirstName { get; set; }

        [Display(Name = "Very long name", Order = 1)]
        public string LastName { get; set; }

        [Display(Order = 11)]
        public int Age { get; set; }

        [Display(Order = 111)]
        public DateTime DateOfBirth { get; set; }

        [Display(Order = 2)]
        public bool Married { get; set; }

        public Home HomeObject { get; set; }

    }

    public class Home : IEquatable<Home>, IComparable<Home>
    {
        public int Count { get; set; }
        public string Name { get; set; }

        public bool Equals(Home other)
        {
            return Count.Equals(other.Count);
        }

        public int CompareTo(Home other)
        {
            return Count.CompareTo(other.Count);
        }

        public override string ToString()
        {
            return Count.ToString();
        }
    }

As you can see, Person has a Home property, which is an object with its own (child) properties.
Now if I bind my gridview/raddatafilter to a collection of Person, I'll have issues I described.

6. The link between a RadGridView and RadDataFilter: Thank you for your comprehensive explanation. I think I understand most of it :) If it's by design, I'll do as you suggest - use RadDataFilter or column filters, not both together.


All the best,
Kowal

[Kowal]

Small edit:
I've got one feature that I think is a musthave for an advanced data filter. It should provide an opportunity to set "is empty/is not empty" column condition (is null/is not null).
Also it should be possible to use 'between' clause on datetime columns (now it's only possible by defining two separate filters and joining them with AND operator).

Kowal

[Rossen Hristov]

Hi Kowal,

Thanks for the reply.

Poor binding to object properties: We will look into this issue.

The link between a RadGridView and RadDataFilter: Instead of writing so many words I could have explained this with a single sentence:

By using RadDataFilter you can create infinitely complex hierarchies of filters. RadGridView's filtering UI is fixed to server the particular needs of the grid, i.e. it has a list of distinct values and two field filters. That is why the link is one way -- if I create a mega-complex hierarchy in RadDataFilter it simply cannot be shown in the hard-coded filtering UI of RadGridView. I hope this makes more sense.

Empty/Null: We were thinking of adding something like a combo so that the user can select null, string.Empty or FilterDescriptor.UnsetValue.

Between: I doubt that we will add this. We are trying to keeps things as simple and uniform as possible. As you said -- this can be done by combining two simple filters. Providing "custom" stuff for specific data types will break the control's "lookless-ness".

Once again, thanks for the feedback.

All the best,
Ross
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.

[Kowal]

Hi,

I would like to describe my general idea for look and feel of an advanced data filter.

I'll try to be as short as possible and not describe all of the details now.

Your solution (and other, apart from one, that I've seen) has one basic flaw: it forces a user to imagine the whole query (represented by a set of joined filter conditions) he wants to set first and then to enter it using UI of your control. One has to know in the beginning all the logical operators which will join subfilters because he has to enter them first. He is forced to think in an unnatural way. He can't enter filter conditions first and then join them by using logical operator. He can't undo his decisions without deleting most of the conditions he entered, he can't ungroup conditions, he can't move them somewhere else (up or down).

An average user doesn't think like a mathematician, he doesn't know that a query (filter) is built like a tree. So your approach of representing it in UI in exactly the same way as it is built underneath makes it hard to use (but is definitely easier to implement).

Ask yourself, how would you like to enter conditions to a filter, how do you write sql queries, etc. Do you use prefix notation (http://en.wikipedia.org/wiki/Polish_notation) or rather infix or postfix notation, and which one is easier to understand and use (not by you or other developers but by all users).

Example:

I would like to filter shapes by its colour and number of angles:

(Color == Green OR Color == Black) AND NoAgles == 5

Using your control I'll have to think a lot and then enter something like this:

AND (OR Color == Green Color == Black) NoAgles == 5

Oh no.... :)

I know that what I write ruins your idea and would require a lot of changes in the control but I think it is worth it.

Let me know if you want me to send any further clarification on the topic.

Kowal

[Rossen Hristov]

Hello Kowal,

Thanks for the suggestion. We will have our interaction designers think about that.

Kind regards,
Ross
the Telerik team

[Tim Kahne]

We've had the exact same reaction as Kowal.  So much so that we had 3-4 users look at it - ranging from expert developers to very experienced power users to design architects.  All liked the look and feel, but once starting to use it, it was not intuitive nor could changes be made (no undo feature...) 

And because of the way the RadFilter is constructed and requiring knowledge of the whole query structure in advance (as Kowal stated so well), we've been forced to write our own, using a RadGridView as the mechanism to enter the conditions... The columns are: Operator (And/Or/Not - but empty on line 1, Parens [( or (( or ((( ], Field, Operator, Value, Parens [) or  )) or )))].

With these columns in a RadGridView the user can easily incrementally add conditions, delete, manipulate, change grouping (parens), etc.

[Rossen Hristov]

Hi Tim Kahne,

Thank you for the feedback. It is very valuable for us. We would like to ask a couple of additional questions.

Can you explain how do you imagine the undo feature. We are really interested in this, but we need more elaborate description of this feature. If you formulate this well, we will add it to our PITS System as a feature request and people will be able to vote for it.

I guess that we will need to implement some kind of drag-and-drop support, so that a user can move one already created condition to another group somewhere in three. Does this sound like a valuable feature?

Also, if it is not a secret of course, can you send us a screen-shot of your filtering grid. We would be really thrilled to see it. It can lead us to many new ideas.

We have plans to add something called "connecting lines" to enable the end user to see the hierarchy easily. Also, we might introduce a vertical mode, i.e. build the query down and not to the right. But these are just ideas.

You can vote for the drag-and-drop feature on its PITS address: 2637
You can vote for the visual aids (connecting lines) feature on its PITS address: 2638

If you think of another feature, please formulate it well and we will add it to PITS so that people can vote for it.

Please, keep up letting us know what you think about the controls. After all, we are making them for you -- the customer.

All the best,
Ross
the Telerik team

[david mcintyre]

Hi Ross, I have a RadDataFilter attached to a Rad DDS and a RadGridview.  Works fine, but it still doesn't allow for filtering values that are string.empty or null.  I need this for string properties only.  Has any workaround been added for this in the more recent releases, or are there any plans to add it?  The ugly workaround is to set a non-null default value for these string properties and train users to search on that text. 

[Rossen Hristov]

Hello david mcintyre,

If you can invent a way to let the user enter null and string.empty into the filter editor, then you can create your very own custom filter editor and use it.

Here is the on-line example that demonstrates custom filter editors. You can place any user control there as long as you bind it to the Value property of the underlying view model, like shown in the on-line example.

I hope this helps.

Kind regards,
Ross
the Telerik team