63
The Agony & Ecstasy of the Mobile Web Matt Henry Viget Labs Friday, November 5, 2010

The Agony and Ecstasy of the Mobile Web

Embed Size (px)

DESCRIPTION

Developing for the mobile web is as rewarding as it is frustrating. The purpose of this talk is to put you on the right path to maximize reward and minimize frustration.

Citation preview

Page 1: The Agony and Ecstasy of the Mobile Web

The Agony & Ecstasy of the Mobile WebMatt HenryViget Labs

Friday, November 5, 2010

Page 2: The Agony and Ecstasy of the Mobile Web

O Hai.

‣ Senior front-end developer at Viget Labs

‣ Ex-Yahoo! mobile

‣ @greenideas

‣ Friend to animals

Friday, November 5, 2010

Page 3: The Agony and Ecstasy of the Mobile Web

Why develop for mobile?

Friday, November 5, 2010

When you have a mobile site, users can access it wherever they are. If you make something great--something that people want to use--your site or app can be a part of your users daily lives in a way that a desktop webapp could never be. Where would Twitter be if people couldn’t tweet about the guy they just saw throwing up during the Giants “riots” in SF.And then there are the apps that simply couldn’t *be* without mobile. There wouldn’t be a Foursquare or Gowalla without mobile devices and geolocation. Yes those are native apps, but they don’t need to be. Anybody could build the browser-based Gowalla, and it would be immedately usable by anybody on any device that supported geolocation.And lastly, you can’t afford not to be doing mobile work at this point. Three years ago if you had a great mobile site, you were ahead of the game. Now it’s status quo.

Page 4: The Agony and Ecstasy of the Mobile Web

Why develop for mobile?

‣ Your site in users’ pockets at all times

Friday, November 5, 2010

When you have a mobile site, users can access it wherever they are. If you make something great--something that people want to use--your site or app can be a part of your users daily lives in a way that a desktop webapp could never be. Where would Twitter be if people couldn’t tweet about the guy they just saw throwing up during the Giants “riots” in SF.And then there are the apps that simply couldn’t *be* without mobile. There wouldn’t be a Foursquare or Gowalla without mobile devices and geolocation. Yes those are native apps, but they don’t need to be. Anybody could build the browser-based Gowalla, and it would be immedately usable by anybody on any device that supported geolocation.And lastly, you can’t afford not to be doing mobile work at this point. Three years ago if you had a great mobile site, you were ahead of the game. Now it’s status quo.

Page 5: The Agony and Ecstasy of the Mobile Web

Why develop for mobile?

‣ Your site in users’ pockets at all times

‣ You can do awesome things

Friday, November 5, 2010

When you have a mobile site, users can access it wherever they are. If you make something great--something that people want to use--your site or app can be a part of your users daily lives in a way that a desktop webapp could never be. Where would Twitter be if people couldn’t tweet about the guy they just saw throwing up during the Giants “riots” in SF.And then there are the apps that simply couldn’t *be* without mobile. There wouldn’t be a Foursquare or Gowalla without mobile devices and geolocation. Yes those are native apps, but they don’t need to be. Anybody could build the browser-based Gowalla, and it would be immedately usable by anybody on any device that supported geolocation.And lastly, you can’t afford not to be doing mobile work at this point. Three years ago if you had a great mobile site, you were ahead of the game. Now it’s status quo.

Page 6: The Agony and Ecstasy of the Mobile Web

Why develop for mobile?

‣ Your site in users’ pockets at all times

‣ You can do awesome things

‣ You probably don’t have a choice at this point

Friday, November 5, 2010

When you have a mobile site, users can access it wherever they are. If you make something great--something that people want to use--your site or app can be a part of your users daily lives in a way that a desktop webapp could never be. Where would Twitter be if people couldn’t tweet about the guy they just saw throwing up during the Giants “riots” in SF.And then there are the apps that simply couldn’t *be* without mobile. There wouldn’t be a Foursquare or Gowalla without mobile devices and geolocation. Yes those are native apps, but they don’t need to be. Anybody could build the browser-based Gowalla, and it would be immedately usable by anybody on any device that supported geolocation.And lastly, you can’t afford not to be doing mobile work at this point. Three years ago if you had a great mobile site, you were ahead of the game. Now it’s status quo.

