Chrome Mobile: The Mobile Web Developers Toolkit (Part 1)

Uploaded by GoogleDevelopers on 05.12.2012


PETE LEPAGE: All right.
Hello everyone.
Let's try this one more time.
Welcome and thank you for joining me for a special
Chrome Mobile Office Hours.
Today I'm going to be diving into a bunch of great tools
that you can use as a web developer to really build out
your skill set and make yourself more productive in
the things that you're doing when you're building for the
mobile web.
We're going to take a look at some demos.
We're going to take a look at some libraries and frameworks.
With that, why don't we jump in and have a
look at some slides.

Today is the first part.
We'll be having our second version
of this next Wednesday.
and we'll dive into some great testing tools and a couple of
other devices and things at that time.
But for today, we're going to look at the development
environment that's important when you're building great web
applications, and particularly for the mobile.
It's really easy to go and just hack stuff together with
Notepad kind of equivalents.
But really, we become much more productive when we have
really solid tools.
We'll take a look at some things that will remove some
of the authoring abstractions or provide some abstractions
to what we're trying to write, so that we end up not having
to deal with a lot of the crazy or merging stuff
together and all that.
Then we'll move into some of the frameworks and libraries.
Things that will help make your life easier to get things
done and easier to be able to handle some of the stuff that
you don't enjoy doing--
or somebody else has already written it, so why bother
writing it again?
Next week, we'll take a look at performance, testing, and
build optimization.
If you're looking for some other stuff, there's a great
place there where you can check out Paul's Tooling and
the Web App Development Stack.
That's a great presentation that he's got online.
You can download that or pop through those slides.
These slides will be available online afterwards.
And as well, if you look there, say right about there--
OK, well maybe it's a little that way-- but anyways, if you
have questions as we're going along, please post them to our
moderator queue.
And I'll do my best to answer those questions as we move
through the day.
Let's first of all take a jump into the development
things that you're using to code, compile, to build, and
reload your pages.
I have a personal favorite development environment.
And that's Sublime Text 2.
Sublime Text 2 makes my life really easy in terms of
providing intellisense so that I can go in and start typing
something, have it auto complete.
It does it for not just HTML and JavaScript, but if I'm
writing something for maybe App Engine and using Python--
or maybe I'm using Java, or whatever back-end languages I
want to be able to use--
all of that stuff is right there.
Easy for me to be able to go in, get access to,
run quick and easy.
In fact, let's just pop out of here for a sec and I'm going
to bring up Sublime.
This is actually the presentation that we're
looking at right now.
You can see that it's got all of the intellisense that I'd
normally be looking for--
code coloring makes it really easy to find stuff.
If I create a new file--
actually, I didn't want to do that.
Let's say File, New and I'm just going to save this as an
HTML file, demo.html.
Save this.
One of my favorite things is the snippets.
I can actually just type in HTML and Sublime has a snippet
already saved allowing me to go in and fill
these things in.
It provides great tab completion between the
different events.
You can go and add these yourself.
You can grab others from other developers who have already
created these things.
It's a great text editor.
I always forget the simple syntax on stuff.
I could type, for example, link--
because I want to add a CSS style sheet in here--
All I did was hit Tab.
It completed everything--
put my cursor into the right place so that I could quickly
and easily be able to get in and do the things that I want.
It's not for everybody, but it does save a lot of time and it
works for the PC, it works for the Mac.
Really easy to be able to go and use, get access to it
without having to go and do anything too crazy.
And I think to buy it, it's about $25.
It's relatively inexpensive, really easy to go
get your hands on.
If we pop back to the slides, the other one that I really
like is an app called CodeKit.
And CodeKit--
you can do this with build scripts, you could do this
with something like Yeoman.
I find CodeKit was really easy for me to be able to just plug
into a bunch of my existing projects.
But I think the developer of CodeKit calls it, it's like
steroids for web developers.
I really like to think of it as something to do all the
hard work for me.
Something to do all the things that I don't like to do, that
I don't want to have to go in and be like, oh, how do I do
this, or what do I need to go to do that.
It will automatically compile pretty much everything from
CSS, to SCSS, to Less, all that kind of stuff.
It'll do JavaScript.
It'll do inserting HTML into places.
That was a really great tool that I found
worked really well.
It will also do JSHinting and JSLinting, so that as I go
through and work on my projects, it tells me when I
do something that maybe I shouldn't be doing.
It's a quick, easy way.
In fact, if I bring up CodeKit right now, you can see here's
the CodeKit for my mobile tool belt project.
There's the slide config.
It doesn't import anything.
And it's not imported by anything.
But I can check the syntax with JSHint, and then I can
concatenate [INAUDIBLE]
any files that I need to work with.
Couple of great little things there.
Really easy to be able to go and work with these guys.
I really like CodeKit.
I'd recommend that one.
It's only available for the Mac, but I'm sure there are
other equivalent ones for the PC.
Or you could really-- if you wanted to be down and dirty--
you could write your own build scripts to go and take care of
some of this stuff.
But let's dive into some of the development tools, some of
the things that are worthwhile using, worthwhile getting our
hands into, and making great mobile websites.

