Is it a good idea to use column headers as input boxes for filtering the results in a table?
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.
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.
Hope that helps.
Column headers are usually used for sorting.
And even if you will replace this functionality with filtering you will have to:
- Make sure it's discoverable (i.e., users will know how to filter using headers)
- Make sure column headers are still looks like a column headers (not all of your users will need filtering at all)
- Think about how to implement sorting (which are lost now, but could be still useful)
- Moreover, column headers are used for drag and drop of the columns sometimes, so you'll probably will miss this too.
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.
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.