So I have a very large, form based query - where user makes selections and filters by using checkboxes. Each click on a checkbox triggers the query automatically and the results are dynamically updated in a panel.

Though on one scenario, there is an exception:

User is required to enter a value to a input field after clicking the checkbox. I can't auto-execute the query until user enters a value.

My question is, once user has entered the value, what's the best way of continuing with the query execution.

If user remains in the input field after entering a value, I have no way of knowing whether they finished or still typing. I may trigger the query if user clicks outside the field - but user is not accustomed to have a second click action, due to auto-execute behaviour. User may not realise that they have to click outside the field to continue. I may have a time delay and trigger query after few seconds, but I don't think this is intuitive either.

Another possible solution to show a bit of validation text/colour around input field to indicate that user has to provide input and hit 'Enter' (or press a small button) to continue. But I don't like that either!

I appreciate if you have any ideas.

This is the checkbox to activate the input field:

enter image description here

  • Does the query need to be executed automatically? Is it a requirement? – Dimitra Miha Feb 23 '17 at 15:54
  • Correct me if I'm wrong, there are two questions: how to make user aware that he needs to enter text in the input for the results to update; and when to update the results once some text has been entered. Did I understand correctly? – Alvaro Feb 23 '17 at 15:56
  • 1. Auto-execute is a requirement. – Sahbas Has Feb 23 '17 at 18:46
  • 2. Main issue is 'when to update the results once some text has been entered'. Your first assumption is also correct but I can fix that. Thanks – Sahbas Has Feb 23 '17 at 18:47

Why not debounce the auto-executed query? Submit the query automatically after a brief pause.

This would prevent the app from firing 7 queries if the user types the word "Example" (e.g. "E", "Ex", "Exa", "Exam", ...), and instead would wait for a short break (~0.4 seconds) before querying. This would keep this part of the query as responsive as the rest of the search tools, and wouldn't require any additional steps for the user to continue refining his/her search.

Many auto-searches are implemented this way, and that seems to fit very well with the type of search experience you've implemented.

  • That's the problem! I can't know when/if user has finished typing so its not clear when to fire the query. Having a delay was also considered but that does not address the issue. What if user needed to wait/think before finish typing... it would fire the query and may get wrong results. Mind you, the query is very heavy, thousands of results may come back. – Sahbas Has Feb 23 '17 at 18:50
  • A live search query field follows a similar pattern as the existing behavior you describe. A well-implemented live search will not fire on every character the user inputs, but instead only after a brief pause. If multiple queries are sent, why should the user care? If a user types "Exa", pauses, a query is sent to your server, then continues with "mple", the browser should abandon the previous query and instead wait on the new one to return. If the first query comes back during the pause, then I don't see any harm in showing the results even though the user may not be completely done – maxathousand Feb 23 '17 at 19:06
  • If you are not wanting your "incremental query" UI to feel like a live search, then of course you'll need a way for the user to explicitly trigger the search. I was just trying to say that the "fire after every checkbox click" interaction feels more like a live search, so to have the user explicitly trigger the search would feel inconsistent. My suggestion offers a way to make it feel consistent with the existing pattern. – maxathousand Feb 23 '17 at 19:11
  • Thanks Max. Yes, user is accustomed to 'live' search by checking boxes and retrieving results so having the same pattern in text field is worth considering. I agree that explicit trigger for the input field is inconsistent. Each click cancels the previous query and starts a new one, so it may just work same with typing in text field. Hmm.. you have given me something to think about. So thanks for that! – Sahbas Has Feb 23 '17 at 20:17

I assume most of the possible cases can be covered here with a Slider and a text field that can accept value in Ranges, like Export Artboard option in Adobe Illustrator (10-30), (more than 40, 40 or more), (50).

Everytime the slider Stops results will be updated & we can prompt user to press Enter only if he has used Text field as input.

Also whenever user interacts with the Text field - slider and range checkbox changes accordingly.

Default enter image description here

Sliding Min value slider enter image description here

De-select Range option enter image description here

Entering Text enter image description here

  • Thanks very much for taking the time and showing a wireframe. This is only one type of field, there are other type of pickers user still have to manually enter text/words etc. I need to check the other instances to see if I can get away without input fields. – Sahbas Has Mar 6 '17 at 16:10
  • Welcome :) Somehow, Pressing Enter to confirm textual input seemed like a sensible option to me. – Rajat Mar 7 '17 at 3:58

Your Answer

