1.
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, 2011Monday, October 3, 11

2.
Hi, there, Bletchley Park. My name is Lyza.Monday, October 3, 11

3.
I love the web. photo by lukewMonday, October 3, 11Hi, I’m Lyza. I love the web. I always have. Ever since the 1990s, when the web was just a weebaby.

4.
I hail from Portland. Hi!Monday, October 3, 11I 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.

5.
Monday, October 3, 11In Portland, we are known for our coffee.

6.
Monday, October 3, 11Our beer...

7.
Monday, October 3, 11...and our foodie inclinations.

8.
Portland is also famous for its hipsters, bikes and other stu! I don’t have photos of. Come visit. It’s fun.Monday, October 3, 11And a host of other trendy things. Portland’s grown a reputation of late and is particularly thedarling of the New York Times, which publishes fawning articles about its quaintnessregularly. As you can tell, I’m proud of the town. And it also has a strong mobile developmentcommunity.

9.
Portland + Interwebs + mobile + Iamonateam withsome wickedlysmart } Dramatis personae people = Cloud FourMonday, October 3, 11So, I live in Portland, and in 2007 I helped co-found Cloud Four with three other folks I’veworked with for over a decade. We came from a deep “traditional” web background and wewanted to seize on the incredibly neat opportunities provided by mobile.

10.
Cloud Four chose the web. It was in no way an easy choice.Monday, October 3, 11

11.
2008 FlashbacktoMonday, October 3, 11We founded Cloud Four in 2007, with an initial vision of mobile web goodness. In 2008, a lotof stuff happened.

12.
As luck would have it... I was fortunate enough to be on the team that developed the Obama iPhone app.Monday, October 3, 11

13.
What an exciting time. This was a mere few months after the initial launch of the App Store. Everyone was very excited.Monday, October 3, 11This was in the late summer of 2008, mere months after the initial launch of Apple’s AppStore in the US. Everyone was basically quivering with excitement.

14.
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 GoodwinMonday, October 3, 11At Cloud Four, we were faced with a crossroads. Colleagues we knew and admired werethrowing in their lot with native iOS apps. Should we stick with our original dream, pinningour hopes on what we see as a more democratic, more universal and more meaningfultechnology?

15.
What apps can do, the web can do, too...Monday, October 3, 11Cloud Four co-founder Jason Grigsby went over the features of the Obama application with afine-toothed comb. His realization here? There’s nothing in this app that couldn’t beaccomplished with web technologies.

16.
Since then, at Cloud Four...Monday, October 3, 11Epiphanies like this helped us make up our minds. We stuck with the web. Since then, we’vebuilt stuff.

17.
High-performance mobile web applications and sites.Monday, October 3, 11Like Hautelook.com’s mobile site. Hautelook is a fashion flash-sale site with extreme trafficspikes as, at 8am each morning, frantic fashion-conscious bargain-seeking shoppersdescend on the site. It is one of the top 2k sites in the world, and boy, howdy are shoppersgoing to be mad if they can’t access the site because of performance problems or renderingissues.

18.
Web sites and applications for both “desktop” and “mobile” devices and browsers.Monday, October 3, 11But it’s not all about standalone mobile sites—in fact, we generally aim for the opposite. Forexample, we build this full-gamut site for a local craft brewery in Oregon. There’s some neatstuff going on here that you couldn’t do before mobile, for example, we use geolocation tohelp users find the closest shop, bar, or restaurant that carries a specific brew that Deschutesmakes. Fun stuff! We love the mobile web.

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

20.
(A brief aside) regarding terminology.Monday, October 3, 11Before we get down to our little chat here, I want to take a moment to make annoyingobservations about linguistics.

21.
“There is no mobile web.” —Jeremy Keith (@ada!io)Monday, October 3, 11Well-known web dude Jeremy Keith gave a presentation a few weeks ago at the BreakingDevelopment Conference in Nashville, Tenn. The title of his presentation was “There is nomobile web.” At the time, I thought he was trying to stir up a bit of controversy.

