Tip:
Highlight text to annotate it
X
>> CHANEZON: Hello, everybody. So, my name is Patrick Chanezon. I'm a developer advocate
at Google. I've been working on--I've been at Google for five years. I'm based in San
Francisco. I've been doing lots of different stuff at Google. I started with Adwords and
then Google Checkout. And a few years ago, I was in charge of OpenSocial, which is quite
relevant for today's theme. And then, I did HTML5. And these days, I'm more focused on
Cloud computing. So the talk today is about the social web and how it evolved and what
are the current technologies and standards that are used for building social apps. So,
again, there's a mobile agenda that you can find there, where you can see the list of
sessions and rate the sessions and all that. So I have a huge slide deck for today. I'm
going to skip through lots of the sections because there's lots of ground to cover. I
will post my slides online, so feel them more like as references than anything else. And
you can find them on the web. The big news for today is what--what was announced in the
keynote this morning which is the release of Jambool for Orkut. So, I'll dedicate some
time at the end about that. I think that's the--most important news. So I'm going to
explain what is social, a little bit of history about social software, the list of Google
social products and then we'll go over all the standards and technologies, the Open Standards
and technologies that are used in social software. I'll talk a little bit about the Buzz API
and then we'll talk about monetization. So--but first, I'd like to know a little bit about
your interest. So, who among you is developing social apps today? Okay, quite a few. That's
good. How many are doing that on Orkut? Hey, great. How many have used the Buzz API? Oh,
wow. Okay. And then, how many are building apps for Facebook? Wow, pretty impressive.
Great. Okay, so what is social? Like some of you may seen these slides already from
a few years ago when I went to Brazil and talked about OpenSocial, maybe last year.
I like these because it's a good reminder of what social is about. To me, social is
a horizontal layer for the web that just bring on the web a lot of the social activities
we have in real life. But because there are many definitions of what social means, I just
find it useful to go back to kids to see what their point of view is. So I asked my daughter,
Eliette, what social means to her. And she's a very good drawer, so she give me some drawings.
"We look at each other," lots of looking at pictures and all that; we were talking, communication
is an important theme; laughing, like all the fun apps and games and all that; "We help
each other," collaboration is a big theme for social apps; "We read together," like
sharing links and reading lists and all that; and then, collaboration again, do projects
together. So that's kind of--that's kind of what social is in real life and what's been
happening in the past three years, I would say, is that all these activities, thanks
to social APIs from social networks, have moved to the web. We're in the process of
moving all these, in the forms of applications, using social APIs. A bit of history about
social networking; and when I say history, I'm talking about recent history and more
about the history of APIs, how can you leverage social networking in your apps. So in 2007,
it was all of the rage about building social apps inside of the social network. So you
had the Facebook platform on one side that allowed you to build--take a smaller version
of your site and build it inside of Facebook. And then, you could use their API there and
have access to the social graph of users. Same thing for--on the other side, on the
open site, I would say. There was OpenSocial which allowed you to do the same thing for
Orkut, MySpace and all the other networks in the world pretty much, except Facebook.
So, you had Facebook platform and OpenSocial; that was 2007. Then, 2008; in 2008 we saw
a generalization of social networking where a lot more people started using social networks
and at that time, the social network APIs themselves were starting to go out. Instead
of requiring developers to build a smaller version of their site inside of the social
network environment, they started to provide APIs like Facebook Connect or Google Friend
Connect that allowed a regular website with just a few snippets of JavaScript or backend
calls to just pull the social graph from the site. So, you're on Huffington Post or time.com,
you log-in with either your Orkut login or your Facebook login and then you get access
to--and then the site get access to your social graph and they can do some personalization
with that. So that was 2008. At the API level, and when I say at the API level--at the open
standard API level, the standards we are talking about were OpenID, OAuth and OpenSocial again.
Twitter Anywhere is part of that move as well and the Facebook open graph API is part of
that. Now 2009, there's been a shift in 2009 where it's not only about the social graph,
people--and not only people but social networks themselves realized that the most important
aspect of social networking for users was not only playing with apps inside of the social
networks, it was all about the update, what we call the activity stream; seeing the feed
of update from your friends. And so in 2009--and Twitter is really the company that kind of
created that--created that--not the ID, but made it work a lot and all their growth was
linked to the activity stream. And basically after Twitter became popular, Facebook redesigned
their page to focus it around the activity stream. If you've tried the new Orkut, you
see that the activity stream is pretty central there as well. Google Buzz is all about the
activity stream. So, all the social networking companies kind of took notice of that switch
and the whole focus in social networking switched to activity streams. So at the API level and
at the open standards level where that mentioned that there's been a bunch of standards defined
in this area; one called ActivityStreams, another called Salmon about commands on websites,
Pubsubhubbub and Webfinger. We'll talk about these in the session. And then 2010, the activity
stream is still very strong. But then, what is strong as well is geo and mobile with FourSquare,
Latitude, Gowalla; Twitter added Geolocation, Facebook implemented Places. So, geo and mobile
was one of the big theme for this year in social networking. In terms of APIs, it was
GPS APIs in phone where you can have access from the native platform or from HTML5, with
the W3C Geolocation API in JavaScript. And then another big theme was social gaming with
companies like Zinga becoming very successful; and when I say Zinga--also when we talk about
Brazil, Vostu or Mentes, pretty popular on Orkut. And then, monetization; monetization
and virtual currencies, and we're going to talk about that with Jambool. So that's kind
of my version of the history, recent quick history of social networking. Now in terms
of Google social products, the historical, and still very strong social product by Google
is Orkut. Then we had Google Friend Connect, Google Buzz, Google Web Elements and more
recently Social Search. So, I'll go quickly about Google Buzz which is integrated with
Gmail and it's just a new way of doing conversations. So, the whole idea about Buzz is that your--it's
based on the notion of an activity stream, but your stream is not limited to 140 character.
You can put some rich content in there, you can attach images and movies and stuff like
that. But also there's a conversation in there so people can reply in Buzz and--like for
people who use it, there are some rich conversations that are happening in this--in this media.
And some of us at Google, like de Wit for example, is using it as a blog. Like, he has
really long entries and people are commenting in there. It's very, very powerful. Google
Web Elements is another--it's one of the AJAX APIs. Google Web Elements are--it's a system
where you log-in and then you say, "I'm a site owner, but I'm not technical at all.
And I want to add a little bit of Google to my site." And so, you choose whether you want
to add a calendar or a map, you customize it into a UI designer and then we give you
a snippet of JavaScript to put to your site. I add this to the list of social products
because there's this conversation widget, which is very social, that allows you to add
a conversation widget to your website where the conversation actually can happen on several
websites at the same time. So, if you have a network of blogs, for example, that talk
about the same topic, you can have the same thread on several blogs. And plus, it's all
translated, so you can translate the whole thing. For example, if you have Chinese speakers
in there, you can say, "I want to see the whole thing in Brazilian-Portuguese." So,
it's pretty cool and it's very easy to use. Usages of social networking. So, you have
large companies, like consumer companies like Nike who created Nike+. So, they create social
networks that are focused around their brand or product. So, in Nike+ you can share your
activity when you are running and all that with your friends and then you can talk about
the Nike products and all that. People are using it for outwards communication like what
Best Buy did with Twelpforce. When you're twittering about Best--an experience you had
at Best Buy, with products you bought there, or something like that, some representative
from Best Buy from your area can answer in there and they have an internal application
that they use to tweet there, to verify that these guys are indeed Best Buy buyers--Best
Buy representatives. Then you have things like SocialWork, which is social networking
but inside the Enterprise. So, SocialWork is some kind of Twitter for the Enterprise.
It's integrated in the apps marketplace with Google Docs and Google Apps and it's running
on app engine and it's using GWT. It's like they're our poster child forum. They're using
pretty much everything we're doing there. And then one--one trend that personally I
though would develop in 2008 but only starting to develop now is social networking in the
Enterprise. So you have companies like Oracle, SAP and IBM who are starting to build offerings
for the Enterprise. Cisco also recently outlined a product for social in the Enterprise. The
pioneers in there were eXo Platform and Atlassian who had implemented open social two years
ago already. Okay, the technologies. So, there are--I'd say there are two approaches to social
networking technologies. On one side, you have Facebook who has the Facebook platform
which was--like, they're going on their own and they don't want to collaborate on standards,
and that was like two years ago. Now, since two years, they start to open up a little
bit, like, they start to reuse existing standards like OpenID and OAuth and Activity Streams.
They were the first one to implement it. And then there's the open way which is what Google
is trying to do, trying to leverage existing standards or create new standards when need
arises. And the goal of these is to have very narrow standards that just solve one particular
aspect of the problem. And then you assemble all these together, you have open source implementations
for all of these and then you ensure that there's a vibrant ecosystem around these technologies.
So, the standards we're talking about is OpenID, Atom, PubSubHubbub, Activity Streams, OAuth,
WebFinger and Salmon. So, I'll start with OpenSocial which is the oldest one. That's
what you are using to develop apps on Orkut today, but also on 20 other social networks
in the world. OpenSocial is a very simple API; it's an API in JavaScript and there's
a REST version of it that allows you to--when you're building your application to have access
to the social graph of the user and to send things to their activity stream, and to read
their profile as well. It's been very successful, it has a global reach; tons of social networks
have implemented it and it's very popular on Orkut. So this is an example, I just went
to the Orkut list of applications and found these ones; Mini Fazenda and Colheita Feliz
by Vostu or Mentes. These apps have like 16 million and 21 million users, it's pretty
impressive. So there are some people who make money with it already. So let's talk about
the Open Standards. Yes, so that's--okay. So, at Google we're doing lots of Open Source.
Open Source was part of the Google culture even before we started doing APIs. So what
you get from Open Source is freedom and a community. And then Open Standards; the goal
of Open Standards is to have interoperability between different implementations and different
websites, and it simplifies development. For the developer, instead of having to develop
for 20 different platforms, they just develop to the standard and that's it, and then everybody
does the same thing on the server side. So, one of the first standard is OAuth. OAuth
is all about authorization. It's about distributed authorization. So, the way the process works
is that you have a service provider, let's say for example Google Buzz or Google Calendar,
and then you have your application who wants to access the calendar of the best feed of
the user. So your application needs--when your application needs to have access to that
sheet, they just--the application just goes to the feed and then they receive a--they
receive unauthorized request token to say, "You're not authorized to use that, you need
the user to authorize you to do that." So then what happens is that the user is redirected
to the service provider, to Google in this case, and in the--in the redirection there's
a parameter of that, gives the URL where the user should be redirected to your app at the
end. And so you're going through that--through that process with the service provider and
I'm sure it may have happened to you where you are using an application, you were redirected
to Google, you log-in, and then Google asks you, "Do you want this application to have
access to your calendar or to your best feed?" And you say, "Yes." And then when you say
yes, you're redirected back to the application and with this redirection there's a token
that is given to the application. With that token they can now make requests on your behalf
from the API. And the nice--the way OAuth--the reason OAuth was designed is because of the
way people were doing that before were, "Oh, do you want to invite your friends on Gmail?
Okay, give me your Gmail password." And when you were doing that, basically you are giving
them access to all your Google services because it's your same password for Gmail and Calendar
and Google Checkout and all that. So now with OAuth, you can be very specific, you can say,
"Oh, I want to give that application just read access to my Calendar. And that other
application is going to have write access." And when I'm not using the application anymore,
you can go in your settings in Google and say, "I want to revoke this token." And then
the application won't be able to do--to do the request anymore. So that's what OAuth
is doing. So they get an authorized token, and then they can access your feed or your
data. So that's what--so OAuth is just solving the authorization piece of the puzzle. Another
technology, OpenID, allows log-in in a standard way. Then there's another piece of the puzzle
which is called the Atom Publishing Protocol and the Atom Feed Format. It's kind of a standardization,
at AITEF, of RSS. They took the, kind of the RSS mess of tags and different specs; I think
there's something like 12 different RSS versions. So a few years ago, some guys got together
at the AITEF and they standardized it in the name of Atom. And so, Atom defines a format
for feeds. It's kind of an envelope format. And so here you have things that the author
of the feed, OpenSearch is integrated in there and you have entries which have dates and
titles and stuff like that. So Atom is a very simple format to implement. Now, where it
gets interesting is that inside of Atom you can put some--you can put some Namespace XML
data that is specific to a specific service. And so, Google is using Atom in all its APIs.
When you're accessing the Calendar API or the Picasa API, all you access to is Atom
feeds with namespaces that are specific to each service. So for example, in a calendar
feed, you'll have a namespace that will describe calendar entries. In the Picasa, you have
a namespace that describes images. So that's Atom for feeds. Then PubSubHubbub, one of
the problems--there's a hilarious video with Bret Slatkin and Brad Fitzpatrick that explains
really well what PubSubHubbub is about in a nutshell. And I think I have only 15 minutes
left. Yeah, so I have 15 minutes left so I'm going to go real fast on this one. PubSubHubbub,
what it addresses is the problem where--when you're dealing with feeds, you have the client
who's asking the server all the time, "Do you have anything new for me? Do you have
anything new for me?" And that, that is not efficient and that generates lots of useless
traffic. And so, a more efficient to--way to do that is to have a published-subscribed
architecture. But because it's all distributed, it's important to have hubs in the middle.
So that's what PubSubHubbub is doing. Basically, when you have a--so you have a subscriber--yeah,
so a publisher's feed has a link to a hub where they are going to publish their feed.
And so, when a subscriber asks for a feed, the publisher tells him, "Hey, the feed, you
can get it into that hub." And so then, the subscriber asks the hub, "Hey, I want to subscribe
to that feed." And then, there's a little bit of a handshake to say, "Are you really
not a spammer?" And the guy says, "Yeah, I really want the updates on that feed, I'm
not a DoS attacker." And then what happens is that when the publisher has some new stuff,
he's bringing the hub to say, "Hey, I have some new stuff." And then the hub pulls the
updates. And then--and then pushes them to the subscriber, and these can be many subscribers.
So instead of having all the subscribers pull on the publisher all the time and all. All
the publishers, here you have hubs in the middle where the publisher is pushing to the
hub only once when there's some new stuff. And then, the hub is pushing to everybody
only when there is some new stuff as well. And it's a distributed system so there would
be many hubs and many publishers and subscribers. Salmon is another protocol. The problem he's
trying to solve is, there are a lot of commenting system out there and when you're having a
blog and you're using a distributed comment system, you can comment on something on Twitter
and then you end up commenting about the same stuff on Buzz. And then, maybe the conversation
ends up in FriendFeed. And if you start to use many of the systems, the conversation
is completely fragmented. Salmon is trying to solve that by having this notion of source
and aggregators where a source is using PubSubHubbub to warn an aggregator that they have a new
entry. The aggregator is publishing it and when the aggregator gets new comments, it
pushes them to the source. And so, the source can publish it into his own thread. And then,
when the source has new comments it can use PubSubHubbub to push it to all the aggregators
that have registered for this entry. And then, they will republish it into their own threads.
That means that you can start a conversation, let's say on Buzz, continue it on Twitter,
have a comment in WordPress. And all that stuff can go together into a single thread
or actually each system could have the whole commenting story. That's the--that's the story
behind Salmon. Activity Streams. So, as I told you, the whole social web is re-centering
around the Activity Streams. Activity Streams is the standard for interoperating with these
feeds. And, basically, it just defines a scheme on top of Atom like a specific name space
to define a few things about a stream of updates so that in the user interface of the activity
stream, you can make things nicer. So what it defines is an actor, a verb, and an object.
So, for example, "Timothy is posting a note," or, "Barack Obama started following Timothy,"
or stuff like that. So an Activity Stream is just a list of these subject, you know.
Okay. So, I'll be really short on the Buzz API because--if you have anymore questions,
you can find some great slides online, and I'll publish these as well. Basically, the
Buzz API--so, Buzz is a Google product that allows you to have conversations in a very
easy way on the web, and the API is all based in all of these standards. So, you use OAuth
to have access to it and then you use a PubSubHubbub to have access to the, like, the--how is it
called--define a host feed like the host feed on Buzz. The feed itself is in the Atom Publishing
Protocol format. You can ask for adjacent version of it and it's so full of the Activity
Stream spec. And, so, I'll just skip pretty quickly. I'll just show you what that looks
like in the feed. So that's what it looks like. For the Activity Stream, you have an
actor named blah-blah-blah; profile, URL. The verb is post and the object here is a
note and all that. So, we don't implement the whole Activity Streams spec in Buzz. I
think there's only a few. So, these are all the verbs, objects that are available in the
Activity Streams spec. Now, in Buzz, we implement post, and for article; note, photo, photo
album, or video, so these are the object that are supported by Buzz. Okay, so I'll just
skip through that. There's a whole lot of links to code and all that, but I'll just
skip to the awkward part, which I think is more relevant here. And there's lots of code
out there that helps you play with the Buzz API. Okay. Just one last note, we talked about
Open Standards. Now, another important part of Open Standard is open source implementation
of them. So you have status.net, which is a, like, some kind of white-label Twitter
implementation, but it's open source, so you can run your own version of it, and it's implementing
most of these standards. Then, you have Shindig, which is the open source implementation of--it's
an Apache projects, an open source implementation of open social server. Social site, which
is another Apache project, which is the whole social network on top of Shindig that implements
OpenSocial. And then PubSubHubbub, which is a--the server implementation for PubSubHubbub
hub, which is written in--yeah, yeah, you need to train a lot to be able to say that--and
it's implemented in Python. It's running on App Engine. It's lovely. Now, let's talk about
Jambool because all these stuff is good and fun and all that, but at the end of the day,
we developers, we need to make money. So, one good way of monetizing your social applications
especially on Orkut is building virtual currencies, of having a payment system. But, building
that takes a lot of time and it's pretty painful, and so there's a company called Jambool who
created such a system where you can create your own virtual currency, white-label virtual
currency, and they give you--they manage all of it for you. And so that company has been
bought--acquired by Google in August 2010. I was very happy about that. I heard about
it in the media but I had met one of the founders before--because he used to be the guy who
designed the Amazon Payments API, which I found very well designed. And so in Jambool,
he just did the same kind of APIs but for social networking. And so the other leading
leader in virtual economy monetization platform, and their platform is called Social Gold and
it allows for micropayments, subscriptions; you can create your own virtual currency and
they do inventory management for you. They have a pretty powerful analytics and reporting
platform and they do fraud management as well. So, basically, it makes it very easy for you
to create a virtual currency or have payment inside of your social application or games.
And that kind of stuff is very fashionable this day and it's a very good way of monetizing
these apps. So what has been announced today that Jambool is available on Orkut right now
and it starts today. So just get signed up. And the key features for Orkut are support
for Boleto Bancario, which seems to be a Brazilian payment method. I hadn't heard about it but
it seems it's a--yeah, I'm living in San Francisco, but I'm told it's very popular in Brazil.
The experience is completely localizing Portuguese. The fee for using it is 10% and then there's
24/7 customer support for it. So in terms of features, you have a seamless in-app experience.
The wallet that you created is associated with the user's user ID in Orkut. And you
can use a wide array of payment method. So, you can see all of them here, including the
Boleto Bancario. The transaction can happen in--so lots of these games are built in Flash.
You can make these transactions directly in Flash. You can pause the game just when you
are doing the transaction. And they don't need to leave the game in order to purchase
more stuff. You have a subscription offering in there where--and it's completely configurable.
So, you can have free and discounted trials weekly, monthly or annual billing cycles.
And you can customize the CSS for the subscription page. And then you have some APIs, to have
access in your game on your back end to the user's status in the--in terms of payment
or in terms of subscription. Local currencies, they are live with 25 currencies. And when
you get into the system, you're default currency's based on the IP address that you're coming
from. Now, one of the very popular thing that happened in social networking in the past
two years is the rise of virtual currencies. So you're in your game and you need to buy
some stuff in that game and then you can buy this virtual currency with real money. So
building that virtual currency is a lot of work. Jambool just does it for you. So they
have a very simple API that let's you build your own white-label virtual currency. So
you can name it, you set the exchange rates, you determine the events in which people earn
money or not and you can manage, or go credit, debits and the balance. Analytics; so Jambool
provides you lots of analytics about your virtual currency that is very useful to tune
it and tune your game or your app for it, and you can sign up today. So you sign up
on jambool.com. And the APIs are very easy to use and it's a great way to monetize your
social apps. Okay, I think I'm done within time for once. So, you can find the--again,
the agenda, to rate the sessions, at this URL. And since I have time, maybe I have time
for a few questions. Okay. Thanks very much.