One of the biggest complaints that I've often heard from
developers is they often think that, oh you know, it's this
mobile site.
It's got to be ugly.
It's got to be--
oh it's mobile.
There's so many devices to go handle or there's so much
stuff, I just like, oh.
Don't let the fact that people are saying, oh it's mobile, or
oh, it's enterprise, or oh, it's the web be
an excuse for ugly.
That's just lame.
Beauty sells.
We all know that.
When you go into any store, anybody who has a beautiful
product, you go, oh this is pretty, I want this, right?
We want beautiful stuff.
Building a more lickable mobile web is really
important, and something that we should spend
more time on doing.
There's a couple of great things that you can take a
look at for this.
Mobile Patterns and are two really
great sites that provide some great examples, show what
other people have done, and lay things out.
Let me pull one of these up right now.
This is Mobile Patterns, but you could see here's some
interesting ways on what this company has done to provide
easy access to stuff for messaging.
And one of the things I really like about this, is they have
different ways that I can go in and I can say, hey, I want
to see what people have done for photo galleries.
I can see all sorts of different photo galleries and
see what people have done to create photo galleries.
I can get some ideas and I can go and create some neat and
interesting concepts.
Maybe I want to go and figure out what I think a pop-over
should look like.
Here's a big list of pop-overs. is very similar in that it's got
lots of great examples.
You want to get an idea what different
about boxes look like.
You can go through and you can see all these.
Just to get good idea of how should I make my stuff look.
It's a great place for you to go get great inspiration.
But in inspiration, you still need to follow some human
interface guidelines.
Both Android and Apple for iOS have a really great set of
human interface guidelines.
But there's one thing I really want to highlight here.
It's that, these are really fantastic for
those specific devices.
It makes perfect sense for me to follow the human interface
guidelines if I'm building an app that's only
going to work on this--
on my Galaxy Nexus phone.
But if I build something that follows the Android design
patterns, and somebody goes and uses it on an iOS device,
or a Windows device, it's just not going to fit.
It's going to feel awkward.
It's going to feel weird.
It's not going to feel right.
It's really important that we follow through on some of
those different design guidelines.
As well, there's some really great stuff.
Apple has some stuff for designing web content for
mobile Safari--
actually for not just mobile Safari, but Safari in general.
If you're building for web, they've got some
great content there.
And Microsoft even has some really great stuff around
Windows Phone.
I'd recommend checking out those.
But again, don't put too much effort into making your app
look exactly like one particular platform because
it's going to feel unnatural on other platforms and, at
some point, they're probably going to change the look and
feel of the platform just a little.
And all of a sudden you're going to look
awkward and out of date.
You don't want to duplicate the other platforms.
I tend to like to start with some of the boiler plates that
are out there, because I find that they're really useful.
They each have different purposes in life.
They each have different reasons for being and trying
to solve different problems.
I think my two favorites are jQuery Mobile and Bootstrap.
Bootstrap is the one that I tend to use most often,
because I find it's the most flexible.
Gives me the most ability to be able to do things, whether
I'm building something for a mobile website, whether I'm
building something for a desktop website, whether I'm
building something that's responsive and works in any of
those sizes.
But those are really important to me, to be able
to have all of those.
Bootstrap has fantastic responsive layout
capabilities, as does jQuery Mobile.
Checking out both of those-- really good.
But now let's jump into some of the more fun and
interesting libraries.
These are things that I think are really helpful, that
reduce some of the pain that we feel as developers and
really make our lives easier.
Fast Click--
the guys at the Financial Times Labs have been doing
some phenomenal work over the last couple of years, and have
really built a phenomenal mobile web app--
the Financial Times Web App.
It's just absolutely fantastic from a design and experience
It works offline.
It feels and acts and looks like a native app, even though
it's a web app.
And in fact, when you set it up and when you install it,
they encourage you to add it to the home screen so that
it's right there, easily accessible, easy
to get access to.
You've got a quick way to be able to go
and use those things.
But one of the things that they found was there were a
bunch of mobile web bugs, or there were things that didn't
behave like native apps on the web.
And they wanted to fix those.
One of the first things that they really started working on
was the Fast Click libraries.

