Search call is not triggered on certain typing events in an autocomplete field

This is expected behavior. Your "normal typing speed" is faster than the delay and you're pasting the same value that already exists. In both cases, by the time the widget checks if the value has changed, it has not. I also disagree that it's ordinary for someone to paste the existing value into a text box.

Replying to [comment:1 scott.gonzalez]:

This is expected behavior. Your "normal typing speed" is faster than the delay and you're pasting the same value that already exists. In both cases, by the time the widget checks if the value has changed, it has not. I also disagree that it's ordinary for someone to paste the existing value into a text box.

Hi Scott,

Thanks for responding so quickly.

I agree that the widget should check that the value has changed before sending out triggering the search call.

However I respectfully disagree with the GUI behaviour.

I have one chief assumption of the functionality of the autocomplete widget, which may differ from yours:

A user expects an autocomplete field to consistently '''display results, if any''' whenever a typing event has occurred in the field.

Do you agree that this is a reasonable assumption?

Please note that this assumption does not mean that the autocomplete needs to re-trigger the search call if the input is the same as the previous - just that results are displayed consistently based on the input.

Picture this:

1. A user types in "ja", the results are shown.

1. He/she blurs the field.

1. Say the user wants to see the same autocomplete results again. Then he would type in "ja" again right?

1. However the end result since "ja" typed now is the same as the "ja" entered previously is that the '''previous results aren't re-displayed''' - to reiterate, it appears to the user that nothing happens.

In my humble opinion, this behaviour is unexpected and inconsistent with the assumption above, and gives the impression that the autocomplete is broken.

Look forward to hearing your perspective.

Let's take real-world examples of my assumption above:

1. Mac's Spotlight exhibits behaviour in line with my above assumption

1. Safari's Google search field exhibits behaviour in line with my above assumption

1. Google's Instant search exhibits behaviour in line with my above assumption

In all three case above, a user is able to re-enter the same input as before and consistently be shown results.

How strange would it be if I were to type in say "jquery" in Google, and then retype it, getting 0 results the second time I typed it?

Replying to [comment:2 ebunton]:

> A user expects an autocomplete field to consistently '''display results, if any''' whenever a typing event has occurred in the field.
> 

Then turn off the delay. We intentionally don't do that because it will hammer remote services.

Do you agree that this is a reasonable assumption? Please note that this assumption does not mean that the autocomplete needs to re-trigger the search call if the input is the same as the previous - just that results are displayed consistently based on the input.

Separating the search and the display requires caching results, which does not belong in the base implementation.

Picture this: 1. A user types in "ja", the results are shown. 2. He/she blurs the field. 3. Say the user wants to see the same autocomplete results again. Then he would type in "ja" again right?

Or press the down arrow.

4. However the end result since "ja" typed now is the same as the "ja" entered previously is that the '''previous results aren't re-displayed''' - to reiterate, it appears to the user that nothing happens.

There are multiple solutions here: turn off delay, press the down arrow (which requires less effort), customize autocomplete to clear its internal previous value on blur.

Replying to [comment:3 ebunton]:

Let's take real-world examples of my assumption above: 1. Mac's Spotlight exhibits behaviour in line with my above assumption

Actually, it's impossible to blur spotlight. You could easily build spotlight with jQuery UI by clearing the internal previous value on close.

2. Safari's Google search field exhibits behaviour in line with my above assumption

Safari's search field is arguably worse than jQuery UI. Type "ja", then press backspace and watch all results disappear.

3. Google's Instant search exhibits behaviour in line with my above assumption

Google's instant search is completely separate from their autocomplete, they just happen to run simultaneously. I assume you want to discuss the actual autocomplete behavior since Google would obviously not blank out the page during instant search. Go to Google, type "ja" to turn on instant search, copy the value, press escape (to close the autocomplete), tab out, tab back, paste and watch as absolutely nothing happens. If you retype "ja" you'll get results, but again, that's instant - we do the exact same thing if you turn off delay and make the jQuery UI autocomplete instant. You'll also notice that if you type "j", blur the field, refocus the field and type "j" again, nothing will happen.

Replying to [comment:4 scott.gonzalez]:

Replying to [comment:2 ebunton]: >

> > A user expects an autocomplete field to consistently '''display results, if any''' whenever a typing event has occurred in the field.
> > 

Then turn off the delay. We intentionally don't do that because it will hammer remote services.

Yes obviously. I'm sure you understand that from a purely user perspective, the technical implementation doesn't matter - so long as an autocomplete field behaves consistently.

> Do you agree that this is a reasonable assumption? > Please note that this assumption does not mean that the autocomplete needs to re-trigger the search call if the input is the same as the previous - just that results are displayed consistently based on the input. Separating the search and the display requires caching results, which does not belong in the base implementation.

You haven't indicated whether you believe that this is a reasonable assumption of functionality from a user perspective.

