NAZMUL IDRIS: Hi, everyone.
I'm Nazmul.
And I'm a developer.
IZABEL IDRIS: And hi, I'm Izabel.
I'm a designer.
In today's episode of "UX Design for Developers," we're
going to talk about how to create really awesome social
user experiences.
We're going to talk about some best practices and some design
patterns that you guys can use to implement social in your
applications.
And today we have a very special guest named Sam.
SAM STERN: Hi, I'm Sam.
And I'm a developer for Google+ Developer relations.
IZABEL IDRIS: So, I'm going to start off
by asking some questions.
Nazmul, there's a lot of buzz around Social.
But tell us, what is social and why it's important, and
what's the value for us using it in our apps?
NAZMUL IDRIS: So if you go to the slides, there's really two
main concepts we have to think about when we're thinking
about social, because social is like a buzzword--
everybody uses it and everybody interprets it in a
different way.
So what really is social?
There's really two main concepts that make up social.
And they are having a portable identity that you could take
with you and apply to any application on the internet--
and so when you say things like sign in with Google or
log in with Facebook, that's what we're talking about.
The other concept is sharing activities, which means that
whatever actions or activities you perform in whatever
application, the idea is that you should be able to take
those activities and then expose it or share it with an
audience of your choice.
And so when you put these two together, you have the
beginnings of social.
Now, those concepts are implemented very specifically
across various social network providers.
So the three main features that are almost everybody has
are sign-in, personalization, and sharing.
So sign-in, that really, from a user experience perspective,
that feature addresses reducing friction that a user
has to experience when they first encounter your
application.
So it really eliminates having to create a new account by
providing information that you already stored somewhere else,
like in your profile for Google+, for example.
So the idea there is that if you sign in with a provider,
you don't have to provide all that
information all over again.
And that makes logging in and account creation totally
seamless and really, really easy.
So the next thing is once you signed in, how does the
application respond to the fact you've signed in?
How is it showing you that there is a signed in state?
So that's when personalization comes in.
And personalization is the act of your application,
essentially taking things like your name, your profile
picture, and any other relevant information, like
what Google Now does sometimes, when it's your
birthday, it says, hey, happy birthday, Sam.
Not that it's Sam's birthday today, just an example.
But so personalization is key in making you feel at home in
your application.
And, finally, sharing.
Sharing is just taking certain application activities and
then exposing them to whatever audience in a
way that makes sense.
And different or social network providers do it
differently.
IZABEL IDRIS: OK, so now that we know a little bit about
social, should we put in our apps?
And how are our end users going to benefit from social?
NAZMUL IDRIS: That's actually a really good question.
There are really two things to consider from the user
experience perspective to answer the question.
And those are do you have a signed-in experience?
And you have an enormous experience?
So what do those mean?
An anonymous experience is you've, for example, gone to
amazon.com.
You haven't signed in, and it doesn't know who you.
Are it's showing you just a
catalogue of Amazon's products.
If your application can have a signed out experience, or an
anonymous experience, and also signed in inexperienced, just
like, again, with Amazon-- when you're signed in, it
knows who you are, it gives you your wish list, your
recommendations, your shopping cart and so on.
That's an example of an application that can have both
an anonymous experience and a signed in experience.
So sometimes, if you're--
So Gmail is actually another example, different than
Amazon, because Gmail does not have an anonymous experience.
You have to signed in to Gmail for Gmail to make any sense.
So to answer the question, if your application can do
without a signed-in experience, then you really
have to think about how to make your
social integration special.
Don't just put social into an application
because it's a buzzword.
It has to make sense in the context of your application.
Now, if you have a certain type of application which does
not have an anonymous experience, then you don't
have a choice but to make it social.
And in that case, also, make sure that you do a really good
integration, because a bad integration with social will
end up turning people off, more than actually engaging
them or delighting them.
IZABEL IDRIS: There's one thing I wanted to mention,
because social features can surface in your application in
many places.
I think it really makes sense for social to be taken into
consideration early on in the design.
Designers, PMs, and developers should all think about how
social is going to surface in the application, because it
really goes into the DNA of the application.
A lot of people think social is just a Share button or just
a Login button, but I think it needs to be really thought of
in a more holistic way early on in your project.
So Sam, should people implement these social
features on their own?
How should they go about this?
SAM STERN: So I think it's tempting for a lot of people
to say, my application needs a messaging
service, let's build messaging.
But there are people--
and these are social providers-- that do this all
day, and they do it very well.
And you shouldn't reinvent the wheel, we should let these
social networks do what they do best.
And sort of outsource your social
features to these networks.
So if you're going to have a friends model, you should
really consider off loading that to Google+ or Facebook,
or something that can provide you with a social model.
So there's no need, especially if you are a startup, to spend
all this effort implementing social features that have
almost definitely been done better by someone else.
IZABEL IDRIS: So from an end user perspective, why do you
think end users choose social login?
And how do they choose which provider to log in with?
SAM STERN: I think users choose social login, like
Nazmul said, to reduce friction.
Almost always if you can click once and be
logged into a new service.
And, yeah, there's a trust factor there too, because
they've already made an account with the social
provider, so they've already given their trust to that
application.
This way they don't have to further distribute their trust
among more developers that they might not know too well.
And they choose a social provider based on--
assuming there are multiple offers-- based
on the feature sets.
So you might choose Facebook, because you're dying to share
everything you do with your friends, and you might choose
LinkedIn, because you want to connect with your coworkers.
So that's a portable identity.
And which provider you choose is also a data
point in that identity.
IZABEL IDRIS: So as a developer, should we choose to
implement social login?
And if so, should we implement multiple providers?
SAM STERN: I think it's important for developers who
are implementing social login to consider multiple
providers, Because it's one more thing you can
know about your user.
It's a choice they're making, and you should be able to
react to that choice.
Like the example I gave earlier, if someone chooses to
log in with LinkedIn, that's saying something about how
they intend to use your application.
And you only know the choice they made, if
you give them a choice.
So if you just offer to sign them in with Google+, the only
thing you're learning is do they have a Google+ or not.
But if you give them multiple providers, that's one more
thing you can learn about your users, and one more way your
website can react and create a great experience.
IZABEL IDRIS: So now that we know about all the cool things
we can do with social, let's talk about the developer
experience.
What's the best way to implement social?
SAM STERN: Implementing social is not very hard, but it's
hard to do well.
So there's a lot of code you can just drop into your
application, but that can quickly make things messy.
And you have to think about why you're
implementing social.
To make your users able to do more things.
And your code should reflect that you've expanded the
abilities of your users.
So you don't want to have your code littered with branching
statements, like if the user's signing in with Google, share
it to Google, if they're signing in with Facebook,
share it to Facebook, because that's really leaking your
social logic into your business logic and defeating
the point of why you did this in the first place.
You want to just make it seem like your
app has more functions.
So your code should reflect this.
And you want to separate the social logic entirely so that
you just say, the user has bought a widget and the user
is sharing buying a widget.
And you let some other code or library somewhere handle what
network they're sharing this to, how exactly
that's being done.
And of course, this will be harder at the very beginning,
when it might be easier just to drop in code.
But the idea is as you add more features, maybe you want
to add two or three more login providers as you really get
the hang of this, it's going to be so much easier if you do
this in a principaled matter and think of that as expanding
the ability of your users, and not just dropping code
snippets throughout your application.
NAZMUL IDRIS: That makes sense.
It's like using separation of concerns, essentially, to
isolate different providers and make sure that you can
express social capabilities of your application but leave it
up to your provider implementations.
Very much like Android does it with location providers.
Where you can ask Android, hey, give me a location
provider and give it to your criteria.
And then Android might hand you different ones-- like some
consume more batteries, some give you more accurate
readings, and then others give you quick readings, but they
might not be as accurate.
So it's kind of like that, where they've basically taken
this very complex Location Provider model--
or very many different providers and then abstract it
to a much simpler model.
Is that--
SAM STERN: Yeah, that's right.
And it's also-- a way to think about it is you wouldn't let
the social features take over your entire UI, it's an
extension of your business.
And so if someone's looking at your code and you onboarding
new developers, they should see it that way too.
This is an extension and this is not the driving force.
NAZMUL IDRIS: That makes sense.
So you almost don't want to denature the DNA, if you will,
of your application by thinking of it just as a
conduit for sharing activities.
SAM STERN: Right.
NAZMUL IDRIS: Or for how do you
accommodate a portable identity?
It's like you have to maintain who you are, what your
application was meant to do, and then augment it with
social features, as it makes sense, in the context of your
application and the experience you're delivering.
SAM STERN: Exactly.
IZABEL IDRIS: How does everything we've discussed
here today affect the user experience for our end users?
NAZMUL IDRIS: That's a really good question.
If your application allows or provides the user a choice to
sign in with multiple providers, then it's very,
very important in the user experience to really make this
user feel good about the choice that they've made.
So a really, really bad design pattern, an anti-pattern,
would be that if you asked them to basically choose one
provider, then in the flow of your application you keep
prompting them to use another provider, as if you really
wanted them to sign in with this other provider, but you
were kind of--
you're not really OK with them signing in with the provider
they chose, but you're tolerating it.
But you really wanted them to use the other provider.
So if your application is delivering that tone or that
mood to the user, then that's not really good, because then
the user feels bad that they've
chosen the wrong provider.
Also, another anti-pattern is do not ask users to sign with
every single provider that they might have an account on.
That's redundant.
And unless you can deliver value--
and you have to let the user know upfront what value they
are going to get from actually connecting your application to
all their identities--
unless you can give them this value proposition upfront,
it's a really, really bad idea to ask them to connect to
every single provider.
Because the whole point, if you remember,
was to remove friction.
And now what you've done is you've layered more friction
onto a process that's supposed to be frictionless.
IZABEL IDRIS: It takes away value.
It almost makes it feel like you just want their dates,
you're just trying to get at their friends or their data.
NAZMUL IDRIS: Exactly.
And that also is a very bad thing to do is to give the
impression that when you're asking somebody to sign in
with their identity, you have to deliver an experience that
was better than if they had an anonymous experience.
If you're not doing that, then why are you doing social
integration?
Additionally, if you're asking them for multiple identities,
then there has to be a value proposition to the user, which
is pretty clear, and they have to see that in your
experience as well.
That means that you're unlocking certain capabilities
that might not have existed if you had a single provider.
So unless you can do all of the above, it's not a good
idea to actually ask them from multiple providers.
SAM STERN: You said before about making the application
seem like it was built for the choice the user made.
Could you elaborate on that a little bit?
NAZMUL IDRIS: Sure.
So for example, if you're signing in with something like
LinkedIn, then the type of information or the activities
that your application should share should be more
work-related.
Versus, let's say, you've signed in with Facebook, where
that could be more personal stuff, more fun stuff.
Or, let's say, you signed in with GitHub, where now we're
talking more technical stuff, like coding oriented.
So the application that you're building obviously has a
certain user experience in mind, it does certain things.
And so you should align these identity providers with what
you're trying to deliver, and then when there is alignment,
then the user will feel like they're getting a tremendous
amount of value from the choice they've made, and
they'll feel good about having made that choice.
Does that answer your question?
SAM STERN: Yeah, I think that makes a lot of sense.
NAZMUL IDRIS: Cool.
IZABEL IDRIS: I think for one thing that can really enhance
the user experience is, like with Google search results
too, you can see which one of your friends has +1 certain
sites, or even the Google Play store, you can see which one
of your friends in Google+ have +1 certain items.
And that can help you make better decisions.
And I think that adds a lot of value.
NAZMUL IDRIS: That true.
The social proof is a really, really big component of
actually enhancing my experience, because if I'm
looking for a particular application in Google Play,
and Sam has +1'ed it.
I trust Sam, Sam is awesome.
So then by extension, I think this application is good,
because Sam said that it was a really application.
And vice versa, if Sam gives it a negative review, then
obviously, I would take that data point in too.
I would basically trust that interview more than an
anonymous review.
So for example, if I'm signed into Amazon, then I have a lot
of reviews, with a lot of ratings, and I'm not really
sure whether--
I don't know these people.
So if I can see Sam reviewing something, I have much more
confidence in that review then if it's
just some random person.
Even if those reviews are good.
It's just a human thing.
And again, when we talk about social here, it's really
important to think of this as a human experience, because
social should not be some feature set.
Like I mentioned three features--
sign-in, personalization, and sharing.
Social is just not a composite of these features, social is
something that we do as humans.
And these features are trying to enhance what we would
normally do anyway as people.
So that's, I think, another kind of meta concept.
But I think it's really important to now.
And that's why we talked about making users feel good about
the choice they've made, and so on.
SAM STERN: If you're a developer and you're looking
to get started with multiple providers, and Nazmul has
especially convinced you that this can really add advantage
to your application, I've done another GDL on this topic and
I wrote a tutorial on how to get started
with multiple providers.
And the links are below, if you want to get started and
get coding.
NAZMUL IDRIS: Yes, there is a good example, actually, of how
to use Google+ and Facebook.
And I think the application is called Wigwam now.
SAM STERN: Yeah, and there's also code samples on GitHub
[INAUDIBLE] as well.
NAZMUL IDRIS: Cool.
And it's a web app and a mobile application, right?
SAM STERN: That's right.
NAZMUL IDRIS: Cool, awesome.
IZABEL IDRIS: Well, thanks, everyone, for watching today's
episode of "UX Design for Developers." We'll see you,
guys, next time.