And with the Fast Click libraries, the problem that
they were trying to solve is that on mobile devices with
touch screens, the browser says, oh
you touched the screen.
Well, if you just touch the screen, do you
want to drag something?
Or do you want to maybe zoom?
Or what are you going to do?
And so because of that, it sits there and
it has a 300 second--
wow, 300 second delay would be pretty crazy-- a 300
millisecond delay in terms of until it
fires the touch event.
So we want to get rid of that 300 millisecond delay because
it really is awkward.
In fact, let me pull up a little demo for you so that we
can have a look at what's going on.
Here we go.
I've got my iPad up.
And so I'm going to bring up this page.
And here's the Fast Click demo page that the Financial Times
guys wrote.
This top box that you see up here, box A--
box A doesn't use Fast Click.
Box B does.
Now, watch how long it takes for the box to turn green from
when I touch the screen.
You're going to have to sort of trust me to say, touch.
And it took awhile.
and it takes that like couple milliseconds--
well, 300 milliseconds--
from the time that I touch until the time
that the event fires.
Now they've solved that with a library that
they call Fast Click.
We've enabled Fast Click on this box here, B.
Watch as I touch it.
Touch, touch, touch, touch.
It's almost instantaneous.
Touch, touch, touch.
By using this, you can make your buttons, your touch
experience, feel much more responsive.
And the reason that's happening, like I said, is
that instead of looking for the touch end, they fire on
the touch--
let me try that again.
Instead of listening for the touch, they listen
for a touch end event.
When that touch end event happens and the user hasn't
moved their finger from the touch start, it fires the
touch event then.
Using this library is really easy.
It's only a couple of K .
It's pretty small.
And if you gzip it and include it in your library file,
really easy to go add.
But window.addEventListener, you listen for the load event
and then just put a new Fast Click on the body.
And that allows you to go through.
It will go through and find all of the elements on your
page that would register a touch--
buttons, and other things.
And it listens for those.
One thing I did find in some of my projects that I've
worked on, is that if you add a button after the fact--
after you've run that particular Fast Click document
body, maybe you're adding a button to the DOM or something
to that effect--
then you need to go and just add that Fast Click to that
particular element that gets added after the fact.
It doesn't automatically go and watch for new elements.
It only adds for the elements that are already there.
It's a really great tool for being able to make your apps
feel more responsive.

