4

Is it a good idea to use column headers as input boxes for filtering the results in a table?

enter image description here

4 Answers 4

4

Traditionally, grids are designed in such a way that when the user clicks on the header of a column, the values in the table are sorted in ascending or descending format.

One way to include search/filter in the same header area is to add a search icon at the right corner of the cell as shown below.

enter image description here

When the user clicks/taps on the search icon, you can replace the header label with the filter textbox which can implement autocomplete feature as shown below.

enter image description here

Hope that helps.

5
  • So it basically it isn't a good idea to implement this because it will confuse the user, right?
    – naf
    Nov 15, 2012 at 11:14
  • This is one of Oracle's designs. Look at the image in section 10.4 Enabling Filtering in Tables. Nov 15, 2012 at 13:29
  • I don't think it's the same at all. In my design, I've replaced the header with the search box. In Oracle's design, they just added the search box on top of the header box, which might work for some people but I personally feel is inelegant. Especially because, if you implement autocomplete feature since the results will hide/overlap the header text anyway.
    – Girish
    Nov 15, 2012 at 15:24
  • @Girish - I did not mean to imply the design suggested in the answer was identical to Oracle's - although it is very easy to see why my comment suggests that very thing. I meant to say "This is similar to Oracle's design." The similarity is the location of the input boxes in or near the headers. My apologies for any confusion my first comment may have caused. Nov 16, 2012 at 17:37
  • @user1757436 Thanks for taking the time to clarify. Not a lot of people do that these days.
    – Girish
    Nov 16, 2012 at 18:19
1

Column headers are usually used for sorting.

And even if you will replace this functionality with filtering you will have to:

  1. Make sure it's discoverable (i.e., users will know how to filter using headers)
  2. Make sure column headers are still looks like a column headers (not all of your users will need filtering at all)
  3. Think about how to implement sorting (which are lost now, but could be still useful)
  4. Moreover, column headers are used for drag and drop of the columns sometimes, so you'll probably will miss this too.
1

I think it would be pretty recognizable by a user, as many applications, like Excel, implement sorting or filtering in table headers. As the other answers pointed out though, it should give some indication that an action is available there. Here are a few examples of such:

  • Highlighting the header field to make it appear clickable.
  • An up/down arrow if clicking on the header will sort the column.
  • A drop down or search box that allows the user to filter the results.
  • An icon that would bring up a dialog box if more advanced filtering is necessary.
3
  • 1
    I agree with the suggestion for looking at Excel - particularly if your users are also Excel users. Having worked on products with tables needing much sorting and filtering, a frequent comment we get during testing is "I expect it to work like Excel." Here is a picture. Nov 15, 2012 at 13:27
  • Can this also be applied to web apps? Excel runs on the OS, not in the browser. Don't people expect input boxes, select boxes, ... with a label for filtering somewhere in a sidebar instead in a column header?
    – naf
    Nov 15, 2012 at 14:37
  • Microsoft's answer to the question is 'Yes. This can be applied to web apps.' as shown by the identical behavior in their Excel web app.(blogs.office.com/b/officewebapps/archive/2012/10/22/… ). I agree with them. The issue is not web v OS behavior, it is Excel behavior. To frequent Excel users, every data table is an Excel table whether it is in a Windows app or in a browser. Nov 15, 2012 at 14:40
0

Another possibility is one input box for the entire table. This is how the search/filter box works in Windows Explorer.

The ability for one input box to work well with an entire table depends on the characteristics of the data in the table. If there is much overlap between values in different columns then one box may be a problem because (1) natural language filter terms will be ambiguous, and (2) non-natural language (e.g., System.FileName:="quarterly report") filter terms require learning a syntax.

Any of the designs provided (so far) in this answer are plausible.

The best design depends on a couple of factors:(1) the precision needed by the users, (2) the amount of data - both rows and columns - in the table.

From what I've seen in usability testing, when users are looking for a small subset of rows then the users sort first and filter second. When the number of rows that meet their filter criteria increases - which means they cannot scan the table and see beginning and end of the rows of interest - then filtering becomes necessary. Filtering is also necessary if the user is extracting data from a larger table and making a smaller table. In that situation, rows that do not match the filter cannot be present regardless of the size of the data.

I mention this because burdening the UI with a filter control per column may not be necessary if filtering is not the primary task in the table.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.