Ignite UI for Angular is a complete library of Angular-native, Material-based Angular UI components with the fastest grids and charts, Pivot Grid, Dock Manager, Hierarchical Grid, and more.
Is your feature request related to a problem? Please describe.
The current advanced filtering dialog/query builder offers great functionality, but is limited by the UX patterns in use. Some of the functionality is only visible under specific conditions, which is not a bad thing, but it simultaneously makes the UI more complex to process. This is illustrated in the before and after comparison screenshots below.
One main issue is that the dialog relies purely on color to distinguish AND-OR groups. This makes it difficult to quickly process the filters. It's best not to rely on a legend (color alone)to understand a concept that's core to this feature.
Moreover, Material guidance does not describe situations for inline actions like adding a condition or a group. Using a button style makes the UI more cluttered disrupting the visual hierarchy of the dialog. Using icon buttons is OK for common actions like edit and delete, but don't scale to communicate more complex actions.
In the current UI, clicking on the chip selects it. This becomes more useful when multiple conditions are present, allowing you to define new groups. But this gets in the way of quick editing, which might be more common. The ability to create new groups with existing filters can be realized using a different pattern.
Furthermore, chips being such a compact component, it's best to simplify its content for better readability. For instance, by not showing icons for operators inside the chip, and inside the dropdown. Some of the common ones like >= are useful, but not for operators like contains, before, after etc. Skipping these will make it easier to scan.
Describe the solution you'd like
Make qualified assumptions about 1st group
Instead of making the user choose, we can assume AND group is most common. By default add a condition and also select the first column and operator based on column type.
When adding another condition, prefill the column and operator based on most recently used.
Improve readability when conditions are added
Showing the AND and OR labels inline as group headers will match the natural reading pattern.
Skip showing icons for the operators inside the chips for easier scanning.
Make edit the primary action, and delete a secondary action
While chips can be edited by double clicking or by clicking on action-strip, it feels faster to click once on the chip to enter edit mode. Delete, being destructive, is OK to take an extra step. I realize the distinction between remove and delete is not much, but they are. Remove is fine for situations where user is not typing in any data.
Use small size for inputs to better align with chips
The suggested small size of inputs is an aesthetic choice, with an unintentional benefit. Currently the contrast between chip height and inputs is drastic. Using the "small" size for inputs ensures that the UI remains compact and the visual jump is less severe.
Use commonly expected Menus and triggers
If we show the AND and OR labels inline, it's easier to show a context menu than expecting users to click the grouping line indicator. Clicking on the line indicator is rather unexpected.
Allow user freedom to edit conditions and groups instead of using nested modes
As shown in the current UI, every operation seems to set the UI into a mode of one kind or another. For instance, when OR group is in edit mode, one needs exit this mode by clicking END GROUP. On top of that the group is now in "insert" condition mode.
Let users can move freely between groups and conditions without having to enter and exit modes if avoidable.
Improve grouping for filters
Keep filters that are at the same level always together, instead of being split up by a nested group.
Additional features, not present in current implementation
invalid condition state to allow users to jump between conditions. Invalid conditions can be skipped.
Allow dragging chips between groups as a substitute for multi-selection to create groups
Pre-determine nested group condition type based on parent group. For example, create OR group automatically if it's nested inside an AND group.
Show live count of results so as to guide creation and editing of filters.
Show a visual indicator when advanced filter conditions are active on the grid.
“filters(3)”
Is your feature request related to a problem? Please describe.
The current advanced filtering dialog/query builder offers great functionality, but is limited by the UX patterns in use. Some of the functionality is only visible under specific conditions, which is not a bad thing, but it simultaneously makes the UI more complex to process. This is illustrated in the before and after comparison screenshots below.
One main issue is that the dialog relies purely on color to distinguish AND-OR groups. This makes it difficult to quickly process the filters. It's best not to rely on a legend (color alone)to understand a concept that's core to this feature.
Moreover, Material guidance does not describe situations for inline actions like adding a condition or a group. Using a button style makes the UI more cluttered disrupting the visual hierarchy of the dialog. Using icon buttons is OK for common actions like edit and delete, but don't scale to communicate more complex actions.
In the current UI, clicking on the chip selects it. This becomes more useful when multiple conditions are present, allowing you to define new groups. But this gets in the way of quick editing, which might be more common. The ability to create new groups with existing filters can be realized using a different pattern.
Furthermore, chips being such a compact component, it's best to simplify its content for better readability. For instance, by not showing icons for operators inside the chip, and inside the dropdown. Some of the common ones like >= are useful, but not for operators like contains, before, after etc. Skipping these will make it easier to scan.
Describe the solution you'd like
Make qualified assumptions about 1st group
Instead of making the user choose, we can assume AND group is most common. By default add a condition and also select the first column and operator based on column type.
When adding another condition, prefill the column and operator based on most recently used.
Improve readability when conditions are added
Showing the AND and OR labels inline as group headers will match the natural reading pattern.
Skip showing icons for the operators inside the chips for easier scanning.
Make edit the primary action, and delete a secondary action
While chips can be edited by double clicking or by clicking on action-strip, it feels faster to click once on the chip to enter edit mode. Delete, being destructive, is OK to take an extra step. I realize the distinction between remove and delete is not much, but they are. Remove is fine for situations where user is not typing in any data.
Use small size for inputs to better align with chips
The suggested small size of inputs is an aesthetic choice, with an unintentional benefit. Currently the contrast between chip height and inputs is drastic. Using the "small" size for inputs ensures that the UI remains compact and the visual jump is less severe.
Use commonly expected Menus and triggers
If we show the AND and OR labels inline, it's easier to show a context menu than expecting users to click the grouping line indicator. Clicking on the line indicator is rather unexpected.
Allow user freedom to edit conditions and groups instead of using nested modes
As shown in the current UI, every operation seems to set the UI into a mode of one kind or another. For instance, when OR group is in edit mode, one needs exit this mode by clicking END GROUP. On top of that the group is now in "insert" condition mode.
Let users can move freely between groups and conditions without having to enter and exit modes if avoidable.
Improve grouping for filters
Keep filters that are at the same level always together, instead of being split up by a nested group.
Additional features, not present in current implementation
Additional context