Tough call.

I generally like autocomplete, but 11K entries, if they average 20 Unicode characters is 44KB... which is a pretty big payload. If you load them with ajax and the user is on 3G or satellite, latency will be a killer and if the list is long, it may be difficult to navigate on mobile.

The other option necessitates two extra pageloads or AJAX loads of data, but with relatively small payloads.

So.... what about a hybrid - load all the states and provinces on first page load. That's a small, mobile-friendly payload. Select the country, use that to filter the states/provinces. On select for the state/province, run the AJAX call to load the towns into a select list and have that allow either scroll or autocomplete

I was, for a while, using a site with a massive select list and ended up writing a Tampermonkey script for Chrome that loaded Chosen. Chosen lets the user decide between autocomplete or scroll and select - both methods work

[harvesthq.github.io...]

Thanks for the input ergophobe. I asked a question expecting one type of response but now you have brought my attention to another issue, size. I hadn't thought about that.

My file also contains geolocation data, so when the user selects a town they are really inputing the geolocation. As a result, the file size is 8x bigger than your estimate uncompressed and 3x compressed.

I need to think about this...

The country selection is only two, so that is not a problem and the state/province selection is 65 long so that could be local (on-page). Then only one ajax call would be required, but I would need to create 65 json files and maintain them. Maybe a db-call would be better.

Also I am using Twitters Typeahead.js with Bloodhound, so it does a great job of matching user input with the places, and one can limit the number of selections, I have set it to ten. This keeps the list short enough that it just fits the screen without scrolling. If the user doesn't find what they are looking for they just keep typing.

Sorry... I realize I have a typo too regarding size - I meant 440 KB (and I typed it wrong the first time I typed it here as well... my fingers don't like typing zeros I guess). So you're doing better than I was thinking. I don't think 120KB is a big payload at all - one small/medium image can easily be that much.

>>create 65 json files and maintain them... maybe a db-call

A lookup table keyed to country and state/province and indexed would take microseconds for the lookup. Even as a three-table relational setup it should be very fast. Given the total size of the data set (small), you might even denormalize the data and have it all in one table, which I'm guessing would be even faster - no relations, no joins, just a key lookup on your index. So if you're thinking of avoiding the DB because of speed, I wouldn't bother if going to a DB would save you labor in the long run (and assuming you're using a DB in some way anyhow - if you're otherwise not using a DB for the site, then you might just find text files easier and faster anyway)

I've built some "event" pages that just hooked into the Google Maps API or the Open Layers API for event location and let those tools just handle it all in the background. The thing that's nice about doing it with the Google Maps API is they don't even need to get the spelling right - Google applies all it's map knowledge to guessing close matches. I'm not sure that's the best solution on mobile, and it doesn't sound like it would match your implementation needs anyway (not if you're allowing ten choices anyway).

I wish I had better insight on this, but I just haven't given it a lot of thought and even less real-world implementation.

Thanks again ergophobe this is valuable input.

So taking what you explained above into consideration plus some other factors that I did not disclose, I did a bit of a rethink to the design.

What I didn't mention is that I plan on having a second field in my form with an autocomplete, so this essentially doubles things.

My plan was to have a simple search field where the user can search the item by name. This field would have an autocomplete populated with the name of items in the DB. If it is not in the autocomplete its not on the site. This assumes that the user knows exactly what they are looking for and with long names that can vary in semantic structure finding what you are looking for even with an auto suggest may not be so easy. Example of semantic structure variations one possible name would be "Widget Party New York City" [Type, Event, Place] or another name for the same entity could be "Sponsor, Branded Party Name" [Organizing Entity, Brand]. So in this example if the user looks for an event assuming it will be named using the first semantic structure using a search term such as "Party New York", but the organizer names the even using the second structure then the user does not find a match.

So to solve this problem, I have added an advanced search function where the users can search by the most relevant features such as location and date.

Now back to the problem at hand.
The most critical speed issue is to get the page displayed such that the user can see and begin to interact with it. So my idea is to get the content of the advanced search using an ajax call only if the user selects the advanced search option. As such, only the basic search field appears with its autocomplete. If that is all the user needs then great, nothing else is loaded, and everyone saves bandwidth and time. If the user selects the advanced search then we load it and the autocomplete data, but in this case the size is limited to basically the autocomplete data and at about 120kb this should be pretty fast, any latency will most likely be taken up by the users interacting with the other fields of the form.

As for the Database
I am using MongoDB nosql, so the data is already denormalized. If needed I will create a collection for each autocomplete and update it only when needed. I assume location data should be pretty static. And name data will be added whenever a new entity is added to the DB which isn't that often, so the cost of the extract insert will be negligible.

Cool. It occurred to me that you might not be on an SQL DB at all.

Sounds like a reasonable plan... hopefully it survives its first encounter with the enemy.

[Helmuth van Moltke: “No plan of operations reaches with any certainty beyond the first encounter with the enemy's main force.” I think this is true with respect to user interfaces as well!]

I'll let you know if it survives its first encounter.