capcloud

Brief

To enable users to filter the items that are displayed in a data grid by any criteria they choose.

First Steps

The first thing I did was to sit down and talk with the project’s lead developer. He said he wanted something like the search feature in the bug-tracking system that we use (which allows you to create and save complex boolean searches on multiple criteria). My initial reaction was that in most cases, this approach would be overkill and the level of complexity that it introduces would make it difficult to perform the simple filtering that this feature would be used for most of the time.

Research

To get an idea of the possibilities, I looked at several examples of search and filtering interfaces: the in-house bug-tracking system that the developer liked, a different bug-tracking system that had been tried there (JIRA), and things like Google’s advanced search and various ecommerce sites with faceted search.

Based on this, I decided that the following points were important:

• Having the search/filter area separate from the area where the data is displayed (i.e., on a separate page or in a modal dialog box) is A Bad Thing. If you want to tweak your query after seeing its effect on the data, you have to pogo-stick back and forth between the data area and the search/filter area.
• Allowing users to use operators or other complex syntax in a simple text-box-based search/filter interface is useful, especially if you also have an easier way of doing the same thing that shows the equivalent operators. (For example, as you manipulate the controls in Google advanced search, the read-only text box at the top of the page shows the query as if you had typed it into the regular Google search box.)
• Having a wide variety of different types of controls for filtering on different types of data (e.g., having sliders, text boxes, AND combo boxes) introduced too much visual noise and meant that the feature could not be easily reused for data grids displaying different types of data. (This was important for the developer, as the plan was to use this feature for several different data grids.)

Initial Wireframe

After some initial sketching, I came up with this:

(Click for a larger version in a new window/tab.)

This was to be displayed as a slide-down panel between the toolbar and the data grid (to allow users to modify their searches and see the results immediately). The panel could then be closed so as to maximize the area available for displaying data.

The other two options that are shown would work as follows:

• Preconfigured search—this would contain a list of commonly-performed searches which could be selected from a drop-down list.
• Quick search—a simple text-box-based search where the user could type a search query (but would have to know the data field names and the search syntax).

You can view a short screencast that I made from my Visio wireframes here.

Feedback

After discussions with the development team, we came to the conclusion that even this was too complex—having “match all these criteria” and “match any of these criteria” was confusing. We decided to get rid of the second section and only display records that match all of the specified criteria.

Other Issues

There were other issues that had to be figured out:

• Should we call it search or filter?
  In the end we went with filter, as you start out with a set of records of a finite, known size, and reduce the size of the set.
• How to indicate that what is displayed is filtered or not?
  Initially I thought that the grid should have a kind of status bar below it, which could show something like “22 items, 18 hidden”. But I decided that this was too subtle. So I decided on a strip that would be displayed between the toolbar and the grid showing the current filter. The strip’s background color would be the same as that of the filter panel.

  

  
  
  
• What should happen when the user switches from one filter type to another (e.g., from Custom filter to Quick filter)?
  Due to the complexity of taking, say, a complex query that the user typed into the box in Quick filter and translating it into the values in a set of controls, it was decided to clear the filter (and warn the user) when switching.
• Which filter type should be the default?
  Quick filter, although it looks simpler and so perhaps most suitable for use as the default, it is really only for power users who already understand the syntax. So Custom filter became the default.

The Implementation

(Click for a larger version in a new window/tab.)

The initial implementation bore some similarities to my design, but there were lots of missing pieces. For example:

• There was no default filter—the user had to select one of the three options every time.
• The selected filter was not visually differentiated from the others.
• There was no way of knowing whether a filter was enabled or not.
• The spacing and alignment were all over the place, which made it hard to see what was related to what, which elements were most important, etc.
• The panel had a white background, so the fields did not stand out.
• Things that were clickable did not look clickable because the pointer turned to a text pointer instead of a hand on mouseover.

Fixing Things

When I saw how the design had been implemented, I started playing around with the CSS to see what I could fix just by changing things there. It turned out that substantial improvements could be made.

I also sat with the developer and showed her the problems. She fixed most of them, I made the changes to the CSS, and all was well.

For a while…

The New Version

Some time later, the developer who had implemented this feature left the team and a new developer joined. He was given the task of adding another new feature—the ability to group records (and also aggregate selected fields). Unfortunately, nobody consulted me about the feature until after it had been implemented.

The developer had decided that, as adding a filter and specifying a grouping were both kinds of queries, they could safely be combined into a single feature. He had combined them into an “Advanced Query” wizard that was displayed as a dialog box instead of the original panel (so reintroducing the pogo-sticking problem mentioned earlier).

The first stage of the wizard was where the user could specify a filter. The user could apply the filter without having to go through the other two steps of the wizard. But if the user wanted to group records, they had to click Next to move on to the second stage. There was no indication that the ability to group was unavailable until the second stage was reached.

The user would then click Execute, which would close the dialog box and open a new dialog box, containing the third stage of the wizard (specifying which fields were to be aggregated and how—count, sum, average, etc.).

Needless to say, this was less than ideal… I talked to the developer about it, and explained the rationale for originally having a panel instead of a dialog box. I also explained why I thought filtering and grouping are, for users, separate, unrelated things and so should be implemented as separate features. He agreed, but said that to change it, he would have to get the lead developer’s approval.

And that is how things stand right now. I do not have high hopes that my suggested changes will be made before the imminent release. (It works, so fixing it is a lower priority than fixing all the other bugs and problems before the release.)

I will push for this to be fixed, though. If not now, then later.

What I would do differently

I learned from this experience that it is very important to keep in touch with the developers during the implementation stage. To explicitly ask them to show me what it looks like at various stages. Once something has been built and works (however badly) it tends to stay that way (especially in an enterprise setting). If it works, there’s not much incentive to go back and make it better. There are always newer, more important things to work on.