Crap! It doesn't look quite right, or, how I learned to stop worrying and set my mobile web sites free

Crap! It doesn’t
look quite right
Or: How I learned to stop worrying and set
my web sites free

Lyza Danger Gardner / lyza@lyza.com
@lyzadanger / Over the Air, 2011

Monday, October 3, 11

Hi, there, Bletchley
Park.
My name is Lyza.


I love the web.

photo by lukew


Hi, I’m Lyza. I love the web. I always have. Ever since the 1990s, when the web was just a wee
baby.

I hail from Portland.

Hi!


I live in Portland, Oregon, USA. In fact, I was born and raised there. This is actually seriously unusual.
Portland is the kind of place people want to move to, and increasingly, it’s hard to find actual natives.


In Portland, we are known for our coffee.


Our beer...


...and our foodie inclinations.

Portland is also famous for its
hipsters, bikes and other stu! I don’t
have photos of. Come visit. It’s fun.


And a host of other trendy things. Portland’s grown a reputation of late and is particularly the
darling of the New York Times, which publishes fawning articles about its quaintness
regularly. As you can tell, I’m proud of the town. And it also has a strong mobile development
community.

Portland
+
Interwebs
+
mobile
+
Iamonateam
withsome
wickedlysmart
} Dramatis personae

people
=
Cloud Four


So, I live in Portland, and in 2007 I helped co-found Cloud Four with three other folks I’ve
worked with for over a decade. We came from a deep “traditional” web background and we
wanted to seize on the incredibly neat opportunities provided by mobile.

Cloud Four chose the web.
It was in no way an easy choice.


2008
Flashbackto


We founded Cloud Four in 2007, with an initial vision of mobile web goodness. In 2008, a lot
of stuff happened.

As luck would have it...
I was fortunate enough to
be on the team that
developed the Obama
iPhone app.


What an exciting time.
This was a mere few
months after the initial
launch of the App Store.

Everyone was very excited.


This was in the late summer of 2008, mere months after the initial launch of Apple’s App
Store in the US. Everyone was basically quivering with excitement.

Now what?
Follow the !ow and build
native apps for a living, or
continue to bank on the
promise of the web?

photo by Robert Goodwin


At Cloud Four, we were faced with a crossroads. Colleagues we knew and admired were
throwing in their lot with native iOS apps. Should we stick with our original dream, pinning
our hopes on what we see as a more democratic, more universal and more meaningful
technology?

What apps can do, the web can do, too...


Cloud Four co-founder Jason Grigsby went over the features of the Obama application with a
ﬁne-toothed comb. His realization here? There’s nothing in this app that couldn’t be
accomplished with web technologies.

Since then, at Cloud Four...


Epiphanies like this helped us make up our minds. We stuck with the web. Since then, we’ve
built stuff.

High-performance mobile
web applications and sites.


Like Hautelook.com’s mobile site. Hautelook is a fashion ﬂash-sale site with extreme traffic
spikes as, at 8am each morning, frantic fashion-conscious bargain-seeking shoppers
descend on the site. It is one of the top 2k sites in the world, and boy, howdy are shoppers
going to be mad if they can’t access the site because of performance problems or rendering
issues.

Web sites and
applications for both
“desktop” and
“mobile” devices and
browsers.


But it’s not all about standalone mobile sites—in fact, we generally aim for the opposite. For
example, we build this full-gamut site for a local craft brewery in Oregon. There’s some neat
stuff going on here that you couldn’t do before mobile, for example, we use geolocation to
help users ﬁnd the closest shop, bar, or restaurant that carries a speciﬁc brew that Deschutes
makes. Fun stuff! We love the mobile web.

The mobile web is hard.


We’ve learned something. The mobile web is hard. And, frankly, instead of easing up as time
goes by, it kind of seems to be getting harder right now. Before we get down to our little chat
here, I want to take a moment to make annoying observations about linguistics.

(A brief aside)
regarding terminology.


Before we get down to our little chat here, I want to take a moment to make annoying
observations about linguistics.

“There is no mobile web.”
—Jeremy Keith (@ada!io)


