Slide 1

Slide 1 text

GAINING CONTROL IN THE GREAT UNKNOWN MobileTechCon Munich - March 2014

Slide 2

Slide 2 text

Servus

Slide 3

Slide 3 text

@ddprrt

Slide 4

Slide 4 text

Netural

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

Lafers grill recipes The need precise control I need to put meat on fire

Slide 8

Slide 8 text

Weber-Kit

Slide 9

Slide 9 text

Controlled Environments

Slide 10

Slide 10 text

Controllable Environments

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

Uncontrollable Environments

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

UC Browser

Slide 21

Slide 21 text

UC Browser 400 million users 32% market-share in China

Slide 22

Slide 22 text

... to be honest ... only few of them come with their own engine

Slide 23

Slide 23 text

Under the top-most used browsers on iOS and Android

Slide 24

Slide 24 text

Fragmentation

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

iOS screen fragmentation

Slide 30

Slide 30 text

Android screen fragmentation

Slide 31

Slide 31 text

Holy fragmentation, Batman This is friggin' scary

Slide 32

Slide 32 text

And that is just Android ...

Slide 33

Slide 33 text

What are people really using?

Slide 34

Slide 34 text

Holiday season in Austria pseudonymized target audience of a B2C website male or female age 0 to 99

Slide 35

Slide 35 text

The stats different device types: 723 different browser families: 68

Slide 36

Slide 36 text

Top 5 browser families 1. Safari 2. Chrome 3. Firefox 4. Android Stock Browser 5. Internet Explorer

Slide 37

Slide 37 text

Viewport is one thing... Features? Implementation quality? Memory? Resolution? Browser Speed? Connection speed?

Slide 38

Slide 38 text

Parallax Scrolling?

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

moto.oakley.com 1. 85.4 MB page weight 2. 471 HTTP Requests 3. 2 minutes 45 seconds until loading screen replaced with content 4. 4 minutes 10 seconds to wait for onLoad event

Slide 41

Slide 41 text

There sure is a mobile version? ... oh yeah, there is...

Slide 42

Slide 42 text

85.9 MB

Slide 43

Slide 43 text

Costs Roaming in Switzerland for EU clients is 1€ per MB

Slide 44

Slide 44 text

Costs vodafone UK charges 1£ per 25 MB

Slide 45

Slide 45 text

Assumptions Features: Scrolling Implementation quality: Tried, trusted and Robust Memory: A shitload Resolution: Of course Retina! Browser Speed: iPad-near JS execution time Connection speed: Harddrive

Slide 46

Slide 46 text

Features

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

overflow: scroll

Slide 50

Slide 50 text

-webkit-overflow-scrolling: touch

Slide 51

Slide 51 text

Feature detection Test for overflow-scrolling, otherwise use iScroll

Slide 52

Slide 52 text

var has3d = 'WebKitCSSMatrix' in window && 'm11' in new WebKitCSSMatrix()

Slide 53

Slide 53 text

The good: We did feature detects, and polyfilled in case

Slide 54

Slide 54 text

The bad: We assumed iScroll will fix all our problems iScroll assumed hardware acceleration is a good idea overall

Slide 55

Slide 55 text

The ugly: We broke IE10 on Windows Phone 8

Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

When using skrollr on mobile you don't actually scroll. When detecting a mobile browser skrollr disables native scrolling and instead listens for touch events and moves the content

Slide 58

Slide 58 text

A classic $('a').on('click', function()) { window.location.href = $(this).attr('href'); }

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

Don't recreate browser features

Slide 61

Slide 61 text

You can't control everything

Slide 62

Slide 62 text

You can't control anything

Slide 63

Slide 63 text

Brings Parallax back to its roots

Slide 64

Slide 64 text

body { perspective: 1px; transform-style: preserve-3d; } .slide:before { position: absolute; top: 0; left: 0; right: 0; bottom: 0; background-image: url("..."); transform: translateZ(-1px) scale(2); z-index:-1; } http://codepen.io/keithclark/pen/JycFw

Slide 65

Slide 65 text

Implementation quality

Slide 66

Slide 66 text

No content

Slide 67

Slide 67 text

meta-Viewport

Slide 68

Slide 68 text

meta-Viewport

Slide 69

Slide 69 text

... not that it does anything ...

Slide 70

Slide 70 text

@media(max-width: 320px) { @ms-viewport { width: 320px } }

Slide 71

Slide 71 text