Page 7: The Agony and Ecstasy of the Mobile Web

Dude. That sounds great.

Friday, November 5, 2010

Page 8: The Agony and Ecstasy of the Mobile Web

Dude. That sounds great.

‣ Yeah, it is. But it’s not all unicorns and rainbows...

Friday, November 5, 2010

Page 9: The Agony and Ecstasy of the Mobile Web

YOU THOUGHT IE6 WAS BAD

HTTP://WWW.FLICKR.COM/PHOTOS/VOLANTRA/3406410663/Friday, November 5, 2010

Page 10: The Agony and Ecstasy of the Mobile Web

Most mobile phones are terrible

HTTP://WWW.FLICKR.COM/PHOTOS/NOTIONSCAPITAL/869847216

Friday, November 5, 2010

Page 11: The Agony and Ecstasy of the Mobile Web

Developing for the mobile web can be painful

*IE4 < 6.1.4 <= IE6

Friday, November 5, 2010

Seriously, a lot of the time you spend troubleshooting front-end issues in mobile browsers, you will literally wish you were working on IE6.And if the browsers don’t get you, the carriers will.AT&T & Rogers Tidy shenanigans.

Page 12: The Agony and Ecstasy of the Mobile Web

Developing for the mobile web can be painful

Most Windows phones ship with IE4. FOUR!*

*IE4 < 6.1.4 <= IE6

Friday, November 5, 2010

Seriously, a lot of the time you spend troubleshooting front-end issues in mobile browsers, you will literally wish you were working on IE6.And if the browsers don’t get you, the carriers will.AT&T & Rogers Tidy shenanigans.

Page 13: The Agony and Ecstasy of the Mobile Web

Developing for the mobile web can be painful

Most Windows phones ship with IE4. FOUR!*

Windows Phone 7 ships with (basically) IE7

*IE4 < 6.1.4 <= IE6

Friday, November 5, 2010

Seriously, a lot of the time you spend troubleshooting front-end issues in mobile browsers, you will literally wish you were working on IE6.And if the browsers don’t get you, the carriers will.AT&T & Rogers Tidy shenanigans.

Page 14: The Agony and Ecstasy of the Mobile Web

Developing for the mobile web can be painful

Most Windows phones ship with IE4. FOUR!*

Windows Phone 7 ships with (basically) IE7

Many Blackberries have CSS/JS turned off by default

*IE4 < 6.1.4 <= IE6

Friday, November 5, 2010

Seriously, a lot of the time you spend troubleshooting front-end issues in mobile browsers, you will literally wish you were working on IE6.And if the browsers don’t get you, the carriers will.AT&T & Rogers Tidy shenanigans.

Page 15: The Agony and Ecstasy of the Mobile Web

Developing for the mobile web can be painful

Most Windows phones ship with IE4. FOUR!*

Windows Phone 7 ships with (basically) IE7

Many Blackberries have CSS/JS turned off by default

Openwave and Symbian and Netfront, oh my.

*IE4 < 6.1.4 <= IE6

Friday, November 5, 2010

Seriously, a lot of the time you spend troubleshooting front-end issues in mobile browsers, you will literally wish you were working on IE6.And if the browsers don’t get you, the carriers will.AT&T & Rogers Tidy shenanigans.

Page 16: The Agony and Ecstasy of the Mobile Web

Standards vs. Pragmatism

Friday, November 5, 2010

Some phones will fail on rendering unordered lists. You’ll probably (hopefully!) never see them, but they’re out there.If you can get away with using tables for layout, do it! If you’re not specifically targeting Webkit and you’re trying to use floats and junk for layout, then you should GIVE UP NOW. If tables work in the browsers your working on, use them and get on with your life.We all know that user-agent sniffing is bad. So in desktop browsers we use feature detection to target code only to browsers that can use it. But some devices (such as some old Sony-Ericsson phones) will just crash if you send them a page bigger than 12k. If you send all of your code on every request and let the browser sort it out: best case scenario, you’re sending too much code to browsers that can’t use it, and making page loads way longer than they need to be. Worst case, you’re crashing some old Sony-Ericsson phone with your big old page.

