Dynamically Adding Fields For Searching Upon User Entry

Question

I'm implementing a 'query builder' for searching data in my application. The users will select the table they are searching in, the field in the table, and the value to search for.

Here's what it looks like initially (area is larger than picture and will eventually scroll once there's 10 or so rows):

I'm stuck in determining when/how to add a new row for search criteria to the screen. The screen currently starts by displaying a header and an initial row. I think it should add a new row for search criteria once the previous row is completely filled.

Other's that I have talked with think it it's better to have a button to add a new row. Either next to each row (graying out after it's clicked) or near the table headers.

I see pros and cons to both. You obviously are ready to enter any new search criteria once you completely fill in a row of criteria. But, it may distract the user from what they were doing if a new row suddenly without explicitly requesting it. Thoughts?

Answer 1

Firstly, do you know how many rows the typical search is? If they're power users and always have more than 3 rows of search criteria, it may require a different solution.

It might be an idea to start out with 2 or 3 rows showing already, so that the user knows that they can enter multiple search terms from the get-go.

And allowing the user to choose how many rows to add rather than one at a time may be great for your power users who know what they need. If I opened up that form on a daily basis, I might know I need 5 rows immediately, so I can add those rows at the start and then plug away with my keyboard and tab button to fill all the fields in quickly.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Having a specific action below these items also means the user doesn't have to disrupt their line of work by going up to the header to add a new row if they're filling in the form in sequence.

But the most important thing I think is to test with some typical users. You'll soon see if they're frustrated by having only one or two rows to start off with, or having to manually add rows pains them.

Hope that helps with some ideas. :)

Answer 2

If I may make an analogy to being on the road, having an add row button is the equivalent of a speed bump, and a new row of inputs appearing automatically is like consistently getting a green light on the intersection. Neither option is better than the other, it depends on the application.

The better option in this case depends on the average number of queries the user makes, and the relative complexity of the queries. If you imagine your users consistently adding at least 3-5 rows and the queries themselves are simple (meaning the user already knows what they want to type and search for), then yes you would want as little friction as possible, as the add button will just be the 'speed bump' that gets in the way of them typing their full query as fast as possible. Usually the power user type, who I can imagine pressing tab to move through the fields as fast as possible.

If however, each query requires a bit of thought or scanning a dropdown each time as I see you have, or if having more rows will be less frequent than having less rows, then an 'add' button might make more sense. It's no use adding a new row automatically - besides disrupting their flow as you mention, if they are still taking their time finishing or thinking of the previous query (the driver going slow on the road). So what is the rush in that case? This also allows users to add multiple rows of queries at a time, which might be helpful if the queries can be complex (the user work on multiple queries at once if it helps him/her realize what they are searching for in their head)

My only suggestion with the second approach, if you decide to implement the 'add' button, is to keep the button below the row so that it moves down as the user adds more rows. This is less work for the user to click that button from where they are on the page, vs having to always go back to the top.