Well-known web dude Jeremy Keith gave a presentation a few weeks ago at the Breaking
Development Conference in Nashville, Tenn. The title of his presentation was “There is no
mobile web.” At the time, I thought he was trying to stir up a bit of controversy.

At rst, I didn’t get it.


Surely, this is splitting semantic hairs? But then I thought about it a bit more.

The stu# we’re up against is bigger than a pile
telephones

photo by Dave Patten


Not everything that browses the web is a desktop computer or a telephone. By referring to
the “mobile web,” we’re both ignoring the broader context and acting like there is more than
one web, when in fact the goal is universality.

So many devices.


It’s about making the web ﬁt a vast array of devices and platforms. Everyone loves
mentioning those still-odd outliers like Automobiles. Refrigerators. Wristwatches. Yes, mobile
devices like phones represent the big thrust, but the meaning is deeper.

also...


Just to make things yet more complex...

What do we mean when
we say “device?”
device itself (hardware)
+
Chancesare,we platform
meanbitsand +
botsofvarious OS
things
+
browser
+
carrier/connectivity elements


We talk about the devices that are accessing our services. In web terms, what does this mean?
I think it means, unfortunately, too many things for the word “device” to handle on its own.
Bits of hardware, software, versions, connectivity all blended into a muddle.

Upside-down, devil’s-advocate Lyza
asks self: All right, then, smarty pants,
what do you suggest?


Then I get frustrated with myself.

the web of now?

the interblags?
universal web?

THE WEB
pan-device web?

The One Web?

web 3.0?
Oh,whoops,the
Ugh!Veto future web? W3Calready
nabbedthisterm
web for all?

portable web?


There are some nomenclature options. But none seem right, and none capture the essence of
what’s going on, that is, the web exploding out onto a galaxy of device-OS-browser-ugh-
whatever combinations. Bah! I’m sorry, George Orwell. Rest in peace. When you get down to
it, what we’re talking about is THE WEB. But then one loses track of the elements that set the
current and upcoming challenges of the web apart from the previous challenges of, shall we
say, the “traditional web.” Wrangling the emerging mobile or whatever web requires some
serious dev chops. So simply saying THE WEB doesn’t feel very satisfying either.

That was fruitless.
• I’m going to say “device”
• And I’m going to say “mobile web”
• But keep in mind the underlying subtleties.


For those who are saddling up and building the
mobile web, I applaud you.


And now, as we embark, I want to give a shoutout to all of my other dev brothers and sisters.
This is a brave new world. I salute you.

Crap! It doesn’t
look quite right
Or: How I learned to stop worrying and set
my web sites free


The situation today

photo by the internet


Let’s start with some good news! The current situation with the web and the mobile web is a
bit of a recipe for FAIL. How’d this happen? Well, it started from the beginning.

In the 1990s, the Web was born, and boy, was it
awesome.


The beginning of the web, that is. We reached out to it, we embraced it because.


Starry-eyed and enthusiastic, were so busy viewing source in Mosaic and learning how to
make transparent GIFs that we kind of neglected to grapple what we were up to. And we
kinda broke it a bit. That’s totally me in the 90s, wearing my college sweatshirt.

Striking out on a new medium, we had
a tendency to cling to the metaphors
we already knew.


It is perfectly natural to project the characteristics and constraints of a known medium onto
an emerging medium. Problem is, we never let go. What am I talking about here?

fixed-width layouts
spacer.gif

We took (illusory) control.

tables for layout

rigid columns

frames font sizes


To make the web do what we thought we wanted it to, and spurred by the needs and
demands of our customers, we grasped for control. Smart people had some clever ideas of
how to work around the constraints of the web to make it behave more like print media.
But...at what long-term cost?

“Please make the sentence fit all on one
line, like it does on the brochure.”

We acted like we had control, and our
customers believed us.

“Could you move the logo a half
pixel to the right?”


Our customers believed that we had control. We sort of built monsters. We were selling pixel-
perfect control.

176x208

240x320

640x480 320x480

800x600

1024x768

1160x900

2560x1600


We approached the web as a series of slowly-increasing, static resolutions. We built rigid
windows into our content. We thought we saw a pattern. Screens are getting bigger, and
screen size is what deﬁnes our worlds. That’s what we told ourselves. Except. Oh! Mobile
came along! Then they started getting smaller again. Oh, wait! Internet televisions? bigger
again. This is breaking down!