22.
At rst, I didn’t get it.Monday, October 3, 11Surely, this is splitting semantic hairs? But then I thought about it a bit more.

23.
The stu# we’re up against is bigger than a pile telephones photo by Dave PattenMonday, October 3, 11Not everything that browses the web is a desktop computer or a telephone. By referring tothe “mobile web,” we’re both ignoring the broader context and acting like there is more thanone web, when in fact the goal is universality.

24.
So many devices.Monday, October 3, 11It’s about making the web fit a vast array of devices and platforms. Everyone lovesmentioning those still-odd outliers like Automobiles. Refrigerators. Wristwatches. Yes, mobiledevices like phones represent the big thrust, but the meaning is deeper.

25.
also...Monday, October 3, 11Just to make things yet more complex...

26.
What do we mean when we say “device?” device itself (hardware) + Chancesare,we platform meanbitsand + botsofvarious OS things + browser + carrier/connectivity elementsMonday, October 3, 11We 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.

27.
Upside-down, devil’s-advocate Lyza asks self: All right, then, smarty pants, what do you suggest?Monday, October 3, 11Then I get frustrated with myself.

28.
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?Monday, October 3, 11There are some nomenclature options. But none seem right, and none capture the essence ofwhat’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 toit, what we’re talking about is THE WEB. But then one loses track of the elements that set thecurrent and upcoming challenges of the web apart from the previous challenges of, shall wesay, the “traditional web.” Wrangling the emerging mobile or whatever web requires someserious dev chops. So simply saying THE WEB doesn’t feel very satisfying either.

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

30.
For those who are saddling up and building the mobile web, I applaud you.Monday, October 3, 11And 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.

31.
Crap! It doesn’t look quite right Or: How I learned to stop worrying and set my web sites freeMonday, October 3, 11

32.
The situation today photo by the internetMonday, October 3, 11Let’s start with some good news! The current situation with the web and the mobile web is abit of a recipe for FAIL. How’d this happen? Well, it started from the beginning.

33.
In the 1990s, the Web was born, and boy, was it awesome.Monday, October 3, 11The beginning of the web, that is. We reached out to it, we embraced it because.

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

35.
Striking out on a new medium, we had a tendency to cling to the metaphors we already knew.Monday, October 3, 11It is perfectly natural to project the characteristics and constraints of a known medium ontoan emerging medium. Problem is, we never let go. What am I talking about here?

36.
fixed-width layouts spacer.gif We took (illusory) control. tables for layout rigid columns frames font sizesMonday, October 3, 11To make the web do what we thought we wanted it to, and spurred by the needs anddemands of our customers, we grasped for control. Smart people had some clever ideas ofhow to work around the constraints of the web to make it behave more like print media.But...at what long-term cost?

37.
“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?”Monday, October 3, 11Our customers believed that we had control. We sort of built monsters. We were selling pixel-perfect control.

38.
176x208 240x320 640x480 320x480 800x600 1024x768 1160x900 2560x1600Monday, October 3, 11We approached the web as a series of slowly-increasing, static resolutions. We built rigidwindows into our content. We thought we saw a pattern. Screens are getting bigger, andscreen size is what defines our worlds. That’s what we told ourselves. Except. Oh! Mobilecame along! Then they started getting smaller again. Oh, wait! Internet televisions? biggeragain. This is breaking down!

39.
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:Monday, October 3, 11

40.
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.Monday, October 3, 11At least, in some part, we’re doing it wrong. Not in all ways, but certain things we cling to arehindering us in the quest for a better web.

41.
Some other elements of the dilemma This is not my beautiful web. How did we get here?Monday, October 3, 11OK, I’ll relinquish my obsession with layout for just a moment. There’s other stuff going onthat is making the mobile web very hard. Let’s look at the building blocks of our failboat.

