Chrome Mobile Monthly: Responsive vs Separate Sites

[MUSIC PLAYING]

PETE LEPAGE: All right, welcome, everybody.
My name's Pete LePage.
And today, joining me we have Brad Frost, who's going to be
talking to us about some rather cool stuff.
Brad, I'll leave it to you to introduce yourself.
This is a reschedule of an event that we had a
little while ago.
So welcome, and I'll turn it over to you.
BRAD FROST: Yeah.
Thanks, Pete.
Thanks for having me.
I appreciate it.
So yeah, my name is Brad Frost and I am a mobile web
strategist and front end designer at an agency RGA,
which is based in New York, but I'm broadcasting to you
from beautiful Pittsburgh, Pennsylvania.
So I've been spending a lot of time talking about responsive
design verses separate mobile design for
the last couple years.
So that'll do it.
In case you have been living under a rock, you probably
realized that we had an election not that long ago.
So that's what we're going to talk about, is we're going to
talk about the presidential
candidates' mobile web strategy.
So this is the "Responsive Design versus Separate Mobile
Sites Presidential Smackdown Edition."
So let's get started.
This is a dead horse.
And this is a picture of me beating that dead horse.
A lot has been talked about regarding responsive design
versus making a separate mobile website, which route to
go, which one to choose.
There's been a lot of great articles, like this one, this
one, this one.
Google weighing in a little bit.
Facebook's developers blog.
So a lot of people have a lot of different opinions on which
way to go, what's best for your organization as far as
what mobile web strategy you want to choose.
But really, the ultimate answer is that it depends.
It really depends on the way your company is structured,
what your budget is, what sort of team you have in place,
what sort of technologies you're working in, you're
proficient in, and all of that good stuff.
So really, it's not a black and white answer.
So if you're expecting one, sorry about that.
So why are we bothering talking about this?
Why am I tearing apart the presidential candidates'
websites and making them look so bad?
Really, because I'm a terrible human being.
Actually, no.
That's not true.
I'm trying to be constructive here.
But what it really comes down to is that very rarely do we
have an apples to apples comparison of when to use a
certain strategy.
There's a lot of factors at play.
Time is a big one.
So even if you were to have a separate mobile site, and then
redo it into a responsive website, you're
in a different time.
The web landscape, the device landscape has shifted.
People's behavior has shifted.
More people are getting online.
So could you really chalk any success or failure up to a
specific technique?
Maybe, maybe not.
Again, it all depends.
So very rarely do we have something that's actually a
very black and white comparison between two
different strategies.
But that's exactly what we have for this
presidential election.
You have two candidates trying to accomplish the exact same
thing using the exact same mediums, only they've decided
to go different routes.
So that's why this is sort of such an attractive case study
because really, all the other
variables are control variables.
You're going after the same audience.
You're going after the same goals.
There's no difference in what they're trying to accomplish.
So let's take a look at the candidates' websites.
This is Barack Obama's website and this is
Mitt Romney's website.
And for the keen observers out there, you'll probably notice
something--
splash screens are back in full effect.
Why they went that way is beyond me.
But yeah, so splash screens.
Apparently splash screens are still
relevant in 2012, or something.
But this one's my favorite.
Are you in?
In the website?
No, I am not.
Please let me.
So once you get beyond these little terrible splash
screens, you look at something that resembles
something like a website.
So this is Barack Obama's website and this is Mitt
Romney's website.
Sort of similar feel to both of them, so makes very good
comparison.
So again, these are the desktop versions of the site.
So we have to ask ourselves an important question, why bother
with the mobile web?
Why are these candidates spending any time optimizing
their websites for mobile devices?
Well, we have sort of some naysayers.
We have, oh, here we go again with the separate mobile
versus responsive design debate.
I predict in the future people will get sick and tired of
using their mobile device as the primary means of using the
internet and go back to using a nice 27-inch flatscreen
monitor where they can see everything, interact with
everything, and actually type on a real keyboard versus all
this touchscreen nonsense.
We are cultivating a nation of slide-swiping,
screen-surfing zombies.
Well, Ken.
Despite your best attempts at sounding like a huge jerk,
this is pretty awesome.
That line is pretty amazing.
We are cultivating a nation of slide-swiping,
screen-surfing zombies.
That's just great.
I mean, that's what's happening.
We have a population that is increasingly mobile.
If you look at the United States population, it's
sitting somewhere around 311 million people.
55% of US adults access the web through a mobile device.
And that number is growing it seems every single month.
The number gets bigger.
In addition, a full 31% of mobile web capable smartphone
users access the web primarily through a mobile device.
That is how they primarily get online.
Either it's the only way they get online or absolutely the
primary way that they're accessing web.
This is a pretty huge deal.
And what that translates to in the eyes of the candidates--
so the presidential candidates--
is votes, right?
You have this whole population that's mobile
first or mobile only.
And really, getting in touch with them through the mobile
web is one of the best ways to get in touch with them.
If they have a desktop only website, it might be missing
out on a huge chunk of the population.
So we have all these different things that are driving to the
mobile web.
We have SMS smart links.
We have my favorite thing in the world, QR codes, which
open the browser, which open web pages.
We have email marketing, which the candidates
made ample use of.
And email usage on mobile devices is skyrocketing.
A lot of people use their mobile device
to check their email.
That's one of the most common tasks.
Again, you receive a campaign email.
You click a link, it opens the browser.
You have all these different social media channels--
Twitter, Facebook, Google+, all that good stuff, all
driving to the web.
You share pictures.
You share text status updates, but you also share links.
And those links open the web.
You have search engine traffic, and direct traffic,
and referral traffic, and all of these things are driving to
the web on mobile devices.
So it matters more and more to care about this.
So if we take a look at what the candidates did with their
respective sites, this is Barack Obama's
site on a small screen.
And this is Mitt Romney's mobile site or
m.mittromney.com.
So Mitt Romney has basically gone and made a separate
mobile site that exists at an m. location, while Barack
Obama's is all sitting under one roof in
a responsive design.
So we have to ask another important question, why would
anybody visit the candidate's website?
That's a really important question to ask.
So I've broken it down into two different sort of
categories of users.
We have more information-based users and we have more
action-based users.
So information people are looking for the candidates'
biographies, where they stand on issues, upcoming events in
the local area pertinent to the person viewing,
mythbusting, things like Obama wants me to marry a penguin.
No, no he doesn't.
He gets to write back on his own website and bust some
myths of things living out there in the media.
And then also, just general news updates.
Who the candidates chose as their vice president picks and
all tat good stuff.
On the action side of things, we have things like donations,
which is a huge, huge driver, and the candidates make sure
not to leave that button out, the donate button.
Volunteer, free events, you can sign up for local events,
participate in your community on behalf of the candidate.
And spread the word via social networks
and all of that stuff.
And then, of course, buy some swag from their
official shops there.
So those are the sort of whys.
Why are the candidates caring about this?
Why do users care about this?
Why are we even bothering with this in the first place?
So we need some criteria in which to analyze and compare
these sites.
And Christopher Layon is a mobile web strategist based
out of Minnesota.
And he came up with a really clever way of looking at the
basic needs of a mobile web user, or
just a web user really.
And it's based on Maslow's hierarchy of needs.
We, as human beings, have certain needs.
And some of those needs are more important than others.
Some are prerequisites for achieving the
next level of self.
So at the bottom of the heap, we have our
physiological needs.
We need to be able to breathe.
We need to be able to eat, and drink, and sleep, and all of
that stuff.
So that's really important.
But then, as you climb the pyramid a little bit, we have
a sense of safety, a sense of love, a sense of
self-actualization, and all of that stuff.
So those are sort of considered nice-to-haves
whenever you put them side by side to
something like breathing.
So what Christopher did was something very clever.
And he basically translated those into the
needs of a web user.
So basically, he broke it down into our ability to see and
navigate, to be able to read, to be able to respond and
share, performance is in there.
And then he's using the term HTML5 as sort of as a way of
talking about enhancing a web experience to take advantage
of some of the newer HTML5 capabilities.
So what I've done is I've gone ahead-- and I really liked
that idea-- and I took it and sort of just simplified it a
little bit and broke it down into these 4 areas.
We first need to be able to access something.
We then need to be able to interact with it.
It needs to be highly performant.
And we need to take advantage of all of the various
enhancements.
So let's start with access as it is the most important part
of the pyramid.
So these are devices.
And even though I'm coming to you over the interwebs and I
can't hear you, I think I still heard an audible sigh.
This is the environment we are living with.
This is the device landscape.
And it's a pretty humbling sight.
This is really only just a small smattering of the
devices that are out there.
Luke Wroblewski just posted in an article recently that said
something like 33 major devices were released in the
last 2 months.
And so it's just becoming this staggering pace of change.
And we, as web developers, as web designers, we need to pay
attention to all of that.
We need to know how to deal with it because it's becoming
unruly pretty damn quick.
So it's important to understand that the power of
the web is its ubiquity.
If you look back at this image, no native platform, no
iOS app, no Android app, no Windows Phone app, no any
native or proprietary solution can reach
all of these devices.
But the web can.

