JOANNA SMITH: Good afternoon, everybody, and welcome to this
week's episode of Google+ Developers Live, where I'm
going to take some time to discuss
our developer policies.
And the reason that I wanted to do this episode is because
I wanted to be able to make it comprehensible, to define the
key points and break it down in a way that's easy to
understand.
I also want to emphasize that these policies are designed to
ensure that there's a consistent user experience.
We want our users to know that when they click on something
that has the Google name or the Google+ name on it, they
understand what's going to happen next.
And the other thing that is an advantage of this episode is
that the approach here is that these are the things that we
look at when you apply for additional quota.
So if you want a higher rate limit on some of the calls you
make, you need to make sure you're already compliant with
some of these tips and tricks.
And that'll make sure that you go a lot faster.
Not being up to date with this is going to slow down your
process and make your request take longer to get through.
So keep that in mind as you go through and listen to the rest
of this episode.
So what I'm going to do is I'm going to start with our
developer policy.
And this you can find at developers.googl
e.com/plus/policies.
And I'm going to just pull out a few things here.
There's really a lot to look at here.
But I recommend you go ahead and take the time to read
through it.
It should only take 10 to 15 minutes to skim.
And it will help you keep in mind the most important things
that you need to know when you're designing an app that
uses Google+ in any way.
But first, let's take a look at Section c.2.a, because this
is one of the most important things to keep in mind, when
you need to follow the basic guideline.
The basic tip to our policies is never
let the user be surprised.
And so the thing that hits this point the best is 2.a.
And it says, don't mislead your users about what your
application does or trick them into using it.
And this sounds really harsh.
But it's actually not as harsh as it may seem.
Because what it really does, what it really emphasizes, is
that your user needs to know what's going to happen when
they click on something with the Google name on it.
So for example, if I click on the Google+ Sign In button,
and I don't get signed in, I'm suddenly confused.
The best use case that I can think of is if I click on the
Google+ Sign In button, and I suddenly have a handful of
celery and vegetables.
Lots of vegetables.
I don't want to click on the Sign In button and get
attacked by vegetables.
I want to click on the Sign In button and know that I'm a
part of your app, and know that there's my name, my
information, that's going to make a better user experience
for myself.
So keep that in mind.
The other thing that I want to point on that hits on this
"don't surprise your users" is Section b.1.c.
And what this means is don't use stale data.
You don't want your user to have data that's not been
updated in a while.
You want to make sure that if they delete something on
Google+, it's not still on your site a week later.
FEMALE SPEAKER: Where's my celery!
JOANNA SMITH: So the best way you can do this is update your
cache regularly.
Make sure that you don't keep any data forever, because that
wouldn't be a very good user experience.
But also make sure that everything in there gets
refreshed on a regular basis.
So like I said, there's a lot here.
But it's definitely worth going through.
But the easiest way to make sure you're abiding by
developer policies is that simple rule of never let the
user be surprised.
Because if you're meeting that in every possible way, you're
probably meeting the rest of our policies.
So the other major thing that I wanted to hit on today are
our branding guidelines.
And these can be found at developers.googl
e.com/plus/branding-guidelines.
And there's kind of a lot here.
We have some helpful links at the top.
But then what we have are our buttons, our standard options,
the things that just come for free.
And you can actually download.
And a lot of people haven't noticed this, but we have a
download link over here to the right.
And this has all of our attributes, all of our buttons
that you might need for your app to sign in, to share.
They're easy to find, and they're right here.
There are several options, of course.
We've talked about those before.
But let's move on to the other important things.
This next section is what we refer to as the equal
prominence specification.
And what this means is that we want all of your sign in
options to be clear and equal.
If you are offering Google+ Sign In, it should be as up
front and as discoverable as any other authentication
service that you have.
And they should all be there for the user
to have a real choice.
And that's really important to us.
The other thing that's really cool about this section is
that it points out an exception that you might want
to be aware of.
If you're designing a custom button, we have a lot of
specifications and parameters for you.
But if you're doing something in your design that doesn't
quite fit one of those, and yet you're doing it across all
of the authentication services that you provide, we'll abide
by the exception as well.
Because it's consistent in the look and feel of your design.
It's part of your site, and we understand that.
So this is really cool for you.
Now, let's take a look at some of the custom button design
specifications.
There's kind of a lot here, and I understand that.
So I was going to just pull out the key points for you,
and you can take a look later if you want to get to know
more about it.
So the first, with regard to size, is that we just want you
to preserve the original aspect ratio.
Don't really care how large or how small the button is, so
long as it's the same ratio.
With text, this is where it kind of gets important.
You want to choose the wording very carefully.
Do something like "Sign in with Google." It needs to be
very clear to the user that they're not signing in to
Google with your site, but rather they're using their
Google identity to authenticate your app, to gain
access to other features.
That's the distinction.
And your button text needs to show that.
In any case, though, never say Google+ on the button.
It needs to be apparent to the user that signing in with
Google grants access to more than just their Google+ data.
A developer can add a scope, for example, to gain access to
other services, like Google Drive.
And that's beyond the scope of Google+.
And the user should not be confused or surprised to see
if they're giving access to Google Drive, using
Google+ Sign In.
So only ever use the word Google on your button, just to
keep it clear.
Also, for color, we have some specific shades of red and
white listed.
And we'd like you to use these if you're going
to use red and white.
We don't want some off-shade or slightly
wrong look and feel.
This ratio is kind of important to us.
The font that we chose is Roboto Bold.
This is a True Type font, and we have to download
instructions for you.
And then finally, padding.
This is one of those bits that's of
hard to decide sometimes.
So what we would look like is we'd like the right and left
sides of the text to be the same width
as the Google+ icon.
It's that simple.
So you can just use the same width over and over.
We have a section dedicated to the Google+ icon by itself.
And then we have some "where you shouldn't go" directions.
And the most important thing here is that you don't use
anything that's old or outdated.
You may have designed your app over a year and a half ago,
but Google+ has evolved a lot since then, and we would like
it if you would update your branding to meet our
guidelines.
And like I said, this is one of those things that I'm going
to check for, for any quota request that comes by my desk.
And if you haven't met that, if you are using an old
button, that's an immediate hesitation.
You have to fix that before we can approve your request.
So the more up-to-date you are, the sooner you can get
through our process for additional rate limits.
So, the last thing I want to talk about, as far as
branding, is I have an example for you.
And this is one of my favorite partners that we have.
This is Fancy.
And they are a pretty cool site for how to buy things or
really interesting products they have a lot of.
But what they did here is awesome.
They built a custom button, but it fits seamlessly into
their design, which is why it's such
a good custom button.
They've preserved our original red and white contrast.
We really like that.
They've got the Google there.
But what they did that's so cool is they
redesigned our button.
Our button was rounded, a little bit more shaded.
They wanted a flatter look, because you'll notice that
their entire site has a pretty flat look.
It's consistent.
So they have equal prominence.
They have the right colors.
They have the right text.
And they made it fit seamlessly into the entire
design of their side.
This is an example of a well done
customized sign in button.
And you can actually turn to Fancy for a lot of other
ideas, because their implementation is pretty cool
all around.
So I encourage you to check out their site if you're
looking for inspiration.
So that's everything that I have for you regarding our
policies and our branding guidelines.
But before we go, I wanted to take a moment, because I've
noticed a lot of questions lately in the Google+
Developers community regarding some of these developer notice
emails that have gone out.
And these are a sort of implementation check up.
And they're actually intended to help developers find and
fix their implementation.
So, the most obvious causes of these emails are some of the
things that I talked about today.
And for that reason, I really hope that this can help you
find where you might have gone wrong, if you're one of those
developers that's wondering what triggered this email.
These are some of the things that you want to look at.
So I hope that's helped you all today.
And if you have any questions, feel free to ask them in the
comments of this event or raise them in the community.
And I'll take a look this week.
Thanks everybody, and have a good afternoon.