One of the big things that I've often run into when I've
been trying to debug is that there's no real console log on
the iPad and iOS devices.
They had it up until iOS 6.
They took it away in iOS 6.
And on Chrome for Android, or even Android browser for
Android, you don't have access to the debug console unless
you do any kind of remote debugging.
Being able to figure out, hey, what's going on in my console,
is a really useful thing to be able to do so that you can
figure out, hey, what's going on?
What's happening here?
Are things working?
Did I get to that point?
Are the values--
you guys all know what console log can be used for, so I
won't continue on that sort of thing.
But JSConsole is a really great tool that you add some
code to your application, and what it does is it captures
all of the console log events and it pushes them up to a web
service, so that you can watch up on that web service
what's going on.
Why don't we take a look at that for a sec.
I'm just going to bring up my page here.
And I've got a listener.
You can see here, all right.
And let's go to my iPad.
You can see here I've got a listener started.
And on the iPad, I'm going to start my sender.
As soon as I send that, it pops up with a
little dialogue here.
Let's just make this a little bit bigger.
The dialogue is a warning that says, hey, I'm going to send
everything off to another service.
Just a word of warning, remember to remove this script
before you deploy this.
Go back.
I'm going to click OK on this.
And sure enough, you notice a whole bunch of things
went and fired off.
What I did is in my application, I actually have
it go and show me what the screen width is, what the
height is, what the device pixel ratio is, so that I can
understand, hey, what's going on in my page.
And sure enough, I've got a little loop that fires every
about two seconds or so.
Let me actually kill this so that we can see
what's going on here.
But you can see that I've got all of my remote console logs.
My screen available width is 768.
My available height is 1004.
It gives me that insight into what's going on with my
It gives me the idea that, hey, I can go and understand
this stuff.
Now, one thing to just a note on this, is that once you use
a particular key, you can't use it again.
Particularly, if you're doing some testing, you'll use the
key, and it'll say OK, great you've used it.
You try and use it again, it's not going let you.
That's a security precaution meant to make it easier--
meant so that if you do accidentally leave the library
in there, you're not going to leak sensitive customer data.
One thing to note in there.
Don't use this on anything where you might have sensitive
customer data, because you are sending all of your
console.logs over HTTP clear text.
You're just sending them up to somebody else's service.
And potentially, there's people who could be listening
or doing not nice things with those things.
Let's jump over to HammerjS.

Because if you're building mobile web applications,
you're definitely thinking about touch, because touch is
just one of those really cool things that is really
important to be able to use.
And understanding--
touch, you tap something, or something like
that, that's easy.
But if you want to be able to handle gestures--
maybe you want to do drag to delete, maybe you want to drag
to move something around a page, maybe
you want to do anything--
handling those, you could write it yourself, absolutely.
But why write it yourself when someone else has already
figured out all the intricacies?
They've figured out all the little details on how to make
things work properly, make them behave in the right way.
HammerjS is a great library that you can use in order to
simplify some of these things.
Let's pop back to our demo here for a sec.
Sure enough, let's bring up HammerjS.
Here's my page with HammerjS, and it says you can touch me.
If I scroll across.
It says dragging.
And it tells me when we're also
completed, so it's dragged.
I can tap--
single touch.
I can double tap--
you tapped me twice.
I can do a pinch zoom, so that you can maybe zoom something.
It gives you a full set of tools that you can quickly go
in and be able to understand how you want to add things to
different elements.
You can drag, like I said.
It's a really powerful library that's really
only about 2k in size.
It's really easy to include, really easy to go add to your
applications, and it really doesn't add a lot of work or
anything like that to go add.
I, a couple weeks ago, decided I was going to add swipe to
delete gesture to one of my applications.
And I found it really easy to do.
I used the on drag start to notice--
actually, no I didn't use on drag start.
Let me rephrase that.
I used on drag, which fires as you move across.
I used the on drag event firing to change the position
of my elements.
That way, as you dragged it across, it
moved across with you.
And then I used the on drag end to check to see how far
the user had dragged the event or the element.
If they dragged it past the 3/4 mark on their page, I said
OK, great you want to delete this.
And I deleted the element.
But if they didn't drag it past that 3/4 mark, I said OK,
no problem you obviously don't want to delete this.
And I set the left back to zero.
I also used a little bit of CSS transition.
That way, the element swung back in a nice maneuver.
Worked really well.
Provided a really great user experience.