Any time you find yourself in a native versus web debate,
just show them a picture like this.
And just say, oh, I'm sorry.
Can your solution reach all of these devices?
I'm not saying that native apps are worthless.
Quite the contrary.
But at the same time, the web's level of reach is, by
and large, the web super power.
And because of that, we need to preserve and
embrace that fact.
We can't continue arbitrarily locking people out just
because we don't like what configuration they have.

PETE LEPAGE: Folks, it looks like we may have
lost Brad for a sec.
Let's see if we can get him back.
Hang on.
One sec.

All right.
Well, always kind of fun dealing with technology.
Brad's sitting in Pittsburgh right now and I'm sitting here
in New York.
But it looks like we've lost him.
So let's give him a second to join back in and see if we can
get him back on.

All right.
Let's see.

[MUSIC PLAYING]
BRAD FROST: I lost you there.
PETE LEPAGE: Hey, no problem.
I'll get you back one sec.
Hang on.
BRAD FROST: Can you hear me?
PETE LEPAGE: I can hear you now, yep.
BRAD FROST: OK.
Oh, sorry about that.
PETE LEPAGE: That's OK.
You're coming back up in one sec.
BRAD FROST: That's pretty odd.
I can't hear you, Pete.

OK.
My other computer seem to have frozen.
So I'm just going to share my screen again.

And then we can continue on.
All right, sorry about that everybody.
Technical difficulties.

