♪ [intro music] ♪ Have you ever heard of a game
called <i>Name That Tune?</i> The contestants bet
that they can name a song in fewer and fewer notes. and whoever claims the fewest notes
gets to try to name that tune. <i>Place Autocomplete</i> works a lot like that. A great autocomplete experience
guesses what you're looking for in as few characters as possible. The best is when I only have
to type in one letter, and the place I was looking for
is the top prediction. Let's imagine your<i>
Place Autocomplete</i> search bar is a contestant in this game
"Predict That Place," and you want it to predict
what your user is typing in four characters or less. Something a lot of developers don't know is that when you're adding<i>
Place Autocomplete</i> to your app, you can give it some clues
about where the user is or what kind of place they're looking for so that the right prediction
comes up in fewer characters. When developers don't provide these clues, the results can be a bit off base. For example, if I'm searching for
the London-Corbin Airport in Kentucky, I don't want to see
a bunch of results in the UK or other cities named London
around the world. If I use autocomplete
without any location bias, I have to type in eight to ten characters
to find what I want. However, if the developer
has implemented correct location biasing, I only have to type in three characters, and there it is. I'm going to teach you how to use <i>
Place Autocomplete</i> properties to get what the users are looking for
in fewer characters. The first clue to give
is location boundary. You can use location bias
and location restriction, depending on how exact you want to be to improve the quality of predictions and keep them
to the right geographic area. Location bias allows predictions
to come from anywhere, but the predictions closer to the bias
are weighted more, so they have a higher ranking
and show up closer to the top. Location restriction
sets strict boundaries that only offer predictions
that fall within the specified zone. First, define the boundaries
of your location property. The easiest way
is if you're displaying a map, capture the bounds of the map's viewport and set the location bias
to that viewport's bounds. You can also define a rectangular boundary by specifying the corners or the north, east, south, and west
latitudes and longitudes. If you know you only want
to deliver predictions inside the boundary, define it as a location restriction. In the Places Library,
Maps JavaScript API, and the Web Services Places API, use the <i>strictBounds</i> parameter to return only results
within a specific region. In the Places SDK for Android and iOS, it's referred to
as "location restriction." The second clue you can give is if your website or app is only used
in a small list of countries, you can set a property
called <i>ComponentRestrictions</i> to eliminate predictions
outside that list of countries. Countries need to be passed as a two-character ISO 3166
compatible country code. For example, "VN" would provide
only results in Vietnam. Here's an example
of specifying several countries to include in the component restriction. Side note, while you're thinking
about specific countries, you might be interested
in the language parameter to return results in a certain language. Searches will be biased
to the specified language, and results in that language
may be ranked higher. The third clue you can give
to <i>Place Autocomplete</i> is what kind of places
your users are looking for. Chances are your implementation
is probably being used for either typing in
an establishment name, like the Taj Mahal, or for typing in an address or a geocode, and that can help the autocomplete narrow down the possible
predictions significantly. You can use place type filtering
to present more relevant predictions. Pass a types parameter
to specify a type or type collection. Here is an example of what happens when a user inputs "g-r-e-a-t"
into a <i>Place Autocomplete</i> field with a location bias for New York. First, with no place type filtering, we see a mix of cities and establishments in New York and nearby states. If we filter for just geocodes, we see a street and a neighborhood appear alongside
the city name predictions. There's also a place type filter
for just cities. Now, if we apply a filter
to see just establishments, we get a very different looking
set of predictions. As you can see, specifying what type of place
is expected on the page where you're presenting <i>Place Autocomplete</i> can make a big difference
in what shows up. Thanks for joining me to learn more about how to make
your place autocomplete search bars win the "Predict That Place" game
with location and type properties. Although they're optional, they can turn a poorly performing<i>
Place Autocomplete</i> search bar into a winner that presents the right prediction
with just one character. There's a lot more I can tell you about how to improve
your <i>Place Autocomplete</i> performance and optimize the costs
when your app's usage scales. Check out my other videos about how you can master<i>
Place Autocomplete</i> to predict that place in fewer keystrokes for your users. Comment below to tell us what you'd like to see in future <i>Geocasts</i>. Thanks for watching and happy coding! ♪ [music] ♪ So I was watching old episodes
of <i>Name That Tune</i>, and I was really struck
by how intense it is. Like one contestant will say, "Jerry, I can name that tune
in five notes." And the other one will say, "Linda, I can name that tune
in two notes." And just using their names
makes it so personal. It's like too much. ♪ [outro music] ♪