Page 17: The Agony and Ecstasy of the Mobile Web

Standards vs. Pragmatism

Mobile development means doing a lot of things you've previously considered icky and wrong.

Friday, November 5, 2010

Some phones will fail on rendering unordered lists. You’ll probably (hopefully!) never see them, but they’re out there.If you can get away with using tables for layout, do it! If you’re not specifically targeting Webkit and you’re trying to use floats and junk for layout, then you should GIVE UP NOW. If tables work in the browsers your working on, use them and get on with your life.We all know that user-agent sniffing is bad. So in desktop browsers we use feature detection to target code only to browsers that can use it. But some devices (such as some old Sony-Ericsson phones) will just crash if you send them a page bigger than 12k. If you send all of your code on every request and let the browser sort it out: best case scenario, you’re sending too much code to browsers that can’t use it, and making page loads way longer than they need to be. Worst case, you’re crashing some old Sony-Ericsson phone with your big old page.

Page 18: The Agony and Ecstasy of the Mobile Web

Standards vs. Pragmatism

Mobile development means doing a lot of things you've previously considered icky and wrong.

Really simple markup just doesn’t work on some old devices.

Friday, November 5, 2010

Some phones will fail on rendering unordered lists. You’ll probably (hopefully!) never see them, but they’re out there.If you can get away with using tables for layout, do it! If you’re not specifically targeting Webkit and you’re trying to use floats and junk for layout, then you should GIVE UP NOW. If tables work in the browsers your working on, use them and get on with your life.We all know that user-agent sniffing is bad. So in desktop browsers we use feature detection to target code only to browsers that can use it. But some devices (such as some old Sony-Ericsson phones) will just crash if you send them a page bigger than 12k. If you send all of your code on every request and let the browser sort it out: best case scenario, you’re sending too much code to browsers that can’t use it, and making page loads way longer than they need to be. Worst case, you’re crashing some old Sony-Ericsson phone with your big old page.

Page 19: The Agony and Ecstasy of the Mobile Web

Standards vs. Pragmatism

Mobile development means doing a lot of things you've previously considered icky and wrong.

Really simple markup just doesn’t work on some old devices.

Tables. For layout. Srsly.

Friday, November 5, 2010

Some phones will fail on rendering unordered lists. You’ll probably (hopefully!) never see them, but they’re out there.If you can get away with using tables for layout, do it! If you’re not specifically targeting Webkit and you’re trying to use floats and junk for layout, then you should GIVE UP NOW. If tables work in the browsers your working on, use them and get on with your life.We all know that user-agent sniffing is bad. So in desktop browsers we use feature detection to target code only to browsers that can use it. But some devices (such as some old Sony-Ericsson phones) will just crash if you send them a page bigger than 12k. If you send all of your code on every request and let the browser sort it out: best case scenario, you’re sending too much code to browsers that can’t use it, and making page loads way longer than they need to be. Worst case, you’re crashing some old Sony-Ericsson phone with your big old page.

Page 20: The Agony and Ecstasy of the Mobile Web

Standards vs. Pragmatism

Mobile development means doing a lot of things you've previously considered icky and wrong.

Really simple markup just doesn’t work on some old devices.

Tables. For layout. Srsly.

User-agent sniffing is the only thing that works

Friday, November 5, 2010

Some phones will fail on rendering unordered lists. You’ll probably (hopefully!) never see them, but they’re out there.If you can get away with using tables for layout, do it! If you’re not specifically targeting Webkit and you’re trying to use floats and junk for layout, then you should GIVE UP NOW. If tables work in the browsers your working on, use them and get on with your life.We all know that user-agent sniffing is bad. So in desktop browsers we use feature detection to target code only to browsers that can use it. But some devices (such as some old Sony-Ericsson phones) will just crash if you send them a page bigger than 12k. If you send all of your code on every request and let the browser sort it out: best case scenario, you’re sending too much code to browsers that can’t use it, and making page loads way longer than they need to be. Worst case, you’re crashing some old Sony-Ericsson phone with your big old page.

Page 21: The Agony and Ecstasy of the Mobile Web

So how do I do it right?

Friday, November 5, 2010