Share my desktop.
And we're good to go.
Pete, can I get a thumbs up?
All right, perfect.
Thank you very much.
So where were we?
Yeah, Tim Berners-Lee drove this point home at the opening
ceremony of the Olympics where he said, this is for everyone.
Regardless of race, religion, color, creed, location, mobile
carrier, we all have the right to the web.
So we have to stop thinking in sort of these myopic ways.
"Mobile users won't do that," is something
that we commonly hear.
That's absolute horse shit.
Or elephant shit.
Or donkey shit, whatever you prefer.
Mobile users will do anything and everything desktop users
will do, provided is presented in a usable way.
So we can't stop thinking, or we have to stop
thinking of the web--
as the mobile web as the web light.
How many people are used to seeing something like this?
Sorry, that page is not supported on
mobile at this time.
We don't allow mobile devices on Tee Madness.
FollowMyHealth currently requires a desktop browser.
A mobile version will be available soon.
Giving us that false sense of hope, right?
"The page you are trying to visit is currently available
on our full HTML site." Doritos,
no gallery, no articles.
You're using an unsupported browser even though you're on
a very capable Android device.
Pizza Hut.
This is a really robust single-page scrolling website,
but it says, "This site was designed to be viewed on
standard desktops, laptops, and tablets only." Blah, blah,
blah, blah, some long-winded excuse.
"This website contains media too rich for a mobile web
browser." like, I can't be bothered
with you peasant device.
This is Google.
Sorry, guys.
But this is actually for Google Mobile
Web Initiative thing.
And it says, "Alternately, we suggest checking out the site
from your tablet if you have one." I'm not really quite
sure what you would call that guy right there.
That looks like a tablet to me.
This is my favorite one, though.
"This page has to be ideally opened on your laptop or
desktop browser.
Once you open this link on your computer, then you will
have a QR code to the URL that needs to be opened on your
device."
Holy crap.

So really, what we're talking about here
is the one web principle.
I'm sure we've all heard that.
I talk a lot about achieving content parity across devices.
The term "thematic consistency," which was dubbed
by the W3C to talk about how web experiences can look and
function differently provided that the information's still
presentable in some way, shape, or form.
But really what I found to be really beneficial is to just
be-- to talk about it in very common sense language.
Say, give people what they want.
If they click on a link, they have an
expectation for something.
And it's up to us to provide that [INAUDIBLE] and meet that
expectation.
So if we take a look at Mitt Romney's site, this is
actually a previous edition of Mitt Romney's site.
You get to see sort of a breakdown of the desktop site
in the left, and then the mobile site in the right.
But if you look at the navigation in the mobile site,
you'll see that only a few options out of the desktop
site appear on the mobile version of the site.
So that's really bad.
And it leaves a lot of questions unanswered.
Like, who is this guy?
There's no way to access his biography.
Where does he stand on issues there's no way to access that
information.
What about his plan for jobs?
What can he do for my state?
Where could I shop?
All of those things were inaccessible from the mobile
version of the website.
And again, for a lot of people, they might not know to
click the Full Desktop Link.
And as a result, they're just going to go elsewhere for
their information, which certainly could be biased in
some way, shape, or form.
So thankfully, they did a redesign
that did a lot better.
They redesigned the site.
The desktop site looks different.
The mobile site looks different.
And you could see that the menu now contains all of the
sections of the desktop site, which is good.
In responsive design, it does a lot better job of achieving
content parity just because everything
exists under one roof.
But that doesn't mean that it, by default,
achieves content parity.
A lot of times--
and a lot of sites do this--
will simply hide content from mobile viewers.
So the site on the left is a blog and it says, but, hey,
that's just my opinion.
Feel free to shoot me down in the comments.
However, the comments and the comment form are hidden for
small screen users.
So there's no comments, which obviously is a bad thing.
On the right is navigation with a lot of
important-sounding links.
Post a Job, About Us, Our Guarantee, Contact Us.
All of that stuff sounds really, really important.
But because space is constrained on a small mobile
device, they've simply hidden all of the navigation elements
for small screens, rendering those things totally
inaccessible.
So if you look at Barack Obama's redesigned site,
really the only thing that I could see that was
inaccessible from small screens was the store.
So the desktop version had a store, but the mobile version
really had no way to access shopping
experience from the phone.
Another problem with regards to basic access is URL
redirection.
This is something I see a lot of.
How many people have seen something like this?
You go through.
You're clicking on your Twitter feed or your Facebook
feed and somebody shares an m.
link, and you open it from your desktop browser.
We see this stuff all the time.
Here's Microsoft.
Here's this.
Here's this, this this, this, this, this.
This is pretty common.
And then, of course, we end up at Mitt Romney's website.
If you're on a mobile device and you share Mitt Romney's
website and someone clicks from that onto a desktop
browser, they get this page, which clearly I'm sure the
designers never intended for the site to be
viewed in this way.
This comic really sort of helps sum it up, a lot of the
problems of sort of maintaining
separate mobile websites.
"Hi, I'm a server.
Who are you?"
"I'm a browser.
I'd like to see this article."
"Oh, I can help.
Let me get it for you.
Whoa, you're a smartphone browser.
"Yeah."
"Cool.
Well, hey, I got this new mobile version of my site.
Check it out.
Isn't it pretty?"
"Sure, but you just redirected me to the main page.
Where's the article I wanted?"
"What article?
Who are you?
Hi, I'm a server."
So it's really important, URLs are extremely important.
And unfortunately, the sort of m.
and tablet.
and all of those other dots become
a maintenance nightmare.
In addition, coming back to our splash screen issue that I
brought up earlier, this continued to the website link
for Obama's site.
You could click on that all you want from Opera Mini,
which is a proxy browser.
So all the client side stuff gets handled by the server.
And as a result, you get hit with a splash screen and you
can click on Continue to the Website all you want, but you
can't get past the splash screen.
It doesn't redirect you to the proper home page, which is a
really big issue.
All of a sudden, Opera Mini, which is a very, very popular
browser, especially all over the world, regions like Africa
and Asia Pacific and stuff like that, they have no way of
getting to the site if they're using that browser, which is a
pretty big deal.
So access is absolutely fundamental.
Without it, you could make the most beautiful parallaxy,
interactive website you could imagine.
But if people can't access it, they clearly can't
interact with it.
So let's talk about the next tier of interaction, which is
interaction.
Obviously, there is a whole lot of different ways a user
can interact with the site.
But I'm just going to focus on a couple that I think are
pretty important.
So let's talk about navigation.
This is my friend Quincy.
And my friend Quincy is a good friend of mine.
And I say good friend because I was able to peruse his
entire Facebook photo library, pick the most embarrassing
photo of him, and post it online, and show it to all you
people without asking him.
So that's how good of a friend Quincy is.
So anyways, I recently moved from New York City to
Pittsburgh, Pennsylvania.
And the day we were supposed to move, or the day before we
are supposed to move, my wife got really,
really, really sick.
And she was supposed to drive the car across, and help pack
and all of that stuff.
Our friend Quincy went out of this way and said, I could
help you guys out.
And he took his entire weekend off and drove over with us and
helped us move.
So yeah, Quincy is a good friend.
But the thing is, is that we don't really see Quincy all
that often.
We maybe see him once a month or once every other month.
So it's a pretty big deal for him to help us out like that.
So what does this have to do about navigation?
I think that navigation should be like Quincy, where it's
there when you need them but cool enough to
give you your space.
Whenever a navigation is absent, obviously
that's a big deal.
But if the nav is always in your face--
this is an example of a responsive website.
All these different pages, these are different pages of
the website you can see by the little active state.
But the navigation's just in your way.
You're not able to get to the core content of the website.
It becomes that friend that's just always hanging around or
always annoying and just sort of asking you
what you're up to.
Hey, want to hang out?
Hey, want to hang out?
Hey, want to go to the movies?
Hey, want to go to branch?
Hey, hey, hey, hey.
It's annoying, right?
So you want navigation to be accessible, but you also want
it to be out of the way.
So if you look at Obama's navigate, the previous
addition of Obama's website utilized the sort of
Facebook-like slide-out method.
If you're on a small screen, it slides out from the left.
And whenever space becomes available, it simply stacks
the links across the top.
So my friend Stephanie [INAUDIBLE]
took a look at the navigation and tested it out whenever it
first came out.
And she found some pretty troubling things.
She said, "And the menu failed.
Never even opened.
Suddenly, the site was without navigation at all."
She tested on a lot of different devices.
She found that it only worked on the Galaxy Nexus, which at
the time, had just come out, and an iPhone 4
with running iOS 5.
Where it didn't work, as you could see, is a whole lot of
different environments.
And so she wrote about this in a [INAUDIBLE]
for progressive enhancement.
And I have to say that I totally agree with her.
A lot of people think of JavaScript support as being
very binary.
And people say things like, oh, of course users don't have
their JavaScript turned off anymore.
That's very 1998 of you to think that.
But whenever you look at instances like this where
JavaScript has failed in some way, shape, or form, but all
of these different devices are actually quite capable from a
JavaScript point of view, the idea is just about providing
an adequate fallback if things go wrong.
This is me testing Obama's site on a BlackBerry.
And if you note in the top left corner, that's where the
menu button should be.
And there's no way of getting to the navigation.
It just is entirely invisible or absent.

