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
2. @souvikdg
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
5. Learning syntax or making pretty interfaces is NOT an objective of this workshop
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
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
8. Q: Why do we not care about some web browsers?
9. What’s the Web?
10. Tim Berners-Lee, 1989
11. Built upon amazing design principles
12. Tim Berners-Lee Date: 1998 Status: personal view only http://www.w3.org/DesignIssues/Principles.html
13. Simplicity “Keep it simple, stupid!”
14. Modular Design
15. Being part of a Modular Design
16. Tolerance “Be liberal in what you require but conservative in what you do”
17. Decentralization
18. Test of Independent Invention “If someone else had already invented your system, would theirs work with yours?”
19. Principle of Least Power
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
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
22. As a result…
23. It has been around for more than 2 decades
24. Today, the web is turning ubiquitous
25. Ubiquity comes with client fragmentation
26. For a long time we’ve focussed on Graceful Degradation
27. But now there are just too many browsers
28. And oh! • Text mode browsers. • Screen readers. • Read it later services. • Flipboard • Bots, spiders. • …
29. More variables • Devices Capabilities • Screen Dimensions • Methods of interaction • …
30. “Inclusive Web Design For the Future” Steve Champeon and Nick Finck, 2003
31. Progressive Enhancement
32. Content
33. Content HTML
34. Content HTML CSS
35. Content HTML CSS JS
36. What is the Web, again?
37. Protocol HTTP
38. URLs for every possible resource on the web
39. Files mostly HTML, CSS, JS and media
40. Workshop Project
41. HasExpenses
42. Knowns
43. Activity 1
44. Identify Purpose Prioritise Goals
45. Goals? • Consumable • Functional • Aesthetic • Fast • Accessible • Reachable/Locatable • …
46. The Protocol: HTTP
47. Methods
48. Methods Get, Put, Post, Delete
49. GET vs POST
50. URLs
51. URLs are for people
52. “Cool URIs don’t change” http://www.w3.org/Provider/Style/URI.html
53. Activity 2
54. Give URL to everything
55. Files
56. Content
57. Markup
58. HTML
59. HTML gives structure and meaning to content
60. If a machine can understand it, the content becomes functional and accessible
61. Think meaning, not looks
62. Create Once, Publish Everywhere http://blog.programmableweb.com/2009/10/13/cope-create-once-publish-everywhere/
63. Again, what design principles!
64. HTML is forward compatible i.e. older systems will happily work with new tags and attributes
65. On the flip side, almost any code we write will appear to work
66. Tags like <i> and <b> have subtle semantics Don’t use them for visual styling
67. Use the right HTTP methods
68. Style
69. CSS
70. Style can assist functionality but it’s not a robust mechanism of delivering functionality
71. Use colours to indicate meaning? What about folks who are colour blind?
72. Use colons after field labels? That’s just a convention or a style
73. Pretty robust Unknown rules are ignored
74. Order rules carefully so that the newer rules are at the end
75. Do all websites need to look exactly the same in every browser?
76. http://dowebsitesneedtolook exactlythesameineverybrowser.com
77. It’s okay if the old browsers don’t achieve style parity
78. Media Queries • width • height • device-width • device-height • orientation • aspect-ratio • device-aspect-ratio • color • color-index • monochrome • resolution • scan • grid
79. Web is responsive Just keep it that way
80. There’s NO mobile web
81. Behaviour
82. Scripts
83. Javascript
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
85. Javascript error handling isn’t as robust as HTML and CSS
86. Procedures perhaps cannot have a “default” logic
87. And so, Javascript can fail
88. Murphy’s law
89. Dependence on Javascript is a mistake
90. Dependence on Javascript is a mistake
91. Dependence on Javascript is a mistake
92. Dependence on Javascript is a mistake
93. Which is not to say don’t use Javascript
94. Just be prepared for failures
95. Avoid inline styles Instead, add or remove classes
96. Make JS unobtrusive
97. Browser sni ng? No!
98. Detect Features not browsers, devices, etc.
99. Enter Modernizr
100. It’s Javascript time Exhibit restraint, plan well
101. Parting thoughts…
102. Design hacks are okay as long as you are following standards
103. Hatred for browser bugs is di erent than hatred for old (or less featured) browsers
104. Supporting the latter does not mean that you have to make them look or work the same way
105. Polyfills are often unnecessary
106. Using front-end frameworks doesn’t really prevent progressive enhancement
107. When you ASSUME you make an ass out of u and me
108. Q: Why do we not care about some web browsers?
109. Because we’re not as flexible as the medium demands us to be
110. A Dao of Web Design http://alistapart.com/article/dao/
111. Thanks!