Gaining Control in the Great Unknown - The state of mobile browsers and how to handle them

Every heard of the UC browser? Or Ninesky? ExSoul, anyone? Did you know that on Android 4.1 the stock browser is completely different between a Galaxy S3 and a HTC One S?

A web developer's journey leads more and more into the unknown. Instead of having a manageable set of browsers and a good knowledge of their quirks, we now can't prepare for every possible way how a user accesses the web. Features, implementation quality and (connection) speed often rely on guesses and not on facts. A hack might be a good thing on one platform, but results into completely broken experiences on another.

In this talk, Stefan Baumgartner will show how to gain control in the great unknown and how embracing long forgotten development strategies will help you.

Transcript

1. GAINING CONTROL IN
   THE GREAT UNKNOWN
   Drupalcamp - November 2013
   

   View Slide

2. Griass Enk
   

   View Slide

3. @ddprrt
   

   View Slide

4. Netural
   

   View Slide

5. View Slide

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

   View Slide

7. Weber-Kit
   

   View Slide

8. Controlled
   Environments
   

   View Slide

9. Controllable
   Environments
   

   View Slide

10. View Slide

11. Uncontrollable
    Environments
    

    View Slide

12. View Slide

13. View Slide

14. View Slide

15. View Slide

16. View Slide

17. View Slide

18. View Slide

19. UC Browser
    

    View Slide

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

    View Slide

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

    View Slide

22. Under the top-most used
    browsers on iOS and Android
    

    View Slide

23. Fragmentation
    

    View Slide

24. View Slide

25. View Slide

26. View Slide

27. View Slide

28. iOS screen fragmentation
    

    View Slide

29. Android screen fragmentation
    

    View Slide

30. Holy fragmentation, Batman
    This is friggin' scary
    

    View Slide

31. And that is just Android
    ...
    

    View Slide

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

    View Slide

33. What about things we
    trust?
    

    View Slide

34. > t
    r
    u
    e + t
    r
    u
    e
    2
    

    View Slide

35. > 0
    .
    1 + 0
    .
    2
    0
    .
    3
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    4
    

    View Slide

36. > 9
    9
    9
    9
    9
    9
    9
    9
    9
    9
    9
    9
    9
    9
    9
    9
    1
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    

    View Slide

37. > [
    ] =
    = !
    [
    ]
    t
    r
    u
    e
    

    View Slide

38. > t
    y
    p
    e
    o
    f N
    a
    N
    n
    u
    m
    b
    e
    r
    

    View Slide

39. Programming went full retard
    

    View Slide

40. View Slide

41. -webkit-text-stroke:
    4px;
    

    View Slide

42. This is madness!
    

    View Slide

43. You can't control everything
    

    View Slide

44. You can't control anything
    

    View Slide

45. Parallax Scrolling?
    

    View Slide

46. View Slide

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

    View Slide

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

    View Slide

49. 85.9 MB
    

    View Slide

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

    View Slide

51. Costs
    vodafone UK charges 1£ per 25 MB
    

    View Slide

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

    View Slide

53. Features
    

    View Slide

54. View Slide

55. View Slide

56. overflow: scroll
    

    View Slide

57. -webkit-overflow-scrolling: touch
    

    View Slide

58. Feature detection
    Test for overflow-scrolling, otherwise use iScroll
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

62. The ugly:
    We broke IE10 on Windows Phone 8
    

    View Slide

63. View Slide

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

    View Slide

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

    View Slide

66. View Slide

67. Don't recreate browser
    features
    

    View Slide

68. Implementation quality
    

    View Slide

69. View Slide

70. -webkit-something: something
    

    View Slide

71. meta-Viewport
    
    

    View Slide

72. meta-Viewport
    

    View Slide

73. 
    ... not that it does anything ...
    

    View Slide

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

    View Slide

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

    View Slide

76. Browser Speed
    Lightspeed
    

    View Slide

77. Truth is ...
    JavaScript takes long to
    execute
    

    View Slide

78. Pigs of Awesome - iOS
    

    View Slide

79. Pigs of Awesome -
    Android
    

    View Slide

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

    View Slide

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

    View Slide

82. Where is JavaScript
    necessary?
    

    View Slide

83. Lanyrd
    

    View Slide

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

    View Slide

85. Instagram on iOS5
    2/13 - 7/13
    

    View Slide

86. View Slide

87. View Slide

88. View Slide

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

    View Slide

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

    View Slide

91. 13s > 1.4s
    

    View Slide

92. sighjavascript.tumblr.com
    

    View Slide

93. Connection speed
    

    View Slide

94. View Slide

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

    View Slide

96. Reduce everything!
    

    View Slide

97. What does not kill me
    makes me smaller
    

    View Slide

98. RESS
    Responsive & Server-Side
    

    View Slide

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

    View Slide

100. Single Pager?
     Embed CSS and Scripts inline
     Use sprites and fonts
     Beware of base64 asset embedding
     

     View Slide

101. View Slide

102. 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!
     

     View Slide

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

     View Slide

104. Progressive Enhancement
     

     View Slide

105. View Slide

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

     View Slide

107. Why Progressive
     Enhancement
     

     View Slide

108. Not only for the old things we
     know
     

     View Slide

109. But also for the uncertainty of the
     future!
     

     View Slide

110. workingdraft.de/135
     

     View Slide

111. workingdraft.de/137
     

     View Slide

112. workingdraft.de/144
     

     View Slide

113. workingdraft.de/138 -
     CMS Special
     

     View Slide

114. Create the most amazing food...
     ... by choosing the right
     ingredients
     

     View Slide

115. THX
     @ddprrt • fettblog.eu • workingdraft.de
     

     View Slide

116. View Slide