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

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.

187d92c9284160ad908885ab096f5209?s=128

Stefan Baumgartner

November 23, 2013
Tweet

Transcript

  1. 3.
  2. 4.
  3. 5.
  4. 10.
  5. 12.
  6. 13.
  7. 14.
  8. 15.
  9. 16.
  10. 17.
  11. 18.
  12. 21.
  13. 24.
  14. 25.
  15. 26.
  16. 27.
  17. 35.

    > 0 . 1 + 0 . 2 0 .

    3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4
  18. 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
  19. 38.

    > t y p e o f N a N

    n u m b e r
  20. 40.
  21. 46.
  22. 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
  23. 49.
  24. 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
  25. 53.
  26. 54.
  27. 55.
  28. 61.

    The bad: We assumed iScroll will fix all our problems

    iScroll assumed hardware acceleration is a good idea overall
  29. 63.
  30. 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
  31. 66.
  32. 69.
  33. 83.
  34. 86.
  35. 87.
  36. 88.
  37. 89.

    Browsers other than Chrome don't priorize JS over IMG assets

    They take everything in order, to ensure nothing is missing on execution
  38. 94.
  39. 95.

    A though one ... but rule of thumb is to

    reduce requests Load content that is necessary for the first impression
  40. 100.

    Single Pager? Embed CSS and Scripts inline Use sprites and

    fonts Beware of base64 asset embedding
  41. 101.
  42. 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!
  43. 103.

    Solutions Features: Progressive Enhancement Implementation quality: Progressive Enhancement Browser Speed:

    Progressive Enhancement Memory: Progressive Enhancement Resolution: Progressive Enhancement Connection speed: Progressive Enhancement
  44. 105.
  45. 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
  46. 116.