Embracing Progressive Enhancement

We are perpetually on our toes to absorb the latest technologies that power the web and make use of them in our projects. However, in doing so, we often overlook and break the principles that the web has been built on over the past two decades. Even if we choose to turn blind towards philosophies, standards or doing things the right way, we simply cannot ignore the proliferation and diversity of devices and user agents today.

These slides were used to conduct a workshop that revisited the spirit of the web — understanding what makes the web special and how to embrace the principle of progressive enhancement to build robust websites.

“The best way to be future-proof is to be backwards compatible.”

Transcript

1. Embracing Progressive
   Enhancement
   

   View Slide

2. @souvikdg
   

   View Slide

3. View Slide

4. Objectives
   • Revisit the design of web and how it works
   • Progressive enhancement and its importance
   • Write code keeping progressive enhancement in mind
   • Peer review and learn form each other’s experience
   

   View Slide

5. Learning syntax or making
   pretty interfaces is
   NOT
   an objective of this workshop
   

   View Slide

6. Agenda
   • Zone in (25 mins)
   • Understand our project (15 mins)
   • Develop the project
   • HTML (40 mins)
   • CSS (20 mins)
   • JS (50 mins)
   • Zone out (15 mins)
   break
   

   View Slide

7. Conduct
   • Ask, don’t be shy
   • Contribute, don’t withhold knowledge
   • Code, or at the very least assist
   • Give feedback, take feedback, keep it constructive
   • Mutual respect
   

   View Slide

8. Q: Why do we not care about
   some web browsers?
   

   View Slide

9. What’s the Web?
   

   View Slide

10. Tim Berners-Lee, 1989
    

    View Slide

11. Built upon amazing
    design principles
    

    View Slide

12. Tim Berners-Lee
    Date: 1998
    Status: personal view only
    http://www.w3.org/DesignIssues/Principles.html
    

    View Slide

13. Simplicity
    “Keep it simple, stupid!”
    

    View Slide

14. Modular Design
    

    View Slide

15. Being part of a
    Modular Design
    

    View Slide

16. Tolerance
    “Be liberal in what you require
    but conservative in what you do”
    

    View Slide

17. Decentralization
    

    View Slide

18. Test of Independent
    Invention
    “If someone else had already invented your
    system, would theirs work with yours?”
    

    View Slide

19. Principle of
    Least Power
    

    View Slide

20. An essay on W3C’s design principles
    • Introduction
    • Maintainability
    • Modularity
    • Minimum redundancy
    • Accessibility
    • Device-independency
    • Internationality
    • Extensibility
    • Learnability
    • Readability
    • E ciency
    • Binary or text format
    • Implementability
    • Simplicity
    • Longevity
    • Backwards compatibility
    • Interoperability
    • Repurposing of content
    • Timeliness
    • Use what is there
    • Design by committee
    • Expertise
    • Brevity
    • Stability
    • Robustness
    http://www.w3.org/People/Bos/DesignGuide/toc.html
    

    View Slide

21. W3C Mission
    • Web for All
    • Web on Everything
    • Web for Rich Interaction
    • Web of Data and Services
    • Web of Trust
    http://www.w3.org/Consortium/mission.html
    

    View Slide

22. As a result…
    

    View Slide

23. It has been around for
    more than 2 decades
    

    View Slide

24. Today, the web is
    turning ubiquitous
    

    View Slide

25. Ubiquity comes with
    client fragmentation
    

    View Slide

26. For a long time we’ve focussed on
    Graceful Degradation
    

    View Slide

27. But now there are just
    too many browsers
    

    View Slide

28. And oh!
    • Text mode browsers.
    • Screen readers.
    • Read it later services.
    • Flipboard
    • Bots, spiders.
    • …
    

    View Slide

29. More variables
    • Devices Capabilities
    • Screen Dimensions
    • Methods of interaction
    • …
    

    View Slide

30. “Inclusive Web Design
    For the Future”
    Steve Champeon and Nick Finck, 2003
    

    View Slide

31. Progressive
    Enhancement
    

    View Slide

32. Content
    

    View Slide

33. Content
    HTML
    

    View Slide

34. Content
    HTML
    CSS
    

    View Slide

35. Content
    HTML
    CSS
    JS
    

    View Slide

36. What is the Web, again?
    

    View Slide

37. Protocol
    HTTP
    

    View Slide

38. URLs
    for every possible resource on the web
    

    View Slide

39. Files
    mostly HTML, CSS, JS and media
    

    View Slide

40. Workshop Project
    

    View Slide

41. HasExpenses
    

    View Slide

42. Knowns
    

    View Slide

43. Activity 1
    

    View Slide

44. Identify Purpose
    Prioritise Goals
    

    View Slide

45. Goals?
    • Consumable
    • Functional
    • Aesthetic
    • Fast
    • Accessible
    • Reachable/Locatable
    • …
    

    View Slide

