A change to how maps are displayed on your event page

Doorkeeper allows you to display a map to your event's venue on the event page. Due to changes in Google Maps, we're displaying this map a little differently, and the map pin will now be automatically displayed based on the venue's name and address. Previously, we allowed you to manually tweak the exact location of the pin, but due to the change in Google Maps, we can no longer support this.

While the automatic detection works in most cases, sometimes Google Maps will fail to detect the location of the venue, in which case the map will not display any pin. Because of this, we'd encourage you to double check that your event's maps are still displaying properly. If the map isn't displaying properly, see this article for details on how to fix it. We're sorry though for the inconvenience cause by asking you to double check your maps.

Rationale behind the change

We thought we'd provide a more detailed explanation of why we chose to do things the way we did. If you're interested in how Doorkeeper approaches software development, read on, otherwise you can ignore the following.

Background

When we started to show a map on Doorkeeper's event page, Google Maps was the logical choice. At the time (around 2011), Google Maps was the only mapping API we were aware of that was both simple to use and had good support in Japan. Furthermore, it was free to use, so it was an easy choice to adopt it.

In May of this year, Google announced a change in their pricing. For the integration method that we were using, rather than being free, it was now going to be $7 per 1,000 requests. At Doorkeeper, we're happy to use other paid services, and if our application made extensive use of Google Maps advanced features, perhaps it would have been worth paying. But as Doorkeeper is only displaying a map of the event's location, we couldn't justify this price.

Approaches we considered

The announcement of the change gave us just a bit more than a month before the new pricing went into effect. So while we wanted to consider the different approaches, we also needed to quickly move forward with this change.

Google Maps Static Maps

Google Maps priced their Static Maps at a slightly cheaper $2 per 1,000 requests. With Static Maps, we could operate largely as we did before, still allowing the organizer to choose the precise location of the pin. Because of this, as a first step, we switched from Dynamic Maps on the event page to Static Maps, optimizing so that we only load the map when a user scrolls down the page to view it.

However, Static Maps didn't seem like a viable long term strategy to us. The pricing still meant it would be a significant cost, and one that doesn't necessarily scale with our pricing. For instance, it could be possible for a popular free event to end up resulting in us incurring more costs from Google maps than the event generates in revenue for us.

Furthermore, Static Maps didn't offer an easy way for us to display the map nicely across a range of screen sizes, from mobile phones to desktops. It also lacked any of the interactivity, such as zooming or scrolling the map, that Dynamic Maps offered.

Because of this, we decided to go with another solution.

OpenStreetMap

OpenStreetMap is a collaborative project to create a free editable map of the world. We love the idea of OpenStreetMap, and because there is a strong Japanese community behind it as well, the Japanese support has improved dramatically in recent years. However, we ultimately decided against going with it.

The primary reason was that we couldn't come up with an easy drop in replacement for Google Maps, that would allow us to easily display a pin on a map based on a Japanese address. Because of the tight deadline and limited resources, we only took a quick look at doing this, and its possible that we overlooked a simple solution.

We're optimistic about the future of OpenStreetMap though, and will certainly consider switching in the future.

Google Maps Embed

With Google Maps Embed, we could offer the event participant largely the same experience as before. In some ways it was even better, as for instance, it allowed the participants to easily bookmark the venue on their personal Google Map.

The main downside to this approach was that it provided us with no way of specifying the exact location of the pin. Originally, we felt this was important, as Google maps location data for Japan was not so good. However, in recent years, their data has improved significantly, and they have the location of almost every venue in Japan. So from a longer term perspective, we felt that only supporting automatic venue detection would be acceptable.

Rather than requiring existing organizers to double check their map, we considered using the old approach for existing events, and only requiring organizers to migrate to the new approach when creating a new event. Ultimately, we decided against this for a couple of reasons.

First, as we found that when Google Maps couldn't properly detect a location, it showed no location at all, the downside of broken maps seemed relatively minor. Participants might not be able to see a map, but they weren't going to be led to the wrong location either.

Second, doing this in a completely backwards compatible manner would require more development resources. Because it added extra complexity, we'd need to be careful that we didn't introduce any new bugs. We'd also need to consider the transition path, such as what happens when an organizer copies an old event to a new event. If the payoff for doing this in a backwards compatible manner was larger, we could have justified the cost, but in this case it didn't seem worth it.

There is one more downside with Google Maps Embed: Google reserves the right to display advertisements on the map. We pride ourselves on having the event page be dedicated exclusively to the organizers goal of getting people to register for their event, and so don't have any advertisements or other promotions on the page. While it doesn't appear that Google Maps is intrusively advertising now, that could be something they change in the future, and would mean that we'd need to re-evaluate our options once more.

But for the short term, Google Maps Embed seemed like our best option. With that settled, we had to decide how to tell Google to generate the map address, as it only provided a generic query field to search for a location. We considered giving them the venue name, the address, or some combination of the two.

Only passing in the venue name often resulted in ambiguous results, so we decided against it.

Only passing in the address found the location the most often. However, it meant the location name wouldn't be displayed nicely on the map, showing up as "7F" for an address that was indicating it was on the seventh floor, or sometimes even as a different company name than shared the same address. Because we thought this might lead to confusion, we also decided against it.

The combination of venue name and address displayed the results the nicest. The location wasn't ambiguous, and the venue name displayed on the map matched the venue itself. However, we found that sometimes Google couldn't find the location at all, while it could when we only passed in the address. But we decided that as organizers could correct this issue by tweaking what they put in the name and address field, we'd optimize to display the map in the nicest way possible, and go with this approach.

We'd love to hear from you

If you've read this far, we'd love to hear from you. Is this kind of detailed explanation behind the decisions we made interesting to you? Do you have another suggestion for an approach we missed? Leave us a comment here, or getting in touch.