Pragmatic Progressive Enhancement

Slide 1: Progressive Enhancement Playing it safe in unknown territory Christian Heilmann, AKQA Brown Bag, London, May 2008

Slide 2: As web developers, we are working with the unknown.

Slide 3: Right from the start the web was meant to be independent of display unit and rendering device.

Slide 4: This is the reason why web standards are so low level technologies.

Slide 5: There is not much sophistication in HTML – but a lot of portability.

Slide 6: Simplicity means sturdiness – not much can break.

Slide 7: Simplicity also means easy adaptation to environments.

Slide 8: There is hardly any more hostile environment than the web.

Slide 9: You have no clue whatsoever about the technology, the ability or the personal settings of the end user.

Slide 10: If you embrace this fact, you are ready to become a good developer.

Slide 11: Good developers are lazy – they don’t want to do the same thing twice.

Slide 12: Instead, we find solutions that do the job for us.

Slide 13: One of these is progressive enhancement.

Slide 14: Instead of building a solution based on assumptions...

Slide 15: “Everybody has JavaScript enabled and a fast computer”

Slide 16: “All our users have a resolution of 1280 x 1024”

Slide 17: “Yeah, 40 menu entries are OK, there is enough space on the screen”

Slide 18: ... we work in a paranoid fashion.

Slide 19: Things *will* break and the person who created the interface will get the blame.

Slide 20: Does this mean we need to dumb down our solutions?

Slide 21: Does it mean JavaScript and Flash and Silverlight are evil?

Slide 22: Only if we built them evil.

Slide 23: Or if we build them badly.

Slide 24: Used the correct way, JavaScript can help you build amazingly adaptive and clever applications.

Slide 25: Seven steps to take to enhance progressively:

Slide 26: 1. Separate as much as possible. 2. Build on things that work 3. Generate dependent markup 4. Test for everything before you apply it. 5. Explore the environment 6. Load on demand 7. Modularize code

Slide 27: Let’s go through them in detail...

Slide 28: 1. Separate as much as possible.

Slide 29: Separation of structure (HTML), presentation (CSS) and behaviour (JS) is an absolute must.

Slide 30: The reason is pragmatism.

Slide 31: You leave it up to the browser to apply what it can support.

Slide 32: You also know exactly where to change what (and you will have to change things constantly)

Slide 33: 2. Build on things that work

Slide 34: Using JavaScript, you can make anything interactive.

Slide 35: Using CSS, you can make anything look like something it isn’t.

Slide 36: With great power comes great responsibility.

Slide 37: You simulate interaction that is most likely a lot more complex than you think.

Slide 38: Interactive elements can be used with a lot of different input devices.

Slide 39: They also report to all kind of systems when activated and trigger appropriate actions.

Slide 40: If you simulate, do it right – don’t break expectations.

Slide 41: Users trust you to give them a working system – this is what they came for.

Slide 42: Best to use what works – links, forms and buttons.

Slide 43: <span onclick=”help()”>Help</span>

Slide 44: <a href="/help" id="help">Help</a> <script> YAHOO.example.helpdemo = function(){ function doHelp(){ // other work here... } YAHOO.util.Event.on('help','click',function(e){ doHelp(); YAHOO.util.Event.preventDefault(e); }); }(); </script>

Slide 45: 3. Generate dependent markup

Slide 46: If your script needs HTML that only makes sense when being driven or changed by JavaScript, generate it with JavaScript.

Slide 47: Examples are window.print() links or anything that pulls in data only when JS is available.

Slide 48: Using the DOM you can create whatever you need.

Slide 49: 4. Test for everything before you apply it.

Slide 50: This is a no-brainer, as you cannot trust circumstances.

Slide 51: Remember “check the depth of the pool before you jump in head-first”?

Slide 52: <script type=”text/javascript”> var c = document.getElementById(‘info’); var text = document.createTextNode(message); c.appendChild(text); </script>

Slide 53: You cannot modify properties of the unknown!

Slide 54: <script type=”text/javascript”> var c = document.getElementById(‘info’); if(c){ var text = document.createTextNode(message); c.appendChild(text); } </script>

Slide 55: The same applies to any browser or DOM method or attribute you try to access.

Slide 56: JavaScript has conditions. Use them.

Slide 57: 5. Explore the environment

Slide 58: Browsers tell you a lot about themselves when you use JavaScript and the DOM.

Slide 59: You get the browser viewport size, how far down the document the user scrolled, where the mouse pointer is and much more.

Slide 60: You can use this to make sure things don’t break.

Slide 61: For example menus or panels.

Slide 69: 6. Load on demand

Slide 70: One of the biggest issues on the web is performance.

Slide 71: Things are never fast enough.

Slide 72: Therefore it is a good idea to load extraneous content and code needed to support it only when you need to.

Slide 73: You can for example test which images are visible (by comparing their location with the viewport) and only load them when they are.

Slide 74: You can also start with a really small script that generates script nodes with the DOM to pull in larger library code when and if it is needed and can be applied.

Slide 75: 7. Modularize code

Slide 76: This happens in several ways.

Slide 77: First of all you want to ensure that your code does work nicely with other code.

Slide 78: The easiest way to do that is the module pattern.

Slide 79: <script type=”text/javascript”> function init(){ // initialization } function show(){ // show stuff } init(); </script>

Slide 80: <script type=”text/javascript”> modules = function(){ function init(){ // initialization } function show(){ // show stuff } init(); }(); </script>

Slide 81: <script type=”text/javascript”> modules = function(){ function init(){ // initialization } function show(){ // show stuff } init(); return { init:init, show:show } }(); // modules.init(); // modules.show(); </script>

Slide 82: <script type=”text/javascript”> (function(){ function init(){ // initialization } function show(){ // show stuff } init(); })(); </script>

Slide 83: The other kind of modularization that makes sense is collating scripts and CSS definitions into different files.

Slide 84: This eases maintenance and also helps loading on demand.

Slide 85: It is not good for performance, but techniques to work around that issue is another talk :)

Slide 86: Now you know the tricks and their rationale and you have a choice.

Slide 87: You can start using them with your own code and enter a world of pain and misery called cross-browser issues.

Slide 88: Or you can use a JavaScript library and CSS framework that does it for you.

Slide 89: All good frameworks and libraries want to do two things:

Slide 90: Make your life a lot easier by normalizing browser behaviour.

Slide 91: and bridge the gap until browsers are good and do what we tell them to do.

Slide 92: One of those libraries is YUI: http://developer.yahoo.com/yui/

Slide 93: ★ CSS Framework ★ JavaScript Utilities ★ Widget library ★ Skinable ★ Extendable and Modularized. ★ Powers Yahoo! pages ★ BSD licensed (commercial use is OK)

Slide 94: Usable, progressively enhanced applications and sites are not science fiction or “best case scenarios”.

Slide 95: They are achievable by subscribing to the ideas of progressive enhancement and using the right tools.

Slide 96: When we cut corners, we hurt ourselves the most.

Slide 97: Taking pride in our job, targeting maintainability and extendability will make us happier developers and give us more confidence to give achievable estimates.

Slide 98: THANKS!