Search results do not always populate fast enough in drop-down menu

[smarziano]

We have been dealing with this issue for awhile even before we updated how the search worked (see milestone: https://github.com/smartchicago/chicago-early-learning/milestone/16?closed=1).

When users are on slower connections, or if they type very fast (too fast for their connection?), the search results do not populate in the drop-down menu and the user is led to the general /search page. This causes the user to think that there wasn't a match to their search keywords (we've heard this from our partners multiple times).

A couple of ideas:

• Determine if there are ways to show results faster in the drop-down menu
• When the user starts typing show a loading symbol in the drop-down to indicate that the system is working
• Disable the search button if someone starts typing in the search box (I don't think this helps if they press enter and is probably my least favorite solution)

[theandrewbriggs]

Short Term Solution I can push right now, which I don't particularly like:

JQuery's Autocomplete feature--what we use for the drop down populated with search results--has a built-in delay of 300milliseconds. What this means is after every keystroke, the javascript behind the search bar waits up to 300ms before executing the code that a) matches queries against our list of location names and b) searches the Google Places API for addresses. If a user presses another key within that 300ms window, the timer starts over and no search takes place.

We have control over the value of this delay, and can even set it to zero if we really wanted to (i.e., executing search code at every keystroke). The problem with this is, if in fact this is a problem affecting users who have bad internet connections, we're suddenly having their browser send exponentially more API calls to Google, possibly slowing their connection even more.

Setting the delay to something like 150ms might be a better compromise, but if that's still not satisfying partners then a UI-focused solution (to signal that information is coming) will probably be the best alternative, as well as an additional search that catches for this specific scenario (I'll detail this fix below later on).

**I should note that I am generally skeptical of this being a problem in real-world use. I tested this in Chrome, which has built-in speed-throttling tools, and it wasn't that much slower. I have a longer term solution for this problem which I'll address later, but this is something we can evalutate by building into our Google Analytics collections.

[theandrewbriggs]

Medium Term Solution (which could probably be implemented relatively quickly):

We probably should have had this from the beginning, but a catch-all for this specific scenario - if the search form is submitted before the Google API code is returned, a separate call should fire to Google's API, and send the map to the first valid address returned by Google. If Google returns no matching results, throw an error.