We got away with this illusion of
control for awhile. But with the
explosion of mobile devices, browsers
and platforms, this forced control of
uncontrollable constraints is one of
the things that it is making it clear:


We R DOIN IT
RONG.
Our false sense of control over layout combines
with other factors to make life for us on the
current pan-device web very di!cult indeed.


At least, in some part, we’re doing it wrong. Not in all ways, but certain things we cling to are
hindering us in the quest for a better web.

Some other elements
of the dilemma
This is not my beautiful web. How did we get here?


OK, I’ll relinquish my obsession with layout for just a moment. There’s other stuff going on
that is making the mobile web very hard. Let’s look at the building blocks of our failboat.

local storage
web sockets iOS Update breaks my video!
WebOS is dead. Long live WebOS

A new browser quirk Device detection Mobile transcoders

Broken CSS selectors HTML5 Geolocation on BlackBerry OS 4

No one can possibly “know enough”
broken box model Microformats
Media Queries
CSS transforms on mobile

A new, slightly broken Android
Responsive images
cache manifest

Feature detection
People still use OpenWave?
different UI conventions
Today’s newest JavaScript framework
Mango! IE9
HTML5 input types
JavaScript performance
DOM disasters Viewport tag


It seems like today’s choices are either implement (and not keep up) or keep up (and never
have time to implement). Today’s mobile web expert really does need to be a rocket surgeon.
I would posit that it is not possible keep up fully, at all.

Legacy baggage

photo by Michael Coté


We’re hobbled by legacy systems. Content Management Systems, those hefty tools we’ve
built over the years to allow “regular humans” to build and manage web content, are
completely wrong for the many-device web. Their templating scenarios are a nightmare.
Proprietary systems are even worse.

CMSes and WYSIWTF

Seeking to empower normal humans,
we built WYSIWYG editors that let
folks do everything from making text
purple to uploading 3MB images into a
form eld. Whoops?


How do you build content—and how do you teach your customers to build content—in a way
that allows for meaningful markup that actually works on various devices? Today’s so-called
WYSIWYG editors are hopelessly under-qualiﬁed for the task. Bad habits again catching up
with us.

We aren’t always using best practices*
• Conflation of presentation and content
• Bloated sites and resources that assume broadband-

level connections
• Lack of basic accessibility and graceful degradation

* a.k.a. “Don’t have much time for getting this right,” “gotta ship,” “over
budget,” “client doesn’t care,” and “laziness.”


These things, while nice and important on the traditional web, are vital on the new web. To
get the job done on the previous-web (whatever we’re calling that), we built tools that are
now shooting us in the foot. We weren’t good enough about separating content from
presentation. WE got lazy. We have to be better.

We don’t get to make excuses, though.
As devs, we’re on the front lines,
expected to work around obscure and
stupid stu#.


Although these things are stacked up against us, We don’t get to make idealistic excuses for
why it’s broken. We have to ship.

Each new device, OS version, browser,
browser version...


Just serves to multiply the chaos.



Please, make it stop.

The current situation
feels un-
Un-scalable.
Un-testable.
Un-surmountable.*

* Yes, I know how this word is supposed to look normally.


Un-scalable.


Experiment 1.


10 very experienced mobile web professionals...

photo by lukew, modications by me


A few weeks ago, I and 9 other people far smarter than myself secluded ourselves in the
Tennessee woods.

Isolated in a rural house...

photo by brad frost


We called this #mobilewood.

Working on a single project.


Although we had an awful lot of fun, culminating in me falling into a bonﬁre at one point, we
worked our tushes off.

http://futurefriend.ly


Building a manifesto, an idea, and a way of forging into the future. Trying to coalesce the gist
of what we sense is the right direction.

Dev

Testing

Iterating


Madly, we built the site to express our ideas.

By the time we launched...


Exhausted...


Having debugged as much as possible...


...about 100 hours’ time had been invested.


Hmm. If you run the numbers...


That’s about $15,000-20,000* at
average going rates.

*£10,000 - 13,000


For three simple, static web pages.


With a grand total of two images, no interactivity and all of the content is entirely static.

