The new Places page and Google’s intentions

Much has been written about what Google left out in the Places upgrade and much speculation has been offered as to the reasons for the change. The specualtion have often made the assumption that the new design was a reactive response on the part of Google.

After looking at a large number of pages, I would suggest that the changes were primarily proactive in a nature and design driven (did I just say design and Google in the same sentence?). To get a sense of Google’s intentions I looked at a number Places pages in a range of industries and states and captured a screen shot of the information above the fold on a typical size screen 1280 x 1024 screen to see exactly which objects and activities had been prioritized. I captured the same Places page on my iPhone for comparison.

We all know of the call to action for additional reviews and uploaded photos those were very obvious. However Google made a number of other decisions in terms of how to prioritize the information. Here is the slide show and I think you will find the choices made interesting and design driven. Click to start the slide show:


While Google may have left some things off in response to complaints about their use of 3rd party reviews, for the most part the changes are a conscious design effort to make Places more interactive, more current and more social and more transactional.

They include a strong call to action (review, upload photos) and clear sense of priorities as to what is important going forward – even coupons now have a higher visibility – more user generated content, more understanding of your social circles intent and a greater desire, at least in the hotel industry, to use Places to “close” the sale.

Maps APIs over SSL now available to all

As public WiFi becomes increasingly ubiquitous, we spend more and more of our time on shared networks. This can expose our personal data to third parties if the sites we access are not secure. Many sites use Google services to store and manage Google data. In response to this, Google is today announcing improved support for SSL (Secure Sockets Layer) across many APIs, and recommending that any application that manages user data switch to using SSL.

We want to ensure that applications using the Google Maps API are free to follow this recommendation. As such we are happy to offer free access to the Maps API v3, Static Maps API, and Maps API Web Services over HTTPS to all developers from today. To load the Maps API v3 over HTTPS, the API must be loaded from the hostname maps-api-ssl.google.com. For the Static Maps API and Web Services, please use maps.googleapis.com.

In addition to offering access over HTTPS, all of the Maps APIs (with the continuing exception of the Places API) will continue to be accessible over HTTP, and we recommend that sites that are using the API purely to display public data, such as store locations, continue to use HTTP for optimal performance.

Please also note that although SSL access is now available to all developers, the terms of the Maps API have not changed. If your site uses SSL because you charge for access to your application, or because your application is not publicly accessible to all users, you must still purchase a Maps API Premier license. For more information on Maps API Premier, please contact the Maps API Premier Sales team.

We hope this change assists in making your users feel safe and secure using your applications. If you have any questions or concerns about this change, please post to the Maps API v3, Static Maps API, or Web Services forum as appropriate for the service you are using.

Improving the security of Google APIs with SSL

We at Google go to great lengths to ensure every step is taken to protect our users’ data. As part of our ongoing effort to improve security everywhere, we will start requiring the use of SSL in many products. Requiring SSL improves security by encrypting data communications between users and Google, better protecting it from being intercepted by a malicious third party.

Some of these changes have already occurred. Many user-facing Google products now allow or require SSL, including encrypting Google web search, defaulting to SSL in Gmail, and requiring SSL in Google Docs. Next on our list is to improve SSL support for our developer facing APIs. For most APIs, our technical documentation, client libraries and code samples already use SSL. Many new APIs and versions will be SSL only. Further, the Google Maps API, which previously offered SSL only to Premier customers, is offering SSL to all developers starting today.

Additionally, beginning September 15, 2011, Google will require that all users of Google Documents List API, Google Spreadsheets API, and Google Sites API use SSL connections for all API requests. Specifically, this change will disallow all HTTP requests, responding with an HTTP 400 Bad Request response. API requests will only be accepted via HTTPS. For example, a request to http://docs.google.com/feeds/default/private/full will no longer pull a list of a user’s documents. Instead, a request must be made to https://docs.google.com/feeds/default/private/full.

This change should be transparent if you’re using the most recent version of the Google Data client libraries, since they already use SSL for all requests. If you’re not using the latest version, then please upgrade as soon as possible. If you’re not using our client libraries, then simply change any use of an HTTP URL to its corresponding HTTPS version in your code. Your existing OAuth and AuthSub tokens will continue to work using the HTTPS URLs, even if they were requested with a scope that uses an ‘http://’ scheme.

Although we’re initially requiring SSL for only a few APIs (those whose traffic was already mostly over SSL), we strongly recommend that you convert all your API clients as soon as possible to help protect your users’ data. Check the documentation for each API for more information about that API’s SSL support, including the updated Google Documents List API documentation, Google Spreadsheets API documentation, and Google Sites API documentation.

If you have any questions or concerns about this change, please follow up in the forums of the API you are using.