> Picture this: > > 1. A user types in "ja", the results are shown. > 2. He/she blurs the field. > 3. Say the user wants to see the same autocomplete results again. Then he would type in "ja" again right? Or press the down arrow.

I'm sorry but this is a rather curt, odd and unexpected response.

Clearly we aren't here to dictate what user should and shouldn't do depending on an implementation detail in the code.

> 4. However the end result since "ja" typed now is the same as the "ja" entered previously is that the '''previous results aren't re-displayed''' - to reiterate, it appears to the user that nothing happens. There are multiple solutions here: turn off delay, press the down arrow (which requires less effort), customize autocomplete to clear its internal previous value on blur.

Thanks for the suggestion. Clearly turning off the delay is not a clever solution, since it hammers the server, as you point out above.

I will of course now attempt to customise the autocomplete so that it simply re-displays its last results if a user retypes the same query.

I will try to ensure that jquery does not actually destroy the previous results, but simply hides them, in case the results need to be re-shown.

Replying to [comment:3 ebunton]: > Let's take real-world examples of my assumption above: > > 1. Mac's Spotlight exhibits behaviour in line with my above assumption Actually, it's impossible to blur spotlight. You could easily build spotlight with jQuery UI by clearing the internal previous value on close.

Yes, it is impossible to blur spotlight.

That is clearly not my point.

> 2. Safari's Google search field exhibits behaviour in line with my above assumption Safari's search field is arguably worse than jQuery UI. Type "ja", then press backspace and watch all results disappear.

Yes, the backspace behaviour is a poorer implementation.

Again this is not my point. It would be great if you could stay within the bounds of the discussion.

> 3. Google's Instant search exhibits behaviour in line with my above assumption Google's instant search is completely separate from their autocomplete, they just happen to run simultaneously. I assume you want to discuss the actual autocomplete behavior since Google would obviously not blank out the page during instant search. Go to Google, type "ja" to turn on instant search, copy the value, press escape (to close the autocomplete), tab out, tab back, paste and watch as absolutely nothing happens.

Which is still acceptable since google keeps the "ja" results displayed.

If you retype "ja" you'll get results, but again, that's instant - we do the exact same thing if you turn off delay and make the jQuery UI autocomplete instant. You'll also notice that if you type "j", blur the field, refocus the field and type "j" again, nothing will happen.

I find your argument rather weak since Google's implementation is bolstered by their Instant Search. They always show results (autocomplete or otherwise) when there is a match.

Arguably, the last point you make about typing "j", blurring, and then typing "j" again in google is a bug as this is plainly inconsistent behaviour. However it doesn't appear like a bug since google keeps its results on screen for that "j" query (pardon the pun).

All in all, I'm a disappointed by your seemingly snarky comments to what I think is a very reasonable expectation (something which you have not expressed an opinion... perhaps deliberately?).

Thanks anyway for your time in responding.

I wasn't trying to be snarky, I was trying to point out that you're comparing the default behavior of jQuery UI's autocomplete widget to customized implementations out in the wild. I could go into extreme detail about why your comparisons are completely invalid, but since the simple explanations didn't help, I don't think detailed explanations will either. Your argument was that we should behave a certain way because others do, so I argued against that by saying that's not what they do or by pointing out that they're not good models to blindly follow.

I don't think pressing the down arrow is an implementation detail. It's how every dropdown and combobox implementation that I'm aware of works, and how most autocomplete implementation work as well.

I could potentially see clearing the internal value on blur as an improvement, but that won't address all of your issues (and I don't believe all of your issues should be addressed).

Replying to [comment:6 scott.gonzalez]:

I wasn't trying to be snarky, I was trying to point out that you're comparing the default behavior of jQuery UI's autocomplete widget to customized implementations out in the wild. I could go into extreme detail about why your comparisons are completely invalid, but since the simple explanations didn't help, I don't think detailed explanations will either. Your argument was that we should behave a certain way because others do, so I argued against that by saying that's not what they do or by pointing out that they're not good models to blindly follow.

I regret posting the examples as they clearly have derailed my chief point on expected functionality.

I'm just trying to be helpful here and present a case where jquery's autocomplete could exhibit best of breed behaviour.

I am unsure how to express this better than the following:

Users expect that when they re-type a phrase in an autocomplete field, matching results should appear every time consistently and without fail.

I can only urge that you run usability testing of a suitable sample size to objectively judge what a user might expect.

The reason why I have submitted this as an issue here is that in real-world usage, our users have given us such feedback.

I don't think pressing the down arrow is an implementation detail. It's how every dropdown and combobox implementation that I'm aware of works, and how most autocomplete implementation work as well. I could potentially see clearing the internal value on blur as an improvement, but that won't address all of your issues (and I don't believe all of your issues should be addressed).

There is only one issue here, as I have made above in bold.

Let's bring this to a close: please let me know whether you agree or disagree with the bold text.

At some level, we disagree, which is why the existing functionality exists. Feel free to start a discussion on the forum about specific cases where you think a search should be run and we can discuss individual cases.