42.
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 tagMonday, October 3, 11It seems like today’s choices are either implement (and not keep up) or keep up (and neverhave 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.

43.
Legacy baggage photo by Michael CotéMonday, October 3, 11We’re hobbled by legacy systems. Content Management Systems, those hefty tools we’vebuilt over the years to allow “regular humans” to build and manage web content, arecompletely wrong for the many-device web. Their templating scenarios are a nightmare.Proprietary systems are even worse.

44.
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?Monday, October 3, 11How do you build content—and how do you teach your customers to build content—in a waythat allows for meaningful markup that actually works on various devices? Today’s so-calledWYSIWYG editors are hopelessly under-qualified for the task. Bad habits again catching upwith us.

45.
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.”Monday, October 3, 11These things, while nice and important on the traditional web, are vital on the new web. Toget the job done on the previous-web (whatever we’re calling that), we built tools that arenow shooting us in the foot. We weren’t good enough about separating content frompresentation. WE got lazy. We have to be better.

46.
We don’t get to make excuses, though. As devs, we’re on the front lines, expected to work around obscure and stupid stu#.Monday, October 3, 11Although these things are stacked up against us, We don’t get to make idealistic excuses forwhy it’s broken. We have to ship.

47.
Each new device, OS version, browser, browser version...Monday, October 3, 11

48.
Just serves to multiply the chaos.Monday, October 3, 11

49.
Monday, October 3, 11Please, make it stop.

50.
The current situation feels un- Un-scalable. Un-testable. Un-surmountable.* * Yes, I know how this word is supposed to look normally.Monday, October 3, 11

51.
Un-scalable.Monday, October 3, 11

52.
Experiment 1.Monday, October 3, 11

53.
10 very experienced mobile web professionals... photo by lukew, modications by meMonday, October 3, 11A few weeks ago, I and 9 other people far smarter than myself secluded ourselves in theTennessee woods.

54.
Isolated in a rural house... photo by brad frostMonday, October 3, 11 We called this #mobilewood.

55.
Working on a single project.Monday, October 3, 11Although we had an awful lot of fun, culminating in me falling into a bonfire at one point, weworked our tushes off.

56.
http://futurefriend.lyMonday, October 3, 11Building a manifesto, an idea, and a way of forging into the future. Trying to coalesce the gistof what we sense is the right direction.

57.
Dev Testing IteratingMonday, October 3, 11Madly, we built the site to express our ideas.

58.
By the time we launched...Monday, October 3, 11

59.
Exhausted...Monday, October 3, 11

60.
Having debugged as much as possible...Monday, October 3, 11

61.
...about 100 hours’ time had been invested.Monday, October 3, 11

62.
Hmm. If you run the numbers...Monday, October 3, 11

63.
That’s about $15,000-20,000* at average going rates. *£10,000 - 13,000Monday, October 3, 11

64.
For three simple, static web pages.Monday, October 3, 11With a grand total of two images, no interactivity and all of the content is entirely static.

65.
Experiment 1 working hypothesis: This cannot scale.Monday, October 3, 11The barrier to entry for quality web development for the entire mobile web is too high.

66.
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.Monday, October 3, 11It feels very hard to test, this mobile web. Just thinking about testing makes me feel a bitwoozy.

67.
So you think you can build a device library?Monday, October 3, 11So, what about building a device library to do your testing with?

68.
Heck, we’re going to tryMonday, October 3, 11Cloud Four helped to found Mobile Portland in 2008, which has become a rambunctiouslysuccessful little organization and is now an official non-profit. Mobile Portland is currentlyworking with device and browser manufacturers and carriers to establish a mobile devicetesting lab in our offices in downtown Portland.

69.
But even so, there is no way we could possibly have access even a small percentage of all of the...Monday, October 3, 11This is a rather first-of-its-kind effort, and we are more than a little excited, but...

70.
Devices Platforms, OS Versions Carriers and geographies Mobile browsersMonday, October 3, 11Sigh. This massive fragmentation...

71.
Monday, October 3, 11What we’ll have will barely be a drop in the pond of all of the device combinations out there.

72.
I didn’t do much math in college, but:Monday, October 3, 11

73.
The number of combinations is sort of mind- blowing* * I think that’s the technical term.Monday, October 3, 11

74.
“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 everMonday, October 3, 11This is loosely based on typical real events. We’ve even had customers ship specific devicesto us and still been unable to reproduce client-reported bugs.

75.
If I had a nickel for everything like that...Monday, October 3, 11Sure, we test the heck out of things, but if I had a nickel for every time I heard somethinglike...

76.
I could probably retire young. photo by Volker NeumannMonday, October 3, 11

77.
Even a well-stocked device library is never going to be able to represent the full gamut of what’s out there.Monday, October 3, 11There are just too many combinations.

78.
And there are only so many hours in the day.Monday, October 3, 11And just because you haven’t tested it doesn’t mean it’s not broken.

79.
Un-surmountable.Monday, October 3, 11All this combines to make the mobile web feel unwinnable.

80.
It can’t go on like this.* * (But it likely will. For a while.)Monday, October 3, 11

81.
Monday, October 3, 11The landscape feels pretty grim.

82.
Well, that was depressing. Now what?Monday, October 3, 11That was quite an onslaught of the bleak. Did I bring you here to make you swear off the webforever?

83.
Take heart.Monday, October 3, 11

84.
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.Monday, October 3, 11

85.
Um, how?Monday, October 3, 11

86.
Things we can do right now.Monday, October 3, 11

87.
Deep breath. Release.Monday, October 3, 11

88.
Four considerations and four weapons you can use right now, in the short term.Monday, October 3, 11

89.
Consideration 1: Start to free your content. “Content like water”Monday, October 3, 11

90.
Monday, October 3, 11Like I keep harping on and on and on about, we’ve had a habit of keeping ourcontent in arbitrary cages, and we’re ignoring it at times, waylaid by the sound andfury of other distractions. It wants out. We can help liberate it by retooling ourdesign practices.

91.
Monday, October 3, 11These new practices are some rst steps to treating our content like water.

92.
Monday, October 3, 11Opening the door to future greatness and content freedom.

93.
Old and busted.Monday, October 3, 11The 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, weship off an approved mockup and never look back again. Implementation continues withoutrevisiting the design assumptions.

94.
Monday, October 3, 11Our tired, one-size-ts-a-few desktop web shoe doesn’t t the new generation.

95.
New hotness.Monday, October 3, 11It’s time to get a bit smarter.

96.
Monday, October 3, 11Updating the design process: Its about flex, flow and adaptation. Showing a bit more, tellinga bit less.

97.
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.Monday, October 3, 11Static, pixel-specific mockups lock in unrealistic expectations with clients about the way themany-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 siteadapting over a range of shapes, shifting flow more noticeably at defined breakpoints.

98.
Image from “Pragmatic Responsive Design,” Stephanie RiegerMonday, October 3, 11This 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 designher company, Yiibu, recently developed. Notice how the design adapts, and reflows to acertain 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 shiftsnoticeably at the breakpoints.

99.
Monday, October 3, 11This kind of design gives your content the power to fill its own spaces, and is an element ofResponsive Web Design, which I’ll come back to in a few moments. Like vector versus rastergraphics, this design approach is about proportion and flexibility, not pixels and points.

100.
Do this. Build functional mockups—with HTML where possible—so that you can show (not tell).Monday, October 3, 11Stay away from rigid mockups that lock in expectations with clients. Get your customersseeing the flow early and understanding the way that the design will adapt. Get yourself andyour customers handling the early prototype mockups on devices as soon as possible.

101.
photo by Nick ThompsonMonday, October 3, 11Retune to design iteratively. No longer can you deliver design stuff once to a client and neverlook back.

102.
Do this. Work in tight, focused loops of iterative design to deal with inevitable, device-specic tweaks and inevitable client feedback.Monday, October 3, 11Repetition and fine-tuning is inevitable in the state of the new web. Content informs designand as things shift, your design will need to adapt.

103.
Monday, October 3, 11Granted, 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.

104.
Monday, October 3, 11We need to help communicate where we’re putting our emphasis, and how flexible contentthat is adaptive is really a good plan for the future. It won’t sell itself overnight, but let’s starttrying to talk about it. This is new stuff. We’re forging the future.

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

106.
Monday, October 3, 11There are a couple of bridging techniques you could use while we work toward fixing thecontent and CMS disaster. What I’m saying is: no one has fully solved this problem yet.

107.
Do this. Work with customers to build or adapt existing APIs to access or munge content.Monday, October 3, 11WYSIWYG doesn’t really exist. Until we can afford to retool all of the existing, mired legacysystems 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 bepleasantly surprised at how often APIs actually already exist, and how flexible customers’ devteams can be about building or extending them.

108.
Do this. Consider less presentation- littered options like markdown or textile for existing CMSes.Monday, October 3, 11But 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, whichkeep presentation minimal in stored content, and also have the nice, future-friendly habit ofbeing human readable.

109.
Consideration 2: Essentials first! Progressive enhancement isn’t just for the cool kids. It’s required.Monday, October 3, 11Many of you may have heard of the Mobile First mantra. My colleague Luke W. is a leadingproponent of this and has recently published an eponymous book. The idea of mobile first isto, well, design for mobile first, and expand that design out to enhance for larger or morepowerful devices, e.g. the desktop.

110.
Mobile rst! Essentials rst!Monday, October 3, 11 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 essentialsor baseline first.

111.
photo by seattle.roamerMonday, October 3, 11Either way, the point is, we got fat and lazy in many way and we need to start trying to paredown our focus and get at what really matters in our web sites.

112.
Monday, October 3, 11This is a bigger-picture thought process about simplification and focus. A mobile- oressentials-first attitude can help us go on a diet and figure out what really matters. It’s goodfor us, and It’s not just about mobile.

113.
Monday, October 3, 11Finding 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 towork on as many devices as possible.

114.
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?Monday, October 3, 11Become 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 desperateneed for simplification, is some innovative approaches that build on rock-solid HTML5 andprobably some more frameworks that can do some of the annoying stuff that is so hard forus.

115.
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!Monday, October 3, 11We’ve got our future-friendly HTML5 and we’re ready to do something with it. There aresome tools out there to help simplify our lives and get our jobs done effectively. Some ofthese tools and ideas are bridging techniques until the world gets to be a bit of a safer place.Some are just great things.

116.
Engage weapon 1: Adapt and !ex with Responsive Web Design (RWD)Monday, October 3, 11

117.
Monday, October 3, 11This is the article in A List Apart that introduced the idea of Responsive Web Design.Brainchild of Ethan Marcotte, Responsive Web Design combines several implementationtechniques to bring to life the kind of flowing, adaptive layouts I’ve been talking about.

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

119.
1: CSS 3 Media Queries @media all and (min-width: 480px) { }Monday, October 3, 11There are three technical underpinnings to the RWD approach. A quick CSS 3 Media queryprimer for those who might not be initiated. CSS Media queries (one of the forty or so CSS 3modules) let you selectively APPLY different CSS based on logical conditions. In this case, theCSS rules between the brackets are applied only if the window width is greater or equal to480px.

120.
2: Fluid media. img, object { max-width: 100%; }Monday, October 3, 11With this simple CSS rule comes great power. This makes our images and embedded objectsscale with the size of the containing element. Don’t forget that (at least not without greatfutzing) 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.

121.
3: Fluid grids. • CSS layouts based on proportional elements. • Type in ems. • Widths in percentages. • Flexy, !exy!Monday, October 3, 11If you’re not doing fluid layouts now, you should be. Learning how to do it takes about halfan hour, and then you may find that your life is changed a bit for the shinier. Fluid grids usepercentages for body element widths and ems for type (typically). What does this mean? Itmeans that you’re not locking in any fixed units, and your design can scale. Fluid grids are ariff on flexible grids, which have been around for a while. You can learn how to make them byreading Ethan’s ALA article or his quick-read book.

122.
Monday, October 3, 11In this simple responsive design I threw together, you can see how three columns collapseinto one on a narrower screen. I’ve used a media query to apply different CSS based onscreen width. The layout is a fluid grid, with element widths defined with percentages.

123.
Monday, October 3, 11And also here, the use of fluid images allows the photo to scale with its container, fitting aswell into the single-column layout as the multi-column layout.

124.
Monday, October 3, 11Although there is a lot of hubbub about the specifics of RWD implementation (in fact, CloudFour co-founder Jason Grigsby wrote a controversial post about media queries that hasseriously made the rounds), try to let your mind float past the specifics about and meditateon the premise, which has a certain harmony. Borrowed to some extent from ideals ofphysical architecture, RWD is about flowing the content, adapting the environment aroundthe user instead of trying to control the experience rigidly or making the user adapt.

125.
Do this. Use media queries to enhance layout. Avoid media queries in your baseline, reference implementation.Monday, October 3, 11Consider media queries as an enhancement technique. That way you’re not relying onsupport in your baseline, content-is-king version. Hey, this is a great way of letting go ofsome crap to worry about!

126.
Do this. You may need to use shims for IE. But most desktop browsers are media-query-savvy.Monday, October 3, 11You may need to use a JavaScript shim, if the media queries you’re making need to work in IE7, 8 or whatever.

127.
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.Monday, October 3, 11Just because you’re scaling images using the fluid technique doesn’t mean you’re out of thewoods. You’re still delivering all of the bytes that are in the full-sized image.

128.
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.Monday, October 3, 11A lot of the tutorials out there for fluid grids have you accounting for every last scrape ofroom in the design, often resulting in, literally, percentages with 6 or 7 decimal places. AtCloud 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 thedesign. Less precision-control, perhaps, but less likely to cause box-model rounding errors,esp. in IE.

129.
Target lock with weapon 2: Enhance and adapt with client-side feature detectionMonday, October 3, 11

130.
Monday, October 3, 11With client-side feature detection, you can ask questions like, hey, do you support the HTML5audio tag? I’d like to drop in some sound!

131.
Monday, October 3, 11These client-side feature detection tools ask the browser to tell us if it supports somethingright at this very second. Then we can enhance our content based upon the answer.

132.
Monday, October 3, 11Modernizr is a prime contender in this space, and there are other cool polyfills, shims andtools like yepnope.js, adapt.js...

133.
Monday, October 3, 11Sometimes it feels like there is a new JavaScript tool, library or framework every day. It can behard for me to keep my house in order! But the up side is that there are tons of things to helpyou get your job done out there.

134.
Do this. Keep it e$cient. Use Modernizr’s new-ish modular approach to build your feature detection.Monday, October 3, 11Don’t throw in the kitchen sink! This keeps your JavaScript payload size small and demandsless of your user’s browsers and CPUs.

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

136.
Weapon 3: Rocking it old skool on the server sideMonday, October 3, 11

137.
Monday, October 3, 11You can do some heavy-lifting on the server side, some gearwork so that you’re not puttingso much pressure on lighter clients.

138.
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 • RespectMonday, October 3, 11

139.
User Agent Sni$ng photo by ex.librisMonday, October 3, 11Sometimes 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 isnot something only small-time folks do; most major websites that have mobile optimizationare using device detection of some sort, and the vast majority of those hinge on user agentstrings. It ain’t perfect, but it works.

140.
Device Databases photo by Tim MorganMonday, October 3, 11So, given a user agent string, how do we know more information about the client? That’s thejob of device databases, which look up various capabilities based on, well, usually, a useragent string. We can make good first estimates about the resolution, browser version, videosupport, etc.

141.
Monday, October 3, 11You gotta crack some eggs sometimes to make that tasty omelette. This isn’t about lockingpeople 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.

142.
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).Monday, October 3, 11Don’t this. And by combining server-side detection with clients-side detection, you can findconsiderably more nuance.