These are big deals.
So thankfully, whenever Obama redesigned his website, they
did something a little more clever utilizing the footer
anchor technique where you basically click a link in the
header and it jumps you down to the footer of the website
where the navigation lives.
And also, using the multi-toggle, which is
basically just nesting sub-navigation items in little
accordions or sort of nesting them in there like that.
So the result of that is something that's a lot more
accessible.
It works on more devices and sort of avoids a
lot of those problems.
If we look at Mitt Romney's website, you could see that,
again, this is the earlier version of his website.
We talked about how it doesn't include everything on the
website or on the desktop version of the website.
That's a pretty big deal.
But it's also sort of weird that the only navigation
exists on the home page.
The home page is sort of this dashboard.
And all the other sub-pages basically just link back to
the home page.
So there's really no navigation on any sub-pages.
So it becomes sort of this full-page redirect in order to
navigate to another section of the site.
So I wouldn't say that that's very efficient.
In addition, you look at things like back buttons.
If you look, all browsers have some way of
going back in the history.
So that sort of back button that you're including there is
a bit redundant.
So again, if we look at the updated version of Romney's
website, we see he's utilizing what's called the toggle,
where it basically says Open Menu.
You tap that, it exposes the navigation.
And then is says, Close Menu.
So again, that's a pretty good way of keeping things
accessible, yet still unobtrusive.
So definitely a step in the right direction for him.
Another interaction that doesn't really get talked
about a lot is that of scrolling.

It's a pretty common interaction, obviously. .
But it's also not terribly sexy to talk about.
But what I found is that whenever we scroll on mobile,
whether on the web or just anywhere else in apps or
whatever, we're typically doing one of three things.
We're either going back in time.
We're going through a Facebook feed or an email feed or some
form of time-based grouping of items.
We're going through grouped items or we're diving in deep
into content.
So again, so we have things like going back in time.
You're scrolling back in time through your posts, through
your email, through whatever.
Going through groups of items, things like categories of
names and stuff like that.
So I'm going through my contact lists on my phone, or
I'm going through an artist's list in iTunes, or Rdio, or
something like that.
Or I'm diving in deep into a single piece of content.
I'm reading my email and this Nigerian prince email looks
very attractive to me, so I want to learn more.
So I'm going to scroll down.
Or I'm reading a really great article on the web and so I'm
going to scroll down to read it.