Page 22: The Agony and Ecstasy of the Mobile Web

Know your audience

Friday, November 5, 2010

Page 23: The Agony and Ecstasy of the Mobile Web

Know your audience

Who uses your site?

Friday, November 5, 2010

Page 24: The Agony and Ecstasy of the Mobile Web

Know your audience

Who uses your site?

Who doesn't use your site?

Emerging markets?

People with accessibility needs?

Friday, November 5, 2010

Page 25: The Agony and Ecstasy of the Mobile Web

Know your audience

Who uses your site?

Who doesn't use your site?

Emerging markets?

People with accessibility needs?

Are they not using it because they can’t?

Friday, November 5, 2010

Page 26: The Agony and Ecstasy of the Mobile Web

Know your audience

Who uses your site?

Who doesn't use your site?

Emerging markets?

People with accessibility needs?

Are they not using it because they can’t?

Always know what you’re leaving on the table.

Friday, November 5, 2010

Page 27: The Agony and Ecstasy of the Mobile Web

Know Your Audience’s Phone

Friday, November 5, 2010

So once you have a good idea of who you’re targeting, you want to try to get a sense for what kinds of devices they’re using. Admob has decent data up on its blog for free, or you can pay to get data that may or may not be more relevant to you.Once you know what phones your users have, you might want to try to get a sense for how bad the browsers are on those phones, so you can begin to map out your development strategy. The jQuery Mobile Graded Browser Support chart is actually pretty good. The short version is basically anything that’s not a Webkit phone is going to be a total nightmare.

Page 28: The Agony and Ecstasy of the Mobile Web

Know Your Audience’s Phone

What devices do your users have? http://metrics.admob.com/

Friday, November 5, 2010

So once you have a good idea of who you’re targeting, you want to try to get a sense for what kinds of devices they’re using. Admob has decent data up on its blog for free, or you can pay to get data that may or may not be more relevant to you.Once you know what phones your users have, you might want to try to get a sense for how bad the browsers are on those phones, so you can begin to map out your development strategy. The jQuery Mobile Graded Browser Support chart is actually pretty good. The short version is basically anything that’s not a Webkit phone is going to be a total nightmare.

Page 29: The Agony and Ecstasy of the Mobile Web

Know Your Audience’s Phone

What devices do your users have? http://metrics.admob.com/

How bad do those devices suck? http://jquerymobile.com/gbs/

Friday, November 5, 2010

So once you have a good idea of who you’re targeting, you want to try to get a sense for what kinds of devices they’re using. Admob has decent data up on its blog for free, or you can pay to get data that may or may not be more relevant to you.Once you know what phones your users have, you might want to try to get a sense for how bad the browsers are on those phones, so you can begin to map out your development strategy. The jQuery Mobile Graded Browser Support chart is actually pretty good. The short version is basically anything that’s not a Webkit phone is going to be a total nightmare.

Page 30: The Agony and Ecstasy of the Mobile Web

TAILOR THE EXPERIENCE TO THE DEVICE

HTTP://WWW.FLICKR.COM/PHOTOS/BLMURCH/335988192/

Friday, November 5, 2010

Page 31: The Agony and Ecstasy of the Mobile Web

FLICKR, TWO WAYS

Friday, November 5, 2010

Page 32: The Agony and Ecstasy of the Mobile Web

Targeting Devices

Friday, November 5, 2010

So one of the reasons we don’t do user-agent sniffing in desktop browsers anymore is that, during the browser wars, there was a user-agent arms race between browser vendors that resulted in all of the vendors having pretty similar user-agent strings (hence IE having “Mozilla” in its user-agent string. WTH?).The thing is, mobile user-agent strings are pretty rock-solid. Vendors are pretty good about differentiating them, even between different versions of a single browser.

Page 33: The Agony and Ecstasy of the Mobile Web

Targeting Devices

Media queries?

Friday, November 5, 2010

So one of the reasons we don’t do user-agent sniffing in desktop browsers anymore is that, during the browser wars, there was a user-agent arms race between browser vendors that resulted in all of the vendors having pretty similar user-agent strings (hence IE having “Mozilla” in its user-agent string. WTH?).The thing is, mobile user-agent strings are pretty rock-solid. Vendors are pretty good about differentiating them, even between different versions of a single browser.

