MICHAEL FINK: Hi, my name is
Michael Fink and I'm a Product
Manager for the Google
Chart Tools Team.
Amit and I flew over from
Israel, we're part of
the Israeli office.
And what I'd like to talk about
today is Google's unified
approach for creating
dynamic charts on the web.
Now if you want to follow this
talk what I strongly recommend
is type in that tiny URL.
That's 9-9-T-M-X-I.
We'll try to make this talk as
interactive as possible, so if
you have your laptops open just
type in that URL and what
you should essentially
land on is this Wave.
And what we have on this Wave
is the moderator page if you
want to put up your questions
there and vote for them.
I think that will be a
good time to do that.
And I have here the link
for Chart Tools, which
is our splash page.
AUDIENCE: [UNINTELLIGIBLE].
MICHAEL FINK: I think that's
their responsibility
back there.
Is this better now?
Cool.
So what you see on this Wave
is first our splash page.
You're welcome to visit that.
And then a list of demos that
we'll try to run through,
through this talk.
And in demo one you can
see that it says enter
your hometown here.
Some of you are welcome
to try that out.
It's a very small form that
just requires you to put in
your first name and your
hometown and we wanted to
collect some live data that
we'll be able to show later on
the charts and we wanted to
show you how data that's
collected from your visitors
could be reflected
on your website.
So we thought this would
be a good opportunity to
demonstrate that capability.
So just go ahead,
fill out that form.
It will take you just a second
and hopefully we'll be able
to do something meaningful
with that data later on.
Now I thought that the best
place to start would be
by showing a very nice
visualization and that
essentially shows Tweet
patterns across the week.
This is a visualization
developed by one of the users
of the Google Chart Tools.
How many of you would actively
Tweet, like on a weekly basis?
Hands up high.
Great.
How many actively Tweet,
like on a daily basis.
Wow, that's a nice percentage.
How many Tweet like
more than once a day?
Do we have any volunteer
here that has a
simple Tweet account?
What's your name?
AUDIENCE:
[UNINTELLIGIBLE PHRASE]
MICHAEL FINK: OK, that's fine.
What's your Twitter account?
AUDIENCE: [UNINTELLIGIBLE]
MICHAEL FINK: OK,
wait just a second.
I'll get to that in one second.
OK, so Pete will give us
his Twitter account.
But before we do that I want to
show this very nice
visualization that essentially
shows how many times you Tweet,
how many times you got replies
for your Tweets, across
different days of the week
and across different
times of the day.
And what we have here is the
Twitter account of someone
who chose the name God
as a Twitter account.
And what you can see is that
God has fairly regular hours.
OK, so he sleeps
throughout the night.
He has an intense Tweeting
pattern through working hours.
Maybe towards the evening he
spends some time with the kids,
probably Tweets a little bit
less and then towards the end
of the day, a bit before
Midnight he Tweets a bit more.
OK, so that's the Tweeting
pattern of a user named God.
And what's interesting is that
all of this information is
available in Twitter and you
could easily go through the
logs and see when each Tweet
was created, but one
visualization could give you
are very elegant summary of a
certain pattern that is
hidden across all of
the different records.
That's the power of a
very nice visualization.
And what we can contrast that
is with another Twitter user.
Much less active, luckily.
He only has 56 Tweets across
the last few years and what you
could see is that Twitter
account is most active
during the night.
It has very little activity
throughout the day and
luckily for us, gets
very little replies.
So that's I would say the power
of a good visualization that
could take data that is
publicly available, anyone
could see it, but somehow
summarizes it and presents it
in a very effective way.
So I won't type in your Twitter
account because it's long and
scary, but if anyone wants to
try this application out it's
in our first or second
demo on the Wave.
Cool.
So noticing the power of the
good visualization is what
motivated out team to create
this Chart Tools perspective
where we try to develop charts.
Both for internal use in
Google and then to make
them freely accessible to
developers externally.
And our mission essentially is
to make the world's structured
data universally acceptable
and useful by providing
enticing visualizations.
So that's our teams mission.
And what I'll be talking
about today is essentially
four components.
We'll have four
parts in this talk.
The first I'll be talking
about image charts.
It's a very basic, simple API.
Where essentially you ping
a Google server with a
get request, a simple URL
and you get a PNG back.
OK, so that's the simplest
API that you could imagine
for getting a chart
on your website.
And the chart, as I said, is
rendered on Google servers.
Then in the second part I'd
like to talk a bit about
interactive charts that are
based on a JavaScript library
and that provide a very rich,
client side interactive
experience to your users.
And then I'll switch over to
Amit, our tech lead and he'll
give you an under the hood
perspective on how to do this
with two or three simple steps.
And in the final part Amit will
talk about combining the power
of server side rendering with
client side interactivity.
OK, so let's start with part
one, which is the image charts.
And as I said this is probably
the easiest way-- if you
want to have charts on your
website-- this is probably
the easiest way to do it.
Is just to ping a get
request and get a PNG
back from our servers.
And the way to do this
is fairly simple.
Here's the server, a chart API
is Google.com/chart and what
you see here is essentially
the parameters of the chart
that you would like to get.
I kind of magnified that
because it's kind of small to
see, but essentially it's
very, very straightforward.
So the chart size should
be 500 by 200 pixels.
That's part of your request.
The second part is the chart
type should be p3, which just
indicates that it's
a 3D pie chart.
The chart data should have a 60
for the hello label and then a
40 slice for the world label.
OK, so you see you can just
send this URL, get an image
back and it's as simple
as you could imagine.
So here's that very same URL
and notice I'll just click and
enter and here's the chart and
you could put in an image tag
and get the charts and you
could generate these charts
dynamically and get
different charts.
If I want to say decrease the
size of or increase the size of
the worlds part I could just
change that percentage
and it changes.
So that's very, very simple.
Very, very user-friendly.
And what we started out with is
providing a gallery of the
standard charts that
you would imagine.
So we have the bar charts, the
line charts, combinations of
bar charts and line charts.
Then we progressed to provide
radar charts, maps, bubble
charts, and a variety of other
charts that people asked for.
And what's nice is that we are
continuously surprised, almost
on a daily basis on that
creative use cases that our
users make use of this API.
So could anyone recognize
what's going on here?
So, I think I heard the right
answer, but maybe that will
give you a small hint.
So, that's the great dipper.
And what you could see, this is
essentially a bubble chart
rendered by the chart API, the
image chart API and one of our
users essentially built a
website that you enter your
location on the planet and you
say here's the time of the day
and it will give you a perfect
rendering of the night sky
using the image chart API.
And there are a lot of
creative use cases as I said.
So the standard procedure with
working with the image charts
is usually to play around
manually, finding the right
chart that you would
like to render.
Maybe playing around a bit with
its parameters and then once
you're happy with that result,
usually go to generate that URL
programmatically using some PHP
and JavaScript wrappers that
are available out there.
And in order to facilitate
this process what we've just
yesterday launched is a very
straightforward chart editor,
which gives you a variety of
different charts that you
might want to choose out of.
Say I take this radar chart and
I'm quite happy with this radar
chart, but I want to play
around with maybe
with the fill.
I could change that maybe to a
blue fill, maintain some
transparency and the output of
this editor is a URL that I
could just plug into my
browser and you can
see here's the image.
That I just wanted to I could
play around with the data
obviously and pretty much with
any of the parameters of the
chart and that gives the manual
prototyping and then I could go
to those PHP and JavaScript
wrappers that I mentioned
earlier on and make sure that
live data could be reflected on
my website using this API.
So we started out, as I
said earlier on with
focusing on charts.
And what we've done in the
last year is we've gradually
realized that there are a lot
of rendering needs that we
could help out using te
essentially same servers
and same interface.
And this effort started
out with essentially
pins for Google Maps.
You might have
recognized these pins.
So they usually have certain
letters or text in them that
might vary and the color
might change and the
shadow might change.
So we essentially extended
the API to provide what
we call dynamic icons.
So very often as a developer
you might need small icons or
small visual elements that you
want to plug in into your map
in your site or onto any other
element and what we provide as
part of the image chart API is
this ability to create
dynamic icons.
And we have a very
rich gallery.
We recently added all of the
maps of the world and there are
several hundreds of other
configurable icons that you
could play around with.
We also added a functionality
to provide QR codes.
So if you want a service to
provide QR codes you're
welcome to use the service.
If you want to use a LaTeX
equation you just again, use
the exact same APIs image
I mentioned earlier on.
You type in a get request
and you could get a
dynamic LaTeX equation.
And you can see here some
other nice use cases
for dynamic icons.
So that pretty much sums up the
first part that talks about
static images, which are nice.
But what we are really excited
about is the interactive charts
and interactive experiences
that we want to
provide to our users.
So what we have here is
essentially the second API.
The interactive chart API
and it comes with a very
rich gallery of charts.
You could see in the top
the basic core charts
that you would expect.
The bar charts, the line
charts, the scatter plots.
But then gradually we added
gauges, term clouds,
organizational charts.
Here in the third line you
could see charts that
you might find familiar.
So we have here an annotated
timeline chart that was
originally developed
by Google Finance.
We have here a geomap chart
that was developed by the
Google Analytics team and
it's part of the Google
Analytics reports.
We have a motion chart
that was developed by
the Gapminder guys.
And we have the math charts.
And essentially what we're
trying to do is we're trying to
say each and every one of these
charts probably required
several thousands of hours of
engineering work that has been
done within Google and has been
done mostly for Google needs.
Could we somehow wrap it in a
unified way and an elegant way
and then give it back to the
community so any one of you
could use his own data and
present it with these charts
that are made available?
And what we could see on the
bottom line is that this
community effort is starting to
pay back in the sense that the
protocol that defines the
data-- we have a specific data
table protocol that we work
with-- has been adopted by many
other external developers and
on a monthly basis we get
contributions that extend our
gallery by external developers
that say hey, I have
this new [? tree map ?]
flash chart and I would like
to add it to your gallery,
are you willing to add it?
It complies with the same
format as the other charts and
we just add it and we gradually
get more and more
contributions.
And what I'm trying to
emphasize here is that this is
really a community effort in
trying to have the richest
gallery of charts available in
a free manner for
all developers.
So in the last few months we
tried to take the core charts
that were originally developed
probably two or three years
ago and go into a major
rewrite of these charts.
And the first thing that
we targeted is the color
palette of the charts.
And we really did a in-depth
research into optimizing the
new colors of these
core charts.
As you can see here
in this pie chart.
And then the next thing that we
targeted is carefully designing
the layout of the charts.
So we went into this extensive
session of optimizing the white
space versus the central
area of the chart.
And I think we're very
happy with our new layout.
This just been
launched yesterday.
So if you look into our site
you could see that all of our
new charts are available there
with some comparisons to how
the charts used to look and how
they look right now and I think
that you'll see that they've
gone through a major revision.
Once last addition that we've
done is we're in the process
of adding a lot of
new functionality.
This will come out in
the next few weeks.
What we could see here is the
option of combining line chart,
bar charts, area charts
all into one thing.
So, in order to demonstrate how
this rich gallery could work
together and how it could be
presented and essentially do a
major facelift to a website we
built a mock website called
Backpaki and it will be
integrated into our
documentation so you're able to
take snippets out
of this website.
And Backpaki is essentially a
wiki page for backpackers.
OK, so if you're a backpacker,
you just came back from Mexico
and you want to give some
stats about your trip.
How much did it cost?
Who were you traveling with?
You could just go into this
wiki page and fill out the
textual information and the
page looks right now just as
a plane textual page and
it's not very exciting.
And what I would like to show
you in the next few slides is
how we could completely change
the experience using the
appropriate visualizations.
So the first thing that you
would obviously expect to do is
to say, OK, why would I have a
textual table of all of the
destinations in the world?
What I would naturally expect
to have is a map that
highlights, what are the hot
destinations right now.
Again, I want to show you how
simple it is to add such a
visualization to your site.
So what we see here on the
left-hand side is our code
playground, which is
available on Google Code.
And what we would like to do is
to take this geomap that you
see on the left-hand side and
just use it to replace
that textual list that
is kind of boring.
And notice that the color
palette of the Backpaki is this
brownish, nice brownish colors.
So here's our playground.
And you could see that it has
a nice code snippet for each
visualization that
you would like.
So here's the geomap snippet.
And what you could see down
here in the bottom is a live
version of the visualization.
And what's misfortunate is
that the geomap is right now
color-coded with this green
color that is completely
not suitable for Backpaki.
So what I would do is I'll just
go to the HTML snippet and go
down to the options part
that draws the geomap.
And with a simple change,
adding the option, which
naturally is called colors.
I'll try to set the range of
colors to go from say white,
all the way to a
brownish color.
Let's see if that works.
OK.
So I just go into the code
snippet, modify anything that
I need in order to get the
visualization to fit exactly
into the scheme that my site
presents and then I'm just
copying this snippet,
opening a new file here.
OK, saving that.
And essentially if I go to test
HTML, so I'm trying to open
that site and here's my website
with a relevant visualization.
So as you can see it's just as
simple as going into the
playground, modifying a few
options and then pasting that
snippet into your website.
And voila, the
visualization is there.
So what you're probably asking
right now is, OK, you
configured the chart to look
the way you want it, but it's
not connected to the actual
data that I have on my website.
So what I want to show you
right now is that again
could be done with two
very simple steps.
How many of you actually
filled out the form?
Quite a lot.
OK, so here's the form.
And here's the spreadsheet
that aggregates all the
data that you guys filled.
Is Roger from Menlo Park here?
Hi, Roger.
OK, so this is the data that
was just collected live and
here's the version of Backpaki
that I mentioned earlier on.
And I'll just go to the friends
on map tab and what I would
like to do is to show whether
we could use in this
visualization in order to help
Roger find a friend that lives
close to Menlo Park and to make
sure that if you're a
backpacker you could
look around and find
backpackers in your area.
So that's Michael.
Let's zoom into here.
So quite a lot, quite a few
are from the Bay area.
Is Roger here?
Roger, I think we
found you a date.
So there's Julian, that's
in-- is Julian here?
Julian, talk to Roger
later on if you want
to go backpacking, OK?
So you could see how live data
that was aggregated just a few
minutes ago could be tied
together into a very compelling
visualization that helps people
with the information that
they're trying to find.
Now what we did is we added to
Backpaki a few additional nice
visualizations that we've
recently added to our gallery.
What you could see here is
a tree map visualization.
So a tree map to those who
don't know, a tree map is a
visualization that essentially
is aimed at describing
information that is in a
taxonomical structure.
And essentially you could say,
what are the destinations that
guys usually go to and they're
kind of color-coded here in
blue and the size of the
rectangle says how many
travelers actually
go to destination.
And you could see that
there are countries
that like Cypress.
Very few people go to Cypress,
but say Malaysia is a much more
prominent destination and you
have an additional color that
you could kind of indicate
where gals are going and where
guys are going and I think
this is a nice visualization.
We also have here an
example with prices.
And one more thing that we have
is in, so here's the same
geomap that we've seen earlier
on and you could see that maybe
this month Mexico is a
hot destination for
people to travel in.
What I did is I just clicked on
Mexico and I could drill down
into the next level of
resolution, which are the
regions within Mexico.
I could see that Wachaca is a
very popular destination within
the backpacker community
that's going to Mexico.
And what I have here in the
bottom part is, as I
mentioned earlier on, is an
annotated timeline.
You might recognize it.
It originated from the
Google Finance team.
And I could just zoom into the
duration that I want to go to
Mexico, which is sometime in
October and I could see that in
October I could go to and catch
the Independence celebration
and that there are two other
events that I could play around
and visit while I'm in Mexico.
OK, so this is how
visualizations could
work together.
And then I could drill down
into Wachaca and say hey, what
are the actual treks that
people are going through.
And I could drill down to the
level of actually seeing a map
that has the relevant
trek information.
And what I have here on the
bottom is an altitude map of
saying that this is
a five-day trek.
It starts at fairly low and you
reach a peak of 3,200 meters.
And what's nice about this
is that these charts
could work together.
So you could just catch the
event of clicking on any one of
these destinations and the map
up on top is centralized around
that specific destination.
And what I kind of plugged here
on the side, if you want to
post on your backpackers motel
in the evening you know, here
are the details of
tomorrow's tour.
You could just plug it with
that same QR code that we saw
earlier on generated by the
image chart API and get kind
of a comprehensive summary
of tomorrows destinations.
So I think I pretty much
covered all of the things I
wanted to show in Backpaki.
Now the only thing that I had
to do in order to connect the
data into the spreadsheet that
aggregated your information was
to take a snippet
from our site.
Oops, sorry.
Take a snippet from our site
and the only line I have to
actually put in, in order to
hook up to my data is this
line, which as you could
imagine it's just a query that
goes into this specific
spreadsheet that's aggregating
my specific data.
OK, so that's essentially the
only change I have to do after
I configured the look and feel
of the chart to the brownish
colors that Backpaki has is to
change the data source to be
the spreadsheet that I want.
And it could be any other
data source as Amit will
explain in a few minutes.
So that's pretty much my
section of the talk.
And I want to invite Amit, who
is our tech lead and he'll
take over from here.
AMIT WEINSTEIN: Thanks Michael.
So let's go back to the
site for one moment.
OK, what we saw here is the
demonstration of how we drill
down in the geomap between
the two zoom levels.
So we start in the world map in
order to see better the entire
world all the relative volume
of travelers in each place.
But you want to be able to
drill down into a specific
zone and see more
information about it.
So how would you like to
implement such a thing when
you have a visualization?
So basically what we want, we
have the data for each of the
zoom levels and we want to
travel between the
different regions.
So we basically want to listen
to the click event of a user
on a region and tell the
visualization, OK, the user has
clicked in some region and you
want to step into a specific
region to get more information.
Let's look at the code.
So basically this is part of
the real code that is available
on the Backpaki mock site
that you can see later on.
So we basically hold a stack of
the current state where we are,
so we start in the global scope
and then as the user push on
the region we simply step into
the stack and we
add new regions.
So when we listen to the region
click event we simply push a
new region to the stack and
redraw the visualization.
And of course we want to be
able to zoom out, so we listen
to the zoom out event, which is
built in into the geomap
visualization and we pop the
last region from the stack and
redraw the visualization.
So this is a demonstration how
you can really be interactive
with the chart even though the
chart doesn't support the zoom
capability as part of
the chart itself.
So you can add new interactions
using the JavaScript code
instead of the visualization.
Let's have an overview of how
this API works in case you
have different episodes,
like Michael showed.
In our example we use
the Google Spreadsheet.
So we have the browser
and we want to show
some visualization.
So the Google Chart Tools
define some data structure.
Structured data, we call it
data table and the API is
documented on our webpage
and it's publicly available
so everyone can use it.
And basically in the JavaScript
code we create some data table,
populate it with the data and
send it to the visualization in
order to show it
on the webpage.
But the question is where's
the data come from?
So we saw in the playground
example the data is simply
hard-coded into the JavaScript
code and stored there.
But this is not practical
for real data for the
webpage that we have.
So what we want to have,
we want to take the data
from a remote source.
We have the Chart Tools
protocol for query
and response.
And what we saw in the previous
slide, we simply had a Google
Spreadsheet which has a
specific URL and we get the
data directly to a browser.
So the question is, where
do we manipulate the data?
We don't want to have different
spreadsheets for each
query that we want.
And we want to be able
to extract part of
the data to show.
For example, in the GeoMap we
wanted to show only the regions
of a zoomed in country
and not all the map.
So for this end we have a query
language, which is SQL like and
is also part of protocol
and Google Spreadsheets
implement that language.
So we can send the spreadsheet
query and ask for a specific
part of the table and in order
for us not to get the entire
spreadsheet so we can
visualize the data.
But Google Spreadsheet is
only one data source.
And obviously users want to
have different data sources.
So for example, if you have a
SQL database or a CSV file that
you store the information in
you might want to be able to
create your own data source,
which wraps these databases.
So to this end, we have two
open-source libraries.
One in Java and one in Python
that allows you to wrap your
data sources and create a
simple server that gets a
request in our protocol and
process the request in
restoring the data and the
library as I said, has some
query language and the Java
library also supports
Acorn management.
And the question is, if you
have for example a SQL
database, where do you
want the query to happen?
So although our query has the
capability to perform select
operation and field operation
it is much more efficient if
the operation of the query
language happens inside the SQL
database because this is very
efficient and the data doesn't
have to be transferred from the
data to the data source server.
So to this end the Java library
also enables to use that
database native capabilities
in order to make the
query more efficient.
Let's look at some example.
Let's say we have some
spreadsheet data as the thing
below here and we want to have
our query select
the department.
But we want to only take it to
where our revenues are above
$20,000 and we want to order it
by the revenue in
descending order.
So this question is sent from
the browser to the remote
data source, to the
Google Spreadsheet.
And we take only the subset of
the data and send the response
back to the browser.
If this were SQL database we
could either apply the query in
the Java library or use the SQL
native capabilities in order
to make it more efficient.
OK, of course SQL and CSV and
Google Spreadsheet are strong
databases, but obviously user
has some other custom databases
and you can always use your
own database as the back end.
Even using our library in Java
and Python you can use whatever
database you have, but our
users also contribute
some other languages
that you can use.
For example, PHP
and Ruby on Rails.
and you can use whatever
library that you want as the
protocol is open sourced
and is freely used.
So this was an overview of how
you can connect whatever data
source that you have or
whatever database that you want
in order to show it in the
browser for the final user.
OK, as Michael said, this is a
community effort and we defined
some API, which is a common
language to be shared for all
the visualization in order
to reduce the number of
adjustments that we need to do
in order to show visualization
from different data sources.
So we have the [? converting ?]
from data sources to our
API and we want all the
visualization to use our API
in order to get the input.
So this is for example,
a nice visualization
written by WordPress.
A ball cloud, which the words
is different sizes according
to the volume that
they define here.
For example, it's probably
how common these words are.
And this is a very nice
visualization, which is written
in Flash and because it is
written in Flash it accepts it
input in XML format to
the Flash objects.
We want to use this
visualization inside
our Backpaki site.
So if I go here to the Backpaki
site we can add this
visualization so it
demonstrates what are the most
common places to travel in and
it is visualized in
a very nice manner.
So the question is, how can we
embed this visualization and
make it simpler for all
the users to embed this
visualization who uses our API?
So instead of us converting the
data table format, which we
have into the XML we can write
the code once and host it in
a public place so that
everyone could use it.
So I use [? rough, ?]
the visualization,
decided to do it for us.
And here is the code
that he wrote.
You can see this code in
[? codegoogle.com/feed ?]
that he uploaded there.
So now everyone can use the
visualization if using our API.
This code has two main parts.
The first part is converting
our format of a data table
into the XML variable.
So we can see here it's
a very simple code.
We go over the rows of the data
table and we simply take each
row and create an
XML tag for it.
And in the green part we simply
embed the visualization
and parse the variable
that we just created.
So using this code you can see
that this visualization is here
and all we needed to do is
change the name of the
visualization since the data
was already in our format, so
the change was very simple.
So this is an example of how we
can take from the community,
our visualization which was
open sourced and can freely be
used and we only need to add a
small part to make it
accessible to all our
users who uses our API.
So, the last part of the talk
is about server side rendering
and the client side
interactivity.
So we saw the server side the
charts API and also the
interactive charts and we want
to compare the two
APIs that we have.
So obviously the image charts
are static images and they have
no interactivity versus the
interactive charts, which can
really enhance the user
experience by adding
interactivity.
So it's a nice experience
of exploring the
data interactively.
The API for the image
chart is the only URL.
You just give a URL and get
the image which is very
simple and portable.
And the interactive charts you
have very basic JavaScript
code as you saw.
You take from the playground,
just copy, paste the code
and embed it in your page.
One of the advantages of the
server side image charts
is it is very fast.
This is very fast
because two advantages.
One, this is run on the
Google servers in C
code and it is also cached.
So if two users request the
same image, the same chart
we simply compute it once
and send the results back
from the cached version.
And in the interactive
charts the data remains
on the client side.
You don't have to send the data
and all the rendering is done
locally and you can also
manipulate the data.
You can sort and group and do
whatever you want with the
data before visualizing
it and it is very simple.
In the last year, we wanted to
combine the two efforts and to
make it even better, to enhance
the user experience with server
side rendering and client
side interactivity.
And what do I mean by that?
So the [UNINTELLIGIBLE]
visualization, which are very
computational intense and
that requires the server to
render the visualization.
However, we don't want to lose
the interactivity only because
the rendering is very
intensive computational wise.
So how we can combine the two?
We can make a JavaScript in the
client side visualization,
which makes a request to the
server only to get the layout.
To do the complex part
of the computation.
And then in the JavaScript side
you visualize the data and
add the interactivity.
So one of these examples
is the GeoMap that we
already saw before.
So the GeoMap also has a very
deep down metro-level zoom
of the United States.
So this zoom has very large
amount of polygons and these
polygons cannot be computed on
the client side and we even
prefer not to store them on the
client side if we
don't need them.
So this is an example of such a
combination of a server side
rendering and the client side
interactivity where the client
side sends a request to
the server with which
polygons it needs.
And the server returns
back the polygon that the
client side should draw.
And this way we get the
benefits of the two worlds.
We can do a heavy computation
and still get the interactivity
on the client side to
enhance the user experience.
Another example, which is
very new, is still a bit
in experimental stages is
having a photograph is.
So graph layouting problem is
a very difficult problem.
Basically the problem
indicates that we give
you some restrictions.
For example, in the network or
a social graph and we say which
two items are connected in an
edge and there is some
restriction on the edge and we
want to know how to layout
these nodes, these items in the
two-dimensional space so
it would be optimized.
Highly optimized spaces so
there would be as few edges
as possible that cut one
another or even know that
overlap one another.
So this problem is very
difficult and it was
researched for a long time.
And there are very strong
libraries that do these
computations for us.
And they're also publicly
available and they're
open sourced.
So what we did, we simply
wrapped using the charts API.
The rendering of this image.
So you basically send the
server in some specific
format the restrictions
that you have on the graph.
And you get returned
two things.
The first thing that you get
is an image of the chart
as you can see here.
Bu the second thing that you
get is the layout, so you
know each node, where it
is located and what is
the value of the node.
Let's go back to
our Backpaki site.
And if you want to see our
social graph here, so you see
the image that we just saw in
the presentation that we
take from the server.
But when I hover over a node I
can also add some interactivity
to it and show the
image of that person.
So obviously this is not
exactly me, but you can see
here pictures of people
from our office.
So we combine the server side
power in order to sort of
layout the problem of a graph
and we add the client side
interactivity to enhance
the user experience.
So this is one of the
approaches that we take in
order to make the experience
better in the future
development of the
Google Chart Tool.
So let's summarize what we saw.
We basically saw very rich
gallery of visualization both
in the image charts API and
the interactive charts.
They are free of charge.
You can use them
wherever you want.
Even in the
commercial software.
They are highly
customizable as you saw.
We can change the colors and
the size of the charts in order
to embed them whenever we want
to make the experience of the
site complete and don't
make the visualization
alien in your site.
We have both interactive
playground for the interactive
visualization and the image
chart editor for the charts
API, so you can customize and
play with the visualization
before you embed it in your
site and to optimally choose
which visualization
you want to use.
We have an active developer
group that we answer e-mails
on a daily basis, so you can
send your questions there.
And we saw how to take the data
from whatever data source that
you want in order to connect
the visualization to the
real data that you have.
The charts are very easy to
use and you can see the
documentation that we have.
In order to find the
documentation, you can simply
search for Google Charts and
see our documentation.
So you have here both the image
charts and the interactive
charts and you have side by
side comparison to know which
one of them you should choose
in order to embed in your site.
And I just want to show
one more example.
Just wanted to add that in the
tree map visualization you can
also drill down into the area.
So you can also-- nevermind.
It's not complete, but this
entire site is with mock data,
so not everything exactly
presents the real information,
but only to demonstrate the
power of the visualization.
So that's about it and if
you have questions we
would be happy to answer.
AUDIENCE: Hello, so can you
clarify the difference between
the Google Charts API and the
Google Visualizations API?
Is that just sort of rebranding
or what's the difference?
AMIT WEINSTEIN: OK, so the
charts API is basically
using our URL based charts.
So you send the URL and
get an image back.
And the visualization API is
what we discussed the
connection between the
visualization, the browser
and the remote data source.
So this is basically
the difference.
The visualization API is the
public protocol that allows
you to send a request and get
a response with the data.
AUDIENCE: OK, so my first
question is, I'm used the
visualization API and one thing
I found frustrating was dealing
with the data table object
because it's kind of like
obtuse and if you want to go
ahead and do something like
change the data at run time,
like say you have an annotated
timeline and you want to say,
display a completely different
set of annotations with the
same data that you already
have, is there an
easy way to do that?
AMIT WEINSTEIN: So the question
is, can we change the data in
the data table dynamically?
AUDIENCE: Yes, or is there
an easy way to do that?
I found that I could do
that, but I don't know.
Like the way that I ended up
doing it was just walking
through all the data points and
then changing the annotation if
I have a new one, you know?
AMIT WEINSTEIN: OK, so the data
table itself is an object that
you have inside your JavaScript
code and you can modify it
either by going cell by cell
and changing it or you can
also have something
called data view.
so you apply a view on a data
table and ask for specific
filters to happen so you set to
see only subset of the rows or
subset of the column or you can
apply some function so you want
to have a computed column that
is the result of applying a
function on each of the rows.
So I hope that answers
your question.
AUDIENCE: I don't know.
I won't waste too
much time with that.
But the question I had by the
way was at my company I can't
use the chart API because of
legal reasons about letting
data out because we would be
putting the data into the URL
that's private information.
Is there any way to do user
rendering API for like static
charts that don't use Flash,
but without posting data
to a remote source?
AMIT WEINSTEIN: So most of our
interactive visualization don't
send the data back
to the servers.
Obviously the visualizations
that use the charts API must
send the data to the server
because it renders it.
And every visualization that we
have in the documentation it
says, explicitly, what is the
data for, [UNINTELLIGIBLE]
and the information
is sent to a server.
AUDIENCE: My question
is, is there one that
doesn't use Flash?
But also doesn't post data.
AMIT WEINSTEIN: So the
interactive visualization, most
of them are written in HTML 5
technology and [? namely SVG ?]
for Internet Explorer, which
are not browsers which are
not Internet Exploreer,
and the VML for IE.
And most of the interactive
charts are of this form and
they don't send the data
and are not in Flash.
AUDIENCE: Do you know if the
annotated timelines one is
available in HTML 5 yet?
AMIT WEINSTEIN: So the
annotated timeline is currently
in Flash, but we hope that in
the next few quarters we would
be able to supply some
alternatives, which
does not use Flash.
AUDIENCE: Thank you.
AUDIENCE: It's been
awhile-- whoops, OK.
It's been awhile since I used
the charts API, but this
has kind of inspired me.
I have a complicated data
set and I'm familiar with
communicating with the
API using get requests.
That's easy enough.
But if I have a complicated
data set I'm just ultimately
going to overrun what I
can put in a get request.
Is there some sort of way that
I can kind of say, go look at
this spreadsheet or something
like that in my get request
or am I going to have to
think of way to do this?
AMIT WEINSTEIN: That's
a great question.
So currently we don't have a
way to specify in the charts
API to fetch the data
from a third location.
However, we do allow you to do
a post request and we even
wrap it for you in the
interactive chart.
There is the wrapping for some
specific charts, like that bar
chart where you have an image
emerging of the bar chart.
We automatically send it using
post id the URL is long enough.
And we have a generic image
chart visualization, which
allows you to essentially do
whatever you like with the
charts API and we wrap it
in the post request for
you if it's too long.
AUDIENCE: And so if I go
to the site I'll be able
to see all of this?
AMIT WEINSTEIN: Yeah,
search for Google Charts
and you will see.
AUDIENCE: Got you.
Thanks.
AMIT WEINSTEIN: No problem.
AUDIENCE: OK, a little bit of
the same question that was
asked a second ago, but a
little different spin.
The APIs, they're all basically
you have to have anl internet
connection to use them, is
there any plan in the future to
maybe bundle these up in a SDK?
Either the Android
SDK or the GWT SDK?
MICHAEL FINK: No.
AMIT WEINSTEIN: So currently
there is no plan to change the
policy and we currently only
allow you to use it dynamically
and load the current
version that we hold.
MICHAEL FINK: Maybe I could
add a word about that.
So I think our motivation
behind that policy is we really
want to change the charts and
augment the gallery-- as I
said earlier on-- like on a
weekly and monthly basis.
So right now we were motivated
to have like one version of the
library that we have a loader,
which is very fast and
efficient and provides it if
you do have internet access.
Once we will have to work with
many versions-- I mean, if we
go to the offline scenario and
there are many live versions
out there and there are many
bugs that were fixed, but that
are being used by
older versions.
It kind of bogs us down in our
capability to make rapid
changes and to provide
new functionality.
If however, that use case will
surface as a major use case for
many people, whether it's on
the mobile community or any
other community we'll obviously
reconsider that decision.
But currently
that's our policy.
AUDIENCE: Do you have a place
where we can see a roadmap?
AMIT WEINSTEIN: Do we
have a place where you
can see a roadmap?
AUDIENCE: Yeah, do you have
plans to publish a roadmap?
MICHAEL FINK: Obviously
internally we have a roadmap
that we're working by.
We usually are somewhat
hesitant about exposing
this externally just
to an expectations.
But what I could say as a
strategy is that we're
committed to-- as Amit
mentioned earlier on-- to
gradually migrate towards HTML
5 and make sure that a large
percentage of our gallery
is available on purely
HTML 5 visualizations.
And I think that's kind
of one major strategy.
Another one is to-- as Amit
said earlier on-- is to try to
see where server side rendering
and sophisticated layout
engines could provide clients
kind of a back end that is
shifted over to the client and
then augmented with client
side interactivity.
So we saw a highly detailed
GeoMaps that do that already.
We saw this new approach with
graphers that has the layout
calculated in the back end and
then shipped to the client side
and we will try to
do more of those.
And I think that's where our
strength as Google that has
both server side serving and
this JavaScript library could
really come into play.
AUDIENCE: And my last question
is, do you have any suggestions
for dealing with
large data sets?
Or is that just not
an option right now?
AMIT WEINSTEIN: So
the question was--
AUDIENCE: Too large to deal
with the process on the client.
AMIT WEINSTEIN: What?
AUDIENCE: Data set largely,
as I said, as in too large
to process on the client.
AMIT WEINSTEIN: So do we have
a strategy to maintain the
data sets, whcih are larger
than the client can hold?
I think that the visualization
cannot really represent
something that a client
cannot hold in site.
So if you choose the proper
visualization I think that you
could be able to refine the
data for the visualization to
really be small enough
in order to handle it
in the client side.
And I guess that my suggestion
is to make all the data
manipulation either in the
remote data source or in the
database itself in order to
really ship to the client
the small essence of the
visualization that you want to
eventually see in the browser.
AUDIENCE: I guess you've
potentially answered this
question already, are you
planning to add things like
being able to scale maps and
regions of maps based on data?
So that we can do areas that
have large populations show up
large and areas that have small
populations are smaller even if
they are geographically large,
is that something you're
thinking of doing?
MICHAEL FINK: That wasn't on
our immediate roadmap, but
you're not the first to ask for
that, so we might reconsider
and add that as you know, the
next visualization that will
come out in the next
two or three months.
AUDIENCE: And in a similar
vein, in the visual display
of quantitative information
that Edward Tufte goes a bit
further in removing pixels.
Particularly from graph
axes and just showing
the tics on data points.
That's something I've always
wanted to see, but I've never
found a graphing package
that will do it.
Would you be interested
in considering that
as an option as well?
MICHAEL FINK: So there was
actually a blog post about two
weeks ago that shows how
Tufte's recommendations could
be fully implemented
using the chart API.
Our new look and feel for the
interactive charts is very
much inspired by Tufte's
recommendations.
There are a few places where we
decided to do things
differently, but we'll try to
add more and more a
functionality that gives
options to kind of minimimalize
the chart if you really want
to see only the crisp
version of the data.
AUDIENCE: Thank you.
AMIT WEINSTEIN: I just want
to mention that we have an
issue tracker and the
active is a group.
So if you have requests it is
best to put them there so we
have some documentation and we
can remember what the user
really wants us to implement.
AUDIENCE: Are there any
plans for a GWT library?
AMIT WEINSTEIN: A what?
AUDIENCE: GWT.
MICHAEL FINK: G-W-T.
AMIT WEINSTEIN: Oh, ok.
So most of the charts are
already GWT integrated.
And we also have in the
documentation some link
saying which charts
are GWT integrated.
And we try to extend the GWT
support that we have for
new charts that we add.
And please feel free to send
us requests if you have a
visualization that you want
to use and they're
not GWT enabled.
MICHAEL FINK: Thank
you very, very much.
AMIT WEINSTEIN: Thank you.