@-ms-viewport { width: device-width; }

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

-webkit-text-stroke: 4px;

Slide 74

Slide 74 text

-webkit-text-stroke: 4px;

Slide 75

Slide 75 text

This is madness!

Slide 76

Slide 76 text

-webkit-something: something

Slide 77

Slide 77 text

For what it's worth, the current trend inside Mozilla is exactly what you say: avoiding vendor prefixes by either turning things off before shipping or shipping them unprefixed if they're stable enough. W3C List http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0731.html

Slide 78

Slide 78 text

In short: we won't use vendor prefixes for new features. Instead, we’ll expose a single setting to enable experimental DOM/CSS features for you to see what's coming, play around, and provide feedback [...] Only when we're ready to see these features ship to stable will they be enabled by default in the dev/canary channels. Blink Developer FAQ http://www.chromium.org/blink/developer-faq

Slide 79

Slide 79 text

Vendor prefixes for experimental features experimental means: not stable, not final not stable: not ready for production

Slide 80

Slide 80 text

noPrefixes in v3.0

Slide 81

Slide 81 text

ModernizrProto._config.usePrefixes

Slide 82

Slide 82 text

"options": [ "setClasses", "addTest", "html5printshiv", "load", "testProp", "fnBind", "prefixedCSS" "noPrefixes" ],

Slide 83

Slide 83 text

Browser Speed Lightspeed

Slide 84

Slide 84 text

Truth is ... JavaScript takes long to execute

Slide 85

Slide 85 text

$('.item.' + filterCriteria).each(function() { $(this).hide(); });

Slide 86

Slide 86 text

$('.filterArea').addClass('.filterCritera'); .filterCritera .hasCritera { display: none; }

Slide 87

Slide 87 text

Where is JavaScript necessary?

Slide 88

Slide 88 text

Lanyrd

Slide 89

Slide 89 text

Lanyrd User Agent Detection ... done right! Got a slow JS engine? Don't get any JS.

Slide 90

Slide 90 text

Instagram on iOS5 2/13 - 7/13 and since 12/13

Slide 91

Slide 91 text

No content

Slide 92

Slide 92 text

No content

Slide 93

Slide 93 text

Browsers other than Chrome don't priorize JS over IMG assets They take everything in order, to ensure nothing is missing on execution

Slide 94

Slide 94 text

Use JavaScript to load content that's only available with JavaScript

Slide 95

Slide 95 text

13s > 1.4s

Slide 96

Slide 96 text

sighjavascript.tumblr.com

Slide 97

Slide 97 text

Connection speed

Slide 98

Slide 98 text

No content

Slide 99

Slide 99 text

A though one ... but rule of thumb is to reduce requests Load content that is necessary for the first impression

Slide 100

Slide 100 text

Reduce everything!

Slide 101

Slide 101 text

What does not kill me makes me smaller

Slide 102

Slide 102 text

RESS Responsive & Server-Side

Slide 103

Slide 103 text

if ($(document).width() > 640) { $.get('path/to/html', function(data){ $('[role="complementary"]').append(data); }); }

Slide 104

Slide 104 text

No content

Slide 105

Slide 105 text

Solutions Features: Use, when certain that it's there! Implementation quality: Modern features should be an add-on Browser Speed: Less JavaScript dependent content Memory: Optimize Images, reduce Image Footprint Resolution: See above, use SVG, use Responsive Images! Connection speed: Fear for worst, reduce requests!

Slide 106

Slide 106 text

Solutions Features: Progressive Enhancement Implementation quality: Progressive Enhancement Browser Speed: Progressive Enhancement Memory: Progressive Enhancement Resolution: Progressive Enhancement Connection speed: Progressive Enhancement

Slide 107

Slide 107 text

Progressive Enhancement

Slide 108

Slide 108 text

No content

Slide 109

Slide 109 text

Progressive Enhancement Provide a solid (HTML) base, something you trust and know Enhance your presentation by applying new styles Enhance further by applying behaviour with JavaScript

Slide 110

Slide 110 text

Why Progressive Enhancement

Slide 111

Slide 111 text

Not only for the old things we know

Slide 112

Slide 112 text

But also for the uncertainty of the future!

Slide 113

Slide 113 text

workingdraft.de/135

Slide 114

Slide 114 text

workingdraft.de/137

Slide 115

Slide 115 text

workingdraft.de/144

Slide 116

Slide 116 text

No content

Slide 117

Slide 117 text

No content