Lawn Chair is another great library that I like to use.
It does a bunch of things and normalizes
storage on the client.
One of the things that I've often had a bit of a challenge
with is what different index and data stores are available
on the user's device.
Well, does the device have IndexedDB?
Does it have Web SQL?
Does it have local storage?
Does it have session storage?
Which one's best?
Should I use local storage?
Because there's been a whole bunch of articles recently
saying don't use it because it's really, really slow.
But then earlier this week, there were a couple articles
that said, no use it, absolutely.
It's really fantastic.
And the only time it's slow is that very first read where
it's a couple of milliseconds.
Now, the one reason I would recommend not using local
storage or session storage for your applications is because
it's synchronous.
You can make it asynchronous by wrapping it
in a set time out.
But most other storage mechanisms that are available
for the web-- in fact, almost every other storage mechanism
available for the web-- is asynchronous.
That means you're going to go and say, get me this
And then when you've got it, call this call back and give
it this information.
By using something like Lawn Chair, Lawn Chair's really
smart in that it goes, OK great, you're telling me that
your preferred provider is IndexedDB, but if you don't
have that, I should use Web SQL.
But if I don't have that, I can use local storage.
And if I don't have that, I'm going to fall back to
something completely different.
It gives you a really nice fall back, an ability to
specify your preferred order on which way things fall back.
That's one of the things I really like about it, in that
it just gives you that real easy fall back ability.
And it abstracts away all of the implementation details for
each of the services.
You don't have to know, oh crap, does it do this, does do
this, how do I do this?
It just works.
I don't have a demo for it because it's not really the
most sexy thing to go demo.
Like ooh, look, I can go store something.
Oh look, I can pull it out of a database.
Really, that's one of those things that, eh.
But when you do get it to work, it's pretty awesome.
And it's a good way to be able to go and grab access to some
of these things.
High DPI Displays is another really useful one that I think
is definitely worth mentioning.
Because there are a lot of tools out there today, in
terms of how to go use those, what you should do when you
need to use those, or anything like that.
So there isn't an easy answer today.
Lots of browsers are working on things.
The W3C is working on a standard.
But there are a couple of options.
The first thing I want to mention is using the--
sorry, excuse me--
using media queries in order to go specify how you want
your images to be produced.
In this particular case, we've got media-only screen and
minimum device pixel ratio of 1.5--
1.5 being a high DPI screen, a reasonably high DPI screen.
Great, go use this as the image.
If you're not a high DPI, it would go use something else.
There's a really easy way to be able to go do those for
background images, or images that are placed as
background on pages.
Image-set is the second one and it's only available in
Chrome and Safari today in WebKit browsers.
But I expect to see it coming in future browsers.
That's the primary reason why you see a vendor prefix there.
But with image-set, what you can do is in your CSS, you can
specify, all right, well, here's the URL to my image for
one device pixel ratio devices.
But for other images, where maybe it's 2x, 1.5x, whatever,
you can specify which image you want it to use so that you
can say I want you to use the 1X, I want you to use the 2x.
So that's something that's available today.
Again, that's specified in CSS, so that's not going to
work beautifully well for images that are dynamic or
images that are stored sort of as actual image
tags on your page.
For documents that are stored as images in your page-- let
me hide myself here so that we can actually see
all the text here--
what this would be is using the source set.
With source set, you can actually specify different
images for different properties.
It's kind of like using the video tag where you have a
source element, and you can specify different sources for
different properties.
Maybe you've got different video formats or
something like that.
It's the same concept behind source set on the image tag.
You specify here, I want-- this is my high-def image,
this is my low-def image, and what's going on from there.
A quick easy way to be able to go and use those things.
For best practices on this, there's a lot of things that a
lot of people are trying these days.
The number one thing that I would call out and say, that
image replacement--
using some of the JavaScript libraries that people are used
to using to go and do image replacement is generally
frowned upon.
It's a performance hit.
You start downloading one image and then you go and
replace it, so you end up downloading more.
It's just generally not the best practice.
Instead, using vector images and CSS styles for maybe
gradients or wherever you can specify vector images,
definitely use that.
If you need to put images in your page Boris Smus, one of
the guys on the Chrome [? dev ?] team, has a great
article on HTML5 Rocks that he compared taking a high DPI
image and compressing it a lot, versus a high DPI image
that wasn't compressed a lot, and compared the file size.
And actually found that it's to our advantage as web
developers to use high DPI images and use a higher
compression ratio.
They more often and than not tend to be smaller in byte
size, but also end up being as high quality or beyond
perception in terms of the degradation in quality that
you're going to see if you take a 1x image and you make
it twice as big--
as well, using some of the font icons, or icon fonts like
Font Awesome and other stuff,
There's a couple of other things I just want to point
out for today.
This and this are two very different things.
If you think about your mouse or a touch point on a mobile
device, they're very different in size.
And depending on how you look at some of these things, it
becomes a bit of a challenge.
Let's just pop over to the demo for a sec.
When I first made this page, if you look at some of the
text here, I had had just text links as ways to get over to
different places.
But I found that it was too small to click on.
Instead, I decided that, for this particular case, it would
be better to use buttons because they're easier to
click on, they're larger, and for my mouse or for my finger,
a much easier thing to be able to go use.
Avoid tables, relative positioning, absolute
positioning, floats.
Headers and footers--
use position fixed so that it goes up at the very top.
And if you want to do scrolling inside an element,
set the overflow to scroll so that it goes
to the right place.
And if you want the inertial scrolling, like the stuff that
you're used to when you scroll through on a native app, you
can add this WebKit overflow scrolling touch.
And I believe this also works on some Chrome Mobile as well,
in that it provides a really nice scrolling experience.
I have couple of favors to ask of you guys.
And if you have questions, please be sure to post them in
the moderator.
The link's down there at the bottom.
But my big request is, help support your
local open device labs.
We need more of these.
There are so many devices out there that people are using.
And to be able to, and need to, test your devices across
that plethora of different devices around the world, we
need more people to help support them.
If there's not one in your community, start an open
device lab or find somebody who can.
If you have older or unused devices, donate those to your
local device labs.
Here in New York, there's one in Brooklyn.
Hopefully we can get one started here in Manhattan
sometime soon.
But donating your devices to these labs so that they can
have more devices to test on.
So that when you need to go and test your app on a
particular screen or a particular device, that device
is available to you.
You can go get it.
You don't have to go and figure out ah, crap,
where can I do this?
How can I test this?
You have a great set of devices that you can use.
Finally, we need your help.
Don't accept the status quo.
Don't accept that the mobile web--
it's OK for it to look crappy.
It's in our hands as web developers to
make it look better.
If you find bugs with Chrome--
Chrome for Android or Chrome for iOS--
go to and tell us about it.
Let us know.
If there are things that bug you about Chrome for iOS or
Chrome for Android, go see if there's already a bug there
and star that bug.
We look at those stars to know how many people this is
affecting and how many people are really
passionate about this.
Build some mobile Chrome experiments.
There aren't a lot of them there today, but this is your
opportunity to go build something cool that's just
neat, that works amazingly well on the mobile web, on
mobile devices-- whether that's a tablet, whether
that's a phone.
And submit them to