So what I've found though, is that we're always scrolling
through a singular content type.
This is important for responsive design because so
much of responsive design is how to--
the conversation is about how to re-flow layouts.
What do we do with those second and third and fourth
columns and stuff?
And typically, the answer is to simply stack them
underneath each other.
And what I found is that that just doesn't make for a very
good user experience.
So if you look again, here's Mitt
Romney's site on the left.
And here's a previous version of Obama's site on the right.
And you can see you have this sort of big call out, this
Obama, Clooney, and you.
You have an email sign-up form.
You have a couple touts that highlight certain things.
You have his record in brief.
And then, as you scroll down--
sorry about that.

Oh, doesn't seem to work.
But as you scroll down this page, you
have all of this stuff.
You have the record in brief.
Then you get down to his blog posts.
And you see the blog posts and you see all these share icons
for each blog posts.
And it goes through about 10 different blog posts.
And then underneath, there's a bunch of
things like his tweets.
And then underneath that, it's like take action.
And then underneath that, it's even more stuff.
And then eventually, you get down to the footer where it
just contains this huge spray of links.
And the idea is that you're simply sifting through all of
this disparate content just to find what you're looking for.
It's not a very good user experience.
Again, like the user expectation on a mobile device
is to scroll through a single content type.
And by simply stacking things on top of each other, users
are forced to go on a treasure hunt just to find what they're
looking for.
So we want to avoid that.
And if we look at Obama's redesigned website, they've
done some sort of clever optimization where basically
on small screens they just exposed the title of their
blog posts instead of showing the full excerpts, and all
these images, and all these share buttons
in addition to them.
So that creates a more scannable experience a better
performing experience, and all of that stuff.
So definitely a step in the right direction.
Conditional loading is sort of what we're talking about with
regards to how to solve those problems.
How do we include a full experience, especially for
larger screens, but still keep things nice and compact and
fast-loading right out of the gate for small mobile screens?
Scott Jehl calls this aggressive enhancement.
I really love that term.
I hope it catches on.
But basically, the idea is this.
We have a web page.
This could be any web page.
We have the thing.
And the thing is the thing that's divined by the URI.
If you click on a picture that says Click Here for Cute
Kittens, whenever you click on that link, what do
you expect to find?
You expect to find cute kittens.
But in addition to those pictures of cute kittens,
there's all this other stuff.
We might have related pictures of cute kittens.
We might have a comment form.
We might have social icons to share the thing.
But all of those things aren't the pictures of cute kittens
themselves.
So what we could do is we can actually chunk
those things out.
Those sort of supplemental or [INAUDIBLE]
bits, which actually, again, might--
they might not all be crap.
It's not like you could just remove them entirely.
But we can just be a little more thoughtful of how we
introduce them into the experience.
So what we could do is we could simply chunk those out,
link to them from the main page.
So link to the comments and have them isolated.
So again, if JavaScript fails, or when it fails, the user can
click Click Here to View Comments.
And they tap that, and then they get taken to the new
screen that shows the comments.
So again, the idea is to create an accessible
experience.
But then from there, we could sort of pull everything
together, like Voltron when the conditions are right.
Whenever the screen's large enough to accommodate those
extra chunks.
Or whenever the user requests them.
We could sort of just pull everything all together.
I think that's a really, really valuable technique that
we have at our disposal to sort of help keep the core
experience really, really light, but also not sort of
sacrifice serving up an eventual robust web
experience.
So the next thing we're going to talk about is performance.
Performance is, in my opinion, very neglected.
And the expectations are high.
Mobile users expect mobile sites to load as fast, if not
faster, than desktop sites.
And that's a pretty huge majority there, 71%.
And a full 74% of mobile visitors will abandon a site
if it takes more than 5 seconds to load.
That's a huge number, a full 3/4.
So in other words really, you have 5 seconds
of someone's time.
And if you don't give them something in that 5 seconds,
they're gone.
And they'll oftentimes go to a competitor's site.
And they will be gone and never come back.
But the problem is, is that the average page size just
keeps growing and keeps growing, growing more obese
every single day.
Why is this happening?
What I found is that just performance is invisible.
It's the sort of invisible aspect of design.
You can't mock up performance in Photoshop.
You can't sort of just put it there as a line
item on your thing--
performance.

It's often this thing that's just--
it's always there, but it's always neglected.
So because of that, I've been talking about elevating
performance as a design feature rather than as
something that only developers need to worry about.
Because very often-- and this will probably sound familiar
to you, performance is usually one of the
sort of lesser concerns.
Deadline's getting closer.
We don't really have a whole lot of time.
It's like, oh, yeah.
We'll just worry about all those performance
optimizations later.
Don't worry about it.
We just need to get the site launched.
And, oh, that's just something that the developers need to
take care of.
If the site's slow, it's the developer's fault.
It's not the fact that they've designed 30 meg images and
included a bunch of crazy parallax stuff.
So I've been talking about performance as design.
We need to elevate it earlier in the design process.
You can't just leave it at the end of the process.
If you don't think that performance is important, it's
important to understand that performance is good design.
Good performance is good design.
If you don't believe me, just look at the
whole Facebook thing.

