A Better Search Field for OpenStreetMap


Web site search fields are weirdo UI elements. They usually give you no clues as to what to enter, so you’re left to your own devices. Do I enter a question phrase? A keyword or two? Getting to the right information using a search box is still not very straightforward. This is the reason why people don’t use them very often. Navigating a menu structure or site map is usually quicker and requires less thinking.

Google's autocompleting search field providing insight in the Big Questions that are on our collective minds.

The role of the search field has become somewhat more important when it started to receive some interactive AJAX-style love. Many search fields will now come up with suggested results in a drop-down item when you type a few letters. This makes interacting with a free text field much more responsive and tells you if you’re on the right track with your search strategy. Autocompleting search fields can now be found on many big web sites. Google recently upped the ante with its new Suggest feature, showing a full results page preview instantly. We’ve come to a point where old-fashioned search fields start becoming a disappointment. You type, you wait for suggestions to pop up. Nothing happens. Fail.

Still, that is what happens on the main OpenStreetMap web site. Only when you hit ‘Enter’ do you get to see search results. And even though the results page is much improved since it started using the Nominatim engine and it started to incorporate results from Geonames, it still is far from perfect. Having used the OpenStreetMap search field a lot, I came up with the following wish list that would make it a much more usable thing:

  • Suggestions
  • Heed My Location
  • Bigger is Better
  • Bigger is Better

Let me elaborate.

Suggestions

Autocompleting search field for OpenStreetMap using Nominatim and Google Closure

Like I said. Not suggesting results is starting to become a major UI fail. On the front end, it is not hard to implement. I did a prototype the other day based on the Nominatim API and the Google Closure JavaScript framework. All it required was learning how to call the Nominatim API, learning how to do an autocomplete text field in Google Closure, and bringing the two together with a PHP wrapper around the API call. You can try out the result for yourself here. (If it’s down, my server has croaked or my home internet connection fails. Be patient.)

Playing around with this, and comparing it to the Google Maps search box, I noted a few things that would make this prototype work a lot better. Some of this is front-end hacking, some of this might need to be coded into the back end search engine, Nominatim.

Heed My Location

I assert that the big bulk of geographical name searches entered on a mapping web site fall in one of these two categories:

  • Either they are local searches for something on the large scale: POI, city street, bus stop.
  • Or they are global searches for something on the small scale: country, capital or major city, national park, major airports, et cetera.

It would make sense if the search suggestions would be optimized to take this assertion into account. It could do this by following this path

  1. Detect the user’s location when the page loads.
  2. When the user enters a few letters, fire a large scale name search using a small bounding box (10x10km maybe). This would be done against a dataset that includes all streets and POIs.
  3. Display the results, if any, in a drop-down suggestions box.
  4. Then fire a second name search, a global one this time, that runs against a database of important small scale features.
  5. Append these results to the ones already displayed from the initial local search
  6. If both searches yield nothing, perform a classic global large scale name search

This way, the search field response could be much improved, both in response time and in result relevance, while decreasing server load.

Bigger is Better

suggestions for 'nieuwe' on Google Maps when zoomed in to Amsterdam

Improved result relevance is a good start, but it would make even more sense if the suggestions would be ordered in a way that you would expect them to. When I enter ‘nieuwe’ in the search field and I am in Amsterdam, there’s bound to be a lot of results: ‘Nieuwe’ means ‘New’ in Dutch and a lot of streets start with those letters – both important streets with lots of traffic and businesses and small streets with little or no public destinations on them. I assert that most searches are going to be for the important streets, so I want those to show up at the top. This is what happens in the Google Maps search field and I think they succeed in predicting the most relevant results for a geographic search quite well.

Bigger is Better

I’m not about to repeat myself, this is about the size of the search field. To let users know that the search field is actually a very friendly and fast way to get to the part of the world you want to see a map of, it should be more inviting and more prominent on the site. The way to do this is simple, make it bigger – like I did in my prototype. OK, maybe not that big – but it does make a lot of sense. Users are afraid of free-form UI elements so we need to make them less intimidating. Believe it or not: bigger text fields are less intimidating than small ones, and if they work well, they are an important part of the user interface, and that importance should be reflected by its relative visual impact.

About these ads

6 thoughts on “A Better Search Field for OpenStreetMap

  1. Nominatim bases results on the area you’re viewing (to some degree).

    Does OSM.org not detect which country you’re in by IP? Yes it could know a more detailed location these days, but personally I don’t let my browser tell websites and it would only seem creepy if the map was zoomed on on where I was.

    • Gregory,
      Thanks for your comments.

      On location detection: What some find creepy, many will just file under added convenience. Whichever way you feel about it though, this geo-IP information is just out there, so exposing your IP address means exposing your location to anyone who chooses to link this information. If you’re not comfortable with that, you should probably use a anonymizing proxy server.

      That said, some of the elements of a good search experience I mention are just as attainable without location detection.

      On location awareness: OSM.org does do that, and Nominatim does take the visible extent of the map into account. So some steps in the right direction of a good user experience are definitely already taken. For an autocompleting search field, some improvements are necessary though. I am not familiar with the internals of Nominatim, but it seems to favor full name matches, which is not what you want when you do autocompletion and your typical query will be a partial name.

  2. I get the feeling it does autocorrection better than autocompletion. If I type Roesela (to get Roeselare in Flanders), I only see Rosela in Indonesia. I guess less correcting and more completing, together with rough geo information would be better.

    for the rest, I really like the service. It goes a lot faster than the current search.

    • The actual behavior of the autocomplete field is almost exclusively determined by what Nominatim returns. So improving this – and I agree it can be a lot better, as I mentioned in the blog post – means delving into Nominatim development. I would love to but lack the time at this point to invest in this, unfortunately. I hope someone feels inspired to take it a step further, though.

  3. Pingback: Weekly OSM Summary #1 | OpenStreetMap Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s