143.
Monday, October 3, 11There’s also a bit of Zen in the combination of weapons 2 and 3, that is, using a server-sideapproach 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 thisarea...

144.
Killer Weapon #4: Optimize the hell out of itMonday, October 3, 11

145.
Do this. Huge, huge improvements can often be made in a couple of minutes by editing your .htaccess or apache conguration le.Monday, October 3, 11You don’t get a get-out-of-jail-free card on this one. Performance on mobile matters morethan ever. It’s amazing the massive performance improvements that can be made that areroutinely overlooked by devs. These are simple changes that have huge impact.

146.
Monday, October 3, 11

147.
Do this. Get the YSlow extension for Firebug in your browser. Read it, study it, know it.Monday, October 3, 11

148.
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 /IfModuleMonday, October 3, 11I’m giving you some basically cut-and-pastable code for an .htaccess file so you can’t use theexcuse that you don’t know how. This madly, madly cuts payloads.

149.
Far-future expires headers IfModule mod_expires.c # Enable expirations. ExpiresActive On # Cache all files for 2 weeks after access (A). ExpiresDefault A1209600 /IfModuleMonday, October 3, 11Tell browsers not to refresh content for a while; keep it cached. Be aware that when you’returning this on, you’re kind of locking yourself into the file version. You’ll have to invent afile-naming convention to work around this.