Experiment 1 working hypothesis:
This cannot scale.


The barrier to entry for quality web development for the entire mobile web is too high.

Un-testable*.

* To be clear, I’m not saying it’s 100% untestable. I’m saying it’s 100%
impossible to test it 100%. Which makes it, in a sense, untestable.


It feels very hard to test, this mobile web. Just thinking about testing makes me feel a bit
woozy.

So you think you can build a device
library?


So, what about building a device library to do your testing with?

Heck, we’re going to try


Cloud Four helped to found Mobile Portland in 2008, which has become a rambunctiously
successful little organization and is now an official non-proﬁt. Mobile Portland is currently
working with device and browser manufacturers and carriers to establish a mobile device
testing lab in our offices in downtown Portland.

But even so, there is no way we could
possibly have access even a small
percentage of all of the...


This is a rather ﬁrst-of-its-kind effort, and we are more than a little excited, but...

Devices

Platforms, OS Versions

Carriers and geographies

Mobile browsers


Sigh. This massive fragmentation...


What we’ll have will barely be a drop in the pond of all of the device combinations out there.

I didn’t do much math in college, but:


The number of combinations is sort of mind-
blowing*

* I think that’s the technical term.


“Our marketing manager has a
BlackBerry 8330 on Verizon. For him,
there is a weird border around all of
the links on the FAQ page.”
—Pretty much every customer ever


This is loosely based on typical real events. We’ve even had customers ship speciﬁc devices
to us and still been unable to reproduce client-reported bugs.

If I had a nickel for everything like
that...


Sure, we test the heck out of things, but if I had a nickel for every time I heard something
like...

I could probably
retire young.

photo by Volker Neumann


Even a well-stocked device library is
never going to be able to represent the
full gamut of what’s out there.


There are just too many combinations.

And there are only so many hours in
the day.


And just because you haven’t tested it doesn’t mean it’s not broken.

Un-surmountable.


All this combines to make the mobile web feel unwinnable.

It can’t go on like this.*
* (But it likely will. For a while.)



The landscape feels pretty grim.

Well, that was
depressing.
Now what?


That was quite an onslaught of the bleak. Did I bring you here to make you swear off the web
forever?

Take heart.


We can’t x everything right now, but by

thinking in a future-friendly manner and
relinquishing control we never had in the rst place,
we can help shape the future of the web.


Um, how?


Things we can do right now.


Deep breath. Release.


Four considerations
and four weapons you
can use right now, in
the short term.


Consideration 1: Start
to free your content.
“Content like water”



Like I keep harping on and on and on about, we’ve had a habit of keeping our
content in arbitrary cages, and we’re ignoring it at times, waylaid by the sound and
fury of other distractions. It wants out. We can help liberate it by retooling our
design practices.


These new practices are some rst steps to treating our content like water.


Opening the door to future greatness and content freedom.

Old and busted.


The first mistake we often make when starting a new web site is to create a fixed-width,
blank canvas in photoshop and start cramming crap into it to fill the spaces. Oftentimes, we
ship off an approved mockup and never look back again. Implementation continues without
revisiting the design assumptions.


Our tired, one-size-ts-a-few desktop web shoe doesn’t t the new generation.

New hotness.


It’s time to get a bit smarter.


Updating the design process: Its about ﬂex, ﬂow and adaptation. Showing a bit more, telling
a bit less.

Do this.
Instead of delivering static image-based
comps at one or more “resolutions,” consider
wireframes that demonstrate the !ow and !ex
of content across a continuum of device and
window sizes, indicating major breakpoints.


Static, pixel-specific mockups lock in unrealistic expectations with clients about the way the
many-device web really works, and asserts that false control I keep whining about. Instead,
newer design techniques use proportional, simpler-feeling wireframes that show the site
adapting over a range of shapes, shifting flow more noticeably at defined breakpoints.

Image from “Pragmatic Responsive Design,”
Stephanie Rieger


This slide is from Stephanie Rieger’s great presentation about pragmatic responsive design,
which I’ll provide a link to at the end of this presentation, showing breakpoints in a design
her company, Yiibu, recently developed. Notice how the design adapts, and reﬂows to a
certain extent at each deﬁned breakpoint. There is no pre-determined set of breakpoints.
They are per-project. Notice how the design scales between breakpoints, and then shifts
noticeably at the breakpoints.


