Tip:
Highlight text to annotate it
X
>>Seth Ladd: Okay. Welcome, everybody. Thank you. We're going to go ahead and get started.
Really appreciate you coming and spending your time with us today.
This panel is Chrome Web Store Publisher Forum. My name is Seth Ladd. I'm a developer advocate
here with Google. I work with the Chrome team, which means we focus on Chrome, HTML5, and
the Open Web Platform. We work with partners of all different sizes and help them get up
productively on these APIs and products. A couple of housekeeping notes.
This session is being streamed live, so for everyone here and everyone at home, we have
a Google Moderator link up here. Please do enter your questions here. Vote them up and
down, and at the end of the sessions we'll do an open Q&A, so please come up to the mics
and/or we'll use the moderator here as well. Please do find me and any of us -- my Twitter
handle is @SethLadd -- here at the show, after this session, or just online. Love to chat
with everyone, what they're doing with HTML5 and Chrome and Web Store and apps. So definitely
love to hear about what you're up to. So this is the Web Store panel, and I want
to give a quick just recap of what's been happening lately.
We actually announced the Web Store one year ago at Google I/O, worked really *** it,
released it in December of last year, and today it's integrated with every U.S. version
of Chrome right there on the New Tab page. So Chrome users are now getting access to
the Web Store. Chrome is a platform in and of itself, with
120 million active users. It's really cool to think about Chrome as a platform, not as
a browser, so we have CHROME ENTERPRISE, Chrome browser, Chrome OS netbooks, Chrome Frame,
lots of different ways to get Chrome into the hands of your users.
So whenever a new platform arises, the question now is: Well, the user expectation is really
changing and they're saying where are the apps. They're no longer concerned about WiFi
or anything like that. They want to know where the apps are.
So the Chrome Web Store gets your apps into the hands of the Chrome platform users.
This is -- might sound like a really obvious point, but I think it's subtle and bears repeating
that the Chrome Web Store users use Chrome and if we think about this, that means that
the users of your apps can get the full power and benefit of HTML5, fast release cycles,
and the Chrome browser. So this is, in a sense, your safety net to
develop and deliver great HTML5 apps and not necessarily have to worry about legacy browsers.
So it's your chance now to really push forward the power of your apps on the web.
Today we're going to hear from three different successful Chrome Web Store publishers, each
telling a different story about their experiences. We're going to start with Springpad, who is
going to tell us their story of how they moved from a website to web app and explore some
of the differences between sites and apps. We'll then hear from World Golf Tour, who
is going to tell us a little bit about what happened after they published into the Web
Store and why you should publish into the Web Store.
And then the New York Times will take it on home to talk about HTML5 and some of the great
APIs and tools there to develop a really powerful HTML5 app.
But you didn't come here to listen to me, so I'd like to turn it over first to Jason
Horman, chief architect of Springpad, who will tell us about moving from website to
web app. >>Jason Horman: Hello, everybody. My name
is Jason Horman, chief architect and cofounder at Springpad, and I've been a Boston-based
developer for about 15 years. Started out at Lycos.com and been doing DHTML since then,
doing Java, Python, and working in the Boston developer community.
So what is Springpad? Springpad is a task application. It's a note
application. It's an application to track your movies, your books. It's really a way
to organize your life, and we'd like to think of it as a database for your life.
So we store all of this information in a structured way. That allows us to enhance it, to provide
enhancements to it. We can give you movie show times. We can give you restaurant reviews.
We can take your notes and do more with them than a traditional just text-based note application.
So back in August of last year, we had launched our iPhone apps, we had launched our Android
app, and we noticed a problem. We noticed that the Web application's engagement was
trailing our mobile applications by quite a bit. It was almost two-to-one. And we took
a look at that and were just thinking what do we need to do? What is it about those mobile
applications that's working and the web -- what is it about the website that's sort of not
working? And we sort of came to the conclusion that
the great thing about the mobile applications was that they were so focused. That the constraints
of the device allowed us to think through how do we make a great -- a great application
that users can get in, get out, and use very quickly to get their tasks done.
And we looked at the Web application and sort of noticed that we had designed more of a
website than a Web application. That the -- the website had a lot of extra information. It
had settings buttons and it had your sort of profile picture. It was fixed width. It
used a number of sort of web development, website techniques, and we -- we took a look
at this and said, "Let's think about how to move this along and become a true Web application."
And I think that what that means is that we want that application to -- you know, to sort
of feel like a desktop application. And so what was natural for us to think about was
to launch that into the Chrome app store. So we wanted to launch this as an app, relaunch
this as an app. So the process of moving from a site to an
app. Well, we had a frame of reference. Our mobile
applications were sort of where we wanted to be. We liked the idea that our users are
using their iPads, they're using their XOOM tablets, and like the interface and they want
to know that when they move between devices and between modalities, that they're using
the same application and they understand how to use that application, so we wanted to unify
it. So where do we start? We started with our
navigation. We decided let's go full-screen. Let's sort of remove all of that extra stuff
that is great for a website that doesn't work great for a Web application. Headers, footers.
Let's make it feel like this is an app you've installed onto your desktop and moves as fast
as you need to move. The next thing we did is we sort of added
the polish. So, you know, we sweated the details around gradients, colors, the HTML5 CSS3 animations.
We added user customization features, theming, let users select their own backgrounds, let
them really customize their experience so they feel like they own it.
Then we sort of took it a step further and we introduced what we called the board. And
what the board is, is it allows our users to organize their information visually. They
can take those notes, take those tasks, take those restaurants, and they can place them
onto sort of a board there where they can organize things underneath a label of "Tuesday,"
"Wednesday." They can sort of group the related information together that they want.
They can resize each individual component. They can drag and drop off the desktop files,
notes, attachments, photos. And again, we sort of liked the idea of taking notes a step
further and allowing users to use them any way they want, and for us a number of our
users wanted to be able to do it in a sort of visual way.
So where we ended up was that we are really proud that we have a cross-platform experience.
All of our apps sort of feel and look the same.
And I think that's really important, in that, again, our users can understand our platform
in one place. They might not even really understand that we have a Web application yet, but when
they finally make that jump between modes, they understand where they are. And I think
this can apply in the future towards Google TV. Wherever we are, we want to have sort
of a consistent experience, and that experience is our application.
So it's only natural for our Web application to feel like an application.
So how did we do since launching? Well, right after launch, you can see that
we had a spike in that our Web application users started to match our Android users.
We actually doubled our Web application users in the next two months after launching into
the Chrome app store. Another important metric is that we had a
5X growth in the number of saves. One of the metrics we like to track is that people are
saving a lot of things, and that's sort of engagement, and we like to think that because
the application was faster and simpler and more engaging, that these users were saving
a lot more into the system. Other statistics, the web makes up about 50%
of our daily access now. That's up quite a bit since launch. And our Chrome users spend
a lot -- Chrome app store users spend a lot of time in our application. They spend, on
average, about 30 minutes a day, which is fantastic.
They sort of leave it up all day and they record new notes into it.
We also have a Chrome browser extension where as they're surfing the web, they can be clipping
directly into their Springpad. "All I can say is it is the best." Feedback
from some of our users from the Chrome website. Wow! Absolutely fantastic.
So I want to talk a little bit about websites versus apps again.
So another thing I'd like to point out is that we feel that productivity users are sort
of app-focused people. They think about desktop apps quite a bit.
They might think about, in the old days, you know, installing a task management app or
using Outlook, and I think it's only natural for those people to want to install an application.
And so I think it might seem like a minor distinction, but becoming more of an application
sort of, I think -- especially these days with Android and iPhone, pushing the envelope
with applications and pushing consumers to understand what they are, that that's really
important. So what makes applications great is -- what
makes Web applications great is they should be very, very fast.
They should have a layout that fills the screen, that feels like it would if you were clicking
it on the dock. And I assume in the future that's where we'll be, where you could run
a Web application right from your dock, and I wouldn't want it to feel like a website
when I do that. On that note, I think applications are a little
more task-oriented than websites. Websites are more about browsing.
So when you're -- when you're in an application, you want to do something. You want to create
a task. You want to create a note. You want to act on it. You want to book a reservation.
And I think apps also imply some additional functionality that you don't necessarily associate
with the web, which includes background notifications, background processing. Offline access is a
big one. And Chrome provides that from -- through local storage, through Web SQL, and IndexedDB.
So people are looking for apps, and where do they go to find apps?
Well, they go to the Chrome app store, of course.
You know, the great thing about an app store, obviously, is when you're searching for apps,
it provides a curated experience to browse and search for those applications. You're
not just going to Google and searching for "task" and sifting through the millions of
results that might come back. You're going to get what you were looking for, which is
a web-based application for handling tasks, movies, whatever you were searching for.
And obviously for companies, it provides a new channel to reach users.
You know, there's traditional advertising, affiliate, but having these stores now for
us -- you know, for iPhone, for Android, the marketplace, and now the Chrome app store
-- it provides this amazing channel to get users into your application.
The other thing the app stores provides is that enhanced permission feature, where you
can -- when you install from the app store, you can request things like unlimited storage
or access to your geolocation, and that opens up a lot of possibilities for designing complicated
applications. So today, we're announcing that we've implemented
Springpad offline. We think, again, productivity apps should
feel very, very fast. Well, offline isn't necessarily all about
being off line. One of the great things about implementing offline support is that you're
essentially saying "I'm going to sync all the user's data to their machine, so even
when they're online, they're using their local database." And that's very powerful. They're
not waiting for these RPC connections or JSON connections to servers where those servers
might have some latency. Some of you in the room probably have experienced
that a few weeks ago Amazon had some issues. Our user base wasn't super happy about that,
and at the same time we were building our offline support and we were just thinking
to ourselves, wow, if we had this, that whole Chrome user base wouldn't have even really
cared because all their apps -- all their data was local and they might not have really
even noticed that we went down. Our iPhone users and Android users didn't really notice,
and now our Chrome users won't really notice, necessarily.
We base this implementation on Web SQL. We needed the power of SQL. Springpad does
a lot of "select group by count," a lot of complicated queries to filter down for the
notes you're interested in, the movies you're trying to find, and Web SQL provided that
power for us. The New York Times is going to talk a little
bit about how they use Web SQL and the performance that it provides.
And one of the great things about Web SQL is that it's based on SQLite and our Android
app is based on SQLite, so we took our Android code base, we used GWT, Java to Java. Very
simple. We sort of just moved our database class from Android over to Chrome and got
up and running very, very quickly. And again, the -- another really huge benefit
of this is that all these Chrome users are not touching our servers anymore, and, you
know, we have to run quite a few servers to keep up with the number of users we have installing
the -- our applications, and we've seen that we're reducing our server queries by 30 to
40% by having this offline access, which is just amazing and our ops guy is sort of thanking
us for Chrome, you know. So where we ended up. We converted our web
-- I'd say "site" -- to a web app. We believe now that it's a multimodal world where you
have to sort of address that there are a lot of clients out there, and I think that consistent
UX is key to that; that these users should understand your application and understand
how it works in a consistent way, which -- which means you should bring your Chrome app -- your
web apps up to speed with these mobile applications, and I would argue make them as simple and
as streamlined as those mobile applications are.
And HTML5 makes this possible. You know, in particular, I'd say the Web SQL stuff really
is amazing and will provide some real strong performance benefits to your applications.
So I'm Jason Horman from Springpad.com, twitter @JHorman, and now I'm going to pass it to
YuChiang Cheng, from World Golf Tour, to talk a little bit more about Chrome.
Thanks. [Applause]
>>YuChiang Cheng: Hello. My name is YuChiang. I'm the cofounder of World Golf Tour, a serial
entrepreneur, which probably means I should seek some help, but despite that, let me share
a couple of stories that we have about World Golf Tour as well as talk about our experience
with publishing on the Google Chrome Web Store. So World Golf Tour, we're based here in San
Francisco. We are just leading the way in changing how people, sports fans, can engage
with the Web and the products they like. In the past, sports fans, in order to game, they
had really limited options. They could either go to the local brick-and-mortar store, buy
a game console for, I don't know, $300, buy the game they wanted to play for another 60
or $40 and get a really, really great visual and engaging experience.
Or, they could go on the Web and, really, for sports fans, the main Web application
or Web use that they had was looking up scores, reading about the news or playing fantasy
sports. Each of those had their own limitations in terms of how the fan could engage with
those products. And so at World Golf Tour what we've done,
we've been able to merge the visual aspects of a game console, you know, AAA title such
as a game from EA or so and actually bring that onto the Web and bring that same experience
to have all the openness, accessible, and actually the free use of that type of game
online. This is a shot of Harbor Town, and that's a screen capture of our product. It
doesn't take any download. You don't need to install anything to play this game. And
the visuals are really the best in the world. So that formula has worked out really well
for us, to be able to bring the accessibility of the Web with the production qualities and
large budgets of the big-game publishers. We have over 3 million registered users now.
We are the largest golfing game online property there is.
And we have merged the game with the more traditional online media model. Now we are
the Number 3 largest Web site for golf in the world also. So being able to sort of create
a hybridization of gaming, which is very engaging content, with the accessibility of a Web site
has done very well for us. Here's a quick video of our product. And I
will just walk you through it here very shortly. In our product, it is very simple. You, basically,
go to the Web site or, in this case, Google Chrome Web store. You can go and choose from
14 world-famous courses. These are all courses that are in the top 100 in the world. Anything
from Kiawah Island, Bethpage Black, St. Andrews as well as Pebble Beach at times.
And it is a whole community of people. They not only play games but they read the news,
they social network with each other. We have our own social graph that they are able to
connect with other golfers to play multi-player games with each other.
They are also able to play in tournaments against each other. So they take their gaming
skill and actually can compete in tournaments. And they actually win real prizes and are
able to see how they rank against the rest of the players in the world.
We also have a virtual golf store where you're able to buy virtual equipment. So what you're
able to do, we have partnerships with games like Ping, TaylorMade and Callaway. What we
do is we actually take the physical properties and the cad cams of those equipment, we actually
hit them in the store, record all the properties of them and then actually put them into the
game. So if an R11 driver is easier to hit and it has a larger sweet spot and you can
hit the golf ball a little further, you get those some properties here in the game.
We also have a strong sponsorship model. So between the sponsorship model and the virtual
item sales, we're able to, basically, give the game for free for everyone to go and play.
Let's see here. Let me show you a little bit about how we build it because it is actually
pretty interesting. We actually go to all the different golf courses and we take helicopters
and aircrafts and we actually fly over the course and laser scan them to half-an-inch
accuracy. That allows us to produce all the different surfaces as well as the greens and
replicate them to a high degree of accuracy, where if you roll the ball across the greens,
it will actually roll and dip and move exactly like it does in real life.
It was so accurate, in fact, that for the last U.S. Open, the players actually played
our game ahead of time to get used to the course to understand where it was. And there
is a game name Ramada Ryuji Imada, who is a pretty famous golfer in Japan, he actually
prepared for Bethpage Black for about 16 hours just rolling the ball across our virtual greens
looking at how it played. Here is a quick picture -- video of us flying
over Oakmont. Basically, what happens is after we laser scan the course, we take roughly
300,000 photographs of the course. We geo tag all that information, and it is sort of
like Street View on steroids. You then are able to walk through the course and not only
see the photographs at each individual point but also able to interact with each of the
photographs. We have a very complex metadata layer behind each of these photographs mapped
onto the 3D environment model that we build to create detail that allows you to then interact
with every single pixel on that photograph. So Oakmont is a beautiful course if you haven't
been there. So here is a quick view of one of our internal
tools. Basically, what it does, is after we geo tag every photograph, we are able to put
it into our school set which then basically places the photograph in its correctly geo
located space and actually tries to align it into the 3D model automatically. It is
pretty cool technology. So at the end of the day, this is what you
get. You get to play a game on a beautiful golf course for free in your Chrome Web browser.
So as you can tell, we have a pretty mature game. It is a really big-budget product. And
we're in the phase where we're really just trying to find more users for the product.
What we've learned is when people come and they show up and they are able to experience
the game, they stay and they like to play and they are very engaged.
So for us, what we're doing is we are looking for new channels of user acquisition. Right
now we actually drive a lot of users from Google AdWords as well as from Facebook and
where we are actually looking for a different way for driving users so that we don't have
so much dependence on single sources of traffic. So we are also looking for the fact that different
players from different channels actually have different spending and engagement characteristics.
And so our company is pretty driven by our analytics. And what we're looking for is actually
a user profile that could actually spend more time on our product, be able to target those
users better and then have them deposit by their virtual items and participate longer
on a product and effectively have a higher lifetime value to us for making deposits.
And one of the major barriers to actually getting someone to be worth something to us
in terms of a deposit value is actually getting through the payments hurdle. So that's actually
a big problem that we have where you get large breakage from the top of the funnel into the
deposit. And, you know, just a few percentage points even in terms of reducing the friction
to get that deposit means a lot. It turns out to be a very substantial difference in
the revenue you can generate from each of the users. So we are looking for some solutions
and some channels where the payment mechanism could effectively have a lot less friction.
So that really brought us to find the Chrome Web store. And so as usual, what we wanted
to do is test things. So our approach to this was to, basically, take our product, package
it into an application and put it into the Web store. And for us, we decided to go with
two different applications. And the main reason for this is we wanted to, A, test the duration
and simplicity that's required to have an application in the Chrome Web store and see
how it affected conversion rates as well as LTV.
So we created two apps. One of them is a 9-shot challenge, which is actually a very narrated,
simple experience where the user basically comes in and can do nine quick shots. They
don't really need to know anything about golf at all, and they can come and play the game
quickly. It is a very simple experience. Our second application is the full product
where they can actually go play all the different courses. There's less hand holding of the
user as they get into the environment and there is a lot more depth of play.
And so we were just seeing, like, what's the trade-off between the conversion rate between
something that's more simple versus something that's a little bit more in-depth versus the
long-term value of the users that we acquired on the simple product versus the more in-depth
product. So as it turns out, the simple product is
working better. The conversion rates are higher, and the LTVs are actually the same. So this
game here is actually the number one sports game on the Chrome Web store now. This is
the short version of our product, and the second one is the longer version.
And what we've learned is that they're actually worth relatively the same. The shorter product
converts better. So you can see the users have rated it 4 1/2
stars out of 5. They love the experience. They really value the fact that there's a
large budget product game available in the Chrome Web store and that they can play it.
So let me just go into more details about the result. This is the most popular sports
game right now. And we basically acquired over 60,000 users in just six months. What's
surprising to us and a great sign is that of the users that we acquire on the Google
Chrome Web store, they play on average 23% more in terms of time and duration on our
site than all the users we get on aggregate from the other channels. So they're highly
engaged compared to the rest of the Web. Additionally, these are users who spend money.
These are users, for some reason that we're trying to delve into, that have a better sort
of deposit rate than we get from the rest of the Internet. So on average, they deposit
147% more in terms of lifetime value to us, which is a great sign, because, you know,
you never know what the channels are, especially if they're free. And this is really the number
one statistic that we look at. And because of that, we're putting our full
weight and shoulder behind launching more applications and putting more marketing and
product development behind our products on the Chrome Web store. So we're announcing
today that this summer you are going to be able to, basically, experience the full U.S.
Open through the Web store. And with a partnership with the USGA, the U.S. Open and ourselves
and Google, you are going to be able to see live streaming of the U.S. Open golf tournament
as well as the scores. And through us, you are going to be able to actually play the
same course that the professionals are playing at the same time online. So we have gone and
shot Congressional and replicated it so you can go and play that.
So the big take-aways for us is that, you know, large-budget games can be successful
in the Chrome Web store. It was really easy for us to launch and repackage it. The folks
at Google were very helpful. We, basically, got both applications up and running in less
than a week. The rankings sort of speak for themselves,
and the great surprise to us was the value of the users that we were able to acquire.
And, you know, one of the things that I didn't quite emphasize enough but -- is the payment
part of it is actually pretty crucial. And we think that that's probably why our LTVs
are higher here, is that the trust of the Google brand to, basically, use app payments
or the Google checkout payments, seem to be helping quite a bit.
And for all of you guys, if you want to go try out our app, you can just go to the Chrome
Web store and type in WGT, find our app. To help you out a little bit, you can put in
"io" and we'll give you a free TaylorMade driver that you can go and try.
On that note, I'm going to hand you off to Andre who is going to talk a little bit about
developing on the Chrome Web store. [ Applause ]
>>Andre Behrens: Hi, everyone. I'm Andre Behrens, I'm a senior product engineer for "The New
York Times," which means that in addition to writing code, I come up with product ideas
and try to make them happen. So one of my main products that I work on
is called the Times Skimmer, which also serves as our Chrome map. You can find it on the
Chrome Web store or you can go to nytimes.com/chrome. I will do a quick demo of it. You can read
columns in it. You can navigate around sections very easily with nice, little sliding -- one
of my favorite features is that you can really change the way it looks very quickly with
a whole skinning engine. We have some enthusiastic users. They say
things like "I like the app," "Best way to read 'The Times,'" "Basically, the best thing
ever." I think that's my favorite tweet I have read, and I have read a lot of tweets,
thousands of tweets actually, and lots of comments on blog posts on the store itself.
If I had to summarize it into one sentence that you just hear over and over and over
and over from the fans, it's "it's like reading the paper," which really made me happy because
that was sort of a goal. But I think there is an important point here
that they're not saying that it's like the paper, they're saying it is like reading the
paper. And I think that's a really important point
when you are doing media consumption apps like we are.
So this is our ideal customer from sort of the traditional business. He's sitting at
the paper. He's very, very happy. We like to see that.
What is he happy about? To sort of think about that, we should look
at the alternative, and why are our customers responding so much to our app?
So we have the web. We all know it. I think it's sort of like this for a lot of people:
it's enormous, it's amazing, it's full of potential. It's also -- we haven't figured
out how to get around it entirely. We haven't figured out how to be comfortable in it. It
takes some work to deal with it. And there are certain ways that it's broken
for our customers. This is one of them.
This is a developer conference, and we all sort of understand what makes this page happen.
And so I think in the back of our mind, we a little bit sort of compensate for it. We
don't think this is an enormous, huge failure for the user.
This guy doesn't have that problem. You know, he picks up the paper. He reads it. The stuff's
there. He's having a good time. He doesn't have to think about if something will just
suddenly -- like a page won't just suddenly not be there.
Nobody gets in their car and drives to Boston and today it's just not there.
This doesn't happen in the real world and our customers don't like it.
When it works the way this is working for him, it makes you feel calm about things.
Things work the way you know they will. It makes you feel confident. It makes you feel
empowered to use it. So the challenge is to bring this to our app.
A newspaper is always available, it is consistent the way you use it, and it's a thing you can
sort of understand. You can see what its boundaries are. You understand what it means.
I don't think it's any accident that most of the browsers, when they first came out,
were called things like "navigator" and "explorer." We're looking for something slightly different
here. I think that availability is the place to
get the biggest gains right now, and I think HTML5 really does solve this for us, and this
is really crucial. So the first step to making availability happen
is that a good app always turns on. And the way to do that is to use the application
cache. So a quick sort of run-through of this.
You're going to make a file and you're going to basically describe to the browser how to
handle every request it receives. And you do have to include every possible request
one way or another. You're going to put this all in a file. You're
going to give it an extension of "manifest." You're going to reference it in an attribute
in your HTML tag. On the server, you're going to have to set
up a mime type that is "text application manifest." This will tell the browser, "This is the one
I'm going to use." All these things have to go through or it won't work.
This is what the actual cache file looks like. You have a bunch of headers. They're in all
caps. Two really important sections of it, cache and network. Cache means I'm going to
take this file and I'm going to put it in the mother of all browser caches.
This is not going to hit your server again. Any file that's listed here, it's in the browser,
it stays in the browser, it doesn't go out of the browser, it's just there. It just exists.
And every file that's in here is pulled down in a transaction, which means that it won't
pull down any of them until it can pull down all of them. Which means having a situation
where your assets aren't lining up doesn't happen.
Think about that. So now you have all your files. Your app is
going to run. You also need to punch holes to tell it, "It's okay to hit the network
for this." So this is going to be things like services. You may even just sort of wildcard
the whole Internet, say, "If I didn't think of it already, go for it."
There's a lot more to learn about it, and I will tell you that the initial stage of
using the application cache is the most difficult. Once you get over that part -- it's not super-difficult.
It's just sort of a little bump, making sure all your Is and Ts are crossed, all right?
You're going to want to refer to some of these. I strongly encourage you to look at any of
them. They're all excellent sites. Appcachefacts.info is a wonderful resource for this particular
technology. Read about it, learn it, use it. We're fixing the web for our users.
So now we have an empty newspaper, which is a really excellent start but it's not worth
anything to our customers if they can't actually read something.
So we've got two problems. We've got to move a lot of data into an offline situation and
we've got to store it. I'm going to start with storage.
So there's a couple of options available to you. Easiest is called local storage. There's
Web SQL, which is like using SQLite, and there's IndexedDB which is sort of the wave of the
future but also not quite fully ready for prime time yet.
We use Web SQL for ours at the advice of Google. Main reasons are speed and in the Chrome store
you can have unlimited offline storage. Web SQL works with that; local storage doesn't.
This is what Web SQL looks like. If you're not used to highly asynchronous
programming like happens a lot in AJAX and JavaScript, this may look a little off-putting,
and, you know, it's a little bit of doing. Every time you do something with Web SQL,
you're getting a function that's getting a callback that has the thing you need and then
you're doing another thing and you're getting a callback and there's success callbacks and
error callbacks. It's a little bit of extra work, but I -- I'm
not kidding when I say that it's faster. It is really, really, really fast.
It is as fast as it can be. I was really -- I kind of blinked the first time it worked,
when I switched from local storage to using Web SQL. Fast.
There is one thing you need to know. So I've just been singing the virtues of SQL. This
is probably a technology that doesn't have as bright a future as some other technologies,
so the W3C doesn't seem to want to go forward with it. I think this is what you need to
use now if you're using heavy data the way we are. Just be aware you might have to shift
your program a little bit in the future to move over to something like IndexedDB.
But I really think you should look into it now because you're still going to be dealing
with callbacks and stuff, and thinking about it and building an app that uses databases
on the client side will really get you ready for the future.
Okay. So now we got to move a lot of code. We're going to use another HTML5 -- we're
moving a lot of data so we could just make a bunch of AJAX calls.
In our case, we're making about 22 calls to load all of the sections that we need, but
we're probably going to have more in the future, and potentially a lot more, and AJAX occurs
on the same thread as everything else. It's happening in your UI. So we wanted to put
our requests in this little box where it could never hurt the rest of the performance of
the app, never call an animation to jerk, so we're using workers to do all of our network
requests. A worker is a separate thread. It's a separate
process that can run any JavaScript code that you want, but there are a couple of important
caveats. You can't access the window object. You can't access the DOM. You can't see the
document. There are a couple special properties that you can see. There are a couple of HTML
technologies that have versions that are available in a worker, but you should treat it like
a separate application. So you take a piece of code, you instantiate
it as a worker, and you're going to define an event for it called a "message," and that's
going to receive an event object very similar to one you would get on a mouse click or a
keystroke and it's going to have a property on the event called "data" and that's going
to be an object or a string that you're getting from the worker.
So each side of the worker, on the inside and on the outside, there's a post-message
and an on-message. On-message where you pick up a message, post-message put it in. So you
put it in, get it out, put it in, get it out. In this case, we're going through a list of
sections and I'm throwing them into the worker with post-message. When it gets back, I'm
going to store it essentially to a SQL. Inside the worker, again, this could theoretically
be any JavaScript code that you wanted. You're going to have an on-message function which
is going to do the same thing it did on the outside: get the data, deal with it.
In this case, we're making a synchronous -- that's important; everything that happens in a worker
is synchronous -- AJAX request, we get the data, we put it back, and when you watch it
run, when the app first loads, it just goes (making sound). Worker is at work.
And we're back. We're back to this guy. He's happy. He's reading the paper. There's stuff
in it. And even if EC2 goes down, which our app is on EC2, not a problem for the users.
Epic, epic win. They won't even notice. Now, one bonus point. People who really, really
like the news really like to not wait to get it. They get it delivered to their house.
They don't want to have to go to the corner to get it or worse.
So for our app, we're using one of the newer features of the Chrome Web Store, which is
background windows. This lets you make an invisible window that is in every other way
like a window, but the user never sees it, and that can be open even when your app is
not open as a tab. All you need to do, you go into the manifest
file for your Chrome app, which is in the bundle you submit to the store, and there's
a section called "permission," so you see we have unlimited storage notifications. You
have one called background. Then you're going to do a window.open call,
just like you always have, and instead of at the end where you would put status, height,
width, leaving all that out, you're just putting background. Now, one caveat. This is a Chrome-only
feature and if you don't sequester it and you open it in another browser, you're going
to have a couple problems. You know, the window is going to open, no one is going to understand
why. So you want to make sure you're in Chrome,
you're in a Chrome app, and you want to make sure it's Version 10 or higher, because that's
the version that understands this particular feature.
Opens the window. We have a sort of light version of the app that runs. And it's continually
looking for new news and new breaking news so we can notify the user when something happens.
That way whenever they turn it on, they have stuff to read and it's as up-to-date as possible.
So in review, application cache, Web SQL, web workers, always-functioning app.
Now, one thing we're working on -- it isn't quite ready but it will be ready in the coming
weeks -- is we're using the brand-new file API which is Chrome-only and we're using workers
and SQL again and we're going to be storing the images offline so you'll be able to read
the whole New York Times in your Chrome browser. We're using the background feature to make
sure it's there. And on top of the technology, again, this
is a really wonderful platform for getting your app out there.
We saw an order of magnitude interest -- increase in users of this app by putting it through
the Chrome Web Store. So now we have the web app that's as available
as a newspaper, consistent the way a newspaper is, and is graspable and understandable for
customers, and now we have people that feel calm, confident, and empowered using our app.
All using HTML5, which I'm here to tell you we are betting big on.
So I'll turn it back to Seth. [Applause]
>>Seth Ladd: Thanks, Andre, and thanks everyone else. Great stories.
So to summarize, building apps makes a real difference. We heard from Springpad. When
they moved from a website to a web app, they saw, for instance, five times more saves.
That means people are more productive and using it a lot more.
We also heard that publishing to Chrome Web Store helps users find you. For instance,
World Golf Tour saw 60,000 new users from six months and playing -- those users playing
23% more. And finally, HTML5 gives you the tools and
techniques to build really powerful Web applications. New York Times just told us about some of
the techniques and tools that they use to make their app offline and accessible all
the time. So now we're going to open it up to open Q&A.
Hopefully you can grab the link here for the Moderator. This is also on the Google I/O
page as well. We definitely appreciate feedback, so please do provide the feedback afterwards.
And you can find this presentation as well. So please do come up to the microphones. We'd
love to hear from you. I'll go ahead and start this here.
Okay. So we'll take some from here and we also have some prepared questions. This is
also for the panel. So the first question here from Moderator
is: Chrome apps to be fancy links to websites. Web Store appears to be a showcase of cool
sites. What can we -- what can or will Chrome do to make apps much more than just links
to websites? So I have a personal opinion on that, but
I'd like to hear a little bit from you guys. Like, is this -- how does this question resonate
with you? >>YuChiang Cheng: Well, I think for us it's
just an evolutionary process. You know, I think this is just early in the cycle and
we're all trying to feel our way and test our way into what works the best, and the
best way to start is to put something up as quickly as you can.
But for us, we are really seeing the data that shows that if you make applications that
do specifically things and package them in a way and actually create the UI in a way
that's more application-like than a website, you're going to be far better performance
because the users have an intent to use those applications and you need to fit that intent
with your product and then you're going to get more distribution, so --
>>Jason Horman: I'd say, you know, since -- they're just links in the Chrome app store. That's
not necessarily a bad thing. It is a distribution mechanism to get out there to more users.
Users might trust Google. They might find your app where they'd never find it in any
other place, and I think that trust is really powerful. That's something, again, I think
that the Android store and the iPhone store has sort of proved.
And there are technical reasons as well. One of the great things is that the app store
does provide for enhanced sort of permission schemes, so, you know, when you install from
the app store, for us we were able to ask for that unlimited storage permission, and
you're installing from the store, the store tells you that the app's going to require
that permission, and you can build sort of more powerful applications because of that.
>>Seth Ladd: The way I look at it, I actually think that the fact that they're links is
a very good thing, right? What's the power of the web, right? You have a back button.
You can move back at any time. You can kind of escape from where you are. That's powerful.
You can share stuff by copying the link. That's powerful. You can bookmark things. That's
powerful. So I think that when we try to make an artificial
distinction based on the technology that they're just links, I think we're looking at the problem
wrong. I think there's a lot of work we can do as
a community to integrate more app-like features but, you know, as Springpad shows, it can
be done. It's fairly straightforward to be done. And so we just need to continue to embrace
HTML5. And remember that the Chrome Web Store allows us to publish to Chrome so we can build
these apps straight to a targeted platform. Live question.
>>> What about the way those links actually look? They are like a gigantic hash of sorts
that you can't really control. Would it be all the things that you brought up there that
are good for the Web and things like that, would those not even become better if we could
have some sort control over the beauty of those links which are fairly ugly at this
point? >>Seth Ladd: I imagine you are talking about
the actual display in the Chrome of that browser itself? Sure, I think there is a the lot of
work we can look at other people are doing and what user expectations are of the experience,
too. So we're very early in the stages here, so I think there is more work to be done for
>>> Can you guys share anything you have learned about managing user expectations? Like, maybe
something happened with EC2 and some functionality went down and as a result you got a lot of
bad reviews for your Web app? What are some ways you would deal with that or things that
you have learned? >>YuChiang Cheng: For us, it is just being
very, very straightforward with the user on what they can expect in the application within
the description. You know, the biggest lesson we learned about
the description was, you know, if you are going to call your app "free," it better be
really free. You get a lot of really bad feedback if it is not.
For us, we are pretty lucky because 99% of all our content is free. But in terms of managing
expectations of how they can use it, it is just being very straightforward with them
and describing your product accurately. >>Jason Horman: For us, I'd say we were affected
by EC2 going down. We tried to be very, very straightforward on Twitter. We tried to blog
a lot explain why this was happening to them and try to direct them to the mobile clients
where they had synced some of that data. And we sort of then started promising that HTML5
was coming soon, and they had wished that it already was here.
But it is a really tough problem because I would say, you know, when EC2 went down, we
sort of failed in interesting ways as well. We were trying to communicate that to the
user as well. And we have changed our application and improved it to handle some of those scenarios
to at least communicate better to the user because sometimes they weren't sure if the
things they were saving were actually saving. Or, What's going on? Some of the app works
and some of it doesn't. There is a lot of sort of last-mile work to
make your app great in those scenarios. You focus a lot about when everything is working
great, the user experience of that. When everything is working very poorly, you need to focus
on the user experience of that as well. That's sort of really hard, and we are getting better
and better at it. >>Seth Ladd: Do you have any kind of specific
user forms or support forms? >>Jason Horman: We use Get Satisfaction quite
a bit, and we have an active community there. We actually have a community manager, and
her job is really to just keep communicating with these users when these things happen.
And people were really happy about that. People were thanking us for just being open
about what was going on, which was sort of easy for us we just put it on Amazon. They
were really happy that we were just so vocal about it.
>>YuChiang Cheng: You can expect that you are going to have to communicate with your
users. It is actually a really, really good thing. I highly suggest you guys do invest
in community management. You should definitely check the reviews and everything on your store
every single hour. You should do your email. And you need to provide them another forum
where they can communicate with you at so that they don't go just directly to posting
a bad post, right, that's negative. If you give them other ways and you can sort of have
a better dialogue with them, you can keep the reviews pretty positive.
>>Jason Horman: We are definitely still at the size where even user by user if they have
a problem, we can investigate that problem on our server logs quickly for that specific
account and try to fix them and people seem to respond to that as well.
>>Seth Ladd: I had a question for the panel and actually the group here as well: How do
you see payments evolving on the Web? Specifically for the Chrome Web store, we have in-store
payments and in-store subscriptions and we announced back at GDC that we are working
at in-app payments as well. A lot of different ways to monetize apps that may be or may not
be distinct from Web site monetization. How are you thinking about how to monetize
your apps here? >>YuChiang Cheng: I guess I'm the only one
taking credit cards right now. Basically, for us it is definitely evolving and changing.
I think the user behavior is definitely changing in a way where most people don't want to pay
up front for stuff. Unless there is a high level of credibility and they know exactly
what they're going to get, they don't want to shell out the dollars. And so what's proven
very successful for us and a bunch of other gaming companies as well as people who are
starting to sort of gamify their productivity applications is you give them a lot of features
and then you try to upsell them throughout the process.
That's why sort of in-running or frictionless payments within the application, I think,
are going to get really, really popular. So you build the trust with the users. And then
when we get to the point where there is something they want to do a little bit faster, get access
to something a little bit different but they already find your application very useful,
they are willing to pay that incremental $1 or 2 to continue.
What we have actually learned is that by doing this type of payment mechanism, you're able
to actually capture a lot more people who wouldn't normally pay you, so you sort of
get a larger mass market. But the great surprising side of it is that you actually get more money
out of the people than you would have if you would have just made a fixed price for the
application. So the fixed price actually caps the total
value a user can be to you other than through advertising a sponsorship. If you do an incremental
payment or a microtransaction, you are able to capture a lot more of the top end also.
We are really excited about the in-app type of payments that we're coming out with.
>>Jason Horman: For me as a user, I really like the idea that I can have a few trusted
sources I'm going to give my credit card, too. I do trust Google. I trust Apple. I don't
trust Sony anymore. [ Laughter ]
And so I have been thinking a lot personally about how do I remove my credit cards from
all these different applications. And really I trust Paypal. I trust a few sites that I
think are really good at security. And I think the Chrome store, you know, again, the store
provides that level of trust for users where they might think, "Well, I know that Google
has my credit card but I don't necessarily want to give it to this other random application
that's out there."That's great for me as a user.
>>Seth Ladd: Live question? >>> Do you guys obfuscate your JavaScript
at all? Do you run it through any systems to kind of hide the code? Obviously, you worked
a lot on developing those really nice systems. Do you try to protect that at all, or do you
figure it is out there, it is out there, sobeit? >>Jason Horman: We use GWT, and GWT naturally
obfuscates everything and also will compress it. It helps with g-zipping that code down.
I don't think we really did it to be secretive. We sort of did it to make the code size smaller,
and I think everyone didn't mind that it was a little more secretive.
But for us, I don't think we have a ton of proprietary JavaScript that we would be too
worried about versus our backend being some of the core infrastructure.
>>Andre Behrens: I used to worry about that a lot when I first started on the app. I don't
worry about it a lot currently. I used to be very worried about sort of copying. And
I think that's sort of a mind-of-the-creator thing, honestly.
I think like we worry about a lot. We get very upset when we see things that are very
similar. "Oh, they're stealing my ideas, stealing my stuff."
Number one, it rarely happens. And I almost have never seen, you know, a sort of copycat
thing actually be good. And I have never seen anything that seemed like it was fit to lure
our users away. They seem happy. So I think we are sort of leaving that mostly
as a problem that we'll solve if it becomes a real problem.
>>Jason Horman: There is so much amazing JavaScript already out there that is open that, like,
you know, you don't even have to copy because it is probably out there.
>>Andre Behrens: The people that are really, really good would be offended at copying your
stuff, right? It would be beneath them. >>Jason Horman: That's true.
>>Seth Ladd: Thanks for your question. >>> Thank you.
>>Seth Ladd: I have a question for the panel then. So do you think we even need a store?
Shouldn't just Search solve this problem? >>Andre Behrens: People -- I don't know. It
is a really good expectation setter, you know? You go into Search, you can get anything in
the universe. Again, giant space probe. Being able to say here is a cordoned-off area where
everything that I get is going to be an app the way I want it to be an app.
The proof is in the pudding. I mean, people responded to it. You can argue about why,
but people do respond to it. They like this. They like going to the store.
>>YuChiang Cheng: I think we were just talking earlier before the panel started actually
among ourselves that we're just in a cycle right now where, you know, Search is sort
of -- I type in my intent and I get this world of possibilities and it is kind of wild west,
the user beware of what you click on and what you find and all that.
And we're sort of now entering the next phase of where we actually create more narrative,
structured environments to help guide the users through things so that they can find
them and find the right thing at the right time and something that hopefully that they
will like to use and find helpful. And the app stores right now just seem to
be doing a pretty good job of that. I think it does have to do with sort of the
gating factor that not everything can show up in the store. There is some controls there,
and there's some level of quality that is associated with it. That's what's important.
And I think there's always going to be a use for that and that consumers will appreciate
it. >>Jason Horman: I think verticalized search
is always powerful. I go to Epicurious to search for recipes, and I do personally think
to myself I want to go find an app sometimes. And going to a store is a curated place to
go do that. It is a verticalized search for apps. That's always going to be a powerful
thing for some users. Some users are always going to Google. That's okay, too, and they
will still be able to find your application. >>Seth Ladd: There is also the two different
user models, right? Like Search when you know exactly what you're looking for and browsability
when you are not really -- have a targeted idea.
I think that's, for instance, productivity apps, for instance, it is hard to find Springpad
when you type "productivity app." There is a lot going on.
But if you can have a more targeted experience when you just browse through them, it might
lead to finding it easier. So let's take a question here from Moderator.
I think this is for Andre. Are native apps on smartphones and tablets here to stay, or
do you think there will be a shift toward HTML5 apps? What will trigger that shift?
>>Andre Behrens: There will be a shift towards HTML5 apps.
>>Jason Horman: Done. >>Seth Ladd: Excellent. This is something
you were talking about back at "New York Times." >>Andre Behrens: When I said we are serious
about HTML5 at "The New York Times," I wasn't kidding. There is a lot of reasons for that.
It is not purely ideological. Part of it is just that we were going along and we were
like, "Hey, you know what? This is good enough." This can do it now.
You know, I had been sort of telling my bosses about my progress and the things I was working
on. And I made a couple of changes and at one point it just clicked (snapping). And
it was like, "This will work. This stuff is here. All the pieces that weren't here the
last time that we went through this cycle, they are here now." And everyone is on board.
Microsoft is on board. Everyone is on board. And it is all going to be there. And all of
these devices are going to have these things. And I don't know. I don't think a lot of people
want to build something seven times and implement a feature seven times.
I mean, I think there will be a place for native things for a long time, particularly
for tooly things. I think there will be a long period for that, but I think -- I have
always said to people that the Web -- I always bet on the Web winning because the Web is
better at emulating other things than those things are at emulating it.
The thing it figured out is so unbelievably hard to get right that all the other stuff,
you know, it can just do a pretty good job of doing it. And I don't think those things
will have any luck emulating the way URLs and hyperlinks work. It is just too much.
We've seen this in our own apps. I mean, there is a lot of pain.
And HTML5 apps -- like, today, right now, we're seeing the worst HTML5 apps that there
will ever be. These are the worst ones. Think about that.
>>Jason Horman: I think that if HTML5 -- if HTML and JavaScript were as fast as native,
which way would Apple have gone? It seemed to me they wanted to go with Web applications.
It just didn't end up performing the way they would like.
If you could start over and say they performed equally well, they probably would have gone
with HTML5 and that's probably telling. I feel a little bit betrayed by the -- I was
a Web developer. I thought it was great the direction everything was moving with open
standards and the performance improvements and the separation of layout from presentation,
from implementation. That was all great stuff. And then all of a sudden, iPhone took off.
And as a company, we had to start hiring up in that direction and hiring up from the Android
direction. We have to deploy to so many platforms now.
That was sort of the problem with the Web. We didn't have to necessarily do that. We
are sort of back of this role where we have to build five or six versions of everything.
I still think HTML5 sort of could be the future to avoid that.
>>Seth Ladd: So quick question here from Moderator. When will the Web store be opened up in other
countries? Just stay tuned for that. Live question.
>>> Yeah. In terms of that difference between the HTML5 app and the native application,
what about if we're building Chrome apps, how can we port those to different platforms?
And to avoid having to write things twice, how could you -- what would be some thoughts
you would have on building a Chrome app and then having a mobile version of it and how
to -- some best practices that way? >>Jason Horman: I mean, I would say -- one
thing that was very powerful for us is GWT. It is java. I'm talking specifically about
Android. We were able to take a lot of our core java code and just move it to Android
and it all worked great. That included even some of the WebSQL stuff. It didn't include
a lot of the layout. The actual Android interface couldn't be based that way.
That said, one of the great things about Android is that it has this XML layout language and
it almost has a style sheeting language. So I was able to really pull our designer in,
and he implemented a lot of the Android application with me by just editing those templates -- those
XML templates and those style sheets. We almost ported some of the look and feel over.
That process with iPhone was quite a bit more difficult where he was passing Photoshop screen
shots with pixel placement and our iPhone developer got it a little bit off. They argued
about what was off. And I really had wished that we could have
done an easier job with iPhone. >>Seth Ladd: Yeah, great question. Sorry we
are out of time. But definitely if you want to follow up, we are going to be up here.
Just because we are all on the panel and this is Google I/O, it is not going to be an all-softball
question, I think. So I just want to end with maybe the toughest one here.
So: Chrome Web store, great store or greatest store?
[ Laughter ] >>Jason Horman: Greatest store, of course.
>>Seth Ladd: All right. Excellent. Thank you, everyone, for your time. I really appreciate
it. [ Applause ]
Thank you to our panel members as well.