150.
cache manifests AddType text/cache-manifest .appcacheMonday, October 3, 11I won’t lie. Futzing with cache manifests is a bit of a finicky business. You may need this inyour apache config/.htaccess to make them work.

151.
cache manifests CACHE MANIFEST CACHE: /assets/fflogo.png /assets/signed.png /index.html /thinking.html /resources.html /styles.css NETWORK: *Monday, October 3, 11Here’s the contents of the cache manifest on futurefriendly.

152.
IV. Now find places to draw the line. Letting go and finding a bit of balance.Monday, October 3, 11

153.
Plant the seed early.Monday, October 3, 11Plant the seed early. As much as I loathe the expression: “Set expectations.” Learn to talkabout what devices can and cannot do, how browsers break, and how you can’t controleverything.

154.
Take note of when you get mired.Monday, October 3, 11Sometimes when you’re deeply in dev, you can’t see the forest for the trees. Learn torecognize when you’re mired. Take note. Try not to chase your tail quite as much.

155.
Don’t fear the occasional egregious hack.Monday, October 3, 11Don’t be afraid to pull out an egregious hack or two. Use your best duct tape programmingskills, as per Joel Spolsky.

156.
Put your energy into the devices that “matter.”Monday, October 3, 11Focus on the devices that matter. That doesn’t mean to do this at the expense of everyoneelse, but don’t get mired in small tweaks for every single thing out there.

