Risk Complete Failure

On Monday the Google+ Javascript SDK team announced the release of a number of enhancements to the sign-in SDK on the web. These are all things that have either been directly requested by developers, or were created in response to something that developers have asked for, but I wanted to go into a bit more depth on one of the more subtle, but also very useful, changes. The feature is the combination of the page level configuration and the dynamic sign in callback. This simplify managing configuration for a page, makes managing sign-in state easier, and generally provide a much better feel for the user. Page Level Config The biggest change is moving configuration information from either HTML data- attributes or Javascript options to meta data on the page itself. This means that you won’t run into a problem of having one button configured with scopes A and B, but another with just A (which can lead to confusing situations), or miss out some app activity types. The configuration

Brian Balfour recently wrote an interesting post about the measures startups use at different stages of growth. In the early days of building a startup its really important to have a regular stream of users trying our the application or service, and for a decent number of users to come back and continue using it. Having decent retention makes it a lot easier to experiment. A group of real users to give feedback and spread word about your product is a worthwhile goal. Getting users to try an application is a pretty difficult thing, but the worst result is to have those users bounce having only scratched the surface of the product. If you get a user to the point of signing-in to your application, then its worth rolling out the red carpet to give them the best chance of having a good experience, and to give them opportunities to come back. One of the best things about using social sign-in like Google+ Sign-In is the access to services which you can use to enhance that out of the box ex

YouTube is an amazing resource for creating and discovering videos, but it is valuable for people building non-video experiences as well. Looking at YouTube usage is a great way of finding out what a user is into, and can help provide information to allow a more tailored out of the box experience. It's really easy to request access to YouTube alongside Google+ Sign-In, and then use the YouTube API to retrieve the user's watch history or their likes. YouTube offers several scopes for allowing access to different facets of the functionality, but in this case we will be using the readonly scope. This means the user only consents for the application to view their activity on YouTube, and doesn't grant it the ability to upload videos or subscribe them to channels. In an Android setup, we can request the scope with our call to PlusClient.Builder . Because the YouTube API is not part of Google Play services, we will also need to create a GoogleAccountCredential from the Goog

I wanted to explain a small addition that has recently appeared in the Google Javascript API that a couple of people have asked me about. You may have notice that the argument to the sign-in callback (which I'll refer to as authResult ) from the sign-in flow now contains an extra field: status . This simple object tells you a lot about how the user is accessing your page, and allows you to do some smoother and more reliable checks than before. See if the user is signed in to your app Rather than testing for the presence of the error or access_token properties, you can now test authResult.status.signed_in . This will be true for a user who has signed in to your app, false for a user that has not (or if we don't know, because they're not signed in to Google). See if the user is signed in to Google You could always use checkSessionState to see if the user had an active Google session, but now you don't have to make a separate call - that information is direct

These days there are few purely client-side applications - even traditionally unconnected software like casual games make use of servers and services to provide a better, richer experience - and importantly one that can follow the user across devices. We are in a world where we need to authenticate a user of many clients to a set of back-end services. There are a few ways of doing that when using a identity provider, like Google, but in this post I want to talk about a specific method that makes use of ID tokens. This approach has been well covered by Tim Bray for Android , but with the release a couple of months ago of the iOS 1.4.0 SDK for Google+, it is now available across Android, iOS and the Web. This makes it a particularly powerful way of signing in a user, and asserting the identity of that user securely to your application servers. Why ID Tokens This whole architecture relies on a point of view which I suspect is still not particularly common amongst developers impleme

I've written before about common technical problems with Google+ Sign-In implementations, but there is whole other class of errors that I've seen in applications. These generally aren't technical mistakes per se, but more about best practice. One the aims of the guidance on developers.google.com/+ is to promote a standard experience - users trust new applications because they behave in a way they expect. A good implementation does this, and makes all three parties involved happy: the app developer, the identity provider, and the user. Bad consent screens Common problems with consent are asking for more access or more scopes than are needed, and not adding a logo and clean name. For example, take this consent screen Here the app name is generic, and not tied to where the user was signing in. The app is requesting full access to both my Drive account and my YouTube data, and there is duplication - it asks for basic information, and basic profile. Each of these can

Once you get beyond the basics of adding Google+ Sign-In, and start looking at what is available across the Google platform there are some real gems to be found. One of these is a fantastic feature of Google Drive called appdata , which allows an application to store data in a user’s Drive account without worrying about the user fiddling with it. These is handy if you’re building something like a Javascript web app and need some storage, but don’t want to setup a server. Unlike localStorage or other browser based options it doesn’t rely on the user being on the same device, so it’s easy to allow users to access their data from wherever they are. Most of the time this sort of feature seems a natural fit for mobile applications - as Drive is about manipulating files - but it’s just a straightforward to build it in to a web application. There’s a little form in the iframe below - you can sign in and save your data, and then if you sign in to another device you should have the same data