Start an open device lab in your area like I mentioned.
But the mobile web really is what you make of it.
As developers, it's our
responsibility to build beautiful.
We can build crappy but that's not fun and nobody's going to
enjoy that.
Building beautiful, it really is up to us.
With that, I want to thank you guys very much.
I'll open it up to a couple of questions now, and see what
you guys are thinking and go from there.
So one of the questions that I saw earlier on our YouTube
comments was somebody wanted to know, oh hey, I
don't have a Mac.
Can I still do some of this mobile web development in
terms of using CodeKit, using some of the other stuff?
You can't use CodeKit unfortunately, because it is
But Sublime, you can absolutely use.
It's available for Mac, Windows and PC.
You can get equivalent apps.
I don't think I've seen any personally that are equivalent
to CodeKit, but I'm sure somebody's got one somewhere.
I'd check that out.
All right.
I think that's about all the time we have for today.
I want to say thank you very much for joining me, and I
hope you learned something interesting.
Next week, we're going to be diving into
testing on mobile devices.
This is a really interesting piece because, how do you do
remote debugging on a mobile device?
How do you do debugging when you're trying to figure out
how does this work?
We'll try and take a look at how to remote debug on iOS, on
an Android, Chrome for Android.
As well potentially, if we have time, we'll try and look
at Firefox and Opera.
All of those guys have mobile remote debugging available.
We'll try to take a look at some of those.
And we'll dive into some emulators and other things
that you can do to really take your device and mobile web
development to the next level.
So with that, I want to say thank you very much.
Hope everybody has a wonderful day, and
thanks for joining me.