46. The Protocol: HTTP
    

    View Slide

47. Methods
    

    View Slide

48. Methods
    Get, Put, Post, Delete
    

    View Slide

49. GET vs POST
    

    View Slide

50. URLs
    

    View Slide

51. URLs
    are for people
    

    View Slide

52. “Cool URIs don’t change”
    http://www.w3.org/Provider/Style/URI.html
    

    View Slide

53. Activity 2
    

    View Slide

54. Give URL to everything
    

    View Slide

55. Files
    

    View Slide

56. Content
    

    View Slide

57. Markup
    

    View Slide

58. HTML
    

    View Slide

59. HTML gives structure and
    meaning to content
    

    View Slide

60. If a machine can understand it,
    the content becomes
    functional and accessible
    

    View Slide

61. Think meaning, not looks
    

    View Slide

62. Create Once,
    Publish Everywhere
    http://blog.programmableweb.com/2009/10/13/cope-create-once-publish-everywhere/
    

    View Slide

63. Again, what design principles!
    

    View Slide

64. HTML is forward compatible i.e.
    older systems will happily work
    with new tags and attributes
    

    View Slide

65. On the flip side, almost
    any code we write will
    appear to work
    

    View Slide

66. Tags like and
    have subtle semantics
    Don’t use them for visual styling
    

    View Slide

67. Use the right
    HTTP methods
    

    View Slide

68. Style
    

    View Slide

69. CSS
    

    View Slide

70. Style can assist functionality
    but it’s not a robust mechanism
    of delivering functionality
    

    View Slide

71. Use colours to
    indicate meaning?
    What about folks who are colour blind?
    

    View Slide

72. Use colons after
    field labels?
    That’s just a convention or a style
    

    View Slide

73. Pretty robust
    Unknown rules are ignored
    

    View Slide

74. Order rules carefully so that
    the newer rules are at the end
    

    View Slide

75. Do all websites need to
    look exactly the same in
    every browser?
    

    View Slide

76. http://dowebsitesneedtolook
    exactlythesameineverybrowser.com
    

    View Slide

77. It’s okay if the old browsers
    don’t achieve style parity
    

    View Slide

78. Media Queries
    • width
    • height
    • device-width
    • device-height
    • orientation
    • aspect-ratio
    • device-aspect-ratio
    • color
    • color-index
    • monochrome
    • resolution
    • scan
    • grid
    

    View Slide

79. Web is responsive
    Just keep it that way
    

    View Slide

80. There’s NO mobile web
    

    View Slide

81. Behaviour
    

    View Slide

82. Scripts
    

    View Slide

83. Javascript
    

    View Slide

84. “Any application that can
    be written in JavaScript,
    will eventually be written
    in JavaScript”
    http://www.codinghorror.com/blog/2007/07/the-principle-of-least-power.html
    

    View Slide

85. Javascript error handling isn’t
    as robust as HTML and CSS
    

    View Slide

86. Procedures perhaps cannot
    have a “default” logic
    

    View Slide

87. And so, Javascript can fail
    

    View Slide

88. Murphy’s law
    

    View Slide

89. Dependence on
    Javascript
    is a mistake
    

    View Slide

90. Dependence on
    Javascript
    is a mistake
    

    View Slide

91. Dependence
    on Javascript
    is a mistake
    

    View Slide

92. Dependence
    on Javascript
    is a mistake
    

    View Slide

93. Which is not to say
    don’t use Javascript
    

    View Slide

94. Just be prepared for failures
    

    View Slide

95. Avoid inline styles
    Instead, add or remove classes
    

    View Slide

96. Make JS unobtrusive
    

    View Slide

97. Browser sni ng? No!
    

    View Slide

98. Detect Features
    not browsers, devices, etc.
    

    View Slide

99. Enter Modernizr
    

    View Slide

100. It’s Javascript time
     Exhibit restraint, plan well
     

     View Slide

101. Parting thoughts…
     

     View Slide

102. Design hacks are okay as long
     as you are following standards
     

     View Slide

103. Hatred for browser bugs is
     di erent than hatred for old (or
     less featured) browsers
     

     View Slide

104. Supporting the latter does not
     mean that you have to make
     them look or work the same way
     

     View Slide

105. Polyfills are often unnecessary
     

     View Slide

106. Using front-end frameworks
     doesn’t really prevent
     progressive enhancement
     

     View Slide

107. When you ASSUME
     you make an ass out of u and me
     

     View Slide

108. Q: Why do we not care about
     some web browsers?
     

     View Slide

109. Because we’re not as flexible as
     the medium demands us to be
     

     View Slide

110. A Dao of Web Design
     http://alistapart.com/article/dao/
     

     View Slide

111. Thanks!
     

     View Slide