This kind of design gives your content the power to ﬁll its own spaces, and is an element of
Responsive Web Design, which I’ll come back to in a few moments. Like vector versus raster
graphics, this design approach is about proportion and ﬂexibility, not pixels and points.

Do this.
Build functional mockups—with
HTML where possible—so that
you can show (not tell).


Stay away from rigid mockups that lock in expectations with clients. Get your customers
seeing the ﬂow early and understanding the way that the design will adapt. Get yourself and
your customers handling the early prototype mockups on devices as soon as possible.

photo by Nick Thompson


Retune to design iteratively. No longer can you deliver design stuff once to a client and never
look back.

Do this.
Work in tight, focused loops of
iterative design to deal with
inevitable, device-specic tweaks
and inevitable client feedback.


Repetition and ﬁne-tuning is inevitable in the state of the new web. Content informs design
and as things shift, your design will need to adapt.


Granted, parts of this shift are a soft science, and hard for devs like me to glom onto easily.
However, the conversation does need to be steered over time and our customers enlightened.


We need to help communicate where we’re putting our emphasis, and how ﬂexible content
that is adaptive is really a good plan for the future. It won’t sell itself overnight, but let’s start
trying to talk about it. This is new stuff. We’re forging the future.


Oh, dear, so while we’re talking about honoring content, what about that problem with user-
generated content and WYSIWYG editors and markup, oh, my!


There are a couple of bridging techniques you could use while we work toward ﬁxing the
content and CMS disaster. What I’m saying is: no one has fully solved this problem yet.

Do this.
Work with customers to build or
adapt existing APIs to access or
munge content.


WYSIWYG doesn’t really exist. Until we can afford to retool all of the existing, mired legacy
systems out there, continue to fight the fight of separating content from presentation. On in-
depth projects, work with customers to build APIs to access content and data. You’d be
pleasantly surprised at how often APIs actually already exist, and how flexible customers’ dev
teams can be about building or extending them.

Do this.
Consider less presentation-
littered options like markdown or
textile for existing CMSes.


But you can’t always build or use APIs. Another option is, for existing CMSes and less-than-
techy editorial customers, more minimal markup concepts like markdown or textile, which
keep presentation minimal in stored content, and also have the nice, future-friendly habit of
being human readable.

Consideration 2:
Essentials first!
Progressive enhancement isn’t just for the
cool kids. It’s required.


Many of you may have heard of the Mobile First mantra. My colleague Luke W. is a leading
proponent of this and has recently published an eponymous book. The idea of mobile ﬁrst is
to, well, design for mobile ﬁrst, and expand that design out to enhance for larger or more
powerful devices, e.g. the desktop.

Mobile rst!
Essentials rst!


I think we’re onto something with this idea, hugely, but that maybe the word “mobile”, again,
is distracting us from what we’re really trying to accomplish. Maybe it’s more like essentials
or baseline ﬁrst.

photo by seattle.roamer


Either way, the point is, we got fat and lazy in many way and we need to start trying to pare
down our focus and get at what really matters in our web sites.


This is a bigger-picture thought process about simplification and focus. A mobile- or
essentials-first attitude can help us go on a diet and figure out what really matters. It’s good
for us, and It’s not just about mobile.


Finding serenity and meaning with your markup. Start from nothing. No JavaScript, no CSS.
Figure out what content, services and functionality matter for every user. By starting simple,
we avoid introducing (from the outset) complexity that will hinder our success, which is to
work on as many devices as possible.

Do this.
• Get laser-sharp focus on your markup. Start
with HTML. Believe in the HTML.

• Essentials rst. Focus on semantics, clarity
and simplicity. Is this the content that is
core to all of your users?


Become extraordinarily friendly with the ins and outs of HTML5. This may seem like a no-
brainer, but I think one of the things we’ll see in the near future, as a result of the desperate
need for simpliﬁcation, is some innovative approaches that build on rock-solid HTML5 and
probably some more frameworks that can do some of the annoying stuff that is so hard for
us.

