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 rightOr: How I learned to stop worrying and set

my web sites free

Lyza Danger Gardner / [email protected]@lyzadanger / Over the Air, 2011

Monday, October 3, 11

mailto:[email protected]


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+

=Cloud Four

I�� am�� on�� a�� team�� with�� some�� wickedly�� smart�� people

Dramatis personae}


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.


2008Flashback�� to


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

I was fortunate enough to be on the team that developed the Obama iPhone app.

As luck would have it...


This was a mere few months after the initial launch of the App Store.

Everyone was very excited.

What an exciting time.


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.

photo by Robert Goodwin

Now what?

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


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?

http://www.flickr.com/photos/sideshowblues/2690419548

http://www.flickr.com/photos/sideshowblues/2690419548

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 fine-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 flash-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 find the closest shop, bar, or restaurant that carries a specific brew that Deschutes makes. Fun stuff! We love the mobile web.

The web is hard.mobile


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.

photo by Dave Patten

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


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.

http://www.flickr.com/photos/davepatten/124418044/

http://www.flickr.com/photos/davepatten/124418044/

So many devices.


It’s about making the web fit 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)+

platform+

OS+

browser+

carrier/connectivity elements

Chances�� are,�� we�� mean�� bits�� and�� bots�� of�� various�� things


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 WEBpan-device web?

future web?

universal web?the interblags?

web for all?

web 3.0?

The One Web?

portable web?

Ugh!�� VetoOh,�� whoops,�� the�� W3C�� already�� nabbed�� this�� term

the web of now?


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 rightOr: How I learned to stop worrying and set

my web sites free


photo by the internet

The situation today


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?

We took (illusory) control.

tables for layout

frames

spacer.gif

fixed-width layouts

rigid columns

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?

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

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

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


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

2560x1600

1160x900

1024x768

800x600

640x480 320x480

240x320

176x208


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 defines 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.

No one can possibly “know enough”

A new browser quirk

A new, slightly broken Android

Mobile transcoders

Responsive images

Feature detection

Device detection

Today’s newest JavaScript framework

CSS transforms on mobile

HTML5

iOS Update breaks my video!

Mango! IE9

Media Queries

Geolocation on BlackBerry OS 4

HTML5 input types

Broken CSS selectors

JavaScript performance

cache manifest

local storageweb sockets

broken box model

different UI conventions

People still use OpenWave?

WebOS is dead. Long live WebOS

Viewport tag

Microformats

DOM disasters


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.

photo by Michael Coté

Legacy baggage


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.

http://www.flickr.com/photos/cote/54408562/

http://www.flickr.com/photos/cote/54408562/

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?

CMSes and WYSIWTF


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-qualified 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, modi"cations by me


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

http://www.flickr.com/photos/lukew

http://www.flickr.com/photos/lukew

Isolated in a rural house...

photo by brad frost


We called this #mobilewood.

http://www.flickr.com/photos/brad_frost/6165231108

http://www.flickr.com/photos/brad_frost/6165231108

Working on a single project.


Although we had an awful lot of fun, culminating in me falling into a bonfire 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-profit. 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 first-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:


* I think that’s the technical term.

The number of combinations is sort of mind-blowing*


“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 specific 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...

photo by Volker Neumann

I could probably retire young.


http://www.flickr.com/photos/prawnpie/285546553

http://www.flickr.com/photos/prawnpie/285546553

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 flex, flow and adaptation. Showing a bit more, telling a bit less.

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.

Do this.


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 reflows to a certain extent at each defined 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 fill 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 flexibility, not pixels and points.

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

Do this.


Stay away from rigid mockups that lock in expectations with clients. Get your customers seeing the flow 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.

http://www.flickr.com/photos/pelegrino/3957449915/

http://www.flickr.com/photos/pelegrino/3957449915/

Work in tight, focused loops of iterative design to deal with inevitable, device-speci"c tweaks and inevitable client feedback.

Do this.


Repetition and fine-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 flexible 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 fixing the content and CMS disaster. What I’m saying is: no one has fully solved this problem yet.

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

Do this.


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.

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

Do this.


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 first is to, well, design for mobile first, 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 first.

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.

http://www.flickr.com/photos/pahphotos/3454871464/

http://www.flickr.com/photos/pahphotos/3454871464/


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.

• 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?

Do this.


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 simplification, 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 flowing, 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.

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

1: CSS 3 Media Queries


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 fluid grid, with element widths defined with percentages.


And also here, the use of fluid images allows the photo to scale with its container, fitting 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.

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

Do this.


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!

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

Do this.


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

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

Do this.


Just because you’re scaling images using the fluid 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.

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.

Do this.


A lot of the tutorials out there for fluid 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 floating 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 polyfills, 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.

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

Do this.


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

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

Know this.


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.

• 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

Server-side devs #represent


photo by ex.libris

User Agent Sni$ng


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.

http://www.flickr.com/photos/exlibris/2498153305/

http://www.flickr.com/photos/exlibris/2498153305/

photo by Tim Morgan

Device Databases


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 first estimates about the resolution, browser version, video support, etc.

http://www.flickr.com/photos/timothymorgan/75593157

http://www.flickr.com/photos/timothymorgan/75593157


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.

• 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).

Do Don’t this.


Don’t this. And by combining server-side detection with clients-side detection, you can find 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 first 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


Huge, huge improvements can often be made in a couple of minutes by editing your .htaccess or apache con"guration "le.

Do this.


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.


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

Do this.


# 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>

GZip. Don’t even really consider not doing it.


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

<IfModule mod_expires.c> # Enable expirations. ExpiresActive On # Cache all files for 2 weeks after access (A). ExpiresDefault A1209600</IfModule>

Far-future expires headers


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 file version. You’ll have to invent a file-naming convention to work around this.

AddType text/cache-manifest .appcache

cache manifests


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

cache manifestsCACHE 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.





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, specific, 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


http://www.slideshare.net/yiibu/pragmatic-responsive-design




http://www.abookapart.com/products/responsive-web-design




http://www.abookapart.com/products/mobile-first




http://www.slideshare.net/stephenhay/mobilism2011

http://www.slideshare.net/stephenhay/mobilism2011

http://www.slideshare.net/bryanrieger/rethinking-the-mobile-web-by-yiibu






http://www.joelonsoftware.com/items/2009/09/23.html




Coming soon.


Thanks for enduring me!

Lyza Danger [email protected]@lyzadanger

Photos ‘n stu# in this presentation are mine unless otherwise noted

You�� can�� use�� ‘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

Technology

nomobile web

web technologies

web sites andapplications

coms mobile site

cloud fourmonday

standalone mobile sitesin

gamut site

im lyza