It is generally accepted that a good user interface is one that allows users to perform the task at hand efficiently and effectively. It should be as simple as possible to limit distraction and misunderstandings.
When it comes to filtering data in grids, providing users with every filtering capability in the toolshed is therefore probably not the way to go. Neither is providing a sledgehamer when you only need a nutcracker. So, how should you proceed?
Understand your user’s job
Outside the context of the users web application, understand the tasks that your user is trying to achieve. Ask them to give you a broad overview of their job, then ask questions to drill into the details. It is always difficult, but try not to lead the user to say or agree with pre-existing assumptions. It can be useful to record these conversations (with permission of course) so that you can listen a few times and make sure you fully understand.
Basic questions to ask
From a filtering perspective, some important questions to ask are:
- How many and what fields do you filter on?
- Do you repeat the same filter (or filters) every time? If so, how often?
- Do you perform some types of filters more than others? If so, are some performed more frequently than others?
- Roughly how many rows are in the result set?
Once you understand their requirements, document them and verify with the user.
Align the solution with the user’s needs
The whole purpose of enterprise applications is to make users more efficient. Underpowered UI is frustrating. Too many bells and whistles can mean extra unecessary clicks. Based on the user’s requirements, choose a filtering paradigm, (or a hybrid) that meets their needs. Note that for each method of filtering there are typically many options that allow you to easilly refine the behavior.
Does your user repeatedly use the same 1-3 fields to identify, view/update a single record? For example, to search for a single order ID, part number, or customer? In this case, a simple filter on the grid columns will work very well. It will allow them to type values directly into the fields above each column.
The above filtering can be added to grid by setting
Note: In the above example, it is easy to disable some columns so that they are not searchable (for example, if they contain icons). See here for more info.
As an alternative to the above, you could provide fixed filter fields above the grid, along the following lines. This may work well for users who are less comfortable using web applications and need a more explicit UI:
Does your user want to find a data set to investigate? For example, look at sales of software products over $500 shipping in the next 90 days. In this case, something a bit more advanced is required. A great option is to be able to filter each column using inline operators like greater than, equal to, less than, starts with, contains, etc.
The above inline operator filtering can be added to grid by setting
Play with the inline operator filters sample in the live showcase here.
For date based filtering, there are excellent capabilities available:
RelativeDateRangeItemallows selection of dates in three ways: you can select a preset date string, like “Today” or “Tomorrow”, or a “ranged” date string, such as “N days from now”.
Are your users trying to spot trends, anomalies, correlations across millions of rows of data? For example, exploring patients who have been prescribed aspirin and anti-malarial drugs, have a specific gene, and have above average life expectancy. For this, they need to be able to construct pretty complex queries.
The FilterBuilder works very well to construct queries of arbitrary complexity.
FilterBuilder, and the underlying
AdvancedCriteria system, support building queries with subclauses nested to any depth. Try the FilterBuilder live sample here. See also the gif below.
There are several more grid filtering possibilities and various options/configurations to explore here.
The Isomorphic Team