Page 34: The Agony and Ecstasy of the Mobile Web

Targeting Devices

Media queries?

User agent sniffing.

Friday, November 5, 2010

So one of the reasons we don’t do user-agent sniffing in desktop browsers anymore is that, during the browser wars, there was a user-agent arms race between browser vendors that resulted in all of the vendors having pretty similar user-agent strings (hence IE having “Mozilla” in its user-agent string. WTH?).The thing is, mobile user-agent strings are pretty rock-solid. Vendors are pretty good about differentiating them, even between different versions of a single browser.

Page 35: The Agony and Ecstasy of the Mobile Web

Targeting Devices

Media queries?

User agent sniffing.

On mobile, it pretty much works.

Friday, November 5, 2010

So one of the reasons we don’t do user-agent sniffing in desktop browsers anymore is that, during the browser wars, there was a user-agent arms race between browser vendors that resulted in all of the vendors having pretty similar user-agent strings (hence IE having “Mozilla” in its user-agent string. WTH?).The thing is, mobile user-agent strings are pretty rock-solid. Vendors are pretty good about differentiating them, even between different versions of a single browser.

Page 36: The Agony and Ecstasy of the Mobile Web

Targeting Devices

Media queries?

User agent sniffing.

On mobile, it pretty much works.

Also, it’s not like you have a choice.

Friday, November 5, 2010

So one of the reasons we don’t do user-agent sniffing in desktop browsers anymore is that, during the browser wars, there was a user-agent arms race between browser vendors that resulted in all of the vendors having pretty similar user-agent strings (hence IE having “Mozilla” in its user-agent string. WTH?).The thing is, mobile user-agent strings are pretty rock-solid. Vendors are pretty good about differentiating them, even between different versions of a single browser.

Page 37: The Agony and Ecstasy of the Mobile Web

Targeting Devices

Media queries?

User agent sniffing.

On mobile, it pretty much works.

Also, it’s not like you have a choice.

Lastly, there are tools out there that take (some) of the pain out of this stuff.

Friday, November 5, 2010

So one of the reasons we don’t do user-agent sniffing in desktop browsers anymore is that, during the browser wars, there was a user-agent arms race between browser vendors that resulted in all of the vendors having pretty similar user-agent strings (hence IE having “Mozilla” in its user-agent string. WTH?).The thing is, mobile user-agent strings are pretty rock-solid. Vendors are pretty good about differentiating them, even between different versions of a single browser.

Page 38: The Agony and Ecstasy of the Mobile Web

The right tool for the job

