Any thoughts (or better yet - resources) on the pros/cons and usability concerns for either of the two design approaches regarding data filters? We’ve been having this discussion in our department for some time, and I’m just looking for some solid UX/UCD reasoning for either to bring to the table.
Scenario:
You’re displaying a list/table of data, which has more than 5 columns of data, and spans multiple pages. You want to have filters on at least 4 of the columns, possibly all of them (the point being - there are numerous fields). Your users are average non-technical business managers who are comfortable with computers, but wouldn’t have a high-level of experience.
Option 1: Traditional
Option 2: Inline-column (event driven, or with a “search” button)
The advantage of the ‘traditional’ design is that it is clear that you type in the filters and hit the ‘go’ button. That doesn’t strike me as quite so immediately obvious with the ‘inline’ design, especially as you haven’t shown how you’re going to integrate the ‘go’ button. On the other hand, the ‘inline’ design makes it much more obvious which text box matches which column – it depends if people are likely to get that wrong with the ‘traditional’ design.
I haven’t seen any studies on this choice before. Maybe you should pioneer it! Get a few of your customers or people in a similar context and get them to try the two designs out, half of them doing one first and half doing the other. See what they do, and see what they say.
As you stated - those are the main two perspectives and arguments. As always, these things are somewhat subjective and there isn’t a hard and fast right or wrong answer. I think I might do a case study like you suggest…
To better explain how the “go” button would be integrated… there are two ways we’ve addressed it before. You can either add a small “go” button at the far right (on the same row as the fields) or you could do a more ajax/event driven approach (which is a little more technical).
With the event driven approach, the list is filtered “live” as they type. This can be done with a short (.5 second) delay so it isn’t filtered on every key press, but rather as soon as they stop typing. This eliminates the need for a “go” button at all. Of course, this introduced a further aspect into the usability/UX…
That sounds like a nightmare to me - a recipe for a database full of typos. Or perhaps the average business manager has considerably better typing skills than I have? (Wouldn’t be hard!)
These are search fields, not data entry… Not sure how that would have any effect on the database? You’re right though, if these were data entry fields, it would be horrendous.
You will need to include a ‘go’ button to make the filter accessible to anyone without Javascript, for a start. You’ll also need to consider the typical computer setup of your customers. That kind of funky feature can really slow a site down – I know that at work, our computers are old and useless (not unlike certain colleagues (ahem, did I say that out loud?)), and anything like that is a nightmare to use. I will only Google search by typing into the address bar now, because the live sorting if I use Google’s search page is too much of a PITA.
The OP won’t need a GO button if this is some internal environment where JS is always on.
However if this is on the web, then agreed.
It might be valuable to know what programs (on the Desktop, or in their mail) these people are already using; that ought to strongly influence which scenario makes most sense.
You can also combine the two: using the first setup, still have the inputs as one long strip, mostly matching the columns below, and then user test which side the submit button goes on (since lower right and lower left aren’t always the same, as SitePoint found out after the recent forum upgrade lawlz).