Consideration 3: Now,
arm the weapons!
Adapt, enhance and optimize: a bunch of
tools for your arsenal. Here come some slides
with text on them!


We’ve got our future-friendly HTML5 and we’re ready to do something with it. There are
some tools out there to help simplify our lives and get our jobs done effectively. Some of
these tools and ideas are bridging techniques until the world gets to be a bit of a safer place.
Some are just great things.

Engage weapon 1: Adapt and !ex
with Responsive Web Design
(RWD)



This is the article in A List Apart that introduced the idea of Responsive Web Design.
Brainchild of Ethan Marcotte, Responsive Web Design combines several implementation
techniques to bring to life the kind of ﬂowing, adaptive layouts I’ve been talking about.


Using a combination of CSS 3 media queries, fluid grids and fluid images and media, we can
build those flow-like-water layouts that adapt more easily across a lot of devices.

1: CSS 3 Media Queries

@media all and (min-width: 480px) { }


There are three technical underpinnings to the RWD approach. A quick CSS 3 Media query
primer for those who might not be initiated. CSS Media queries (one of the forty or so CSS 3
modules) let you selectively APPLY different CSS based on logical conditions. In this case, the
CSS rules between the brackets are applied only if the window width is greater or equal to
480px.

2: Fluid media.

img, object { max-width: 100%; }


With this simple CSS rule comes great power. This makes our images and embedded objects
scale with the size of the containing element. Don’t forget that (at least not without great
futzing) you can’t use width and height tags on images and objects managed in this way.
This one really is this simple: just drop this rule into your CSS.

3: Fluid grids.
• CSS layouts based on proportional elements.

• Type in ems.

• Widths in percentages.

• Flexy, !exy!


If you’re not doing fluid layouts now, you should be. Learning how to do it takes about half
an hour, and then you may find that your life is changed a bit for the shinier. Fluid grids use
percentages for body element widths and ems for type (typically). What does this mean? It
means that you’re not locking in any fixed units, and your design can scale. Fluid grids are a
riff on flexible grids, which have been around for a while. You can learn how to make them by
reading Ethan’s ALA article or his quick-read book.


In this simple responsive design I threw together, you can see how three columns collapse
into one on a narrower screen. I’ve used a media query to apply different CSS based on
screen width. The layout is a ﬂuid grid, with element widths deﬁned with percentages.


And also here, the use of ﬂuid images allows the photo to scale with its container, ﬁtting as
well into the single-column layout as the multi-column layout.


Although there is a lot of hubbub about the specifics of RWD implementation (in fact, Cloud
Four co-founder Jason Grigsby wrote a controversial post about media queries that has
seriously made the rounds), try to let your mind float past the specifics about and meditate
on the premise, which has a certain harmony. Borrowed to some extent from ideals of
physical architecture, RWD is about flowing the content, adapting the environment around
the user instead of trying to control the experience rigidly or making the user adapt.

Do this.
Use media queries to enhance
layout. Avoid media queries in
your baseline, reference
implementation.


Consider media queries as an enhancement technique. That way you’re not relying on
support in your baseline, content-is-king version. Hey, this is a great way of letting go of
some crap to worry about!

Do this.
You may need to use shims for IE.
But most desktop browsers are
media-query-savvy.


You may need to use a JavaScript shim, if the media queries you’re making need to work in IE
7, 8 or whatever.

Do this.
Keep your eyes on your media and
image (!le) sizes! Take a peek at
Responsive Images (by Scott Jehl)
or server-side techniques.


Just because you’re scaling images using the ﬂuid technique doesn’t mean you’re out of the
woods. You’re still delivering all of the bytes that are in the full-sized image.

Do this.
We’ve found that it’s OK (and
relieves a bit of pressure) to leave
a bit of unmanaged gutter
(percentage) space in !uid
layouts.


A lot of the tutorials out there for ﬂuid grids have you accounting for every last scrape of
room in the design, often resulting in, literally, percentages with 6 or 7 decimal places. At
Cloud Four, we’ve found that we often avoid browser rounding difference issues and, really,
just painful math, by allowing for a ﬂoating percentage or two to creep into the space of the
design. Less precision-control, perhaps, but less likely to cause box-model rounding errors,
esp. in IE.