I had a lot of people-- and whenever I mention that I work
in mobile, people would say, Facebook suck, as if it was my
fault or something.
But they weren't saying that Facebook sucks because the
navigation was unintuitive, or that the timeline redesign
wasn't elegant, or that the navigation wasn't cool.
They were saying it sucks because it was just so slow.
So we really need to prioritize performance in this
day and age.
We can't just sort of cross our fingers and hope that 4G
and LTE and everyone's just going to be rocking a FiOS
connection anytime soon.
We really can't bank on that.
We need to address the constraints of bandwidth.
So if we look at how the candidates fared, this is
typical web page on Romney's site, the Pennsylvania page.
And I ran it through a tool, which at the
time was called Blaze.io.
It's since been renamed, and we'll get to that in a minute.
And what I found is that the mobile site took 8.75 seconds
to load and weighed 687K, which is
actually pretty decent.
It's still above that 5 second mark that we'd like to see.
But at the same time, the file size is significantly lighter
than the average page weight.
Then we get over to the responsive end of things.
Guy Podjarny, who helped make Blaze.io, which is now
Mobitest, now works at Akamai, found that 86% of responsive
websites serve the same payload, or roughly the same
payload, to small screen viewers as
large screen viewers.
So in other words, all these mobile sites are basically
getting a desktop heavy experience.
And so that's definitely reflected in
Barack Obama's website.
This is again, a previous edition of it.
And we ran it through the same test and found that it takes
21.68 seconds to load and weighed 3 and 1/2 megs, which
is gigantic.

And that actually creates some serious accessibility issues.
My cousin, who's a geologist, has a company-issued
BlackBerry.
And I asked him to fire up Obama's website on his
BlackBerry.
And this is what he sent back to me.
It said, request entity too large.
In other words, it's saying, I'm not even going to try to
render that page.
It's just way too big.
And it's funny to point out that Obama actually has a
Blackberry.
So I was sort of curious to see if Obama could access his
own website from his phone.
Hopefully he can.
But if you look at the waterfall charts, on the left
is Mitt Romney.
On the right is Obama.
You could just clearly see that Obama's site is loading
way more stuff.

Through the course of the campaign, they both underwent
some pretty serious redesigns.
So I ran both of the redesigns through the updated tool,
which is again, called Mobitest by Akamai.
And basically, it fires up--
you could paste in any URL.
It will fire it up on a real device and then spit back the
performance stats for it.
So how long it takes to load, what the page size is, and all
the waterfall charts.
And you can provide some screenshots and stuff.
It's a great, great tool.
So I ran Mitt Romney's website through this tool and found
that it actually now takes 19.58 seconds to load and now
their mobile site weighs 1.6megs, which is giant.
Once upon a time it was sitting around, like 8 seconds
to load and 687K.
And now it's huge and it's bloated.
Now granted, they are achieving content
parity a lot more.
But it's a serious step backwards for them as far as
performance goes.
And if we look at Obama's website, their redesign
actually came down quite a bit in file size.
It used to be 3 and 1/2 megs and they cut it down to a meg.
It's still on the heavier side of things, and it still takes
18.76 seconds to load.
But at the same time, that's a pretty big step
in the right direction.
So performance is absolutely essential.
I think that we need to sort of elevate its status.
We need to treat it as more of an urgent matter.
Treat it as a design problem rather than
a development problem.
I think that does a lot of good as far as getting more
people on board.
Just include that in your statements of work and in your
project briefs and stuff.
Just say the goal is to create a really fast website that's
very flexible.
So the last little bit of the pyramid is this concept of
enhancement.

Progressive enhancement is your friend.
Just because we have more limited devices, or legacy
browsers, or whatever, doesn't mean that we can't capitalize
on all the new and great features that are coming down
the pipes really fast and furious.
But in order to do this, we need to build up from a core
experience.
We need to embrace the constraints first, address
those constraints first, and build up.
You hear the term mobile first a lot.
And really, from a development standpoint, it's about sort of
addressing the constraints of the mobile medium--
low bandwidth, small resolutions, potentially
inferior feature sets, and stuff like that.
And really just sort of build up those experiences so that
as devices have more screen real estate, as devices have
more capabilities, we're in a position where we could simply
add it onto a core experience in order to capitalize on
those features.
Instead of sort of assuming things by default-- oh, of
course users are on a large screen or of course users
support touch.
Or of course users whatever.
All of a sudden you have to cross your fingers and hope
that nobody releases a popular device that
doesn't meet those criteria.
So it's really, really important to progressively
enhance experiences now more than ever.
And really, what I say is that this is foundational work.
Jeremy Keith wonderfully stated, he said, starting with
the lowest common denominator--
or progressive enhancement doesn't mean designing for the
lowest common denominator.
It means starting there.
I think that there is.
There's a misconception that if you want to do anything
advanced or whatever, you have to ignore progressive
enhancement.
That's simply not the case.
It's just a matter of laying a solid foundation and covering
your bases, and then building up from there.
Again, we have tools like Modernizr, that gives us all
sorts of different things that we could detect and
capitalize on them.
Introduce more advanced functionality if a device
supports geolocation, if the device supports App Cache, or
WebSockets, or whatever.
We actually have these tools on the server side.
This is Detector by Dave Olsen, which actually is sort
of a combination user agent/feature detection tool
that all gets handled on the server end of things.
So again, it doesn't all need to be client side when we're
doing this adaptation.
But the idea is to really capitalize on the specific
device that's accessing your experience.
And it's also important to understand that different
users have different expectations.
My cousin's BlackBerry, he's not expecting this crazy
multi-touch CSS3 transition web experience.
He's really just trying to access some information, and
read some things, and maybe fill out of
form or two, or whatever.
But he understands that he doesn't have the latest and
greatest Android device or the latest and greatest iPhone.

Whenever you make these stupid assumptions, you
start looking silly.
"Fatal Error.
No iPhone, iPad, HTML5 images available." I honestly don't
really know what that means.

