STEVEN BAZYL: Thanks for
coming today, everyone.
My name is Steven Bazyl.
I'm a Developer Advocate here
at Google, where I work with
web developers like yourselves
to help them integrate their
web apps with Google Apps and
Google Apps Marketplace.
Before we get started, I just
want to get a quick sense of
who's in the audience today.
So if you already have an app
in the Marketplace, can you
just raise your hands?
All right.
Pretty good.
Great.
And who here is just learning
about the Marketplace for the
first time today?
Maybe you went to Scott's
earlier talk this morning?
Anyone?
All right.
Good.
And does anyone actually
use Google Apps.
All right.
That's pretty good.
So today we're going to talk
about some of the best
practices that we've seen emerge
in the Marketplace over
the past year, specifically in
the area of integration.
Because integration is such a
wide topic, this is not a
deeply technical talk.
However, I hope that by the
end you're going to have a
better sense for the value
integration brings to both
your customers and
to your business.
And along the way, I'll try to
provide some technical tips
and tricks to help you
get started in
integrating your app.
For those who are new to the
Marketplace, it is a business
to business web application
store for the more than three
million businesses and three
million users on Google Apps
to discover, try, and purchase
new web applications to help
run their business
in the cloud.
It is not a consumer
web store.
You will not find games.
You will not find media,
music, or books,
anything of that sort.
Instead, what you'll find are
business productivity tools.
Things like project management,
customer
relationship management,
accounting, financing, expense
reporting, [INAUDIBLE]
need to help run their business
in the cloud.
We [INAUDIBLE]
Marketplace a little
over a year ago,
back on March 9, 2010.
And started with 50 apps
in the Marketplace.
Shortly after, at last year's
Google I/O actually, we
unveiled some new integration
points--
contextual gadgets for Gmail.
And I'm going to go into more
detail on this later on.
More recently, this past
January, we expanded the scope
of the Marketplace by
introducing a category for
Google Apps for Education and
added over 20 applications for
K-12 and universities.
And more recently celebrated
our first
birthday this past March.
And hit a milestone of 300
business applications now
available in the Marketplace.
Today, we're getting
close to about 350.
And we continue to add
more each week.
So why the history lesson?
Well, over the past year we've
got to work with a lot of
different application developers
in integrating
their apps.
And we've observed
a lot of customer
behavior over that year.
What we learned--
well, let me say we still have
a lot to learn in terms of
what makes for a great
Marketplace app and successful
experience.
But over that year, we have seen
certain trends and best
practices emerge.
And what I want to focus on
today is integration.
So let's talk about
integration.
Just give you a couple
examples of
what it mean by this.
For starters, it includes
things like providing
universal navigation-- a quick
way and a consistent way for
users to access their
[INAUDIBLE]
and sign in and without
having to have another
user name and password.
[INAUDIBLE]
thought this was such an
important [INAUDIBLE]
of having a consistent user
experience that we made this a
core requirement for joining
the Marketplace.
You could also do things like
import and export contacts,
access and update calendars,
documents.
Applications can also publish
content and gadgets to sites.
Gadgets turn out to be pretty
useful in other contexts.
You can actually use
gadgets in Gmail
as I mentioned earlier.
They also can be used
on a calendar and
in the Gmail sidebar.
And another one which is often
overlooked but we've seen some
pretty clever uses of
is Google Talk as
an integration point.
And we'll see some examples
of that later on.
Of course, this is just a quick
example of the things
that you can do.
Throughout the talk, I'm going
to go into some of these
integration points
in more detail.
And show you how some apps in
the Marketplace are using
these today to drive additional
value for customers
and for their business.
For you as an application
developer, the reason this is
so important is simple.
Integration gets you
more customers.
A few weeks ago, I wanted to see
if there was a correlation
between how well integration in
an application was and how
well it performed in
the Marketplace.
So I decided to take a look at
the top 100 applications in
the Marketplace.
And this is measured by their
weekly installs for the
previous week.
What I found is that the top
10 applications in the
Marketplace--
all 10 of these went well
beyond the minimum
requirements for going
in the Marketplace.
That is it addition to Single
Sign-On, they all found ways
to integrate Google Contacts,
Calendar, Docs, and so on.
When you look at the next 50,
the rate's still pretty good
about three out of the four
apps, but we're starting to
see some apps that are really
just getting by
with the bare minimum.
And when you go out to the
top 100, that rate
drop down to 66%.
Of course, there are some
variables that go into how
well an application performs.
The pricing model, the
category of the app, how well
they do marketing and
support-- all of these are
things that we would have to
control for in order to find out
if there's really a strong
correlation or a strong
causation even.
I'm still really interested in
getting to that the heart of
that question.
But fortunately other people
have been looking at this
question and they came to the
very same conclusion.
Sunir Shah is founder of one
of the applications in the
Marketplace--
FreshBooks.
And FreshBooks spends a lot of
time integrating their app
with others.
Not just Google Apps, but a
whole host of web applications
that their customers use.
When he blogs, he summed it up
pretty simple for why this is
so important.
People want end-to-end
solutions.
It translates to the
bottom line.
And the kicker--
if a customer uses any of their
integrations, they're
three times more likely to
become a paying customer.
That's a huge difference
in conversion rate.
For those of you who went to
Scott McMullan's earlier talk,
you may have heard Cameron
from GQueues echoing
[INAUDIBLE]
and he's seeing phenomenal
differences in conversion
rates when people use their
integration with Google Apps.
Why do they convert?
Because customers love
integrations.
Not only do they want those
end-to-end and solutions, but
it saves them time and it makes
them passionate about
the products.
Jeff Harmons, a small business
owner and entrepreneur, was
profiled in a case study with
Outright and Google Apps.
And he summed it up.
This is icing on the cake.
He can stay focused.
And move on to helping the next
customer or spending time
with my family.
In other words, by saving
time, making them more
efficient, we're letting our
customers focus on the things
which are important to them.
It's a little paradoxical, but
this is exactly what we want.
We want people spending less
time in our applications and
more time doing what's
important.
So when we talk about
integrations, we don't want to
just add features to our
applications for any old reason.
We don't want to add
integrations just to say that
we did them.
So when you think about what
you can do with your
application, your really want to
focus on those things which
provide immediate value to your
customers and save them
time and save them effort.
For today, I'm going to focus
on three areas where I think
integration can help
us do that.
The first in on the out
of the box experience.
How do we use integration and
the data available to help
make users--
help them get up to speed more
quickly on our application and
become productive?
The second is collaboration.
How do we use integration points
available and the data
to help people connect to their
co-workers and their
customers and suppliers
and work
more effectively together?
And the third is improving
access to information.
Saving them time by making
information available to them
when they need and where
they need it.
So let's start with the out
of the box experience.
Something really important to
note about the Marketplace is
that this is not a traditional
enterprise sales channel.
There are no sales people.
There are no sales engineers,
consultants or anything to
help customers set
up, configure,
deploy, and train users.
So it puts a burden on you as
an application developer to
make sure that your applications
are designed for
a self-service model.
Things like the configuration
and deployment need to be very
easy and streamlined.
Training for users needs to be
built into the application so
people can get started
with minimal effort.
When it comes to integration,
there's one area where I think
we actually can provide a
lot of values to users.
And that's in the user account
provisioning process.
Those who have been enterprise
space know this has been a
pain point for a long time.
And fortunately over the past
decade or so, we'd actually
seen a convergence on LDAP
directories in the enterprise
as a way to manage user accounts
and authenticate
users and ensure people have
the right permissions.
Unfortunately when we all made
the move to the cloud, a lot
of those lessons been lost.
So today in the marketplace
what we're seeing for
provisioning is really
two models emerging.
One is what I would describe
as an invite model.
And this is where an
administrator has to
explicitly create an account for
their users before those
users can log in and use
the application.
The second is an ad hoc model.
And this is where accounts and
organizations are just
dynamically created and
associated every time a new
user logs in for
the first time.
On either case, remember that
we're always authenticating
the user with their Google
account through our Single
Sign-On mechanism, which
is based on OpenID.
But in addition to being a way
to do Single Sign-On and
authentication, OpenID is also
an opportunity to streamline
the set-up process for users.
You can do this by taking
advantage of an extension
called Attribute Exchange
which allows us to fetch
profile information such as a
user's first name, their last
name, and language,
and email address.
So let's actually take a look at
this in practice and how it
can improve the apps.
This is actually a screen shot
from another app in the
Marketplace--
BatchBook.
It's a CRM application.
And this is their sign-up form
that users who come directly
to their site would see
when they sign up.
It looks just like any other
sign-up form on any other web
application.
The problem though is that the
longer and more complicated
these forms become, the more
opportunity and the more
reason there is for users to
abandon your sign-up funnel.
So it's really important that
you make the sign-up process
as streamlined as possible.
When it came to integrating
with the Marketplace, they
were able to take advantage of
Attribute Exchange and OpenID
to simplify this greatly.
The result is a form which is
basically one field asking for
their time zone.
And if they really wanted to,
they probably could've skipped
us too by using geo-location
data to figure out where the
user is or using some JavaScript
to test the
browser's time zone.
But you can see that by using
the information they got when
the user authenicated, they
were able to eliminate the
need to ask for their
name and email.
They were able to eliminate
the need
to ask for a password.
And the whole process became
much, much simpler for users.
When you talk about the invite
model, the savings can
actually be even
more dramatic.
So in this case we're looking
at a screen shot from
Expensify, which is an expense
reporting application in the
Marketplace.
This is a screen in the form
that administrators would see
when they need to bring
additional users into the
application to get started.
For a small company, three to
five people, this isn't really
that big a deal.
You probably know everyone.
You know their email
addresses.
You could probably set them
up in under a minute.
But what happens when you
get to 20 users or
50 or 100 or 500.
This process breaks down.
When they joined the
Marketplace, they were able to
simplify this by taking
advantage of some information
available to applications
from our user feed.
This basically gives you access
to the list of users in
the domain, including their
name, email, and so on.
The result for administrators
is that now they just get a
form with all of their users
pre-populated and, to complete
the work, they just simply
need to say what are the
reporting relationships and
who has access to approve
expense reports.
Much simpler.
Much faster.
And if the company sizes to
scale up, the savings become
more and more dramatic.
The user feed has another
purpose which is really,
really useful for speeding
adoption of your application,
which is helping administrators
improve the
awareness of your application
and provide them
some training material.
This is a screen shot.
The text might be a little
bit hard to read.
But it's from another expense
reporting asking app--
Concur Breeze.
And at the end of their
deployment wizard, they
present administrators the
option of sending an email to
all their users or at least all
the ones that they invited
into using the application.
And that email provide them with
some quick instructions
about how to actually get
started with the application
and beginning submitting
expense reports.
As I mentioned earlier in terms
of the importance of
building training into your
application, leveraging the
user feed, leveraging the list
of users, and proactively
reaching out to them is a great
way to provide some of
that training material.
And we'll go into some more
of it later as well.
Of course if you do have
access to this user fee
information, you have to be
careful not to abuse it.
It's a lot of information.
You have the email addresses
for an entire company.
Don't spam users.
Don't abuse the information.
Try to be a good Net citizen.
Give them the ability
to opt out.
And likewise if you start
subscribing people, give them
an opt out as well.
Please comply with all
the spam regulations.
So what we just saw are two
different ways of basically
getting the same information.
We saw the user feed and OpenID
with Attribute Exchanges.
And if you compare them side by
side, you actually see you
get pretty much the same
information from both.
You get email, first name
and last on both APIs.
OpenID does give you the
language, whereas the user
feed gives you a little bit more
detail about the user's
role in the organization and
their account status, whether
it's enabled or disabled.
The main difference is when this
information is available
and about which users.
With OpenID we're always getting
information about the
current user at the time
that they log in.
With the user feed, the
application can get
information about any or all
users on the domain at the
request of the application.
One important note with OpenID
is that the attribute
information does require that
you do additional verification
if you want to use it for
anything other than
pre-filling in a registration
form.
You can do things like verify
that the OpenID request is
from a trusted identity provider
like Google where you
know that we do some
verification of information.
You could also just do
traditional verification
techniques such as sending
somebody a verification email
to make sure that they actually
have access to the
email address.
So before we move on to
collaboration, I just want to
quickly wrap up here.
Remember that you do
want to streamline
adoption as much as possible.
The longer and more complicated
you make your
set-up process, especially in
the self-service model, the
greater the chances customers
are going to abandon that
funnel or delay or just never
come back at all.
The simpler you make it, the
better and the higher your
conversions will be.
You can do this by taking
advantage of existing data.
We talked about two strategies
for doing this.
One is OpenID.
The other is the user feed.
And it's actually pretty common
for application to use
a combination of both
these APIs.
One, to prefetch the list of
users to the domain, but still
using OpenID and Attribute
to make sure that they're
actually authenticating
the correct users.
You could also use this
information for training
purposes and to increase
awareness.
Again, you do want to make sure
that you don't sacrifice
security or become
a bad citizen.
Verify your attributes when
you're using OpenID.
Don't abuse the email lists.
Don't spam users.
So let's talk next about
collaboration.
When we talk about
collaboration, there's two
aspects that we like
to talk about.
One is collaboration
among people.
These are my customers, my
co-workers, my suppliers--
people that I need
to connect to.
The other aspect is the
actual data that we're
collaborating on.
So how do we use integration to
make this more effective.
We'll start with a really simple
example in Goggle Apps
which is auto-completion
of contacts.
One of the things I love as a
user of Google Apps is whether
or not I am sending an email,
inviting somebody to a
meeting, or sharing a document,
I rarely have to
remember somebody's
email address.
I simply type in the first few
characters of somebody's name
and it's going to display me
a list of matching people.
And I can quickly select.
Because I rely this so much, I
actually don't remember all
that many email addresses of
people that I talk to them on
almost a daily basis.
And it's one of these things
where the time saving seems
really small, but based on the
frequency that we communicate
with each other, it actually
builds up to be very quickly.
So as a user, I've come to
expect this behavior in other
applications.
Now it turns out that data is
available for third-party
party applications like your
own to actually do this.
Here we see a screen shot from
Mavenlink, a project
management application that
actually syncs with Google
Contacts in order to provide
that same user experience of
auto-completion to users
in that application.
It's actually really
simple to do.
Probably the most confusing part
of it though is the fact
we have so many different APIs
for accessing information
about people.
For starters we do have the
Contacts API which gives you
personal contacts for
an individual user.
But we also have some additional
APIs such as a
Shared Contacts API which is
a global address list for a
domain of users who
are external.
There's a related API called
the Profiles API which is a
global address list
of internal users.
And to make it even a little bit
more complicated, there is
the previously mentioned user
feed which gives you a subset
of all this information
for domain users.
So the question is like which
ones do you use if you want to
get information about people
that I collaborate with?
Well, both of the shared
Contacts APIs are restricted
to Google Apps for Business
and Education customers.
And so from a developer's
perspective, you do need to be
aware of that co-defensively,
and make sure that you're not
relying on those APIs
being available.
I encourage you to actually look
at both the Contacts API
and the user feed first. And
the contacts are useful in
cases when you want to get
usually external contacts that
a person might know and the user
feed is a great way just
to get a list of somebody's
co-workers or all the people
in the domain as another source
of information for
autocompletion.
Of course, you can still
use these other APIs.
And it's actually a great way
to add additional value for
those larger customers that are
actually on Google Apps
for Business--
and drive additional
value for them.
Another way that
document-centric apps at least
can add some basic collaboration
features is by
taking advantage of Google Docs
as a storage mechanism.
Here we actually see a screen
shot from Gantter, which is
another project management app
that does Gantt charting.
And they've seamlessly
integrated Google Docs as a
cloud file system.
One of the things missing
though from Gantter's
implementation is a notion
of who we're
actually sharing with.
So as a user if I wanted to
share this project plan with
the team that I'm working on,
I'd have to go back into
Google Docs, find that document,
and then set the
sharing permissions so that
everyone has access.
And that way when they opened up
Gantter, they would be able
to see that document as well.
So how do we make this better?
How do we make this
more seamless.
Let's take a look at another
example, another project
management app called
Manymoon.
And Manymoon allows users
to attach Google Docs to
projects and tasks.
And you can actually search for
a doc or create a new one.
But they do something else
which is pretty clever.
They actually take a look at
what the user's intent is when
they do this.
And they realized when
I attach a doc, I'm
not sharing a link.
That's not what I want to do.
What I really want to do is
share the content of the
document itself.
And since Manymoon knows both
the set of users who are
working on that project and the
set of documents that have
been shared with the team, it
can proactively manage the ACL
through the document.
and they do that by taking
advantage of the ACL feed in
the document's API.
Any time a user or a document is
either added to or removed
from a project, the ACLs are
automatically updated.
To understand how important this
is and how much of a time
saver it is, you have to realize
what would happen if
they didn't do this.
If I were to share a document
with the team and send it out
review but I didn't set the
permissions, anyone who came
along would try to open up the
document and get an error.
And they'd have to send off an
email to me asking for me to
approve access.
If I happened to be in
email at the time,
that's not so bad.
It might take me a minute or two
to see that email and make
sure that they have the
right permissions.
But if I'm stuck in a meeting or
if I have to go out of the
office for a day or two, that
minute can stretch into a few
hours or it can stretch
into a few days.
So all that time those users are
blocked, waiting for me to
take action.
So it's really great to see
applications like Manymoon,
Mavenlink, Box.net and a few
others improve upon our
sharing model to make
collaboration really
effortless.
So before we move on to the next
section, we just want to
quickly wrap up again here.
Remember you can import the
contacts and the user feeds to
make sharing with
people easier.
This is something that Google
Apps users have come to just
rely on in Google Apps.
They will come to rely on it in
your applications as well.
This is also great for apps
that spread virally.
If you have an invite model
where you rely on people
socializing your app for you,
kick starting that process
with their contacts
is a great way to
get additional customers.
Remember that sharing
it not just linking.
We really want to focus on the
content that we're sharing and
making sure that people
have access to it.
And of course none of
this is limited
to contacts or documents.
This all applies to any piece
of data that you can have in
your application.
It may be calendars
and team projects.
It could be your customer
records in your CRN.
Anything that people collaborate
on you want to
find ways to make collaboration
as simple as possible.
So the third area I want to
focus on is improving access
to information.
So we've seen how we
can streamline the
set-up for our users.
We can make it easier for them
to connect to each other.
But we still have some
inefficiencies in how people
work that we can make better.
Let's start with an
example of this.
So suppose I'm a salesperson
and I get this
email from a customer.
And the customer really
wants to do a pilot.
And potentially there's going
to be this huge company-wide
roll-out that could be worth
tens of thousands or hundreds
of thousands of dollars
in business for us.
So what do I do?
Well assuming that we actually
have a CRM that we use to
track these opportunities--
let's say in this case,
Solve360, which is another
application in the
Marketplace.
I'd have to go and switch over
to that application, look up
that customer record, and search
for the right entry,
then update it.
I might have to switch back and
forth between Gmail and
the CRM in order to copy and
paste some information back
and forth to make sure the
CRM is up to date.
It works.
But I'm losing time
in doing that.
So how do you make it better?
The answer is you bring
the application
into the mail itself.
And so is what contextual
gadgets allows developers to
do-- to actually embed their
application in Gmail, in the
context where it's
actually needed.
And you can actually match on
things like who sent the
message, the subject, the
content of the message itself,
and use that to determine what
your gadget shows or if it
should show at all.
So the advantage is now as a
user I don't have to go and
look at that customer record.
It already knows who the
customer is based
on who sen the email.
Now I can just open that up,
update the opportunity, and do
this without ever leaving the
message and without ever
leaving Gmail.
Really, really powerful.
It turns out on to be one of the
most popular features that
applications developers
are using today.
And rave reviews from users
using these integrations.
So a quick tutorial
on how these work.
They actually turn out
to be really simple.
It is all based on OpenSocial,
which as open standard for
embedding third-party content
into an application.
If you could write HTML
in JavaScript,
you can write a gadget.
That's basically what it is.
It's just HTML in JavaScript
and a small bit of
XML to wrap it up.
For gadgets, the way it works
is you start with an email.
The customer opens it up.
In the background what happens
is we extract some information
from that message and run
it through a filter.
And these rules for the fields
that we extract and the
patterns that we match are
defined in the manifest for
your application.
If there's a match, we
render the gadget.
Again that just is HTML and
JavaScript, which then gets
rendered into the
email itself.
It's a really simple process.
It does take a little bit of
work just to get started.
But once you are, you're just
using the same development
tools that you use for writing
your own web application.
There are a couple of catches
with contextual gadgets.
First is you have very,
very limited real
estate on the screen.
You notice in the screen shot
of the Solve360 gadget that
their default view basically
just showed two buttons.
And they don't expand into the
full view unless the user
explicitly clicks and
takes action.
Part of the reason
for this is--
one, it's a very small area in
Gmail underneath the message
have to do this.
And then the other thing
is some users may
have multiple gadgets.
And so if one of them is taking
up a lot of screen real
estate, other gadgets that the
user might be interested in
for that particular message
could end up getting buried
beneath the fold and they'd have
to scroll down to get it.
It's not a very good
user experience.
In addition to that, we
encourage people to match very
conservatively.
For some gadgets, that's
pretty easy to do.
If your a gadget for approving
an expense report or
somebody's time sheet, it's
pretty easy to recognize if
it's as an email from your
application that you want to
embed a gadget for.
For CRM apps, project
management-- it might be a
little harder to come up with
a set of very narrow rules
that you're probably going to
trigger on just about every
message that a user receives.
And that's where it become even
more important to make
sure that your UI is kept small
until the user wants to
actually engage with
your gadgets.
Another limitation that you need
to be aware of is gadgets
only have access to about
1K worth of data
in the email itself.
This is just a technical
limitation in how it's built.
There are some work-arounds
though.
So one way to do this is to use
some extensions that we
have IMAP so that you can fetch
the content of the email
and the attachments
in the background.
To make this easier, we do have
OAuth authentication for
IMAP clients.
So you don't need to ask for
the user's user name and
password in order to
access their email.
They can delegate this in
a secure way to your
application.
And there are also some protocol
extensions to make it
easy to access emails based on
the Gmail message and thread
IDs, as well as manipulate
labels.
So open social technology
actually has
uses in other contexts.
Within Gmail itself, you
can actually use
gadgets in the sidebar.
Here we actually see
a screen shot from
Atlassian's JIRA Studio.
It's a hosted development
environment that includes bug
tracking, issue tracking,
Continuous Build
Server, and so on.
So for developer, instead of
having to go and switch over
to JIRA to go and check to see
what my open issues are, it's
really nice to have that list
of all my hot issues and my
top priorities in my Gmail
sidebar so it's always
available at a quick glance.
So using OpenSocial and
OpenSocial gadgets, they
actually provide a Gmail gadget
that you can embed and
keep that list readily
available.
You could do the same
thing in Calendar.
Here we see a gadget from
TripIt, which is a trip
planning tool.
And here I can see in my
Calendar sidebar my upcoming
trips, as well the trips of
people that I'm connected to
inside TripIt.
Talk is another really useful
integration point.
Again, going back to Atlassian,
they've integrated
Talk into their Build Server--
the Continuous Build Servers--
as a lightweight mechanism
to push out build status.
So I'm a developer, it's the
end of the day, I've just
checked into Change, and I'm
waiting for the next build to
go green so that I can go home
and know that I didn't break
the build and cause
a whole bunch of
developers a bunch of heartache.
So rather than sending me an
email, which is pretty
heavyweight and clutters up my
inbox, I can just open up a
Chat window with the Build
Server and get those status
update pushed to me in near
real time in a really
lightweight way.
Beyond pushing information
though, you can actually use
Talk as an input mechanism.
What you see here is actually
an application.
This is GQueues, which is a To
Do list project planning tool.
And they allow people to enter
in items into the To Do list
by basically just chatting
with the application.
And they just used a little bit
of language processing to
convert that text into an item
that would appear on your To
Do list, in your Calendar, and
on your phone, and elsewhere.
Even if you don't have a mobile
application, pretty
much everyone can do SMS
or IM on their phone.
A really nice lightweight
way to do data input
but for some apps.
For Talk, just remember
Talk is just XMPP.
This is an open protocol.
It's widely used.
Lots of libraries out there
to make it easy.
And if you are interested in
using Talk as an integration
point, I really encourage you to
take a look at App Engine.
App Engine has both built in
client libraries for both
Python and Java and of
course now today, Go.
But it has some built-in
classes to make writing
chatbox real easy.
And even if you don't use App
Engine yourself for hosting
your main application, it
actually turns out to be
really useful as a bridge.
You can actually just use it
as a Chat front-end and
forward all those calls
to your application
using your own APIs.
But a great way that you can get
started with Talk, without
really investing a lot into
infrastructure or tools.
And I think Cameron mentioned
his Talk integration--
something he did on App in about
two days' worth of work.
So pretty easy to get started.
It turns out to be pretty useful
for a lot of apps.
In a lot of these use cases,
we've really been talking
about consuming information
from Google Apps.
In addition to consuming, if
you publish information and
make it available, lots of
really good things can happen.
Let's take a look
at an example.
Suppose I'm starting up a
new marketing campaign.
I'm going to go into my project
management tool.
And I'm going to create a new
project-- let's say, let's
work on our new marketing
text for our
email marketing campaign.
I've got to create some
deadlines around that project.
I've got to create a document
that we can use to
draft up the text.
Well, if you publicize that into
Google Docs and use Docs
for storage and we update our
Calendars, that information is
now available in a whole bunch
of different places.
It shows up on my desktop and my
laptop, through my Calendar
and my Docs, and my Gmail.
It also shows up on my phone.
In fact, I probably have used my
mobile phone for reading my
Calendar and my email more
than I use my desktop.
That information though can
then be consumed by other
applications that also integrate
with Google Apps.
So in this case, our email
marketing tool can then import
that document that we've drafted
up in our project and
then use that to send out
our marketing campaign.
Our marketing campaign
goes really well.
We get some customers.
Now I add somebody to my CRM.
Well, if that customer record
is then published back into
Google Contacts, again it's now
available on my desktop,
in my Gmail, in my Contacts,
in Google
Docs, in Google Calendar--
everywhere that Google
Apps uses Contacts.
It's also available
on my phone.
And it could also show up in
our support system so that
when we have a ticket with that
customer, you can trace
that back to our CRM, it could
show up in our list of
customers for our next marketing
campaign that we
send out, and our
marketing tool.
So by publishing information
and sharing it, you can
actually use Google Apps as
a hub to get additional
integrations with other
applications.
Really, really powerful.
And we're trying to see this
happen in the Marketplace as
users start to use more and more
applications together.
Now of course, there are cases
where it doesn't make sense to
use Google Apps as a hub.
And I actually encourage
you to go do some
integrations directly.
Earlier, I mentioned FreshBooks
and how they invest
a lot in integrating with
other applications.
Well, I took a look at their
list of integrations and those
apps in the Marketplace.
And the intersection
of those two lists
actually looks like that.
So these are all the apps
in the Marketplace that
FreshBooks already works
with directly.
There's actually a whole list of
other apps that aren't yet
in the Marketplace that I could
have added to this list.
If you go out to next level
and find out who they
integrate with, you get more.
And these aren't just one-way
integrations.
They actually all integrate
with each other.
And so you actually get this
nice network of applications
that integrate, not just with
Google Apps, but with each
other as well.
Everything I said here about
integration hold true whether
or not you're integrating with
Google Apps or any other web
application out there.
And I sincerely encourage you
to go out, talk to your
customers, find out what they're
using and if there's a
way that your application and
those applications that you
use today can work better
together through some sort of
integration, go ahead
and do it.
Your customers will love it.
Beyond just helping your
customers and giving them more
value, it opens up some
additional value to you as
your business because it
gives you co-marketing
opportunities, it gives
you referral traffic.
Basically, it's a way that
applications can help each
other grow and thrive.
So wrapping up the access area,
keep in mind that this
context switching that we talked
about at the beginning
is a big productivity killer.
You want to find ways
to do that.
A couple different
strategies--
one is to bring applications to
the users where they need
it: contextual gadgets for Gmail
or any of the gadgets--
whether they're Sidebar--
in Gmail Calendar
sites, wherever.
Just a great way to bring
functionality to users where
they need it.
The other way is to
publish data.
Make it available so that people
in other Google Apps or
other third-party apps that
integrate, can also access
that data in a simple way.
And again, remember this is
not just for Google Apps.
Really, I want to reinforce this
again, find out what your
customers use, integrate.
I don't care if it's
Google Apps or not.
They will appreciate it.
You will find a return
on that investment.
So there are a few more things
that I want to talk about.
So I mentioned earlier how
the Marketplace is not a
traditional enterprise
sales channel.
You really have to focus on ease
of use, deployment, and
really make sure that you have
a nice, clean, intuitive UI.
This is one of my
favorite apps--
Mavenlink.
We actually just named them
yesterday as our first staff
pick in the Marketplace.
I think they do a great job at
making it really easy for
users to get started.
Not only is the interface itself
clearly labeled and
intuitive, but they have this
nice built-in tutorial that
when users jump into the app,
they actually are trained how
to use the app, using the
application itself.
Really easy for users
to get started.
They get tons of great reviews
because they focus so much on
making sure that their app is
designed for self-service and
for small companies to
get started quickly.
Even if you look at their help
system, their help system is
just a layer on top
of the UI itself.
There's no switching back and
forth, reading long documents
on how to use it.
You can just say, hey
what's this,?
Click on a link, click on a
video to learn how to use it.
Great app.
Really good one to study in
terms of how to build
something that users
can get up to speed
with very, very quickly.
Of course with all this, you can
build all the integrations
in the world, you can add all
sorts of cool features, but if
customers don't understand them,
if they don't know that
they exist, it's not going to do
much for your application.
So don't forget marketing.
You do want to make sure that
you have a very high quality
listing page that clearly
explains both the value of
your application, plus the
value of the integrations
themselves.
You can also do this on your
site itself by having a very
high quality landing page that
can go into more detail.
Blogging, tweeting,
PR outreach--
all of these are important to
make sure that you have a
really successful launch
on the Marketplace.
Another resource that we
sometimes talk about is
leveraging your existing
customers.
And they turn out to be a great
way to really bootstrap
your growth on the
Marketplace.
So if you are joining the
Marketplace and you happen to
have a set of customers who are
already on Google Apps, I
encourage you to go out to them,
encourage them to try
your application from
the Marketplace.
And if they like it, if they
like your integrations, go out
and provide ratings and reviews
on the Marketplace.
This will help your application
move up in the
search results, get
higher placement.
And additional customers
will follow it.
Also if you start to see some
growth in your traffic, it's
more likely that it will appear
on our radar so that we
can get you into the featured or
a notable section or if you
build something really, really
cool and amazing, maybe we'll
pick you out at the
next staff pick.
So that's really the challenge
for you guys as developers
just to go out there and just
build something that's really
amazing, that really saves
customers time and effort and
takes advantage of the
various integration
points in that process.
Of course, this is just a small,
small sampling of the
things that are possible.
I did mention earlier than we
just started our staff pick
program yesterday.
We will be naming apps
probably two to
three times a month.
So we are looking for
really the best--
not only the best integrated,
but the easiest to use and the
most value they you can
provide to customers.
Again, impress us.
That's the challenge that
we're putting out there.
And we will try to help you get
more customers if you if
you build it--
those really great
quality apps.
Of course while the focus of
today was integration, it's
not the only factor.
Don't forget your marketing.
Pricing is important.
Marketing is important.
There was actually a really
great talk last year at I/O
from Don Dodge.
She did a panel on premium
pricing models.
And so for those of you that
have a premium model or are
thinking about it, I encourage
you to go back to last year's
I/O site, look for
the session.
It was really, really
interesting.
Lots of great advice in there
for how the different
businesses should structure
their pricing in today's
business world.
And again, for the third
time, this is not
just for Google Apps.
Anything you learn today you
can apply it any app that
customers use.
Again, go out, find it, build
those integrations, your
customers will appreciate it.
There are a few resources
that I want to share.
One is the Marketplace itself
which is google.com/enter
prise/marketplace.
Documents and forums for
developing these integrations
are at
code.google.com/googleapps.
Our blog googleappsdevelo
per.blogspot.com.
There's a few Twitter handles
that you might want to follow.
There's the official Google
Apps Developer handle at
GoogleAppsDev.
There's also a few more handles
of some members of the
team that we do post frequently:
Don Dodge, Ryan
Boyd, Scott McMullan,
and myself.
I certainly encourage
you to follow.
We're always looking for
interesting people
to follow as well.
So if you have one and you
follow us, I'll probably call
you back as well.
And certainly session feedback
is appreciated.
Then there's the short length
for those who are interested
in providing it.
So that's all I have
for today.
I do want to turn it
over for questions.
If you do have a question,
please use the microphones.
The question is being
recorded.
And it will just help to make
sure that everyone can hear
the question.
And other than that, I'll be
happy to talk to anyone after
the presentation as well.
Thanks.
[APPLAUSE]
Any questions--
or not.
All right.
Thanks.