157.
Fail with grace.Monday, October 3, 11Be ready to fail gracefully a bit when you set your site free. You have the good underpinningsthere to fall back on.

158.
And what about the future? Looking further ahead.Monday, October 3, 11

159.
Disruption will only accelerate. The quantity and diversity of connected devices—many of which we havent 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 wont hold up. Todays onslaught of devices is already pushing them to the breaking point. They cant withstand whats 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.lyMonday, October 3, 11

160.
Emancipating mobile browsers from the ghetto.Monday, October 3, 11What does this mean? For one thing it means changing the conversation that has...

161.
Changing the conversation.Monday, October 3, 11Changing the conversation? Yes, right now the tone is slightly odd. As devs, we consider itour 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 andOS and browser makers—the people who actually have control over this—make things workas advertised, and deliver on promises.

162.
Be future friendly.Monday, October 3, 11Some of the considerations I talked about run parallel to the future friendly ideals. We’re stillironing out the kinks.

163.
We can steer this ship.Monday, October 3, 11We’re not totally sure exactly what the future looks like. But by thinking in a future-friendlymanner, you can help get the ship on track.

164.
Victory can be ours.Monday, October 3, 11I believe that, though the ride will be bumpy for a while, the increasing chaos will eventuallyreach a tipping point—at least I hope so.

165.
Remember, this isn’t religion.Monday, October 3, 11And we’re all on the same team. Don’t let yourself get caught up in over-idealized squabbles.Let’s work together.

166.
Monday, October 3, 11Set it freeeeeee!

167.
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.htmlMonday, October 3, 11

168.
Coming soon.Monday, October 3, 11

169.
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)Monday, October 3, 11