JAKE: Yeah, let's not
talk about {opt-in.}
MATT GAUNT: [? Flash--
?] I punish myself.
That's secretly what it is.
JAKE: So here he is again.
It's Matt Gaunt.
[APPLAUSE]
MATT GAUNT: Thanks, everyone.
So this talk is going to be
about cross-device development.
Like Jake said-- if my
clicker would work-- my name
is Matthew Gaunt.
I have this wonderful photo
thanks to Addy Osmani.
He took the photo.
He then decided, I know what.
I want to exercise
my Photoshop skills
and make him like Popeye.
So thank you, Mr. Osmani.
You could argue that
there shouldn't really
be a need for this kind
of talk in the sense
that one of the
beauties of the web
is the fact that if
you've got a browser,
it does mean that you can
sit there and develop for it.
But the biggest issue
with mobile devices
is you can imagine a
scenario like this.
This poor guy is
sitting there thinking,
I'm going to develop
for all of those,
and it's going to be great.
By his face, maybe not so much.
And I think the main reason
that it becomes a bit difficult
is you have this
environment on your desktop
where you're developing.
What is the road to
go from your desktop
to supporting all these devices?
What are going to
be the obstacles?
How do you get around them?
How do you essentially
smooth out that path?
And we've all seen that whole
dragging backwards and forwards
the window.
And I think, generally, people
will fall into two camps
pretty quickly.
They think, no, that's
not mobile development.
That's awful.
How could you claim that?
And the other side will be
like, well, it's not that bad.
It just helps you get there.
My opinion is it helps
you focus on the content
rather than necessarily
devices, which
is the right way of doing
things in my opinion.
But at the same time, you
can imagine a scenario
like this, where if
you take a Nexus 4,
you put it in
landscape, it's sort
of the same size as a
Nexus 7 in portrait.
And realistically,
and I don't want
to give users the same
experience on both
those scenarios
based off of width.
And then you can
start, obviously,
doing media queries
with orientation.
But unless you
actually sit there
with a device in your hand
playing around with it,
the incentive to go and do that
extra work may not be apparent.
So we get to this point
where we say, well, OK.
I need to support these devices.
And this looks like a
nice, structured way
of having all your devices,
a nice, beautiful wall.
But it's still daunting
as to how you can actually
utilize this and
develop in the same way.
So for me, I still
break things down
into three buckets
for how I like
to approach these
kind of things.
Number one is the
iteration speed.
When I'm developing,
I want to be
able to get a fast turnaround
over what I'm doing.
The second one is launching.
And that sounds a
bit insane, the fact
that I'm going to tell you
how to launch a browser--
tap that little icon--
but I'm going to.
And then there's emulation.
As {Mr._Paul_Archer} is showing
you, there's already one tool.
So, iterations-- for me,
one of the main reasons
people like tools
like Live Reload
are the fact that you don't
have to hit this icon.
And it's insane to say
it, but there are still
people who are constantly
just hitting Refresh.
I watched one guy who had made
a change in his text editor
and went to Chrome.
He hit a plug-in that
would clear the cache,
then hit the Refresh button.
And he was doing
that for each change.
And I was just like,
what are you doing?
Just open DevTools.
It clears out the cache.
And then use Live Reload, and
then you don't touch anything.
And for me, I use
Grunt for a build tool.
But one of the
nice things is you
get a load of these
extra modules for free.
And one of those that
I literally rely on
is Live Reload.
So if you're not
familiar with Grunt--
I think there was half
that maybe used it--
it's essentially a way of
pulling in third-party modules
and tasks that will essentially
perform some action for you.
So the main one for Live Reload
is this Watch task right here.
And basically,
what this is doing
is saying, whenever a file
changes in my file system,
I want you to perform
certain tasks.
So here we've got
our Compass task.
And whenever a SAS
file changes, I
want you to run
the Compass server
and then run this
Autoprefixer task.
Now, I loved Flexbox when
it first started coming out
and I was playing with it.
The thing I hated
was the fact that I
had multiple versions with
multiple vendor prefixes
that I had to deal with.
Autoprefixer just
took all of that away,
and I've literally
never looked back.
So once we've got
these other tasks that
have run through and
changed whatever we need,
we have this Live Reload task.
Now, what Live
Reload will do is it
will inject a
script into my HTML.
And then, basically, it will
start running the Live Reload
server in the back end as well.
So what that means is
whenever I make a change,
it will tell the
browser to update.
So that's definitely
not what I want.
There we go.
So what that means is as
soon as I come into here,
I can start making my
page look beautiful.
Yeah, there we go.
And obviously, like I said,
it's not just necessarily
SAS and everything else.
It'll start changing files when
it comes to JavaScript as well.
And this is great because
it's not just something
that you have in desktop.
This applies to mobile as well.
But you could be quite
fooled into thinking, well,
that all sounds good and great.
But that Grunt file and all
the stuff that you've done
is kind of horrible.
And I'd completely
agree with you.
If I were to write that, I would
fail miserably and probably
spend several hours
crying, making
every single task play nice.
And it's at that point you
can use something like Yeoman.
Who's heard of Yeoman before?
OK, a lot.
Good.
For those who haven't,
Yeoman is essentially
a tool that helps you
scaffold out a new project.
It gives you a good
set of defaults,
and it can also ask
you a set of things
that you might
want to add in that
is specific to your
personal taste.
And the main reason
I like Yeoman
is because it can touch on the
whole life cycle of your app.
It doesn't necessarily
just have to be
build or specific
tools that you like.
It can actually touch
on a number of things.
And when we were first
talking about Yeoman and web
development and
whether it should
be mobile first or anything
else, we sat and said,
well, do people want a load
of tools specific to mobile?
And if they do, what are
those tools going to be?
So me and Addy, we came
up with this notion
of, well, what I
really want to do
is basically have
a mobile builder
and find out what tools
people actually want to use.
So we came up with
the mobile generator.
So the way you work with
Yeoman is you say yo and then
the project you want to scaffold
out, so in this case, mobile.
Yeah, there we go.
Brief moment of fear
where I thought the demo
was going to fail.
So the kind of things
this gives you is it
will give you first a choice
of whichever framework
you want to build
with, so whether that's
Bootstrap, PureCSS,
TopCoat, Foundation.
It will then ask
you whether you want
to include any boilerplate
from that framework.
So something like
Bootstrap, it comes
with that canonical,
responsive design.
It will also add in a task that
could do the srcset for you.
So it will re-size the
images, create the source.
If you've ever come across
FastClick from FT Labs,
it's designed to remove
a 300-millisecond delay
in some of the browsers.
Although that's going
away pretty fast
with Firefox and
Chrome, at least.
It can also add in a task for
PhantomJS and CasperJS, which
it's a way of essentially taking
your web page, start a server,
and then basically change
the viewport for you
and then create a set of images.
So that way, you get a really
quick turnaround as to what
your site looks like across
various devices-- well,
viewport sizes.
Browser Stack testing.
The idea with this is you could
just go Grunt, open Nexus 5.
And then it would just go to
Browser Stack in a new tab
and open up a Nexus
5 emulator for you
or whatever it might be.
RequireJS support,
converting images to WebP,
polyfill for async
localStorage, also
some boilerplate for
the Fullscreen API.
It's interesting seeing what
people are trying to do around
this, because you
need user interaction.
If you can get these
to scroll and then,
as soon as they start
scrolling off the URL bar,
then kick in Fullscreen
API, this just
simplifies it for you.
And the last thing
we offered developers
was, if you were using
Modernizr to basically help you
with feature detection,
it's nice in development
[? stage ?] just to have all
the tests you could want.
But at the same
time, good practice
is you sit there and pick
the tests you actually need
and clear it out afterwards.
And there's a task
exactly for that.
I'm not going to build it,
because it takes forever
with MPM.
But the point of
this is the fact
that, with Yeoman,
it exposes you
to a new kind of
workflow in the sense
that there's a load of tools
out that you can use and just
basically get at
your fingertips.
Why haven't you
gone full screen?
There we go.
So if you haven't
checked it out,
it's well worth just
playing around with it.
You can get it from MPM, and
it has a load of good features.
Now, Live Reload
isn't just Grunt.
There are a number of other
tools out there that do it.
One of them is Ghostlab.
Now Ghostlab has this
really nice other feature,
which I'm going to give
you a quick demo of.
There we go.
So one of the nice
features with Ghostlab
is you can drag a directory.
It creates a server for you, and
it will do the live reloading.
But one of the
other cool features,
if I launch just
a demo page, which
is just a plain HTML spot--
do I have this on my tablet?
Yes.
Let's move that out of the way.
So you can sort of
see the tablet there.
Now, one of the
nice things here is
it starts syncing up what
I'm doing on my desktop
with what's going
on on the tablet.
Now, you can imagine
a really nice scenario
where, if you're testing
across multiple devices
and you want to see what the
entire UI of all those devices
looks like, you can just
do it from your desktop.
And it's not just scrolling.
You can sit there and type away.
It'll do clicks and options.
And it's just a really
nice, pleasant way
of just syncing up
multiple devices.
So I think whatever you
end up using for tools,
I think it's worth considering
how fast you can actually
get a turnaround over
what you're doing.
So the next thing is launching.
I spared you from it with that
demo, where I painfully try
and type in an IP address
and then fail miserably.
But out of interest,
of all those people
who test on multiple devices,
who also then regularly tests
across multiple browsers
on those devices?
OK, a handful of people.
And you can imagine why, right?
It's a pain in the backside.
And the main reason
for that is you've
got to go across each
of these devices,
select each of the browsers
that you want to test against,
and then repeat for
the next version
if you want to test across that.
And then, also, you've got
to enter in the IP address.
And you could argue,
well, you put a bookmark.
Or hopefully no one
touches the devices,
so when I open up that browser,
it's pointing to my machine.
And no one ever touches it,
and it's all fine and dandy.
But you've still got to
touch the browser anyway,
and it's a bottleneck
for the number
of devices you test against.
So I came up with this thing to
scratch that itch for myself.
And I'm hoping that other people
will find it helpful as well.
And it's called Mini Device Lab
because I have no imagination
whatsoever.
So all it is is a small
Cordova application
with a couple of plug-ins
that I've written.
Can I position
this in a sane way?
Kind of, but not really.
OK, so I sign in with Google+,
and what that's going to do is
basically generate an
account for this device lab.
Please work.
[UNCOMFORTABLE HUMMING]
[LAUGHTER]
MATT GAUNT: I knew this
was going to let me down.
I've been sitting
there going through it.
There we go.
No apps, no devices in the lab.
So I hit sign in
on both of these.
It won't ask me to do anything,
because Google+ Sign-In has
this nice thing where you
don't have to do it once
you've agreed once.
So once you've done
that, you literally
don't need this
app anymore, so I'm
going to fling it
into the abyss.
Hit Refresh on my desktop--
oh, that's definitely not good.
Cool.
There we go.
So now I've got two devices.
And I've got a
couple of browsers.
So if I hit Launch on
this-- damn you, Nexus 10.
See, what's going to be really
bad as well is the Nexus 10
is going to kick in as soon
as I start doing other stuff.
There we go.
So the idea with this
is I enter in a URL,
and it launches across the
devices in that Device Lab.
Now, the nice thing
with this, if I go back
to our lovely Ghostlabs demo
and I want to launch it in,
let's say, Firefox--
damn you, Twitter.
I'm presenting, and you know it.
So if I go and select Firefox
to launch across those devices,
it not totally
clear, but the tablet
has launched Firefox
with the URL.
And the Nexus 4 has
gone to the Play Store
because it's not pre-installed.
So even though you haven't
got the browsers there,
it simplifies it a little
bit to some extent.
And the idea with this was
literally to get to this point
where it encourages you to have
multiple devices that you can
actually develop against
and actually support
the browsers that
are on those devices.
At the moment, it is
100% in alpha stage,
as you saw from my praying to
the gods that it would work.
But it's all open
sourced on GitHub.
You still have to sort
out your own App Engine
instance and stuff.
But I'm hoping to get to a point
where I can just release it
on the Play Store,
and it'll have
iOS support and other
stuff, because it is just
a Cordova application.
I just need to do
the plug-in bit.
And the main thing with as
well is a lot of the tools
out there say, enter
in this IP address.
And I wanted to
get to point where
it will work with those tools.
They don't get in the way.
So that's what I was
going to say on launch.
So then the other
thing is emulation
with emulators and
all the other stuff.
And I expect most
of you might be
sitting there thinking,
well, hang on.
You've talked about
DevTools emulation.
Now you're talking
about devices,
and now you're talking
about emulators as well.
Why do I need all these
different options?
What the hell are
you talking about?
And they all have pros and cons.
Devices, the big con of these
is you have to buy them.
Nobody wants to spend money
on these kind of things.
But at the same
time, you need them.
You get close to
what the user is
going to be experiencing
at the end of the day.
And arguably, they can
be easier to work with
compared to the other stuff.
DevTools Emulation, it's great
for sanity checking what you're
going to end up
giving to a user.
But the problem is,
you're still in Chrome
on the desktop [?
browser. ?] You don't have
feature parity with
Chrome for Android.
So if you imagined
back in the day
when WebRTC may have come
to Chrome for desktop
and not Chrome for
Android, it will still
look like you've got
WebRTC on the Nexus 4
in DevTools Emulation.
You install it on the device,
and obviously it will fail.
But it is still awesome for
the fact you're testing the UI.
Emulators, they're
incredibly useful when
you need to test a particular
platform and, essentially,
specific configurations.
The biggest problem
is sometimes they
can be a bit of a
faff to sort out.
Performance doesn't necessarily
match the device, either.
IOS is super fast,
and you might find
you have performance
issues on the device.
Android is notoriously
bad out of the box,
just when you start using it.
And the other thing
is there is no--
I should have said this--
no app stores, which
means there's no evergreen
browsers that you
can get into those emulators.
I think Firefox
have public builds
available for their APKs.
We have Content Shell,
which you can actually get.
And it's basically like Chrome
for Android, the rendering,
but without any of the
nice, Chromey bits.
The link at the bottom
is to an article
Paul Kinlan had put together.
And basically it's
a shell script.
It'll look at the latest
part of the source tree
with the latest build
of Content Shell
and then install
it to anything that
is connected to
ADB at that time.
So if you've got an emulator
open or a device connected,
it'll install Content Shell.
So I'm not entirely sure
how to pronounce this,
so I'm going to say it's
Intel XHam to be official.
But I'm going to
call it Extreme Ham.
This is essentially something
you can install in our machine
from Intel.
And basically, if you use an
Intel-based Android emulator
as well from the SDK
Tools, it basically
allows the emulator to
get access to the CPU
and run a bit faster than
what you would normally get.
The other one, any of you guys
heard of Genymotion before?
That guy has, [INAUDIBLE].
So Genymotion is a
company which is basically
building versions
of-- I did have it.
Oh, there we go.
So they basically take
builds of Android,
and I believe they put it inside
a VirtualBox-style environment.
So it runs quite smoothly.
Now, you've still got that issue
it doesn't have the Play Store,
but it shows up in ADB.
So if you've got
the APKs again, you
can just install it on there.
It's quite a nice option.
I think there might be
some stuff around the kinds
of processor that it's
running, as in VirtualBox.
But it's quite speedy.
And if you just need to
support the Android browser,
it's already there.
So it might be a slightly
nicer way to support that,
save you pulling your hair out
and looking like Paul Lewis.
So there are cloud-based
emulator options as well.
I'm sure you guys
have seen this.
Browser Stack focuses more
on the interactive playing
around with of emulators.
They've got a much
wider range of devices
than I've seen
anywhere else in terms
of emulating different
viewport sizes
and resolutions, et cetera.
But it does still suffer with
the no evergreen browsers.
Sauce Labs is another one.
Both of these have
local tunneling support,
so you can just route
your local server to them.
Interesting thing
with Sauce Labs
is they have interactive
session support,
but they focus more towards
the automated testing.
So they have web driver support.
And the nice with that is,
if you run through a script
and tell it, say, enter in this
text item, click these buttons,
scroll here, it
will actually record
a video of that
entire session, so you
can review it at the end.
And then the last one that
I was going to talk about
was Device Anywhere.
The nice thing with what
these guys are doing
is basically you're controlling
real devices there and then.
They basically allowed
you to control them
remotely, which means
you're essentially
getting the actual ROMs that
come with these devices--
so any browsers
that come with them.
And if you're finding
you've got quirks
that are really
specific to one device,
this might be a really
nice way of finding out
what those are without actually
needing to buy the device.
The one and only
criticism of this
is they are actually
real devices, which
mean people go into
Settings and say, hey,
I'm going to put a
password on this phone.
Enjoy.
There is a Help box on the
side, so you can hopefully
just get it fixed.
But it takes a while.
So if you were pushing
something out the door
and then someone goes,
can you just check this?
That would be a bit
disappointing at that point.
So you've got all
these emulators,
and it's all super awesome.
And then you come to
debugging a problem.
So there is Weinre.
It's one of those things that
you wish just didn't ever
exist, but at the
same time you love it
because it's kind
of a last resort.
You can get it from MPM, install
it, and just add a script tag,
and it'll just start
basically giving you
really basic debugging.
So if you've got nothing
else, give it a go.
For the Android web view,
there's also this JSHybugger.
And it does some really
quite clever stuff
that essentially allows
you to debug the web
view using Chrome DevTools.
So I have my ever useful
Touch Example application,
which I can show you there.
And I drag that down, and
the little Android pops up.
That's literally all it does.
But if I go into Chrome Inspect
and fumble about a bit-- there
we go-- you should see
that-- oh, come on-- you
get this JSHybugger that
comes up in about inspect.
So this is just the
everyday Android web view.
But one of the really
nice things with this
is you can go in, as
you would before, change
various aspects of
the entire thing.
I accidentally fumbled
around and found this,
but you can actually
put breakpoints
into the JavaScript.
So that point, I've put a break
on changeState, ENDING_TOUCH.
So the minute I
left off, it just
starts going, hey,
what do you want to do.
But it comes with the whole
set of really nice features
that Weinre simply doesn't have.
So if you're getting
to this point
where Android web view and
Weinre just doesn't work,
it's definitely worth
checking JSHybugger.
And there's also a
plug-in for Cordova.
So you can literally
add the plug-in,
and you get all of that set up.
The last thing that I wanted
to talk about in terms
of emulation is the
notion of, basically,
throttling your network to see
what a user might be getting.
This video is an old
version of my website,
and essentially,
one side has Wi-Fi.
The other side
has 2G connection.
Guess which one is which?
And the really nice
thing with this
is it's easy to forget
that, one way or another,
network speed is going
to be a real big variable
for your users.
And what I particularly like is
the notion of if you're showing
text and it's actually
appearing really fast
but you're basically waiting
for a heavy background image
to load up, you can just
apply a dark background,
and hopefully things
will appear a bit faster.
This is a nice way
of just giving you
access to see that that's
going to have an effect.
Same with if you actually
spend time smooshing down
all your resources.
You can actually see
the benefit of it.
The link at the bottom is
for Matt Gemmel's blog post
of network link
conditioning, which is OSX.
But Charles Proxy seems to
be the cross-platform option
for throttling
your network speed.
There we go.
So that, for me,
is the whole suite
of things for
mobile development.
Find a flow that works
for you on desktop
and then gives you the extra
tools that you want for mobile.
I'd say consider having a
little look at Device Lab
and having a play with
it because, for me, it
was one thing that really became
apparent as being an issue.
And then emulation,
just try and get
yourself set up
with the emulators
that you know you're
probably going to want to use
and just try and treat it
as a part of your workflow.
So that's all I
was going to say.
I've included-- there we go--
some links, the GitHub link
for the Mini Device Lab,
Mobile on HTML5Rocks.
There's also my Google I/O
talk on modern workflow,
and then Addy Osmani has
done another awesome set
of presentations on
modern workflow as well.
So that all I wanted to say.
And thank you very much.
[APPLAUSE]
JAKE: Excellent stuff.
So it's now another break.
The breakout sessions
that are happening later,
they've been selected
based on your votes.
If you want to know where
they are going to take place,
you can go to
bit.ly/cdsbreakouts.
But they're also listed
on the board outside,
so you can just
have a look there.
Some of them are going to
be in here, but some of them
are going to be elsewhere.
So you can find out which
ones you want to take part in.
So Paul and Matt are
going to be upstairs doing
Q&A during the break.
So if you have any questions to
ask them, they'll be up there.
And then we're back at 3:30
when the Chrome and Android
leads are going to be--