Target lock with weapon 2: Enhance
and adapt with client-side feature
detection



With client-side feature detection, you can ask questions like, hey, do you support the HTML5
audio tag? I’d like to drop in some sound!


These client-side feature detection tools ask the browser to tell us if it supports something
right at this very second. Then we can enhance our content based upon the answer.


Modernizr is a prime contender in this space, and there are other cool polyﬁlls, shims and
tools like yepnope.js, adapt.js...


Sometimes it feels like there is a new JavaScript tool, library or framework every day. It can be
hard for me to keep my house in order! But the up side is that there are tons of things to help
you get your job done out there.

Do this.
Keep it e$cient. Use Modernizr’s
new-ish modular approach to
build your feature detection.


Don’t throw in the kitchen sink! This keeps your JavaScript payload size small and demands
less of your user’s browsers and CPUs.

Know this.
Client-side feature detection
works most of the time. But it is not
infallible (have you noticed that
nothing is?).


Weapon 3: Rocking it old skool on
the server side



You can do some heavy-lifting on the server side, some gearwork so that you’re not putting
so much pressure on lighter clients.

Server-side devs #represent
• There are absolutely valid reasons that you might
want to alter markup before you serve it to clients.
Here are some words that start with “Re-.”

• Reordering

• Reduction

• Respect


User Agent Sni$ng

photo by ex.libris


Sometimes user-agent sniffing gets a bum rap, but I’m done apologizing. In our wild world,
there is often not another viable tool. Making our best estimates about an incoming device is
not something only small-time folks do; most major websites that have mobile optimization
are using device detection of some sort, and the vast majority of those hinge on user agent
strings. It ain’t perfect, but it works.

Device Databases

photo by Tim Morgan


So, given a user agent string, how do we know more information about the client? That’s the
job of device databases, which look up various capabilities based on, well, usually, a user
agent string. We can make good ﬁrst estimates about the resolution, browser version, video
support, etc.


You gotta crack some eggs sometimes to make that tasty omelette. This isn’t about locking
people out or dumbing down their content or locking them in to a particular view of content.
There’s some nuance that can be used here.

Do Don’t this.
• Don’t be afraid to do some server-side optimization.
Don’t let the bastards get you down.

• Don’t overdo it.
• Don’t leave folks out in the cold (without an escape
mechanism).


Don’t this. And by combining server-side detection with clients-side detection, you can ﬁnd
considerably more nuance.


There’s also a bit of Zen in the combination of weapons 2 and 3, that is, using a server-side
approach to make an educated ﬁrst stab, and augmenting or correcting this guess with live,
client-side feature detection. Bryan Rieger at Yiibu has done some very good work in this
area...

Killer Weapon #4: Optimize the
hell out of it


Do this.
Huge, huge improvements can often be made
in a couple of minutes by editing
your .htaccess or apache conguration le.


You don’t get a get-out-of-jail-free card on this one. Performance on mobile matters more
than ever. It’s amazing the massive performance improvements that can be made that are
routinely overlooked by devs. These are simple changes that have huge impact.

Do this.
Get the YSlow extension for
Firebug in your browser. Read it,
study it, know it.


GZip. Don’t even really consider not doing it.
# Add gzip compression
IfModule mod_deflate.c
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/atom_xml
/IfModule


I’m giving you some basically cut-and-pastable code for an .htaccess ﬁle so you can’t use the
excuse that you don’t know how. This madly, madly cuts payloads.

Far-future expires headers
IfModule mod_expires.c
# Enable expirations.
ExpiresActive On
# Cache all files for 2 weeks after access (A).
ExpiresDefault A1209600
/IfModule


Tell browsers not to refresh content for a while; keep it cached. Be aware that when you’re
turning this on, you’re kind of locking yourself into the ﬁle version. You’ll have to invent a
ﬁle-naming convention to work around this.

cache manifests

AddType text/cache-manifest .appcache


I won’t lie. Futzing with cache manifests is a bit of a ﬁnicky business. You may need this in
your apache conﬁg/.htaccess to make them work.

cache manifests
CACHE MANIFEST

CACHE:

/assets/fflogo.png
/assets/signed.png

/index.html
/thinking.html
/resources.html

/styles.css

