Google I/O 2012 - Fast UIs for the Cross-Device Web

>>Boris Smus: All right. Hey, folks, good to see so many people in the room. Can everyone
hear me fine? Great. So my name is Boris Smus. I'm an engineer
in the Chrome developer relations team. And this talk is called Fast User Interface for
the cross-device Web. So before talking about this, let me motivate the subject a little
bit. Who cares? And I care and you should care because this
is the current state of mobile internet usage compared to desktop internet usage. So you
can see the projected cross-over point for when mobile becomes more used, and this is
sometime around 2013, 2014. This is all internet use, so not just Web. The Web is currently
about 10% of all -- mobile Web is about 10% of all Web usage and it's been doubling every
year, so expect this to change very drastically. Note that I call the talk cross-device, and
not mobile, because the term mobile is a little bit overloaded. Does it include tablets?
Does it include other kinds of devices like TVs, cars, et cetera?
And what is the opposite of mobile? Stationary?
Desktop? Not clear. So I'm not going to jump into pedantic
discussions about this. Instead, clearly, this is not a mobile device, so this is a
desktop, and many people still think of this as the target for the Web. But, in fact, the
Web looks a lot more like this. We have a mass of devices that all access -- that all
expect Web content to serve correctly for them, tablets, SmartPhones, et cetera, it's
very complex landscape, and it's only going to get more complex and more interesting with
future interactions that can include gestural UIs, handtracking, full body tracking, et
cetera, or audio input. So how can we talk about this broad topic?
There are still a set of common issues that we need to tackle for all of these problems
that I've discussed. We have a wide variety of form factors, as you saw a couple of slides
ago. In addition we have CPUs and networks that are much, much slower and much less predictable
in many cases on mobile devices. We need to deal with new kinds of input, specifically
touch and multi-touch, and we have issues with developing when your host machine is
not your target machine. So I'll talk more about that, in addition. So this is -- these
are all issues, but they're also -- this is also a outline for the rest of the talk. So
let's jump right in into the form factor question. And how do we support multiple devices that
access our site? First extreme is we simply create one version.
And some people do this. Some of the examples of sites that do -- that take this approach
are shown here. We have -- you can see text that's not very clearly readable. It's very
small on a mobile device. Text that's being cut off because the developers didn't intend
it to be used on such a screen, or in this last example, we have actually two versions,
one of which says the device doesn't work on your phone, or the application doesn't
work on your phone. Sorry. So this is not a very good extreme to be at. The other opposite
end of the spectrum is to create a version for each device, so we have here a very incomplete
list of sound devices in the market and you can simply say, okay, let's develop a version
for each. You can see this has ten devices, there's probably hundreds, maybe thousands
of devices out there. It's simply not feasible to do this, especially if you take into account
the number of browsers that exists on some platforms. For example, Android supports a
wide variety of browsers. So we need to find some sort of middle ground, keeping in mind
this tradeoff that the more versions you create the better each one can be from a user experience
perspective but the more effort it will require. So the question then is where can we save
some effort? And how can we make this a -- how can we make
a better decision what to build? So we have two sort of axes to choose from.
We have platforms and form factors. Let's talk about platforms. So native platforms,
this is a bit of an aside, they provide human interface guidelines and UI frameworks, so
this is on the -- on the right, example of a human interface guideline for Android, it
provides a set of common UI controls and the corresponding UI framework makes it really
easy to build that kind of UI for a developer. So the point of this is to make it -- to have
developers fall into a pit of success by default. If you try to do this sort of thing on the
Web, as some people have, you quickly run into problems, so emulating native UIs is
a perilous path. It's hard to implement. You're going to be always slightly off and look and/or
feel, and even once you've done this painstaking effort that some people have taken, you still
have to repeat that same process on every other platform that you want to support. So
if you want to read more about some pour soul that did this, you should check out this guy's
blog post. It's very detailed and good. He goes into details like you can see a little
bit of diagonal artifact here in the CSS version of this platform. So that kind of level of
detail. So generally speaking platform differences vary -- platform differences are both small,
so we can have different styles for buttons, but some of them may appear bigger, for example,
the placement of navigation bar, the Android human interface guideline says to place it
at the top of the screen whereas the IOS one places it on the bottom. Fairly major change,
but it's important to note that these are differences that -- or, sorry, these are rules
that are meant to be broken, and in many cases are. So on Android many applications place
the tool bar on the bottom, whereas on IOS for example, on iPad the guidelines actually
say to place it on the top. If we look at form factor differences, though, these are
much bigger. We have completely different usage patterns, phones that you hold with
one hand, and tablets that you hold with two. Major variations in screen real estate. So
these form factor differences I would say trump platform differences, so as a first
cut, and I'm not saying that this is perfect for your application, we can consider having
multiple versions of our site, and compromise to phone, tablet and desktop, just as a starting
point. So how do we actually build this? We build this -- there's two possible angles
to come at it from. We can start from single version and make tweaks -- diversion tweaks
to that version, or we can say up front we're going to build three versions and serve the
correct one. So the first version, many of you are probably familiar with CSS media queries.
In case you're not, it's an easy way to tweak your CSS style sheets depending on properties
of your device. So here I have a media query which says if the screen is less than 1,000
pixels, then hide the side bar. So this is pretty straightforward, and is used to create
websites that look like this. So here is a German design magazine, and you can see, as
I resize the page, the styling changes subtly. You will see -- you'll notice also that Chrome
has a minimum size. Let me show you a cool trick that you can -- you may not know. I
can actually resize the page using the developer tools. Resize it back to the correct size
here. Switch over to Dev Tools, and I will override device metrics here and pick the
resolution that I want. Just set it to 320 by 480, and you can see I've sized it down
-- I couldn't use Chrome natively -- or sorry, I couldn't resize Chrome to be this small.
You can get a good preview of how these sites look like using this feature. But there's
limitations to this approach, right? We're talking here about a shared DOM, shared
JavaScript and simply tweaking the CSS. So if we want to make big changes between form
factors such as this example here where we have Gmail native apps for Android, you can
imagine the pain that you would have to go through to use this same HTML and create these
separate layouts. A lot of CSS tweaks, a lot of hidden content, a lot of conditional CSS
for the various -- for the two form factors. Also, since we have shared JavaScript in this
case, how do we load additional functionality? So one middle ground here, between these -- between
the two extremes of one version and separate versions completely is using media queries
in JavaScript, we can do this with the window of match media call, and this lets you evaluate
arbitrary media queries as in this sample, you can see I'm evaluating this media query
and I'm seeing if it matches or not. You can also listen for changes with this event listener,
syntax, and here in this example, I'm listening for the orientation media query, and as soon
as that changes, if I switch from portrait to landscape, this will fire, and I can respond
to that. It's a much nicer way of going about things using orientation change.
But if we want to completely separate the two -- separate the versions that we want
to create, we can take an approach like this. This is really simple code that basically
says default to a desk -- to the desktop version, then check for touch support, if there's touch
support and the screen is small, is there a phone version, otherwise if the screen is
large but touch is still enabled, serve the tablet. So here we need to figure out how
to know if there's touch or not. Right now there's not a really good way of doing this
on the open Web. So we can use modernizr or other feature detection libraries to do this
sort of thing. So modernizr.touch will return true if touch is enabled. But we have media
queries that are coming through the pipe. They're not implemented anywhere yet. We have
hover and pointer media queries which are used to distinguish between pointer or mouse
pointer type input and touch input. The other question here is how do we know what's small
enough? Where do we draw the line between phones and
tablets? So we can evaluate the media query, but where
do we set this boundary? So here is a -- on the right -- diagram of
various mobile devices and their resolutions in CSS pixels, so it's important here for
this discussion to remember that, CSS pixels are not the same as device pixels. CSS pixels
are scaled to the -- they're scaled by the device pixel ratio to be virtually sized,
essentially, so the history here is when Apple released iPhone 4, they had doubled the resolution
of both dimensions, creating four times as many pixels on the screen. So if they did
nothing about this, then sites would render at half size, so they introduced this notion
of device pixel ratio, and sites render the same way on iPhone 4 and iPhone 3, and other
device vendors have been embracing this and providing device pixel ratios sometimes of
2, sometimes of 1.5, sometimes somewhat irrational numbers so it's a little bit interesting and
you should definitely be aware of this -- this concept. So if we take a look at the diagram,
we can say, well, let's just draw the line at, let's see, 400, somewhere between 400
and 600, that's pretty straightforward, right? But we should remember that all these devices
have landscape mode as well, in which case width becomes height, height becomes width.
So the actual picture is something more like this, if we take a look at the max of the
two dimensions for phones and they're meant for tablets, so we can draw the line roughly
at 650 pixels, and this will work most of the time with some exceptions. For example,
some -- some tablets in portrait mode, in this case will get the phone version. So if
you're specifying multiple versions of your site, you may be sharing a URL or you may
have separate URLs. If you have separate URLs, then you can declaratively define all the
versions of your site in your head section, and you can do that with the link rel equals
alternate and the idea here is you specify the URLs and the associated media queries
for each of these versions. This is good for crawlers that are indexing your site so that
they can know which versions exist and to crawl them with these different settings.
So one thing that you might want to do is based on these versions that you've declared
up front, redirect correctly. So the Web doesn't do this for you, so I worked on a project
called device.js which tries to formalize this approach, and what it does is it parses
the link alternates in your head section, matches the media queries and then redirects
you to the right version, if necessary. So let me quickly show you how this works. So
I'll -- I'll load up a really simple application. This is a fake to do list. Now, if I send
it over to Chrome, on my phone, and switch it, switch the camera here, let me just load
it up... one second... all right. Okay. So I've -- I've loaded the same exact URL on
both devices, here I've been redirected to the phone version. Let me do that again. I'll
try loading to desktop version. Sorry. Hmmm... it's going to work, trust me. Could you guys
turn off your internet? [chuckling]
>>Boris Smus: I should have done that Steve Jobs thing.
[ Laughter ] >>Boris Smus: Thanks. Let's try this one.
The pipes are clogged. It's terrible. Ah, amazing. Watch this. It's loading. So the
same URL loaded a completely different version, so let me just show you for comparison here,
the desktop version, the phone version, so it's useful to still provide a fall-back mechanism
so that you're able to specify a different version if you prefer it, so device.js does
that as well, and here if I switch to layout -- landscape mode, I may actually prefer the
tablet version, so if I pick it, then I can override the default version that was served
to me and this will eventually load, so we can move on for now. So for more details about
this project, take a look at the GitHub page, and you're welcome to collaborate with me
on it, so that's the clientside story, so we've taken a look at both of these approaches,
separate versions and one shared version, but the client has performance penalties for
doing redirection, so if we do a redirect that costs somewhere between 100 and 1,000
milliseconds, on the server we can save on that redirection in some cases, so the only
problem with the server is we have much less features than we do on the client. We don't
have JavaScript. We don't have media queries. All we have is a user agent string, and this
string gets sent with every request, so the server can decide what to do with this. You
can see it's a bit of a mess, so this is what Chrome for Android user agent string looks
like, and this is pretty much as complicated as most other browsers. You can see there's
mentions of pretty much every single browser that has ever existed. I'm exaggerating. But
it's kind of a messy thing to deal with. Let me show you a couple of tools that can make
this a bit easier. Firstly, let me show you how pervasive this use is of user agent strings
on the net. So here is YouTube. If I open Dev Tools, and I'll turn off this screen scaling
device metrics feature that I had before. I can override the user agent, so why don't
I set it to Galaxy Nexus on Android 402, you'll notice the device metrics have been set for
me, automatically, based on a little database that you just send the developer tools, but
when I over -- when I reload the page here, now I've -- I've used a new -- I've reset
my user agent header and YouTube has sent me a completely different version of the page,
so just for comparison, this is the mobile version, and if I reload, I just the regular
YouTube version, it's a completely separate page, so many, many Web properties use this
service side detection and redirect you without you even knowing. So how do they do it?
Generally, they have some sort of device database. These are typically large databases of known
user agents and their capabilities and what device databases do is they try to find the
closest known UA and give you information based on your client. So a couple of them
are device applets in WURFL. They have drawbacks in that they're nonfree for commercial use.
They come in two flavors, typically, one as an API service, so you can make a request
every time you get a new client connected and ask a service somewhere else in the Cloud
what that user agent is, or you can set it up yourself, but it's not that simple to do,
so that's the state-of-the-art right now. And just to recap this multiple versions idea.
If you're separating your versions upfront, I would recommend to start with device.js
or some other similar solution in the client, measure performance overhead, see if that
performance of mobile or of clientside redirection is too high, and if that penalty is too high,
then switch to user side. So at this point you're probably thinking this guy is telling
me to create multiple versions of my app. This is terrible. I'm not going to do this.
And I am probably -- I'm thinking you're probably using a model view controller or if not, you
should be. So if you don't know what this pattern is, it is a way to separate the presentation
layer of your code from the structure and data logic, business logic of your application.
So with a cross-device approach, we can simply swap out the views, create form factor specific
views and serve them to the various devices sharing a lot of code. Okay. So that's the
story for multiple versions, single versions. Let's talk about some technical things about
building a great UI. Firstly, what makes a great UI?
On the Web, on the mobile Web, I would say single page sites are examples of that. Some
features of single page sites are limited zooming so the user gets text that's readable
immediately, they don't have to pinch zoom around. Fixed headers and footers. So content
that scrolls independently of one another or having a header placed that's fixed to
the viewport as opposed to content, and smooth transitions, animations between states as
well as just loading links. The most basic fundament mobile thing to do is the viewport,
viewport is a virtual viewing area that's scaled down to your phones or your mobile
device's display, and you can configure this viewport by setting the metatag called viewport
inside your head, and by default it's set to something ridiculous, like 980 pixels,
which is wider than most devices. You can configure it by setting its width to some
value, but if you set it to a fixed value, say 320 pixels, that won't work on many devices
that aren't 320 pixels wide and you will have the problem of when you switch from landscape
or from portrait to landscape, text will be scaled in interesting ways, so the best practice
here, at minimum, at minimum, is to set the width to be the device width, which evaluates
to be the current width for your device in its current orientation. And you can see without
a viewport the text is hardly readable on the left. With a viewport set as I recommend,
it's much more readable and everyone is happy. We can take this one step further and prevent
zooming entirely to sort of be closer to the user experience of a mobile -- native mobile
application. We can do this by setting initial minimum and maximum scale to 1. Just adding
that to the viewport, and know that you should separate these directives with commas, not
semi colons, a lot of Web samples on the Web use semi colons unfortunately, that is not
the standard thing to do. Also avoid user scalable equals no or supplement it with these
media queries, or, sorry, these content directives, because it's not supported in Chrome -- user
scalable, no, is not supported in Android -- other Android browsers and some other that
I've tested. So generally speaking, on the mobile Web, or on any Web, anywhere, really,
we want our animations to be smooth, and what this means is we want -- we want them to be
approaching the limits of human perception, so 60 frames per second is the animation refresh
rate above which we can't really tell the difference, so on mobile devices, this is
hard, because we have CPUs that are far less powerful than desktops, and because of this
we want to utilize hardware acceleration as much as possible because these devices come
with pretty powerful CPUs, so an example of this, to keep an element fixed in relation
to scrolling of content, the old style way of doing this, you would position something
absolutely, listen to scroll events and then kind of jitter as you try to reposition your
element every time you scroll. With position fixed, what you're essentially saying is you're
telling your GPU that this is a separate layer and composite in a -- composite it separate
from my CPU, and this is a much more, much less janky experience, and much more smooth.
Similar -- similar tactic applies for scrolling. Often we want sub element scrolling, so an
example here is Gmail. Or any two pane tablet application. So we have a list view and a
content view on the right, and we can enable independent scrolling of elements with overflow
auto, so this is old news. The new thing here is Webkit overflow scrolling.
This is a custom Webkit property which works on IOS and Chrome for Android and it essentially
forces hardware accelerated scrolling. Let me quickly show you a demo here. So I'll send
this -- these are beautiful Chrome ponies. Chronies?
I'm not sure. So I'm going to load this on the device. Mobile Web scrolling. I'm going
to load it on both devices. See which one is faster. It's going to be a race. So you
can watch them race. Anyway, while it's loading, the idea here is here with overflow hidden,
we see we can't scroll this region at all, I'm trying to scroll, we can't. Overflow auto
is scrolling, but with this Webkit overflow scrolling touch edition, we get really, really
fast scrolling on mobile devices, and this is what I'm trying to show you with this demo,
and unfortunately it doesn't seem to want to work. That's too bad. Okay, well, hopefully
it will load eventually. Okay. So scrolling. Often we want to go beyond scrolling and have
transformations of an arbitrary nature, animations, et cetera, and we still want this to be as
fast as possible. 60 frames a second. A key thing here is being able to position elements
arbitrarily on the screen. You would use position absolute to do this, but this isn't slow and
takes the software path -- or this isn't fast, and takes the software path, so the hardware
accelerated approach, which is very useful on mobile, is to use the WebKit transform
and the WebKit translate -- I'm sorry, WebKit transform and translate transformations, this
will trigger hardware accelerated rendering, especially with translate 3D, this gives a
hint to the GPU that, hey, you're doing something fancy and probably GPU mode should be enabled.
You can of course also do rotations and scales in this fashion, and it looks like our demo
has loaded, which is great, so let me switch back to the projector here for both screens.
We have our beautiful ponies, as you would expect. As I scroll hidden -- attempt to scroll
the hidden view, nothing works. Auto, you can see it's scrolling. But it's kind of janky,
I don't know if you can notice that on the projector. Compare that to this.
So this is what you get. [ Laughter ]
>>Boris Smus: Thanks, guys, this is what you get with the WebKit overflowing scrolling
touch. So on -- on Chrome for Android, this is the -- basically the smoothness that you
get, on iOS. You end up with -- with bounceback effects. And inertial scrolling as well.
So we'll do questions after. So as I go into the next section, I'm going
to preload this. So in addition to regular transforms, we can
do more advanced things. As I alluded, we can do 3D transformations, we can apply perspective
as well. Even arbitrary matrices, as in this example here, if you are into linear algebra.
And we can let CSS interpolate between the various animation states by using the transition
property and here we are transitioning between -- or say -- sorry, we're transitioning the
transform property, we're specifying its length of time, one second, and an easing function
as well. So these -- both the transition and the transform property need vendor prefixes.
So unfortunately the demo here is still loading. But ... I'm gonna ... just gonna hope that
it will load eventually. Okay. We'll get back to that. We'll have reason
to revisit. So I talked a lot about output here. Let's
talk about input. So for decades, 20, 30 years, more, more than that, this has been the input
mode of computing. Mouse and keyboard. And for quite a long time, even into mobile, we've
had very similar input devices. This is a pretty new Blackberry with keyboard and essentially
a mouse-like implement. So the current state is much more interesting.
Multi-touch pretty much changed the game completely. And one thing that I want to emphasize here
is touch is not the same as mouse. It's completely different. There's no hover state in touch.
There are multiple touch points. Input is far less precise. You don't get the pixel
accuracy of a mouse. And going forward, fingers aren't just coordinates, but they also have
shape and in the future we have all sorts of interesting possibilities. Pressure input,
haptic feedback, et cetera. Touch interface, as I'm sure you are all familiar with, have
essential building blocks. These are very simple gestures. Well, they range from simple
ones like tap and double tap to more complex one like pinch-zoom and rotation and we can
do all of these things on the Web using the touch events. So here we have touchmove, touchstart
and touchend. These are pretty similar to their mouse equivalents,
except instead of single coordinates, we have lists of touches on the screen. There's a
spec and you can read more about this. So one of the first things that you'll notice
is the browser has its own touch behavior. So like I mentioned earlier, pinch-zoom is
one of them, scrolling is another, tap switching as you probably saw in the keynote this morning
between tabs when you slide out from the side of the bevel on some browsers and you can
override some of these behaviors using the event prevent default call in JavaScript.
In IE it's a little bit different, you can specify touch action none, this is IE 10,
and you can even specify which specific kinds of interactions to disable. So you can say
enable no touch interactions by default or you can say only enable pinch-zooms or only
enable scrolls. Touch performance is an interesting topic
because as a Web developer, if you are not creating touch specific input, you end up
having events that are very heavily delayed. The reason for this is, for example, if you
do a double tap, the browser needs to decide if it's a zoom gesture or if it's a click.
So it waits for 300 milliseconds to wait for that second tap and then if there's no other
tap, it emits a click. So this is not great, 300 milliseconds is
definitely visible. You can see the delay and the -- the workaround for this is to use
touchend. Touchend will fire right away. As soon as you release your finger from the screen
and there's a nice guide about this on Google developer docs.
The other consideration here is with multi-touch, events often come in very quickly, much faster
than 60 frames per second. If you are touching your screen with many fingers, every single
finger will fire at whatever that rate is. And if you draw, as soon as you handle the
event, you will end up just having too many things rendering at the same time and this
will be very bad for your performance. So the solution for this is to create separate
handlers for input handling and create a separate animation thread. Or animation timer in this
case. So here I'm doing exactly that. I've got a
set interval call and the touch rendering code goes here. We can do even better in Chrome
for Android and Chrome and Safari and probably other browsers, we just requestAnimationFrame.
What this does is it's essentially a polite request to the browser for animation frame
so it aims to -- to fire roughly 60 to -- 60 times a second. But if something is overloading
the -- the machine or the device, then it scales back in an elegant way and you can
get as smooth of an animation as you possible can.
So with this, let me show you an example of that.
Style switch over. The demo is already loaded. That's awesome!
So for this particular demo, I'm using a requestAnimationFrame and the transitions and transforms that I
talked about earlier, to have this pretty smooth transition experience between multiple
screens. So you can see it follows my finger pretty closely. And when I let go, the transition
will fire. And the content just shows up. So this is using requestAnimationFrame WebKit
transforms and transitions. I also have another demo that I'm going to
start loading now. And I'll get to that in a second as soon as
it loads. So let's talk about some of the problems with
-- with touch input. The first is how do we handle both gracefully?
Right? What if we want to support both? This right now is not very pleasant. So what
we end up with is two essentially completely different input methods. Mouse and touch.
And what we might do is we can extract the positions of the relevant input. And then
just relay them to a common handler. This -- eh ... it's unnecessary boilerplate. It's
not something that you want to do every single time. So instead -- well, we'll talk about
solutions to this in a second. The other problem before I talk about solutions,
is gestures are difficult. You saw that list of gestures that I showed you that are common
for mobile devices, but doing such a thing without gesture events, which are only available
on iOS, is pretty hard. So here's a pinch-zoom snippet that recognizes the pinch-zoom gesture.
It's a lot of code. And doing this every time you want to pinch-zoom just is not reasonable.
So Microsoft has a -- has an input model that they're planning on using for metro. It's
called MSPointer. And the idea is to consolidate input, to consolidate mouse, touch and pointer
into one single type. And, of course, you can still distinguish
between mouse and touch with -- with an event property and it's a really nice idea. I like
it a lot. The problem is, with the current proposal,
it's essentially just another input mechanism to deal with. So now you have the mouse handler,
the touch handler and the MSPointer handler and it's just not necessarily great.
So pointer.js is a project that I worked on to try to consolidate this input problem between
browsers. Using a similar idea as MSPointer events except to take all of these different
event models and make an abstraction layer around them to make it really easy for developers.
So let me show you this in action. And here I have a -- a space shooter. And
actually let me show you this on the device instead. So this is a -- this is a demo that
was created by a friend of mine called Seb and you can see it's essentially just a -- a
space shooter thing demo. It's kind of neat because you can place your control anywhere
you want and then just shoot on the -- anywhere on the right side of the screen.
So this is using pointerevents. One of the benefits of this, it was initially using just
touchevents. So on the desktop nothing would work at all. With pointerevents, though, I
can have essentially the same experience in -- on both mouse and touch input. So this
is a quick and straightforward pointer example. Pointer.js also aspires to have gesture recognizers
on top of the consolidated input model. For more details about this, check out the project
page on GitHub. So let me quickly talk about mobile Web development.
One second. So I've been trying to show you some features
of the Chrome developer tools as we go. And, of course, the easiest path to getting started
with mobile development is to emulate it on the desktop. You don't have to deal with extra
devices. You don't have any of that headache of trying to -- having to touch around all
of the time. So it's nice. And I have shown you how to emulate screen size, how to override
the User-Agent string and let me just show you one more thing ... this is part of the mobile Chrome experiments
that you may or may not have seen. If you haven't seen it, check it out, it's on the
second floor in the Chrome booth. So this is a Chrome experiment. And it's essentially
a scroll view. With a twist. So to show you the twist, I have to scroll,
but you'll notice here that it's using touchevents. And when I try to scroll, nothing works. So
let me open up devtools. And show you a cool feature that's very useful.
I can emulate touchevents. So what this will do, when I reload the page, and switch back
to it, now when I mouse around these mouse events are being translated into touches,
so instead of a mouse down I get a touch start, et cetera. You can see this is using again
requestAnimationFrame and Hakim here has a whole bunch of cool effects to just give you
a sense of how performant you can have these nice transitions. On both Chrome and -- it
works just great on Chrome for Android as well. You should check it out in the Chrome
experiments booth. So that's -- that's some Chrome devtools features.
You can also emulate multi-touch events on the Mac. And this is a fun little project
that I worked on. It requires a bit of setup. But once you've got it set up, then you can
-- you can essentially create multi-touch prototyping, you can do multi-touch prototyping
on any Mac with a magic touch track pad. So here you can see I've got a single touch that's
coming from my Mac track pad and I can do multiple touches, too.
And I can do this arbitrarily. So it's kind of cool if you're doing complex multi-touch
interactions. This game is just like a fruit ninja clone that I whipped up, except with
browsers. It doesn't really make sense. You hit a blink tag and you get a 406. [Laughter
] >>Boris Smus: Right? Anyway, so that's multi-touch.
And, of course, you want to test on your device, ultimately. You can do these emulations, you
can use these tricks, but ultimately you need to test on your device. And Chrome for Android
has great support for remote debugging, and we have plenty of resources about that. In
the interest of time I won't burden you, but you should check it out. And I will make these
slides available afterward. So thank you all for listening. We've got
some time for questions. And, um ... so, yeah, right, we have microphones
on both sides. So feel free to ask anything and I'll be available in the Chrome area as
well afterward. [ Applause ]
>>> You -- I guess the mic is off. There we go.
>>Boris Smus: I think it's on. >>> You showed examples of how to get the
GPU hardware acceleration enabled. Why don't those turn on by defaults? Why do you have
to play tricks to get it to work reasonably? >>Boris Smus: Right, this is -- I agree -- a
problem that we are tackling currently. So the Chrome GPU team is working very hard to
try to make these -- to try to make more of the rendering part of the GPU pipeline, essentially.
So like you are saying, part of the problem is you don't really know which tricks will
render GPU mode, which ones won't, it's very implicit. And generally, of course, the whole
rendering path should be done on the GPU as much as possible. So GPU team is definitely
looking at this and trying to optimize it as much as possible. It's on my radar.
>>> All right. >>Boris Smus: Yes, go ahead.
>>> If you are trying to emulate more of a mobile native experience, the address bar
gets in the way or -- and is there anything more elegant than just scroll one pixel when
your app starts up? >>Boris Smus: Um, yeah. So -- right, as you
are saying, the current hacks are around using Scroll 2, which is a JavaScript function that
you just call and say scroll to the top and in most browsers, in some browsers, it will
hide the location bar. We're working on evaluating what a full screen API might look like. So
this is an example of there's an open Web API that lets you make a browser go into full-screen
mode. So this would be a nice application. That said, right now in Chrome for Android,
we have an Omnibox that's always there. There's good reasons for that as well. Just if you
have your URL bar always present, it's an indication that you are in the browser, you
are not being phished, you know exactly where you are, and it's also very easy to navigate
away, like, to any other page. Oftentimes on iOS I'll have hard time getting
back to the URL bar, especially if someone is overriding the default scrolling behavior.
>>> I see. >>Boris Smus: It's hard to get back. So ... but,
yeah, I agree, it's totally a hack. >>> Should be a new GitHub project for you.
Fullscreen.js -- >>Boris Smus: Thanks. Yes?
>>> I was just wondering, you were always saying it's important on iOS and on Chrome
for Android. What about stock browser that gets shipped?
>>Boris Smus: Right. So the stock browser on Ice Cream Sandwich is actually quite good.
And there's a lot of -- there are many features that are supported on it that I discussed
today. Don't quote me, I believe requestAnimationFrame maybe. Anyway the inertial scrolling certainly
is. So -- yeah. Thanks.
>>> I was curious. So we provide a third-party widget that you can embed on your page. So
we don't have control over things like the meta tags, some of the stuff that you showed.
I'm kind of curious, we were thinking of using the new implementation of position fixed to
allow our chat box to show up. >>Boris Smus: Yep.
>>> But you don't get kind of zoom fixed on it. So when you zoom in, then like eventually
this position fix thing just takes over the whole screen.
>>Boris Smus: Yep. >>> Anything new that we could take advantage
of? >>Boris Smus: Yeah, it's a good question.
Position fixed is a little interesting if you don't have control over the fixed viewport.
Because it -- it actually varies quite a bit in its behavior depending on the browser.
So, yeah, I think you have a pretty unique case in that you're like a third period JavaScript
plug-in. I can't think of anything off the top of my head that you could do that with.
Maybe we should talk offline. >>> Sure thing.
>>Boris Smus: Great, thanks. All right? No other questions? Find me later, I'll be hanging
out in the Chrome booth.