Już 62 429 użytkowników uczy się języków obcych z Edustation.
Możesz zarejestrować się już dziś i odebrać bonus w postaci 10 monet.
Jeżeli chcesz się dowiedzieć więcej o naszym portalu - kliknij tutaj
Jeszcze nie teraz ZAREJESTRUJ SIĘlub
Zaloguj »
ZAREJESTRUJ SIĘ
Nie masz konta?
Google I/O 2010 - Scripting Google Apps for business
Poziom:
Temat: Media
Hello, and good afternoon.
My name is Evin Levey.
I'm a Product Manager at Google
for Google Apps script and
today we're going to be talking
about scripting Google Apps for
business process automation.
And we're going to do a live
wave of this talk, same as
all the others and this
is the bit.ly link.
I should point out that that's
a three O 4D, and you can save
yourselves 20 minutes trying to
figure out why the link
doesn't work if you know
that's the capital O.
So, maybe I'd ask for
quick show of hands.
Anyone can tell me if they've
used Apps Script before?
OK, so quite a few people and
folks maybe who don't know what
Apps Script is, if you can
-- OK, only one or
two, that's good.
All right, so Google Apps
Script is really about
business process automation.
That's what we're going
to talk about today.
It customizes and extends
Google Apps, and really its a
Cloud scripting language and
so all code runs server side.
And that can be a little bit
confusing for some, because its
actually Javascript that we're
using as a language, but it
runs on Google servers, and
there's nothing happening
in your browser.
So, the agenda for today.
First off, we're going to
talk about the Book of Bob.
We're going to make
introductions.
We're going to talk about the
fundamentals of App Scripts and
we're going to talk about
events and interoperability
with non-Google services, a
custom UI generation and
stand-alone script invocation.
And, then after talking about
the Book of Bob, we have a
special guest from Motorola,
Stephanie Anthony, who's going
to tell us about their
portfolio on Google tool.
Motorola's Pogo.
So, let's get started
with introductions.
This is ACME Corp.
It's a small company,
pretty fast paced.
Everybody works
80 hours a week.
All very demanding and
high maintenance people.
And, this is Bob.
Bob's the help desk.
And Bob's responsibility
is to keep everybody
at ACME Corp happy.
And, as a result,
he's not happy.
He spends his time acting as a
gopher and a handyman, doing
all the grunt work for
everybody else at the company.
So Bob started out
with a spreadsheet.
And you can see Bob's
spreadsheet is very
well-organized, its all
color coded, and very
easy for him to decipher.
But, it does take a lot of
maintenance to keep such
a task list up to date.
That's pretty significant
overhead in keeping
on top of his tasks.
Bob started to automate his
spreadsheet by adding this
great little feature
from Google forms.
Has everybody used the
Google forms before?
OK, about half the people.
Does anybody not
know what they are?
OK, so, Google forms: When
you're in a spreadsheet, you're
able to set up a very simple
form designer and you can
publish it on your URL, so that
when anybody comes along that
to that URL, and enters text,
and hits submit, it goes
straight into your spreadsheet.
So, its a nice labor
saving device for Bob.
Instead of answering telephone
calls and transcribing emails
and putting everything into
the spreadsheet, he just
directs people to the form.
They type in their data hit
submit, and it appears
in his spreadsheet.
So it's very good and as
far as it goes, but it
doesn't go far enough.
And Apps Scripts can help.
It can help take some of
the busy work out of
his day to day chores.
So, with App Script, Bob has
been able to add a special
menu to spreadsheet,
called Bob's menu.
And from there, he is able to
send status emails, schedule
appointments, and even and even
push articles to Google's
sites knowledge base.
So, at this stage, we're
really talking about the
fundamentals of Apps Scripts.
Let's walk through a couple
of those examples, starting
with sending an email.
So, we've got some
Javascript on the screen.
And, the first little block
defines a few custom menus.
And we're saying, when the
spreadsheet opens, let's set up
two menus, one to send a status
email, and one to schedule an
appointment and then the bottom
function is the email
sending function.
Very briefly, we reach
into the spreadsheet.
We pull out whatever row has
been selected and from that, we
constructed an email to inform
the user the status of
the of their query.
So, we've got a little
demo this operation.
So, we highlight the row
that's of interest.
Bob highlights the row that's
of interest, chooses his menu,
sends the status email, and
then if we flip over to the
Gmail account of the user, you
see that they get an email from
Bob, that tells them that
their issue has been updated.
A nice little
labor-saving trick.
And now we have a
second example.
Very similar, and this one
simply figures out the next
free slot for Bob to meet with
the person having a problem and
books the event on both
people's calendars.
And, so poor Wayne has a
problem with his hard disk.
Bob needs to stop by
and take a look.
And our little script runs.
The status gets updated, and
you'll see that if we refresh
the calendar, both Bob and
Wayne now have an event
scheduled at a time that's
convenient to both of them.
This type of thing saves Bob a
few keystrokes, a few clicks, a
few minutes every time he
updates the status
of the ticket.
He can send an email very
quickly and every time he needs
to meet with somebody, he does
not have to open up the
calendar, and hunt around
for an appropriate time.
He's saving a few minutes
every time he does this.
Maybe adding up to 30 minutes a
day, several hours a month for
an upfront investment of an a
couple hours of Javascript.
So its a pretty good deal.
Bob gets a lot more productive.
Well, really there is
a lot more we can do.
Instead of Bob having to
actively choose to do these
things, maybe we can automate
it all a little bit more.
This is why we're going
to talk about events.
Events system allows you to run
a script in response to an
event that happens or a
trigger, and function that we
run is known as an event
handler, So, here,
we've got an on edit.
Every time Bob edits the
spreadsheet, we're going to do
some trickery with the colors
and update the status
of the issues.
So, its a very simple demo.
A lot better when you
see it in action.
As Bob changes his status row,
you'll see that the color
coding on his spreadsheet
changes automatically.
This makes it easy to keep his
spreadheet legible, and up to
date without continually
having to reformat.
So event handlers.
App Script has two different
types of event handlers.
The first type is a simple
event handler that is
automatically run in response
to actions happening
on the spreadsheet.
The name of the function
associates it with an event.
So, on open is run when the
spreadsheet is opened.
On edit is run when
the spreadsheet is
edited, and so forth.
These simple event handlers
run in a very tight
security sandbox.
They're not allowed to
do anything too crazy.
They can access
the spreadsheet.
They can color code things, but
they're able to create menus,
for example, but they're
not allowed to look at
anybody's private data.
The second type of
event handler is new.
We're introducing it today.
And it's an installable
event handler.
This type of handler must be
explicitly installed and
it's a lot more functional.
So it can do things like send
emails and access calendars.
So, these installable
event handlers.
There's a small, but growing
selection of events
that we can capture.
Similar to the simple ones,
there's on edit and and on
open, but we've also added
on form submit, so when
someone submits, -- I
see cheers in the back.
This is the number-one feature
requests on our form, so we're
really happy to push it out.
It went out about two hours
ago-- so when somebody submits
the form it goes into the
spreadsheet and then we can do
some processing with our script
and send out an email, for
example, or do something
with the information.
And we also have clock events,
so you can schedule a script to
run an hourly, daily,
weekly or what not.
So let's have a look
at how we do this.
From our script editor,
we select triggers.
There's nothing set up yet, and
so, in this case, we are going
to run form submit reply
function in response to an
event from the spreadsheet, and
that's the on form
submit event.
So we save it.
We go back into our spreadsheet
form, we type in as a user
would, some kind of
complaint about a broken
[? mass wheel ?].
And, when this gets submitted,
this script runs in the
background, and immediately,
we can switch back to email.
And you see that
the script update.
It's actually counted how many
issues are ahead of this
particular person, and it's
able to say there are 15 active
tickets ahead of you, so you
will be waiting a while.
This means that Bob can
be very productive
even when he's in bed.
It's 11:00 a.m.
Bob hasn't gotten up yet but,
everybody at ACME Corp is
getting these emails telling
them where they are in
the queue and they're
all very impressed.
Bob's system is getting
pretty awesome.
We've got forms coming
in, emails going out
automatically and a bunch
of shortcuts in the menu.
Bob gets a promotion.
He's still in bed, by the way,
so he doesn't know he's got the
promotion, but when he gets to
work, he'll hear all about it.
That's great.
It takes us a little
bit further.
Bob has cut out a lot of busy
work, but ACME Corp is growing
and they're getting very big.
They've brought in
a lot of rules.
There's all kinds of spending
limits and managerial
approval required.
Now days, Bob is spending half
his time on Amazon purchasing
new keyboards and mice
and chairs and monitors.
The other half his time is
trying to track down manager's
approval for such items.
So he really needs something a
little bit more integrated into
his existing systems that
aren't part of Google.
So, we're going to talk a
little about that
interoperability with non
native services or
non-Google services.
I know this is pretty
intimidating.
There is a lot of
code up there.
The first one is Soap and XML.
Soap and XML are the
protocols of web services.
So, in order to talk to
anything outside of Google,
we're able to the leverage
these and make calls
too nice services like
Amazon, for example.
So, I'll run through
this code very briefly.
The first few lines connect to
Amazon, and then we get a
little security header that
Amazon has, that has a special
key that Amazon will give out
to anybody, free of charge.
And then the big block in the
middle really just says that
we're going to request a key
word search across
all of Amazon.
And, then we grab the results.
At the very end, we'll see that
we collect the name and price
and maybe some other details.
So not really all that much
code, and we get something
pretty nice like this.
Custom spreadsheet function
that can find on Amazon.
And it really does
run that fast.
It's pretty sweet.
We're also introducing
JDBC today.
This was released, again,
just a few hours ago.
And this means that as well as
talking to Amazon, Bob can
automatically add things to
his cart, and purchase them.
He can also talk to his
own back end data stores.
And he can find out, for
example, in the query who
someone's manager is.
So, he can then ask that
person for spending approval.
We don't have a flashy
demo of JDBC today.
We do have some great demos on
our web site where we integrate
with Amazon web services.
They have a very nice my sequel
database in the Cloud, called
I'd urge everybody to play
with Apps Script integrating
with my sequel on Amazon.
It works very well.
Bob's system has gotten
pretty awesome.
We have the forms coming in,
the shortcuts going out.
All the short cuts in the menu
integration with Amazon.
Both as a backend database
provider, and as a shopping
cart order system.
So, it's working very well.
Bob thinks this is wonderful,
but really there's
something missing.
We've got all this great power
and our users are still using
this pretty primitive
and static interface.
Bob has to figure out what
their text means and go off and
use his shortcuts to do all
this extra look up work.
So today we're also going
to talk about customize
user interface, user
experience for scripts.
This is new and again released
just a few hours ago.
We're now able to build
graphical user interfaces
inside scripts.
So, Bob's menu has a
new item, Show UI.
And, we've got the
little ACME Corp.
Help desk form.
We've got the JDBC query
running in to find out who's
loaded the form, who their
manager is, their location,
the phone numbers,
the spending limits.
And, they're able to now submit
their problems with their
mice, in the same way as they
could on the static form.
So, a couple hundred lines of
Javascript later, and we've
replicated the wonderful
Google spreadsheet forms.
We're not really leveraging
the power of a dynamic UI.
We are able to tell the user
that they need spending
approval, and we are able
to put things into
the spreadsheet.
But we really need to extend
the capabilities and do
something more interesting.
So let's try something else.
Let's give it a second option.
Instead of reporting a problem,
let's try ordering stuff.
We know that John needs a
mouse, so we do our query, and
we'll see that we pull back our
results from Amazon including a
picture and we decide we want
a nice Apple Magic mouse.
We submit the request, and now
because we've got this JDBC
backend , we know that John
doesn't have the spending power
to buy a mouse for $69.99.
It's going to need to get
approval from his manager.
So this is great as
far as it goes.
But I think the eagle-eyed
among you will have noticed
that we're still running
inside a spreadsheet.
And Bob doesn't want people
coming into his spreadsheet
to raise these forms.
They'll just mess with
his nice color coding
and his formatting.
So, again, today we're
releasing another new feature.
Stand alone script invocation.
Inside our script editor, we're
able to publish the service
and add to our domain.
Now this is a Google Apps
Premier feature only today.
And what we'll allow you to do
is run it yourself, share the
service with yourself or share
the service with people
on your domain.
It's not available to
regular Gmail users today.
So, now if
we put all these
pieces together.
Let's have a look at Bob's
system running from
start to finish.
First, we publish the URL.
Bob distributes this on the
help desk page, or makes sure
that it's in everybody's
browsers bookmarks.
Then John comes back to
the help desk, via the
bookmark in this browser.
He knows immediately that he's
ordering something new, a
keyboard, runs the query great.
I'll take a Logitech keyboard,
but looking on the list, John
also decides that he'd like a
nice Cascio keyboard, and he
decides to chance his arm,
and see if it'll get
through approval.
We pop up a little message
saying he's had approval.
We go to the manager's email,
and the manager gets a nicely
formatted message, saying, hey
John wants to buy a
couple keyboards.
Manager does a bit of a double
take, isn't quite sure what
to make of this, says, no.
We won't be having that.
Gets that nice little message
reinforcing the good
approval behavior.
Bob comes back to the
spreadsheet later on, hasn't
been involved in the process up
to this point and the
spreadsheet tells him that John
requested two keyboards, the
manager approved one rejected
the other, and the script has
gone off and already placed
the order with Amazon.
So this is the basics of a work
flow spending approval system.
I hope we've outlined
reasonably well how you can put
these pieces together for
business process automation.
Now, Bob's little story is very
nice, but we've also got
Stephanie Anthony from Motorola
who's been using Apps Script
for the last six months and
she's going to tell you about
their progress and how their
processes have being automated
in a more real world setting.
STEPHANIE ANTHONY: I
am Stephanie Anthony
from Motorola.
We deployed Gmail last year for
mobile devices, and right after
that, we started looking at the
power of Google Apps to
replace some IT Tools.
Everybody knows docs and sites
are great for collaborating
and getting internet
sites up and running.
But, we saw a lot of power
with Apps Script to actually
replaced expensive tools.
So the first area of
opportunity we looked at
was our IT project and
portfolio management tool.
When we looked further, we
found that our costs, annually,
were approaching $1 million,
so we decided to see what we
could do with Apps Script.
And based on the results,
we're now looking to
replace other tools.
We called the tool, Pogo,
or Portfolo on Google.
From a functional point of
view, it's got proposal
data, which is like
you're pre-project data.
This is standard
proftolio management.
It's the stuff to
authorize before you
create a project.
We've got budget forecasts.
And staffing forecast.
Project data.
To get from a proposal to
project, you, of course, have
to go through portfolio
governance, the
standards stuff.
There's approvals.
The portfolio manager creates a
project, the project has
different fields, carries over
some data, but of, course,
there's different.
Budget forecast and
actuals for the project.
We've got staffing forecasts.
Then we have named resource
assignment, in management.
Which means, that we know what
people, by name are working on
which projects or proposals
during which months, so we
can see our resources.
And in terms of reporting, we
focused on, up at the top, the
project dashboards for
help and key data.
We've got our target spend
versus approved and
unapproved spent.
For resource management, its
the standard stuff and all the
tools, what resources are
requested by month, allocated
by month, compare that
against our capacity.
We've got research
allocation percentages.
All the research managers
just love to see.
And then in terms of individual
project reporting, we've got
milestone completions,
requirements volatility
and post release defects.
Then we roll up projects stuff
to the organization level,
because we have to report
these matrix in our
organizatin level.
We also have the work breakdown
structure instead of
Google Apps in the docs.
And it was definately possible,
we had it there last year.
But the users just wanted to
use their own desk top tools,
so we gave in on that for now.
Also we had issues risks,
decisions and action
items inside this tool.
And we piloted it with one of
our major programs at Motorola.
What we found though, once we
started showing them Googles
Apps, they're like, what we
need is team calendar, and we
need these collaboration
documents and, oh, shouldn't
we have our own Google site.
So, for that program, we ended
up making its own Google site
with shared calendars, and all
the different documents, and
then we had issue, risk, action
and decision trackers we put in
there and we put standard
scripts in there.
Scripts to email you
for overdue issues,
overdue action items.
We've got things that inside
the spreadsheet checks for
invalid data, and ID's,
just different functions.
And so we made a standard set
of spreadsheet and site and
we're giving that
to the program.
So we're saying, here's your
standard set, go ahead
and customize it.
As you know, every
program is different.
They need some different field.
We really couldn't say,
everybody these are your
issue fields, because
everybody's different.
So we're deploying this
in August of this year.
Right now, its a
prototype mode.
It's called Pogo, or
Portfolio on Google.
There's the little android
guy jumping on a pogo stick.
This is a flash
gadget that we have.
And then over here, our
proposal date is also
done through gadgets.
I'm sure everybody here has
made a spreadsheet form;
takes five minutes,
its not a big deal.
But the reason that we needed
to put the form in a gadget
until his user interface came
out is that we wanted the users
to be able to edit in the form,
as well as do data entry.
Because right now, if you
use spread sheet forms,
you know it's all nice.
You've got all these different
field values, all these
different drop downs and then,
when they go to edit it there
in a spread sheet, they type
whatever in there and
you've got a mess.
Also, we wanted to hide things
like the proposal ID, which
carries with the proposal
through life cycle, and
different formulas.
So, we needed to use gadget.
So this gadget and this
a proposal that exists.
I found it by number,
already in our exist tool.
Everything has numbers, so
follows the proposal through
the life cycle, and I can
change a value in
the drop downs.
This goes to a temporary
spreadsheet, then there's a
trigger that runs, it moves it
from the temporary spreadsheet
to the master if the data
is qualified to move.
So we recently got triggers,
about two weeks ago,
and they're great.
Because, up until this point,
we actually had a button that
users had to push to kick off
Apps Script, which is
completely annoying.
Now, they can stay in the form.
We've got these triggers
running, with these temp
tables, and we're able to
control the data that
goes to the master.
So, from a process point of
view they did a proposal entry.
There's also portfolio data
which is locked down for just
the portfolio managers.
The portfolio managers go
through their portfolio
governance boards.
It becomes a project.
At the same time, we also
have budget and staffing
forecasts over here.
The project form's
similar this.
Different data.
Some of it carries over.
But what people always want
to know is how we're doing
named resource management.
So, we could have people
enter their research
requests in a form.
But we have large projects in
Motorola, and so you can't
ask someone in enter a
form entry 50 times.
They just aren't
going to do it.
So we have a spreadsheet.
It is a spreadsheet, but
the users are actually
happy about this.
They enter very little data.
They enter, like the user's
name that they want,
the project number.
And, then the spreadsheet Apps
script goes and pulls all the
other data from the master.
Because we've got user masters
and project masters and it
pulls all the data back.
It validates all the
information they put in.
Like you can't request a person
to work more than full-time on
a project, that kind
of validation.
Then, once its been validated,
they push another button and it
sends it to the resource
request master.
Then, once a day, the resource
manager get an email like this.
So, with resource management,
anybody who has a resource
management tool, the resource
managers, its not just one
person, there's usually
there's a backup.
So, my boss forwarded me this.
So him and his back
up got this email.
It's requesting resources
to work on a project,
straight to their Gmail.
Here's my name, here's the
project number, here's the
project name, here's a little
note about why they want me to
work on this, then how much
time they want from me.
FTE, if you aren't familiar
with resource management is
full-time equivalent, so
one is one man month.
So, basically in June, they
want me to work 75% on
this project, July 50%,
August, 50, and so on.
My manager can click, and see
all commitments for resource,
and that will show him
everything else that I'm
already committed to.
Its a list view
that's pre-filtered.
Down below, you can see there's
another person also that he can
approve down here for
different projects.
So, what happens is all the
outstanding resources requests
that haven't been approved or
rejected show up in the email.
So, let's say he ignores this
today, tomorrow these will be
back in with any
additional ones.
So, we think this will actually
help us, because besides the
expensive tool we have now,
we've actually had other
expensive project
management tools.
And our main problem is
the data integrity.
We can have the fanciest tool
in the world, but if people
won't update the data
that's a big problem.
With resource management
you've got all these people.
They don't want to
log into a tool.
They don't care.
So we're thinking with the
email, they're going to get
their data in, and it will
be a lot easier for them.
And we're actually thinking
that they won't even realize
that they're in Pogo or using
Google Apps, because to
approve, all you do is click
this button here, and
it's pre- filled out.
There's the project,
there's the person.
So if I press submit here, what
happens is it goes to temporary
spreadsheet, then there's a
wonderful trigger that goes and
runs Apps Script, and if it the
data goes into the master,
it will approve it.
In this case, I'm not
authorized to approve myself
to work on this project.
So while this is going to
submit, I am not actually going
to be assigned to the project.
It's going to take my manager
or his backup to push the
button before it will
actually be approved.
So there's some security there.
So what's the point of all
this resource request?
Its that you want to
get resource data
for decision making.
So resource pulls like a group.
It's like a team.
This is also a gadget,
also running on a timer.
Right now, all of our timed
triggers are running for every
minute, because we haven't
really done load testing.
We're planning to do load
testing over the next
month, and we're planning
to deploy in August.
So everything's
running on a minute.
Obviously, you don't need to
update charts every minute.
So this will probably be moved
to more of a five-minute thing.
We have triggers
that update charts.
We have triggers
that send emails.
We have triggers that are
moving the data from
one table to another.
And, what's really funny, our
very expensive tools we have
today actually have a bunch of
schedule jobs that runs scripts
to update the resource
and the budget data.
So, it's very similar.
So what this chart means, is in
February, you can see about 3
1/2 FTE or people, full-time
equivilant working on proects.
Then it spikes up in April
and May gets to about 4
1/2 and then it dies off.
So, let's say my capacity is
four people in this group.
I can see that I've actually
over allocated my team in April
and May, but we had a lot of
capacity coming up towards
the end of summer.
So it can help me with my
decision making in terms
of what am I going to
do with my resources.
What can I commit them to?
Then, at least at Motorola,
everybody has to have
everything in Excel for
their pivot tables and
all their analysis.
So on all of our charts,
we have an option here
to export the data.
CSV opens it up in Excel.
They can do whatever
they want with it.
This is actually also
another advantage over
our current tool.
Because we have such a fancy
tool right now, we export the
data from our fancy tool
to a data mart inside of
Motorola, twice per day.
We've got people watching
those extracts.
We've got people
watching those loads.
We've got support people all
along that whole chain trying
to get that data into our
data into our data mart.
Plus, when you are trying to
make a decision, you could be
making a decision on data
that's 11, 12 hours old.
And that's just a fact because
of what we have today.
But with Google, all
this data's real time.
They can get all the data
whatever they want, so they
can make real time decisions.
We'll let everybody
see all the data.
As far as updating the data, we
do have the lock down, like
with the portfolio managers
and research approval.
But everybody can see
it so, its open.
In terms of project data, they
need to see their project
dashboards, and see what's
going with the different
projects, so this is really
easy with the spreadsheet
functions in Apps Script, whole
different data together for
different dashboards that
managers want to see.
Down here, we used to
have automated help.
Automated help is actually
an easy thing to turn on.
You had different matrix.
Based on the threshold of the
matrix, you can make the
you can make the colors
red, green, or yellow.
So, you can decide if a project
has gone red, green or yellow.
So we had that on, but then the
project manager said, no they
wanted to set the colors
themselves, so we're back to
letting them set the colors
of red, green or yellow.
We do have automated matrix
though, so we didn't
turn those off.
We have the triggers that
go out and we're already
capturing this data.
We've got budget,
actuals versus plan.
See this project's
93% on budget.
Resources committed
versus plan.
Milestone completion.
Requirements volatility.
post-release defects.
All the information that the
project managers want to see.
And then they can report
up to their management.
So we went into this just
to see what could be done.
This is not anybody's
full time job.
We've been working on this
since August, like a
couple hours a week.
August, because that's
Apps Script came out.
Then what's really exciting
about Apps Script is things
just keep getting better and
better, like the triggers that
just came out two weeks ago.
It's really been exciting
to see all that change.
We've been working with the
team, prototyping this,
demoing it at Motorola.
Different people are on it.
And what's cool, is that now
people are actually asking
for this not because it's
cheaper, but because it's
better in some ways.
Especially the integration with
email, the real time data.
So there's actually
demand for it not just
because it's cheaper.
So thanks to the Apps Script,
we're able to deploy a light
weight application without
all the overhead of
a packaged tool.
[APPLAUSE]
EVIN LEVEY: Thank you
very much Stephanie.
So you can see that we have Bob
and his little use case and
building up the help desk
system around a spreadsheet
from scratch incremental
evolutionary, and then we have
Stephanie at Motorola who's
replacing at one million
dollar-a-year system with
Apps Script and Google Apps.
So, it's a pretty
compelling story, I think.
So, let's maybe do a summary
of what we've covered today.
Apps Script talks to Google
products and its done that
for a long time, and that's
what it's all about.
It's the glue that lets our
products talk to one another.
Apps Script talks to Soap,
Rest, the language of the web,
and now it talks to JDBC, my
sequel today, and Oracle and
MSSQL are coming very shortly.
And Apps
Script talks to users.
We have a fully capable
UI stack now exposed
again just today.
Motorola is saving over a
million dollars per year
by using this stack.
So, we announced a lot
of new capabilities in
Apps Script today and some blog
posts on Monday, and we've got
the new installable
event handlers.
They allow you to run scripts
based on events that happen
inside spreadsheets or based on
clock events, particular times
of the day, particular days
of the week and what not.
We've got new JDBC
interoperability.
We can talk to my sequel
where ever it may be.
Amazon already acts
in the Cloud or your
own hosted solution.
And, we've got the new
Apps script UI, and
stand alone invocation.
Stand alone invocation, while
it may seem like a footnote, it
is really the thing that allows
us to bust out of the
spreadsheet jail, and so it's
taking App Script from being an
embedded language to being
something that's much more
stand alone and fully
capable for users.
And there's a little bit more
that we haven't covered today,
and a few more announcements.
We have a new documents
lists capability.
We can read files from your
Google Docs list and you can
create and modify files too,
but that's a Googles Apps only
feature, so consumer users
on Gmail won't get
that one just yet.
We've got a new maps API.
This is kind of cute and maybe
not immediately relevant to the
enterprise, but you can create
maps, get directions, do some
limited geocoding
and elevation.
And in two weeks -- we don't
usually pre-announce -- but in
two weeks, we'll have Google
documents extensions so you'll
be able to script our
new document editor
using Apps Script.
Not the existing one, but the
new one that we announced
back on April 12.
I think most of you
will be able to access
that in preview mode.
We also have a few more
pre-announcements just to give
you a sense where Apps Script
is going over the next
three to six months.
In Q3, we're going to launch
Apps Script in sites.
Today, as we've mentioned
several times, Apps Script
really lives inside
spreadsheets and we're excited
to be able to publish
scripts as services.
Going forward, Apps Scripts
will also live inside Google
sites and inside the
new document editor.
We've even got a screen shot
of Apps Script inside sites.
You'll be able manage your
scripts in there, throughout
the script editor and also
catch events from Google sites
like the same way you can
from spreadsheets today.
So I'd urge you all
to try Apps Script.
And we have Google short
link for Apps Script.
And our regular URL is
long and unwieldy, so
definitely give it a go.
I urge you to try it.
And, we're very responsive to
feedback, so if you've got any
comments or questions, please
do hit our user support form.
We're looking forward
to hearing from you.
OK, so maybe we'll stop there
in, and go for questions.
AUDIENCE: This is
[UNINTELLIGIBLE]
I'm with with MWP.
I'm a user of Google
Apps Premier Edition.
And, in your slides, it talked
about publishing something to a
knowledge base, and you didn't
show that in your demo.
Could you talk about that?
EVIN LEVEY: didn't understand
the question part.
AUDIENCE: In your slides, you
showed that there was an option
on the menu to publish from the
help desk to a knowledge base.
I don't think you
showed that part.
You showed pushing an email
you showed the other things,
but you didn't show that.
EVIN LEVEY: That's right.
We will publish that
as a code example.
We skipped over it, it
was an example, but
it's very easy to do.
Apps Script can talk natively
to Google sites and so there's
very nice API where you can
create a page and
push data in it.
And so we will release all the
code for the demonstration
today and I'll make sure that
we include the site's example.
It just seemed to be a little
repetitive once you've
seen the others.
AUDIENCE: We work with the
spreadsheet data API.
We just recently started
integrating with that.
We wanted to have certain
things automated based
on data we push in.
Will Apps Scripts run on
editor whatever from the API?
EVIN LEVEY: a very
good question.
I would imagine not.
It probably does not.
I think you have to be a live
user, using the spreadsheet
or an on form submit event
accessing through the data API.
I think is a non
user operation.
AUDIENCE: OK, I know the
Apps market place was
just recently released.
The Apps domains can have
installed Apps and we would
like to be able to inter
operate like that.
EVIN LEVEY: Yeah, absolutely.
I think Apps Script is
certainly that one of the
pieces that you can building
into your manifest for
the Apps marketplace.
And so, I think that you
will be able have that
functionality in the future.
AUDIENCE: Yes, will you be
bringing some of the app engine
features and capabilities
closer to Apps Script?
Will they work together
in the future?
So, for example, in business
app they talked about sequel
data base as a part
of app engine.
Maybe its service indication.
Is there any thoughts on making
App Script work in a more
unified manner with app engine?
EVIN LEVEY: Yes, you can
absolutely call app engine from
app script today and there's
full interoperability today.
We didn't cover that
in the talk today.
It's something we've
had for over a year.
And, in terms of database
services, certainly we're
always looking for more
database providers.
We understand its a very
important component for you.
And so JDBC is obviously our
first step in that direction.
AUDIENCE: Do you know has
anyone been using this
to create scrum tools?
EVIN LEVEY: Yes Absolutely.
I think that at Google,
we're well-known for
eating our own dog food.
Our engineering director in New
York City, where the Apps
Script team is based, and a lot
of the Apps products
are developed.
It actually has a full tracking
system built in Apps Script.
And it's caught on pretty well.
All of our teams
at Google use it.
AUDIENCE: Are those available?
EVIN LEVEY: I'll ask him.
I think it would be a
great example to post
on our templates page.
AUDIENCE: Thanks very much.
Are there any limitations for
any of the examples you have
been showing to provide
notifications or work flow
outside of the domain?
So, conceivably as the Google
Apps reseller or the individual
that's acting as help desk for
numerous domains, that these
types of applications could be
deployed for that purpose?
EVIN LEVEY: That's a
really good question.
I know that there's a lot of
complex areas that arise in the
world business situations.
We've been working with
partners to address those.
I think that in most cases,
everything just worked
the way we showed it
working here today.
There are few interesting
security implications for some
of the things that we've shown.
The primary one is stand
alone script invocation.
So, where publish your script
as a service, and you can
distribute the URL and people
hit the URL and your
script gets run.
We've been very cautious with
that one to date and that's why
we're only allowing it to run
for that logged in user, or for
users on that Apps domain.
So, I think that would not work
in your scenario, but we're
figuring the right way to roll
it out across the domain and
potentially consumer
users in the future.
AUDIENCE: Hi, great stuff.
For the JDBC services, I'm
assuming that it's only going
to work for a Cloud based
like Amazon web services
or a hosted solution.
What about operability with the
secured data connector to pull
from an internal resource.
EVIN LEVEY: Absolutely.
That's a great question.
We do have support for JDBC
inside the secured data
connector now, and its
not quite ready for
public consumption.
But we expect to get it
at the door within the
next that few weeks.
Let's put it that way.
I don't have a firm date, and
the SDC team did ask us to
announce that, and make it
clear to everybody that if
you're using SDC today, you
will automatically be able to
have your JDBC tunnel through
the secure data connector into
your organization and hit your
own internet databases hosted
there.
Great question.
Thank you.
AUDIENCE: Is there support
for electronic signatures
in workflow processes?
EVIN LEVEY: Sorry, I
didn't catch that.
Could you repeat?
AUDIENCE: Support for
electronical signatures?
EVIN LEVEY: Electronic
signatures.
Not any specific
support at this time.
It is a question that we
get every once in a while.
And I think that there's a big
push, especially with some of
the great products in
the Apps marketplace.
I think that that's something
we'll addressed pretty soon.
I think we have some
live wave questions.
When you say business process
automation, I think you're
talking about a modeler
and an engine that will
execute the process.
Is this something that
you already have besides
Blueprint that uses GRIT?
If not, please take a look
at www.processmaker.com.
That's a great question.
I'm sure there is a question
in there somewhere other
than just an advert.
Let's put it this way, there
are a lot of rules engines
out there, and they
do a phenomenal job.
That's not exact strength
that we're aiming for.
It's not really our nitch.
If it's something that
everybody feels is really
lacking from Apps Script, I
think that we can certainly
move in that direction.
But we're really talking about
glue here that talks to other
best of breed products, and so
I think, that maybe
processmaker is a great
solution that would work well
and would integrate
well with Apps Script.
When will we be able to use
submitting a form as a trigger
for script, preferably
with our script making
a custom results page?
The first part, you
can do it now.
It went live a few hours ago.
The second part, the script
making a custom results page,
is not possible today.
The reason for that is you're
dealing with the spreadsheet
form, and the spreadsheet
form, just returned
it's standard response.
Whereas even with our GUI
capabilities you're not hitting
our service, your hitting
the form service.
That's definitely one of
the next steps we'll take.
The second part is just
not possible today.
Where do I find more
info on custom user
interfaces for scripts?
We do have a user guide that
that's just been pushed
in the last few hours.
It goes into a lot of detail
about how to get up to speed on
writing service like Javascript
with Google Apps Script and
there, there's the kernal of a
tutorial on using the
new UI functionality.
I urge everybody
to start there.
It's very GRIT like.
In fact this incarnation
is based on GRIT.
So if you're familiar
with that, it should
be no problem to you.
AUDIENCE: Could you think of or
describe an architecture a bit
like the Motorola one where
they use forms to not only
insert records in the system
but to update records.
And, the business problem is
that you only want to let
certain users, perhaps the
author of that record to
be able to edit them.
EVIN LEVEY: So with spreadsheet
forms today, there's no
ability to go back and
change a response.
And, I know its a highly
requested feature.
With Apps Script, on the
other hand, now that we've
got a fully capable UI.
You saw that we were able to
pre-populate some of the fields
with the results from the
JDBC query, or sequel query.
You can absolutely build that
today with Apps Script.
In fact, one of the demos on
our templates page populates
the form from the spreadsheet,
lets the user edit, and
submit back and the
rows change and update.
And, obviously we're
very content to have
a spreadsheet be our
data store, because it's such
a nice and fast interface to
Google spreadsheets, but
naturally you could pull that
data from any source at all,
including my sequel data base.
Are there any plans to provide
ODBC connective for sites slash
docs, scripts that will allow
direct connection to internal,
behind the fire wall
databases using SDC?
I think we've probably
covered that one already.
There's a few pieces that have
to fall into place and we will
release JDBC through SDC
in the next few weeks.
And Q3, we'll have sites and
docs be embedded containers for
Apps Script, and so while
you're able to do most of these
things today I think to get the
complete solution to the
question, of it may be a
couple of months ahead.
AUDIENCE: Yes, hi.
I was curious to find out
whether or not, you have in
your road map anything that
would allow people in the
marketplace, application
developers, to package scripts
that would then become
ubiquitous in the target
customers environment since
there's lots of benefits to
them that if you're an
application developer.
EVIN LEVEY: I think the
short answer is no.
We don't have that today.
What we have inside
Google spreadsheets
is a script gallery.
I don't know that many of you
will have seen it, but you can
hit insert scripts, and gives
you a little pop up like the
gadget gallery and you can
install that user generated
content and that's actually
backed by the Google
Apps marketplace.
And obviously there's no fee
for any of the scripts.
This source code is
freely available.
That really helps with
transparency, and auditing what
the code is actually doing.
And that's definitely a
consumer focused piece of
the picture inside of
Google Apps domain.
What we intend to offer is a
domain specific gallery along
the lines of the existing
domain specific template
gallery and gadgets gallery.
I think as we move in that
direction of the next few
months, you'll begin to see
more capabilities to install
scripts for a domain then do
some kind of deployment
management.
For example, every spreadsheet
at Motorola, perhaps would have
a specific script that runs and
audits its use of the product,
or something like that.
AUDIENCE: For this use, it
would be great if you could
install as part of a
marketplace application
installation process.
Thank you.
EVIN LEVEY: I'm not sure if
there are more questions in our
wave, no more live questions.
Oh, one more.
AUDIENCE: Actually, it's
not a question actually.
Just thanks for the
presentation, because we've
been hearing about this for a
while, but, to just kind of
look at a live system
that actually works.
Some use cases that you can
really use for business, I
guess for a business
user a little dumb.
But just to see something that
come together is really helpful
with forms, and a menu going to
the left inside, and how you
can use these things to do
that, so that was great.
Thanks so much.
AUDIENCE: I've
got a question, maybe
for Stephanie.
How do you deal with the
governance of your code?
You've got spreadsheets.
You've got sites.
They have to be long lived
across the owners of those
spreadsheets and the
owners of those sites
leaving the company.
Perhaps their accounts
being deleted.
How have you managed that
internally so that that you
don't delete an important
business spreadsheet that's
used by many people?
STEPHANIE ANTHONY: Part of the
reason we want people in forms
is because we don't people
getting to the scripts.
So, we can keep the actual
users out of the scripts.
But we are backing up all of
our code, and Motorola is big
on code control, and all of our
code being locked down, so we
are keeping copies
and saving it all.
AUDIENCE: But, what if
the person that created
the script leaves?
Then that document
will be deleted?
STEPHANIE ANTHONY: Oh, well,
for instance, in a different
thing that we did, I made a
site for a very top secret type
of thing, so I can't see the
data, I'm not allowed to see
the data, so I made it, and I
made someone else the owner, so
I transferred ownership to him.
And we've got other things
where we actually share
ownership, so we try never
to have one person
owning something.
We try have multiple people
owning it, but I really like
that you can create something
and then transfer the ownership
away and then you're
totally locked out of it.
That really helps for us.
EVIN LEVEY: And I think that's
a great question in terms of
ownership and it comes up
regularly for all of Google
Apps, and I think that what we
envision inside Apps Scripts
team in participlar is the
notion of a [? roller cant. ?]
and so there wouldn't be a
particular employee that owns
the document or the script.
Obviously, we intend to bust
out of spreadsheets, so scripts
will be stand alone, but the
same problem will apply, that
if the [? roller cant ?]
gets deleted, the data
gets deleted too.
But obviously,
[? roller cants ?]
hopefully won't be leaving
the company to move on to to
bigger and better things.
AUDIENCE: This might kind
of weird question, but
I'm a Systems Integrator.
We used to laugh at people that
have legacy applications like
this built on Lotus Notes and
they want to migrate
into something new.
Help me understand how to
convince people, that they
aren't locking into another
scripting language and silo?
EVAN LEVI: This is actually
something ?] that
keeps me up at night.
And Google is all about
basically keeping ourselves
honest, so that users have the
ability to take their data
away and go somewhere
else at any time.
When we're not locking you in,
it forces us to stay ahead
and keep innovating
and keep moving.
And code, written on a
system like this, it's
that big investment.
You sink a lot of cost, a lot
of time into rebuilding your
systems on Google Apps Script.
Hopefully not that much money
and not that much time.
That's our goal.
But it's still an investment.
And at that stage you have some
costs, so what do you do?
I have no solution.
I have answer for you and I
recognize that its a problem.
If you have solutions for that
can make us more open and
transparent, I'd really
love to hear them.
OK, I think we'll leave it.
I'd like to thank everybody
for all the great questions.
And, please try Apps Script.
[APPLAUSE]