NETWORK:
*


Here’s the contents of the cache manifest on futurefriendly.

IV. Now find places to
draw the line.
Letting go and finding a bit of balance.


Plant the seed early.


Plant the seed early. As much as I loathe the expression: “Set expectations.” Learn to talk
about what devices can and cannot do, how browsers break, and how you can’t control
everything.

Take note of when you get mired.


Sometimes when you’re deeply in dev, you can’t see the forest for the trees. Learn to
recognize when you’re mired. Take note. Try not to chase your tail quite as much.

Don’t fear the occasional egregious hack.


Don’t be afraid to pull out an egregious hack or two. Use your best duct tape programming
skills, as per Joel Spolsky.

Put your energy into the devices that “matter.”


Focus on the devices that matter. That doesn’t mean to do this at the expense of everyone
else, but don’t get mired in small tweaks for every single thing out there.

Fail with grace.


Be ready to fail gracefully a bit when you set your site free. You have the good underpinnings
there to fall back on.

And what about the future?
Looking further ahead.


Disruption will only accelerate. The quantity and diversity of
connected devices—many of which we haven't imagined yet—will
explode, as will the quantity and diversity of the people around the
world who use them. Our existing standards, workflows, and
infrastructure won't hold up. Today's onslaught of devices is already
pushing them to the breaking point. They can't withstand what's
ahead. Proprietary solutions will dominate at first. Innovation
necessarily precedes standardization. Technologists will scramble to
these solutions before realizing (yet again) that a standardized
platform is needed to maintain sanity. The standards process will be
painfully slow. We will struggle with (and eventually agree upon)
appropriate standards. During this period, the web will fall even
further behind proprietary solutions.

http://futurefriend.ly


Emancipating mobile browsers from
the ghetto.


What does this mean? For one thing it means changing the conversation that has...

Changing the conversation.


Changing the conversation? Yes, right now the tone is slightly odd. As devs, we consider it
our responsibility to deal with the myriad, weird, speciﬁc, quirky device and browser bugs.
We should try to slowly turn this conversation back around and make the onus on device and
OS and browser makers—the people who actually have control over this—make things work
as advertised, and deliver on promises.

Be future friendly.


Some of the considerations I talked about run parallel to the future friendly ideals. We’re still
ironing out the kinks.

We can steer this ship.


We’re not totally sure exactly what the future looks like. But by thinking in a future-friendly
manner, you can help get the ship on track.

Victory can be ours.


I believe that, though the ride will be bumpy for a while, the increasing chaos will eventually
reach a tipping point—at least I hope so.

Remember, this isn’t religion.


And we’re all on the same team. Don’t let yourself get caught up in over-idealized squabbles.
Let’s work together.


Set it freeeeeee!

Must-Reads
• All of the resources on http://futurefriend.ly/resources.html
• “Pragmatic Responsive Design” Stephanie Rieger http://
www.slideshare.net/yiibu/pragmatic-responsive-design
• Responsive Web Design, Ethan Marcotte http://www.abookapart.com/
products/responsive-web-design
• Mobile First, Luke Wroblewski, http://www.abookapart.com/
products/mobile-first
• “Meta Layout: A Closer Look at Media Queries”, Stephen Hay
http://www.slideshare.net/stephenhay/mobilism2011
• “Rethinking the Mobile Web” Bryan Rieger http://
www.slideshare.net/bryanrieger/rethinking-the-mobile-web-by-
yiibu
• “The Duct Tape Programmer” Joel Spolsky http://
www.joelonsoftware.com/items/2009/09/23.html


Coming soon.


Thanks for enduring me!
Lyza Danger Gardner
lyza@lyza.com
@lyzadanger

Photos ‘n stu# in this
presentation are mine
unless otherwise noted
Youcanuse‘em
too(Creative
Commons)

Crap! It doesn't look quite right, or, how I learned to stop worrying and set my mobile web sites free

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Crap! It doesn't look quite right, or, how I learned to stop worrying and set my mobile web sites free

Ähnlich wie Crap! It doesn't look quite right, or, how I learned to stop worrying and set my mobile web sites free (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Crap! It doesn't look quite right, or, how I learned to stop worrying and set my mobile web sites free