But yeah, you're depriving people an experience
arbitrarily is what's going on here.
It's also important to understand that there's a
difference between support and optimization.
Unless you wanted to hole yourself up in a cabin for the
foreseeable future with a bunch of different devices,
there's no way you're going to be able to optimize for every
single platform and configuration and user
preference and setting out there.
So you do, you need to draw a line between what you support
and what you optimize for.
And it's important to understand that difference,
just because I think a lot of people use--
they sort of misconstrue what optimization or
what support means.
And they say, well, we only want to support WebKit
browsers, or we only want to support the iPhone, and
everything else can take a hike.
There's still a way to optimize for iPhone.
There's still a way to optimize for the best of breed
and most capable devices while still providing some level of
support for those other users.
Just because you don't like their configuration or
whatever, or it's a pain in the ass to develop for doesn't
mean we have the right to arbitrarily lock them out of
an experience.
So there's a lot of different things that we could enhance.
This is the candidate's website.
You have all these opportunities to utilize
things like the right input types for forms.
So here we have a zip code on both Mitt Romney's site and
Obama's site.
And what they could do is define these things as numeric
inputs that allow--
that pull up the right virtual keyboard on touch devices.
That makes the form a little easier to
load or to get through.
Here we have the newsletter site on Obama's site.
And you're looking at the email field will
actually pull up--
so they did that one right.
So they did input type equals email.
And it pulls up the little at sign.
It gets rid of these other unnecessary characters, so it
makes it a little more easy to do.
But then you go down into the ZIP field and that should be a
numeric value.
And it's not.
So there's a lot of different things that we could do.
One of which is, again, changing the input type to
number, which is great.
But then, also adding this pattern attribute to the
string, which basically pulls up the bigger chunkier
telephone prompt.
So instead of just having the numbers 1 through 10 across
the top like the previous screen--
oh, sorry.
I don't have an example of that.
You instead get these big, huge, chunky
keys, which is fantastic.
Another optimization that's really important to understand
is that these telephones in which we're accessing the web
can make telephone calls.
And Obama's website is actually
using this to his advantage.
So they have this Call Tool where people are able to make
calls on the candidate's behalf and say,
hey, are you voting?
Are you registered to vote?
Who are you voting for?
And give their whole spiel.
Basically, from an old school standpoint, you would have to
look at the screen and then dial a phone number on another
device, which is hugely cumbersome, takes a lot of
time, and there's a lot of room for error.
But again, these mobile devices can make phone calls
right from the device.
So the user can be on Obama's website, simply tap that
number, and initiate a phone call.
That's really, really clever.
Other things for the candidates, like geolocation
is really, really important.
Things that battleground states and location matters a
great deal.
But there is ultimately just all sorts of things that we
can enhance.
Again, if we look at that list from Modernizr.
It's a pretty extensive list.
And this is just the beginning.
So wrapping up.
This is what I want you to get out of this, is that users
don't give a shit if your site is responsive.
They don't give a shit if it's a separate mobile site.
They do give a shit when they can't get done what they need
to get done.
Whenever they can't accomplish their task is when they start
noticing what environment they're in.
There's all of these different things that we need to take
into mind whenever we're creating these multi-device
web experiences.
And it's just important to focus on the right aspects of
the process.
And it's important to understand--
I took a lot of shots at the candidates' websites, and on
other sites and stuff as well.
But this stuff is really, really hard.
We're all trying to figure this out.
It's important to start somewhere.
You might have a current desktop site that's big and
clunky and crusty and old, but it's just out of the question
to do a full-blown redesign.
So these separate mobile sites, while they might be
sort of shortsighted in the near term, can be a tremendous
opportunity to help you sort of evolve out from under your
old legacy desktop site.
So while a mobile site might be initially limited as far as
its content goes, as far as its functionality goes, and
stuff like that, you can still plant the seed for a
responsive future.
And that's exactly what a lot of organizations are doing.
And eventually, you put time.
You put effort into it.
And ultimately, you can sort of evolve out of your old
crusty desktop site and into this new global site that's
mobile first built.
It's adaptive.
It's future-friendly.
That's exactly what organizations like the BBC are
doing, like "People" magazine are doing,
and stuff like that.
It just doesn't make sense for them to strip away their old
desktop site just yet.
But at the same time, they're learning how
to deal with diversity.
They're learning all the quirks and the tricks of the
trade with regards to the mobile web.
The takeaway from that is to just start somewhere.
Even if you don't fundamentally agree with
creating separate mobile sites, that's OK as long as
you're planning on sort of treating it as a stepping
stone for future enhancements.
And again, this stuff is really, really hard.
And there's a lot to learn from a lot
of different people.
So it's really important to not get hung up in specific
implementations and technique.
I think that we need to sort of stand together on
principles that we could all agree on.
We all believe in the web.
I like to say, this ain't religion, this is web design.
So be willing to abandon a best practice that you've been
using your whole career whenever you find evidence
that it makes sense to abandon.
I really like this quote from Benjamin Franklin.
He says, "Whenever you're finished changing, you're
finished." And that means we can't get hung up in our ways.
We can't get religious about certain techniques and say,
this is the one right way to do things.
We need to constantly be evolving.
Again, if you think of all the different devices that are
coming out just in the last couple months, we need to be
evolving right there with them.
Because the minute we don't, the minute we
put the web at risk.
And let's face it, this is going to be
really, really fun.
I can't think of a better problem to help someone then
determining who the web can reach, what it can do, where
it can go, how it gets used, and why is still matters.
I think that's a tremendous problem to have and just a
really, really fun problem to help solve.
So with that, I would like to say, I kept
politics out of this.
But I did cast my vote for the candidate that I thought had
the best website.
And that is why I voted for Jimmy McMillan's "The Rent is
too Damn High" party.
It's ample use of Comic Sans, and loud borders, and animated
GIFs, it won me over.
So I had to vote for him.
I might have to change that to 2016, but I hope him and his
awesome website is in our future.
So thanks very much, guys, for listening.
Sorry for the technical difficulties.
And hopefully we can take a look at some questions now.
PETE LEPAGE: Yeah, absolutely.
So Brad, if you want to come off screen-sharing and I'll
bring us up so that they can see us both.
So one of the first questions that we have that's got a lot
of votes, "When creating a responsive sight, is it the
best practice to define media queries in pixels or Ems And
are their pros and cons to consider when using each of
those?"
BRAD FROST: Yeah, so there's definitely advantages to
defining your media queries in relative units, like Ems.
Lyza Danger Gardner of Cloud Four wrote about this, about
basically how proportional media queries are a lot more
future-friendly.
But also, present-friendly.
So in my experience, I have seen pixel
widths sort of destroyed.
So a lot of different devices handle pixels in a lot of
different ways.
16 pixels on a certain device might look totally different
than 16 pixels elsewhere.
But also, user zoom settings are really important.
If I go into a responsive website and command + +,
magnify the site, which I like to do actually--
if your media queries are set in pixels, it won't honor the
user zoom settings.
But if you handle them with relative units using Ems, it
will honor them.
I think it requires a page refresh.
But at the same time, it will re-flow the layout
appropriately if you use proportional media queries.
And the other thing that's worth stating is that we're
using proportional units for everything else now.
PETE LEPAGE: Yeah, that's true.
BRAD FROST: For layouts, for fonts, for everything now.
Just take it that one step further and define your break
points in relative units.
PETE LEPAGE: Cool.
So next question from Dan in Amsterdam wants to know,
"Should we take into account a device bandwidth before
serving content, especially media assets to the device?
If so, how should we implement that?"
BRAD FROST: Yeah, so there's a lot of actually really recent
things that have been coming up
regarding sort of bandwidth.
It's still really tricky to detect bandwidth.
We have sort of the navigation, navigator
connection type, and stuff like that.
But even that's not reliable.
Anybody that's been on like hotel Wi-Fi will probably know
that 3G is oftentimes faster than that.
We can't make assumptions even based on even knowing what
kind of connection type we have.
So I'd say that it's best to assume a slow, painfully slow
connection by default and serve up assets appropriately.
Things like adaptive images--
and there's a lot of different solutions and stuff that's
sort of coming down the pipes with regards to the spec and
stuff like that.
But in the meantime, we have tools like Picture Fill, which
allows us to serve a small image by default.
But then whenever you reach a certain break point or
whatever, then load in a larger image asset.
Same thing with retina graphics and stuff like that.
Small by default, but then conditionally load in a higher
res version.
But one of the most recent things that has been pretty
clever is that they're finding that the image compression,
like JPEG compression, is more a factor in determining a
device's bandwidth--
or, I'm sorry, an image's size than the dimensions of them.
So everyone's freaking out about retina screens and stuff
like that now.
And it's important to understand that you could
actually create larger images with larger dimensions, but a
lower compression and then just simply scale them down
and they'll look great on retina displays, as well as
just standard displays.
And in some cases, the file size of the enhanced--
the bigger--
PETE LEPAGE: Is even smaller.
BRAD FROST: Even smaller than the base image, which is
pretty crazy.
But yeah, image optimization, other things like maps and
other interactive components, just don't include those
things by default.
Again, I was talking about conditionally loading.
I will give my little example.
I have a demo of this on the way.
Hopefully I can share it later on--
of something like Google Maps.
If you want to embed Google Maps in your site, you have to
iFrame in the embedded map.
But for small screens, I would actually argue that's not a
very good experience.
For one, a lot of major smartphone platforms, like iOS
and Android, will intercept links to Google Maps and fire
up the native mapping application, which is a far
better user experience than anything
on the web can provide.
Again, it just has access to more things.
So I'd say that that's the best experience.
So the demo that I have simply includes a
link to Google Maps.
And you could use the Google Static Map API or whatever, to
pull in a still or whatever, if you want to.
And then whenever the screen size becomes big enough, then
you can load in that iFrame and add an editable map and
stuff like that.
So again, it's about sort of serving the right experience
to the right context and stuff.
But by assuming less upfront, you're not forcing mobile
users to download all this JavaScript to render an iFrame
by default.
And as a result, you're able to just sort of take bandwidth
into consideration.
At the very least, if everything fails, they have a
link to Google Maps, and I'd trust Google Developers on the
Maps mobile team more than me to make sure that people can
get to where they need to get.
PETE LEPAGE: Absolutely.
Cool.
Well, Brad, I think that's about all the time that we
have for today.
I want to say thank you so much for joining us.
This was enlightening.
This is the second time I've seen this session and I
learned stuff again this second time.
So I want to say thank you very much.
I want to invite all of our viewers to join us in 3 weeks
on December 5.
We're going to have another Chrome Mobile event where
we'll be talking about some of the tools that you can use as
a developer building mobile sites and mobile applications.
So with that, thank you guys very much.
Brad, thank you.
BRAD FROST: Cool.
Thank you very much for having me.
Appreciate it.
PETE LEPAGE: All right.
Have a good day, everybody.
BRAD FROST: All right, take care.
PETE LEPAGE: Bye.
BRAD FROST: Bye.