WURFL (http://wurfl.sourceforge.net/)

DeviceAtlas (http://deviceatlas.com/)

Yahoo! BluePrint (http://mobile.yahoo.com/devcenter)

Friday, November 5, 2010

WURFL: FOSS, updated regularly, pretty good dataDeviceAtlas: Not free, but cool if you don’t want to host your own data or build your own

Page 39: The Agony and Ecstasy of the Mobile Web

http://www.flickr.com/photos/sergemelki/2612516723/

Friday, November 5, 2010

So there are these great tools out there, how do you leverage them?

Page 40: The Agony and Ecstasy of the Mobile Web

WHAT DOES IT MEAN?

http://www.flickr.com/photos/sergemelki/2612516723/

Friday, November 5, 2010

So there are these great tools out there, how do you leverage them?

Page 41: The Agony and Ecstasy of the Mobile Web

Now what?

Friday, November 5, 2010

It’s that easy. So what have we just done? We’ve solved the bad browser problem. We can now come up with the minimum viable site that can render on pretty much any device, and because we’re using WURFL or equivalent, we can always know that our content is visible on every device we care about. So what’s next?

Page 42: The Agony and Ecstasy of the Mobile Web

Now what?

1.Get the user agent

Friday, November 5, 2010

It’s that easy. So what have we just done? We’ve solved the bad browser problem. We can now come up with the minimum viable site that can render on pretty much any device, and because we’re using WURFL or equivalent, we can always know that our content is visible on every device we care about. So what’s next?

Page 43: The Agony and Ecstasy of the Mobile Web

Now what?

1.Get the user agent

2.Look up the device capabilities

Friday, November 5, 2010

It’s that easy. So what have we just done? We’ve solved the bad browser problem. We can now come up with the minimum viable site that can render on pretty much any device, and because we’re using WURFL or equivalent, we can always know that our content is visible on every device we care about. So what’s next?

Page 44: The Agony and Ecstasy of the Mobile Web

Now what?

1.Get the user agent

2.Look up the device capabilities

3.Serve up the right content for the right device

Friday, November 5, 2010

It’s that easy. So what have we just done? We’ve solved the bad browser problem. We can now come up with the minimum viable site that can render on pretty much any device, and because we’re using WURFL or equivalent, we can always know that our content is visible on every device we care about. So what’s next?

Page 45: The Agony and Ecstasy of the Mobile Web

if (device.doesntSuck) {<script src=”hottness.js” type=”text/javascript”></script>

} else {// Don’t send scripts that old/bad phones // can’t use

}

Friday, November 5, 2010

Page 46: The Agony and Ecstasy of the Mobile Web

Step 3: Profit

Friday, November 5, 2010

Page 47: The Agony and Ecstasy of the Mobile Web

WebKit. Also, WebKit.

Friday, November 5, 2010

Now that we’ve dealt with the lame browsers, we can focus on the fun ones. Right now, and for the long-foreseeable future, the “fun” browsers all run WebKit under the hood. Obviously iOS and Android are based on WebKit, and those make up a huge part of the smartphone market. But pretty much every phone that isn’t made by Microsoft these days is betting on WebKit. And that includes Nokia, who so far have been the only manufacturer to ship a phone with a Mozilla browser installed.

Page 48: The Agony and Ecstasy of the Mobile Web

WebKit. Also, WebKit.

HTML5, CSS3, OMG!1!

Friday, November 5, 2010

Now that we’ve dealt with the lame browsers, we can focus on the fun ones. Right now, and for the long-foreseeable future, the “fun” browsers all run WebKit under the hood. Obviously iOS and Android are based on WebKit, and those make up a huge part of the smartphone market. But pretty much every phone that isn’t made by Microsoft these days is betting on WebKit. And that includes Nokia, who so far have been the only manufacturer to ship a phone with a Mozilla browser installed.

Page 49: The Agony and Ecstasy of the Mobile Web

WebKit. Also, WebKit.

HTML5, CSS3, OMG!1!

Geolocation

Friday, November 5, 2010

Now that we’ve dealt with the lame browsers, we can focus on the fun ones. Right now, and for the long-foreseeable future, the “fun” browsers all run WebKit under the hood. Obviously iOS and Android are based on WebKit, and those make up a huge part of the smartphone market. But pretty much every phone that isn’t made by Microsoft these days is betting on WebKit. And that includes Nokia, who so far have been the only manufacturer to ship a phone with a Mozilla browser installed.

Page 50: The Agony and Ecstasy of the Mobile Web

WebKit. Also, WebKit.

HTML5, CSS3, OMG!1!

Geolocation

Accessibility

Friday, November 5, 2010

Now that we’ve dealt with the lame browsers, we can focus on the fun ones. Right now, and for the long-foreseeable future, the “fun” browsers all run WebKit under the hood. Obviously iOS and Android are based on WebKit, and those make up a huge part of the smartphone market. But pretty much every phone that isn’t made by Microsoft these days is betting on WebKit. And that includes Nokia, who so far have been the only manufacturer to ship a phone with a Mozilla browser installed.

Page 51: The Agony and Ecstasy of the Mobile Web

WebKit. Also, WebKit.

HTML5, CSS3, OMG!1!

Geolocation

Accessibility

Basically, the life of the world to come.

Friday, November 5, 2010

Now that we’ve dealt with the lame browsers, we can focus on the fun ones. Right now, and for the long-foreseeable future, the “fun” browsers all run WebKit under the hood. Obviously iOS and Android are based on WebKit, and those make up a huge part of the smartphone market. But pretty much every phone that isn’t made by Microsoft these days is betting on WebKit. And that includes Nokia, who so far have been the only manufacturer to ship a phone with a Mozilla browser installed.

Page 52: The Agony and Ecstasy of the Mobile Web

WebKit. Also, WebKit.

HTML5, CSS3, OMG!1!

Geolocation

Accessibility

Basically, the life of the world to come.

Friday, November 5, 2010

Now that we’ve dealt with the lame browsers, we can focus on the fun ones. Right now, and for the long-foreseeable future, the “fun” browsers all run WebKit under the hood. Obviously iOS and Android are based on WebKit, and those make up a huge part of the smartphone market. But pretty much every phone that isn’t made by Microsoft these days is betting on WebKit. And that includes Nokia, who so far have been the only manufacturer to ship a phone with a Mozilla browser installed.

Page 53: The Agony and Ecstasy of the Mobile Web

$(‘.mobile-framework’).die()

Friday, November 5, 2010

If you’re a developer or a designer or even a project manager who has to work with developers and designers, you’re probably saying “so what’s the framework I use for making great WebKit sites?” In my opinion, that’s the totally wrong question to ask. The right question, in case you were wondering, is “do I even need a framework at all”, and the answer I think is almost always “no”. Think about the things we usually use frameworks to handle in desktop web applications: Selectors, Effects, and Cross-browser bugs. These just aren’t problems in today’s mobile webkit browsers. When you add 22 or even 12k of extra javascript that you’re not using, and is duplicating functionality that’s already built into the browser, you lose and your users who have to sit around waiting for jQuery to download lose. If anything, grab the lightest weight framework you can find, one that gives you just the tiniest bit of sugar around making ajax calls and using CSS transitions. Better yet, write your own. It’s easy now.

Page 54: The Agony and Ecstasy of the Mobile Web

$(‘.mobile-framework’).die()

Fancy selector engine? Try querySelector();

Friday, November 5, 2010

If you’re a developer or a designer or even a project manager who has to work with developers and designers, you’re probably saying “so what’s the framework I use for making great WebKit sites?” In my opinion, that’s the totally wrong question to ask. The right question, in case you were wondering, is “do I even need a framework at all”, and the answer I think is almost always “no”. Think about the things we usually use frameworks to handle in desktop web applications: Selectors, Effects, and Cross-browser bugs. These just aren’t problems in today’s mobile webkit browsers. When you add 22 or even 12k of extra javascript that you’re not using, and is duplicating functionality that’s already built into the browser, you lose and your users who have to sit around waiting for jQuery to download lose. If anything, grab the lightest weight framework you can find, one that gives you just the tiniest bit of sugar around making ajax calls and using CSS transitions. Better yet, write your own. It’s easy now.

Page 55: The Agony and Ecstasy of the Mobile Web

$(‘.mobile-framework’).die()

Fancy selector engine? Try querySelector();

Effects? How about -webkit-transition

Friday, November 5, 2010

If you’re a developer or a designer or even a project manager who has to work with developers and designers, you’re probably saying “so what’s the framework I use for making great WebKit sites?” In my opinion, that’s the totally wrong question to ask. The right question, in case you were wondering, is “do I even need a framework at all”, and the answer I think is almost always “no”. Think about the things we usually use frameworks to handle in desktop web applications: Selectors, Effects, and Cross-browser bugs. These just aren’t problems in today’s mobile webkit browsers. When you add 22 or even 12k of extra javascript that you’re not using, and is duplicating functionality that’s already built into the browser, you lose and your users who have to sit around waiting for jQuery to download lose. If anything, grab the lightest weight framework you can find, one that gives you just the tiniest bit of sugar around making ajax calls and using CSS transitions. Better yet, write your own. It’s easy now.

Page 56: The Agony and Ecstasy of the Mobile Web

$(‘.mobile-framework’).die()

Fancy selector engine? Try querySelector();

Effects? How about -webkit-transition

Iron out X-browser quirks? Srsly, it’s all WebKit

Friday, November 5, 2010

If you’re a developer or a designer or even a project manager who has to work with developers and designers, you’re probably saying “so what’s the framework I use for making great WebKit sites?” In my opinion, that’s the totally wrong question to ask. The right question, in case you were wondering, is “do I even need a framework at all”, and the answer I think is almost always “no”. Think about the things we usually use frameworks to handle in desktop web applications: Selectors, Effects, and Cross-browser bugs. These just aren’t problems in today’s mobile webkit browsers. When you add 22 or even 12k of extra javascript that you’re not using, and is duplicating functionality that’s already built into the browser, you lose and your users who have to sit around waiting for jQuery to download lose. If anything, grab the lightest weight framework you can find, one that gives you just the tiniest bit of sugar around making ajax calls and using CSS transitions. Better yet, write your own. It’s easy now.

Page 57: The Agony and Ecstasy of the Mobile Web

$(‘.mobile-framework’).die()

Fancy selector engine? Try querySelector();

Effects? How about -webkit-transition

Iron out X-browser quirks? Srsly, it’s all WebKit

What else?

Friday, November 5, 2010

If you’re a developer or a designer or even a project manager who has to work with developers and designers, you’re probably saying “so what’s the framework I use for making great WebKit sites?” In my opinion, that’s the totally wrong question to ask. The right question, in case you were wondering, is “do I even need a framework at all”, and the answer I think is almost always “no”. Think about the things we usually use frameworks to handle in desktop web applications: Selectors, Effects, and Cross-browser bugs. These just aren’t problems in today’s mobile webkit browsers. When you add 22 or even 12k of extra javascript that you’re not using, and is duplicating functionality that’s already built into the browser, you lose and your users who have to sit around waiting for jQuery to download lose. If anything, grab the lightest weight framework you can find, one that gives you just the tiniest bit of sugar around making ajax calls and using CSS transitions. Better yet, write your own. It’s easy now.

Page 58: The Agony and Ecstasy of the Mobile Web

Conclusion: Simple steps to mobile glory

Friday, November 5, 2010

Take the time to figure out who’s using your site and who isn’t using it that you’d like to be. Everything else starts from those data.Once you start building, target the right content to the right device.Send the bare minimum markup & style for your site to low-end phones.Send your bleeding-edge HTML5, CSS3, vendor-prefixed awesomeness to the iPhone, Android, etc.

Page 59: The Agony and Ecstasy of the Mobile Web

Conclusion: Simple steps to mobile glory

Know your audience.

Friday, November 5, 2010

Take the time to figure out who’s using your site and who isn’t using it that you’d like to be. Everything else starts from those data.Once you start building, target the right content to the right device.Send the bare minimum markup & style for your site to low-end phones.Send your bleeding-edge HTML5, CSS3, vendor-prefixed awesomeness to the iPhone, Android, etc.

Page 60: The Agony and Ecstasy of the Mobile Web

Conclusion: Simple steps to mobile glory

Know your audience.

Browsers: Divide & Conquer.

Friday, November 5, 2010

Take the time to figure out who’s using your site and who isn’t using it that you’d like to be. Everything else starts from those data.Once you start building, target the right content to the right device.Send the bare minimum markup & style for your site to low-end phones.Send your bleeding-edge HTML5, CSS3, vendor-prefixed awesomeness to the iPhone, Android, etc.

Page 61: The Agony and Ecstasy of the Mobile Web

Conclusion: Simple steps to mobile glory

Know your audience.

Browsers: Divide & Conquer.

Make awesome things with WebKit.

Friday, November 5, 2010

Take the time to figure out who’s using your site and who isn’t using it that you’d like to be. Everything else starts from those data.Once you start building, target the right content to the right device.Send the bare minimum markup & style for your site to low-end phones.Send your bleeding-edge HTML5, CSS3, vendor-prefixed awesomeness to the iPhone, Android, etc.

Page 62: The Agony and Ecstasy of the Mobile Web

Conclusion: Simple steps to mobile glory

Know your audience.

Browsers: Divide & Conquer.

Make awesome things with WebKit.

Bonus: ditch your framework.

Friday, November 5, 2010

Take the time to figure out who’s using your site and who isn’t using it that you’d like to be. Everything else starts from those data.Once you start building, target the right content to the right device.Send the bare minimum markup & style for your site to low-end phones.Send your bleeding-edge HTML5, CSS3, vendor-prefixed awesomeness to the iPhone, Android, etc.

Page 63: The Agony and Ecstasy of the Mobile Web

Thanks.xoxo, matt. http://spkr8.com/t/4994

Friday, November 5, 2010