My name is Jeremy Keith.
I make websites at Clearleft, the design agency I co‐founded in 2005. My online home is adactio.com where I’ve been jotting down my thoughts for over fifteen years.
46 | Before writing Resilient Web Design I wrote the books DOM Scripting, Bulletproof Ajax, and HTML5 For Web Designers.
52 |My email address is jeremy@adactio.com if you’d like to drop me a line.
53 | 54 |In his classic book How Buildings Learn Stewart Brand highlights an idea by the British architect Frank Duffy:
42 | 43 |44 |46 | 47 |A building properly conceived is several layers of longevity.
45 |
Duffy called these shearing layers. Each of the layers moves at a different timescale. Brand expanded on the idea, proposing six alliterative layers:
48 | 49 |
63 | The idea of shearing layers can also be applied to our creations on the web. Our domain names are the geological sites upon which we build. At the other end of the timescale, content on the web—the “stuff”—can be added and updated by the hour, the minute, or even the second. In between are the layers of structure, presentation, and behaviour: HTML, CSS, and JavaScript.
68 | 69 |Those layers can be loosely‐coupled, but they aren’t completely independent. Just as a building cannot have furniture without first having rooms and walls, a style sheet needs some markup to act upon. The coupling between structure and presentation is handled through selectors in CSS: element selectors, class selectors, and so on. With JavaScript, the coupling is handled through the vocabulary of the Document Object Model, or DOM.
70 | 71 |In a later book, The Clock Of The Long Now, Stewart Brand applied the idea of shearing layers—or pace layers—to civilisation itself. The slowest moving layer is nature, then there’s culture, followed by governance, then infrastructure, and finally commerce and fashion are the fastest layers. In a loosely‐coupled way, each layer depends on the layer below. In turn, the accumulation of each successive layer enables an “adjacent possible” filled with more opportunities.
72 | 73 |Likewise, the expressiveness of CSS and JavaScript is only made possible on a foundation of HTML, which itself requires a URL to be reachable, which in turn depends on the HyperText Transfer Protocol, which sits atop the bedrock of TCP/IP.
74 | 75 |Each of the web’s shearing layers can be peeled back to reveal a layer below. Running that process in reverse—applying each layer in turn—is a key principle of resilient web design.
76 | 77 |In 2003, the South by Southwest festival in Austin, Texas was primarily an event for musicians and filmmakers. Today the music and film portions are eclipsed by the juggernaut of South by Southwest Interactive, dedicated to all things digital. In 2003, South by Southwest Interactive was a small affair, squeezed into one corner of one floor of the Austin Convention Center. It was a chance for a few web designers and bloggers to get together and share ideas. That year, Steven Champeon and Nick Finck presented a talk entitled Inclusive Web Design For the Future with Progressive Enhancement. They opened with this call to arms:
82 | 83 |84 |86 | 87 |Web design must mature and accept the developments of the past several years, abandon the exclusionary attitudes formed in the rough and tumble dotcom era, realize the coming future of a wide variety of devices and platforms, and separate semantic markup from presentation logic and behavior.
85 |
Like Tim Berners‐Lee, Steven Champeon had experience of working with SGML, the markup language that would so heavily influence HTML. In dealing with documents that needed to be repurposed for different outputs, he came to value the separation of structure from presentation. A meaningfully marked up document can be presented in multiple ways through the addition of CSS and JavaScript.
88 | 89 |This layered approach to the web allows the same content to be served up to a wide variety of people. But this doesn’t mean that everyone gets the same experience. Champeon realised that a strong separation of concerns would allow enhancements to be applied according to the capabilities of the end user’s device.
90 | 91 |To paraphrase Karl Marx, progressive enhancement allows designers to ask from each browser according to its ability, and to deliver to each device according to its needs.
92 | 93 |Some web designers were concerned that progressive enhancement would be a creative straitjacket. Designing for the lowest common denominator did not sound like a recipe for progress. But this was a misunderstanding. Progressive enhancement asks that designers start from the lowest common denominator (a well marked‐up document), but there is no limit to where they can go from there.
100 | 101 |In fact, it’s the very presence of a solid baseline of HTML that allows web designers to experiment with the latest and greatest CSS. Thanks to Postel’s Law and the loose error‐handling model of CSS, designers are free to apply styles that only work in the newest browsers.
102 | 103 |This means that not everyone will experience the same visual design. This is not a bug. This is a feature of the web. New browsers and old browsers; monochrome displays and multi‐coloured displays; fast connections and slow connections; big screens, small screens, and no screens; everyone can access your content. That content should look different in such varied situations. If a website looks the same on a ten‐year old browser as it does in the newest devices, then it probably isn’t taking advantage of the great flexibility that the web offers.
104 | 105 |To emphasise this, designer Dan Cederholm created a website to answer the question, “Do websites need to look exactly the same in every browser?” You can find the answer to that question at the URL:
106 | 107 |do
At the risk of spoiling the surprise for you, the answer is a resounding “No!” If you visit that website, you will see that answer proudly displayed. But depending on the capabilities of your browser, you may or may not see some of the stylistic flourishes applied to that single‐word answer. Even if you don’t get any of the styles, you’ll still get the content marked up with semantic HTML.
110 | 111 |Separating structure and presentation is relatively straightforward. You can declare whatever styles you want, safe in the knowledge that browsers will ignore what they don’t understand. Separating structure and behaviour isn’t quite so easy. If you give a browser some JavaScript that it doesn’t understand, not only will it not apply the desired behaviour, it will refuse to parse the rest of the JavaScript.
118 | 119 |Before you use a particular feature in JavaScript, it’s worth testing to see if that feature is supported. This kind of feature detection can save your website’s visitors from having a broken experience because of an unsupported feature. If you want to use Ajax, check first that the browser supports the object you’re about to use to enable that Ajax functionality. If you want to use the geolocation API, check first that the browser supports it.
120 | 121 |A team of web developers working on the BBC news website referred to this kind of feature detection as cutting the mustard. Browsers that cut the mustard get an enhanced experience. Browsers that don’t cut the mustard still get access to the content, but without the JavaScript enhancements.
122 | 123 |Feature detection, cutting the mustard, whatever you want to call it, is a fairly straightforward technique. Let’s say you want to traverse the DOM using querySelector and attach events to some nodes in the document using addEventListener. Your mustard‐cutting logic might look something like this:
if (document.querySelector && window.addEventListener) {
126 | // Enhance!
127 | }There are two points to note here:
130 | 131 |else statement.Back when web designers were trying to exert print‐like control over web browsers, a successful design was measured in pixel perfection: did the website look exactly the same in every browser?
143 | 144 |Unless every browser supported a particular feature—like, say, rounded corners in CSS—then that feature was off the table. Instead, designers would fake it with extra markup and images. The resulting websites lacked structural honesty. Not only was this a waste of talent and energy on the part of the designers, it was a waste of the capabilities of modern web browsers.
145 | 146 |The rise of mobiles, tablets, and responsive design helped to loosen this restrictive mindset. It is no longer realistic to expect pixel‐perfect parity across devices and browsers. But you’ll still find web designers bemoaning the fact that they have to support an older outdated browser because a portion of their audience are still using it.
147 | 148 |They’re absolutely right. Anyone using that older browser should have access to the same content as someone using the latest and greatest web browser. But that doesn’t mean they should get the same experience. As Brad Frost puts it:
149 | 150 |151 |153 | 154 |There is a difference between support and optimization.
152 |
Support every browser ...but optimise for none.
155 | 156 |Some designers have misunderstood progressive enhancement to mean that all functionality must be provided to everyone. It’s the opposite. Progressive enhancement means providing core functionality to everyone. After that, it’s every browser for itself. Far from restricting what features you can use, progressive enhancement provides web designers with a way to safely use the latest and greatest features without worrying about older browsers. Scott Jehl of the agency Filament Group puts it succinctly:
157 | 158 |159 |161 | 162 |Progressive Enhancement frees us to focus on the costs of building features for modern browsers, without worrying much about leaving anyone out. With a strongly qualified codebase, older browser support comes nearly for free.
160 |
If a website is built using progressive enhancement then it’s okay if a particular feature isn’t supported or fails to load: Ajax, geolocation, whatever. As long as the core functionality is still available, web designers don’t need to bend over backwards trying to crowbar support for newer features into older browsers.
163 | 164 |You also get a website that’s more resilient to JavaScript’s error‐handling model. Mat Marquis worked alongside Scott Jehl on the responsive website for the Boston Globe. He noted:
165 | 166 |167 |169 | 170 |Lots of cool features on the Boston Globe don’t work when JS breaks; “reading the news” is not one of them.
168 |
The trick is identifying what is considered core functionality and what is considered an enhancement.
171 | 172 |This is a web book, designed to be read on the web (with or without an internet connection). So you can start reading now. But if you’d prefer to have a copy of this book in another format, you can download a PDF in portrait format (7MB) or a PDF in landscape format (19.9MB). There’s also an EPUB version (4.4MB) and a MOBI version (10.4MB).
60 | 61 |You can subscribe to a podcast feed of the book via RSS, iTunes, Stitcher, or Pocket Casts.
64 |Or you can listen to individual MP3 files: Introduction, Foundations, Materials, Visions, Languages, Layers, Steps, and Challenges.
65 |Or you can download one mp3 file of the whole book.
66 | 67 | 162 | 163 |With a title like Resilient Web Design, you might think that this is a handbook for designing robust websites. This is not a handbook. It’s more like a history book.
311 | 312 |Marshall McLuhan once said:
313 | 314 |315 |317 | 318 |We look at the present through a rear‐view mirror. We march backwards into the future.
316 |
But in the world of web design, we are mostly preoccupied with the here and now. When we think beyond our present moment, it is usually to contemplate the future—to imagine the devices, features, and interfaces that don’t yet exist. We don’t have time to look back upon our past, and yet the history of web design is filled with interesting ideas.
319 | 320 |The World Wide Web has been around for long enough now that we can begin to evaluate the twists and turns of its evolution. I wrote this book to highlight some of the approaches to web design that have proven to be resilient. I didn’t do this purely out of historical interest (although I am fascinated by the already rich history of our young industry). In learning from the past, I believe we can better prepare for the future.
321 | 322 |You won’t find any code in here to help you build better websites. But you will find ideas and approaches. Ideas are more resilient than code. I’ve tried to combine the most resilient ideas from the history of web design into an approach for building the websites of the future.
323 | 324 |I hope you will join me in building a web that lasts; a web that’s resilient.
325 | 326 |With a title like Resilient Web Design, you might think that this is a handbook for designing robust websites. This is not a handbook. It’s more like a history book.
41 | 42 |Marshall McLuhan once said:
43 | 44 |45 |47 | 48 |We look at the present through a rear‐view mirror. We march backwards into the future.
46 |
But in the world of web design, we are mostly preoccupied with the here and now. When we think beyond our present moment, it is usually to contemplate the future—to imagine the devices, features, and interfaces that don’t yet exist. We don’t have time to look back upon our past, and yet the history of web design is filled with interesting ideas.
49 | 50 |The World Wide Web has been around for long enough now that we can begin to evaluate the twists and turns of its evolution. I wrote this book to highlight some of the approaches to web design that have proven to be resilient. I didn’t do this purely out of historical interest (although I am fascinated by the already rich history of our young industry). In learning from the past, I believe we can better prepare for the future.
51 | 52 |You won’t find any code in here to help you build better websites. But you will find ideas and approaches. Ideas are more resilient than code. I’ve tried to combine the most resilient ideas from the history of web design into an approach for building the websites of the future.
53 | 54 |I hope you will join me in building a web that lasts; a web that’s resilient.
55 | 56 |some text
6 | 7 | A web browser encountering this element will display the text between the opening and closing tags. Now consider what happens when that same web browser encounters an element it doesn't recognise. 8 | 9 |width and height attributes, designers could control the amount of whitespace in their designs.
60 |
61 | Another technique used the TABLE element. This element—along with its children TR and TD—was intended to describe tabular data. But with the right values applied to the widths and heights of table cells, it could be used to recreate just about any desired layout.
62 |
63 | These were hacks; clever solutions to tricky problems. But they had unfortunate consequences. Designers were treating HTML as a tool for the appearance of content instead of a language for describing the meaning of content. CSS was a solution to this problem, if only designers could be convinced to use it.
64 |
65 | ###Browser wars
66 |
67 | One of the reasons why web designers weren't using CSS was the lack of browser support. Back then there were two major browsers competing for the soul of the web: Microsoft Internet Explorer and Netscape Navigator. They were incompatible by design. One browser would invent a new HTML element or attribute. The other browser would invent their own separate element or attribute to do exactly the same thing.
68 |
69 | Perhaps the thinking behind this strategy was that web designers would have to choose which proprietary features they were going to get behind, like children being forced to choose between parents. In reality web designers had little choice but to write for both browsers which meant doing the twice the work.
70 |
71 | A group of web designers decided enough was enough. They gathered together under the banner of the Web Standards Project and began lobbying Microsoft and Netscape to abandon their proprietary ways and adopt standards such as CSS.
72 |
73 | The tide began to turn with the launch of Internet Explorer 5 for the Mac, a browser that shipped with impressive CSS support. If this was the future of web design, life was about to get a lot more productive and creative.
74 |
75 | Some forward-thinking web designers caught the CSS bug early. They redesigned their websites using CSS for layout instead of using TABLEs and spacer GIFs. True to the founding spirit of the web, they shared what they were learning and encouraged others to make the switch to CSS.
76 |
77 | Perhaps the best demonstration of the power of CSS was a website called the CSS Zen Garden, created by Dave Shea. It was a showcase of beautiful and varied designs, all of them accomplished with CSS. Crucially, the HTML remained the same.
78 |
79 | Seeing the same HTML document styled in a multitude of different ways drove home one of the beneficial effects of CSS: separation of concerns.
80 |
81 | ###Coupling
82 |
83 | In any system, from urban infrastructure to a computer programme, the designers of that system can choose the degree to which the pieces of the system depend on one another. In a tightly-coupled system, every piece depends on every piece. In a loosely-coupled system, all the pieces are independent, with little to no knowledge of the other pieces.
84 |
85 | In a tightly-coupled system, each part of the system can make assumptions about the other parts. These systems can be designed quite quickly, but at a price. They lack resilience. If one piece fails, it could take the whole system with it.
86 |
87 | Designing a loosely-coupled system can take more work. The payoff is that the overall result is more resilient to failure. Individual parts of the system can be swapped out with a minimum of knock-on effects.
88 |
89 | The hacks pioneered by David Siegel tightly coupled structure and presentation into a single monolithic HTML file. The adoption of CSS eased this dependency, bringing the web closer to the modular approach of the UNIX philosophy. The presentational information could be moved into a separate file: a style sheet. That's how a single HTML document at the CSS Zen Garden could have so many different designs applied to it.
90 |
91 | The style sheet still needs to have some knowledge of the HTML document's structure. Quite often, "hooks" are added into the markup to make it easier to style: specific values of class or id attributes, for example. So HTML and CSS aren't completely decoupled. They form a partnership but they also have an arrangement. The markup document might decide that it wants to try seeing other style sheets sometimes. Meanwhile, the style sheet could potentially be applied to other documents. They are loosely coupled.
92 |
93 | ##Dancing about architecture
94 |
95 | It takes time for a discipline to develop its own design values. Web design is a young discipline indeed. While we slowly begin to form our own set of guiding principles, we can look to other disciplines for inspiration.
96 |
97 | The world of architecture has accrued its own set of design values over the years. One of those values is the principle of material honesty. One material should not be used a substitute for another. Otherwise the end result is deceptive.
98 |
99 | Using TABLEs for layout is materially dishonest. The TABLE element is intended for marking up the structure of tabular data. The end result of using TABLEs, FONT elements, and spacer GIFs is a façade. At first glance everything looks fine, but it won't stand up to scrutiny. As soon as such a website is stress-tested by actual usage across a range of browsers, the façade crumbles.
100 |
101 | Using CSS for presentation is materially honest—that's the intended use of CSS. It also allows HTML to be materially honest. Instead of trying to fulfil two roles—structure and presentation—HTML can return to fulfilling its true purpose, marking up the meaning of content.
102 |
103 | It's still possible to use (or abuse) CSS to be materially dishonest. For the longest time, there was no easy way to add rounded corners to an element using CSS. Instead, web designers found ways to hack around the problem, putting background images on the element to simulate the same end effect. It worked up to a point, but just like the spacer GIF hack, it was a façade. Then the border-radius property arrived. Now designers can have their rounded corners in a materially honest way.
104 |
105 | Crucially, designers were able to use new properties like border-radius long before every web browser supported them. That's all thanks to the liberal error-handling model of CSS. Newer browsers would display the rounded corners. Older browsers would not throw an error. Older browsers would not stop parsing the CSS and refuse to parse any further. They would simply ignore the instructions they didn't understand and move on. No harm, no foul.
106 |
107 | Of course this means that the resulting website will look different in different browsers. Some people will see rounded corners. Others won't.
108 |
109 | And that's okay.
--------------------------------------------------------------------------------
/markdown/chapter04.md:
--------------------------------------------------------------------------------
1 | #Chapter 4: Languages
2 |
3 | Jon Postel was one of the engineers working on the ARPANET, the precursor to the internet. He wanted to make sure that the packets—or "datagrams"—being shuttled around the network were delivered in the most efficient way. He came to realise that a lax approach to errors was crucial to effective packet switching.
4 |
5 | If a node on the network receives a datagram that has errors, but is still understandable, then the packet should be processed anyway. Conversely every node on the network should attempt to send well-formed packets. This line of thinking was enshrined in the Robustness Principle, also known as Postel's Law:
6 |
7 | > Be conservative in what you send; be liberal in what you accept.
8 |
9 | If that sounds familiar, it's because that's the way that web browsers deal with HTML and CSS. Even if there are errors in the HTML or CSS, the browser will still attempt to process the information, skipping over any pieces that it can't parse.
10 |
11 | ##Declaration
12 |
13 | HTML and CSS are both examples of declarative languages. An author writing in a declarative language describes a desired outcome without providing step-by-step instructions to the computer processing the file. With HTML, you can describe the nature of the content—paragraphs, headings, form fields, etc.—without having to explain exactly what the browser should do with that information. With CSS, you can describe the desired appearance of the content—colours, borders, etc.—without having to write a program to apply those styles.
14 |
15 | Most programming languages are not declarative, they are imperative. Perl, Java, C++ ...these are all examples of imperative languages. If you're writing in one of those languages, you must provide precise instructions to the computer interpreting your code.
16 |
17 | Imperative languages provide you with more power and precision than declarative languages. That comes at a price. Imperative languages tend to be harder to learn than declarative languages. It's also harder to apply Postel's Law to imperative languages. If you make a single mistake—one misplaced comma or semi-colon—the entire program may fail.
18 |
19 | Imperative languages such as PHP, Ruby, and Python can be found on the servers powering the World Wide Web, reading and writing database records, processing input, and running complex algorithms. You can choose just about any programming language you want when writing server-side code. Unlike the unknowability of the end user's web browser, you have control over your server's capabilities.
20 |
21 | If you want to write imperative code that runs in a web browser, you only have one choice: JavaScript.
22 |
23 | ##Scripting
24 |
25 | The idea of executing a program from within a web page is as old as the web itself. Here's an early email to the www-talk mailing list:
26 |
27 | > I would like to know, whether anybody has extended WWW such, that it is possible to start arbitrary programs by hitting a button in a WWW browser.
28 |
29 | Tim Berners-Lee, creator of the World Wide Web, responded:
30 |
31 | > Very good question. The problem is that of programming language. You need something really powerful, but at the same time ubiquitous. Remember a facet of the web is universal readership. There is no universal interpreted programming language.
32 |
33 | That was in 1992. The universal interpreted programming language finally arrived in 1996. It was written in ten days by programmer at Netscape named Brendan Eich.
34 |
35 | The language went through a few name changes. First it was called Mocha. Then it was officially launched as LiveScript. Then the marketing department swept in and renamed it JavaScript, hoping that the name would ride the wave of hype associated with the then-new Java language. In truth, the languages have little in common. Java is to JavaScript as ham is to hamster.
36 |
37 | ##Patterns of progress
38 |
39 | JavaScript gave designers the power to update web pages even after they had loaded. Two common uses soon emerged: rollovers and form validation.
40 |
41 | Swapping out images when someone hovers their cursor over a link might not seem like a sensible use of a brand new programming language, but back in the nineties there was no other way of creating hover effects.
42 |
43 | Before JavaScript came along, a form would have to be submitted to a web server before you could check to make sure that all the required fields were filled in, or that the information that was entered corresponded to an expected format.
44 |
45 | Both of those use cases still exist, but now there's no need to reach for JavaScript. You can create rollover effects using the :hover pseudo-class in CSS. You can validate form fields using the required and type attributes in HTML.
46 |
47 | That's a pattern that repeats again and again: a solution is created in an imperative language and if it's popular enough, it migrates to a declarative language over time. When a feature is available in a declarative language, not only is it easier to write, it's also more robust.
48 |
49 | The loose error-handling of HTML and CSS means that any authoring mistakes or browser support issues are handled gracefully; the browser simply ignores what it doesn't understand and carries on. By contrast, if you give a browser some badly-formed JavaScript or attempt to use an unsupported JavaScript feature, not only will the browser throw an error, it will stop parsing the script at that point and refuse to go any further.
50 |
51 | ##Responsibility
52 |
53 | JavaScript gave web designers the power to create websites that were slicker, smoother, and more reactive. The same technology also gave web designers the power to create websites that were sluggish, unwieldy, and more difficult to use.
54 |
55 | One of the earliest abuses of JavaScript came (unsurprisingly) from the advertising industry, a business whose very raison d'être is often at odds with the goals of people trying to achieve a task as quickly as possible. JavaScript allows you to create new browser windows, something that previously could only be done by the user. A young developer named Ethan Zuckerman realised that he could spawn a new window with an advertisement in it. That allowed advertisers to put their message in front of website visitors. Not only that, but JavaScript could be used to spawn multiple windows, some of them visible, some of them hidden behind the current window. It was a fiendish solution.
56 |
57 | Twenty years later, Zuckerman wrote:
58 |
59 | > I wrote the code to launch the window and run an ad in it. I’m sorry.
60 |
61 | Pop-up (and pop-under) windows became so intolerable that browsers had to provide people with a means to block them.
62 |
63 | The advertising industry later found other ways to abuse JavaScript. Ad-supported online publishers injected bloated and inefficient JavaScript into their pages, making them slow to load. JavaScript was also used to track people from site to site. People reached for ad-blocking software to combat this treatment. Eventually ad blocking was built into browsers and operating systems to give us the ability to battle excessive JavaScript.
64 |
65 | Web designers would do well to remember what the advertising industry chose to ignore: on the web, the user has the final say.
66 |
67 | ##2.0
68 |
69 | The rise of JavaScript was boosted in 2005 with the publication of an article entitled _Ajax: A New Approach to Web Applications_ by Jesse James Garrett. The article put a name to a technique that was gaining popularity. Using a specific subset of JavaScript, it was possible for a web browser to send and receive data from a web server without refreshing the whole page. The result was a smoother user experience.
70 |
71 | The term Ajax was coined at the same time as another neologism was in the ascendent. Tim O'Reilly used the phrase Web 2.0 to describe a new wave of web products and services. Unlike Ajax, it was difficult to pin down a definition of Web 2.0. For business people, it meant new business models. For graphic designers, it meant rounded corners and gradients. For developers, it meant JavaScript and Ajax.
72 |
73 | Whatever its exact meaning, the term Web 2.0 captured a mood and a feeling. Everything was going to be different now. The old ways of thinking about building for the web could be cast aside. Treating the web as a limitless collection of hyperlinked documents was passé. The age of web apps was at hand.
74 |
75 | ##Appiness
76 |
77 | In the 1964 supreme court case Jacobellis versus Ohio, Justice Potter Stewart provided this definition of obscenity:
78 |
79 | > I know it when I see it.
80 |
81 | The same could be said for Web 2.0, or for the term "web app". We can all point to examples of web apps, but it's trickier to provide a definition for the term. Web apps allow people to create, edit, and delete content. But these tasks were common long before web apps arrived. People could fill in forms and submit them to a web server for processing. Ajax removed the necessity for that round trip to the server.
82 |
83 | Perhaps the definition of a web app requires some circular reasoning:
84 |
85 | * JavaScript is a requirement for a web app, and
86 | * a web app is a website that requires JavaScript to work.
87 |
88 | In that case, building web apps depends on a fundamental assumption: JavaScript must be available and reliable. But because of its imperative nature, JavaScript is inherently more fragile than a declarative language like HTML. Relying on JavaScript might not be such a safe assumption after all.
89 |
90 | ##Unforgiven
91 |
92 | HTML's loose error-handling allowed it to grow in power over time. It also ensured that the language was easy to learn. Even if you made a mistake, the browser's implementation of Postel's Law ensured that you'd still get a result. Surprisingly, there was an attempt to remove this superpower from HTML.
93 |
94 | After the standardisation of HTML version 4 in 1999, the World Wide Web Consortium published XHTML 1.0. This reformulated HTML according to the rules of the XML data format. Whereas HTML can have uppercase or lowercase tag names and attributes, XML requires them to be all lowercase. There were some other differences: all attributes had to be quoted, and standalone elements like IMG or BR required a closing slash.
95 |
96 | XHTML 1.0 didn't add any new features to the language. It was simply a stricter way of writing markup. XHTML 2.0 was a different proposition. Not only would it remove established elements like IMG, it would also implement XML's draconian error-handling model. If there is a single error in an XML document—one unquoted attribute or missing closing slash—then the parser should stop immediately and refuse to render anything.
97 |
98 | XHTML 2.0 died on the vine. Its theoretical purity was roundly rejected by the people who actually made websites for a living. Web designers rightly refused to publish in a format that would fail completely instead of trying to recover from an error.
99 |
100 | Strange then, that years later, web designers would happily create entire websites using JavaScript, a language that shares XML's unforgiving error-handling model. They didn't call them websites. They called them web apps. That distinction was cold comfort to someone who couldn't complete their task because a service relied on JavaScript for crucial functionality.
101 |
102 | Despite JavaScript's fragile error-handling model, web designers became more reliant on JavaScript over time. In 2015, NASA relaunched its website as a web app. If you wanted to read the latest news of the agency's space exploration efforts, you first had to download and execute three megabytes of JavaScript. This content—text and images—could have been delivered in the HTML, but the developers decided to use Ajax to retrieve this data instead. Until all that JavaScript was loaded, parsed, and executed, visitors to the site were left staring at a black background. Perhaps this was intended as a demonstration of the vast lonely emptiness of space.
103 |
104 | This highlights another difference between HTML and JavaScript. Whereas HTML can be rendered piece by piece as it is downloaded, a JavaScript file must be downloaded in its entirety before its contents can be parsed. While it's tempting to think that only a small minority of visitors will miss out on a site's JavaScript, the truth is that everybody is a non-JavaScript user until the JavaScript has finished loading ...*if* the JavaScript finishes loading. Flaky connections, interfering network operators, and unpredictable ad-blocking software can torpedo the assumption that JavaScript will always be available.
105 |
106 | The problem is not with people deliberately disabling JavaScript in their browsers. Although that's a use case worth considering, it's not the most common cause of JavaScript errors. Stuart Langridge put together a list of all the potential points of failure under the title _Everyone has JavaScript, right?_
107 |
108 | > The user requests your web app. Has the page loaded yet? Did the HTTP request for the JavaScript succeed? Did the HTTP request for the JavaScript complete? Does the corporate firewall block JavaScript? Does their ISP or mobile operator interfere with downloaded JavaScript? Have they switched off JavaScript? Do they have add-ons or plug-ins installed which inject script or alter the DOM in ways you didn't anticipate? Is the Content Delivery Network up? Does their browser support the JavaScript you've written?
109 |
110 | Many of those problems would also affect HTML and CSS files, but because of Postel's Law, they can recover gracefully.
111 |
112 | This doesn't mean that web designers shouldn't use JavaScript. But it does mean that web designers shouldn't *rely* on JavaScript when a simpler solution exists.
113 |
114 | ##Platform
115 |
116 | Web designers who ignored the message of John Allsopp's _A Dao of Web Design_ made the mistake of treating the web like print. The history of print has much to offer—hierarchy, typography, colour theory—but the web is a fundamentally different medium. The history of software development also has much to offer—architecture, testing, process—but again, the web remains its own medium.
117 |
118 | It's tempting to apply the knowledge and learnings from another medium to the web. But it is more structurally honest to uncover the web's own unique strengths and weaknesses.
119 |
120 | The language we use can subtly influence our thinking. In his book _Metaphors We Live By_, George Lakoff highlights the dangers of political language. Obvious examples are "friendly fire" and "collateral damage", but a more insidious example is "tax relief"—before a debate has even begun, taxation has been framed as something requiring relief.
121 |
122 | On the face of it, the term "web platform" seems harmless. Describing the web as a platform puts it on par with other software environments. Flash was a platform. Android is a platform. iOS is a platform. But the web is not a platform. The whole point of the web is that it is *cross*-platform.
123 |
124 | A platform provides a controlled runtime environment for software. As long as the user has that runtime environment, you can be confident that they will get exactly what you've designed. If you build an iOS app and someone has an iOS device, you know that they will get 100% of your software. But if you build an iOS app and someone has an Android device, they will get 0% of your software. You can't install an iOS app on an Android device. It's all or nothing.
125 |
126 | The web isn't as binary as that. If you build something using web technologies, and someone visits with a web browser, you can't be sure how many of the web technologies will be supported. It probably won't be 100%. But it's also unlikely to be 0%. Some people will visit with iOS devices. Others will visit with Android devices. Some people will get 80% or 90% of what you've designed. Others will get just 20%, 30%, or 50%. The web isn't a platform. It's a continuum.
127 |
128 | Thinking of the web as a platform is a category error. A platform like Flash, iOS, or Android provides stability and certainty, but only under a very specific set of circumstances—your software must be accessed with the right platform-specific runtime environment. The web provides no such certainty, but it also doesn't restrict the possible runtime environments.
129 |
130 | Platforms are controlled and predictable. The World Wide Web is chaotic and unpredictable.
131 |
132 | The web is a hot mess.
--------------------------------------------------------------------------------
/markdown/chapter05.md:
--------------------------------------------------------------------------------
1 | #Chapter 5: Layers
2 |
3 | In his classic book _How Buildings Learn_ Stewart Brand highlights an idea by the British architect Frank Duffy:
4 |
5 | > A building properly conceived is several layers of longevity.
6 |
7 | Duffy called these shearing layers. Each of the layers moves at a different timescale. Brand expanded on the idea, proposing six alliterative layers:
8 |
9 | 1. **Site**—the physical location of a building only changes on a geological timescale.
10 | 2. **Structure**—the building itself can last for centuries.
11 | 3. **Skin**—the exterior surface gets a facelift or a new lick of paint every few decades.
12 | 4. **Services**—the plumbing and wiring need to be updated every ten years or so.
13 | 5. **Space plan**—the layout of walls and doors might change occasionally.
14 | 6. **Stuff**—the arrangement of furniture in a room can change on a daily basis.
15 |
16 | The idea of shearing layers can also be applied to our creations on the web. Our domain names are the geological sites upon which we build. At the other end of the timescale, content on the web—the "stuff"—can be added and updated by the hour, the minute, or even the second. In between are the layers of structure, presentation, and behaviour: HTML, CSS, and JavaScript.
17 |
18 | Those layers can be loosely-coupled, but they aren't completely independent. Just as a building cannot have furniture without first having rooms and walls, a style sheet needs some markup to act upon. The coupling between structure and presentation is handled through selectors in CSS: element selectors, class selectors, and so on. With JavaScript, the coupling is handled through the vocabulary of the Document Object Model, or DOM.
19 |
20 | In a later book, _The Clock Of The Long Now_, Stewart Brand applied the idea of shearing layers—or pace layers—to civilisation itself. The slowest moving layer is nature itself, then there's culture, followed by governance, then infrastructure, and finally commerce and fashion as the fastest layers. In a loosely-coupled way, each layer depends on the layer below. In turn, the accumulation of each successive layer enables an "adjacent possible" filled with more opportunities.
21 |
22 | Likewise, the expressiveness of CSS and JavaScript is only made possible on a foundation of HTML, which itself requires a URL to be reachable, which in turn depends on the HyperText Transfer Protocol, which sits atop the bedrock of TCP/IP.
23 |
24 | Each of the web's shearing layers can be peeled back to reveal a layer below. Running that process in reverse—applying each layer in turn—is a key principle of resilient web design.
25 |
26 | ##Progressive enhancement
27 |
28 | In 2003, the South by Southwest festival in Austin, Texas was primarily an event for musicians and filmmakers. Today the music and film portions are eclipsed by the juggernaut of South by Southwest Interactive, dedicated to all things digital. In 2003, South by Southwest Interactive was a small affair, squeezed into one corner of one floor of the Austin Convention Center. It was a chance for a few web designers and bloggers to get together and share ideas. That year, Steven Champeon and Nick Finck presented a talk entitled _Inclusive Web Design For the Future with Progressive Enhancement_. They opened with this call to arms:
29 |
30 | > Web design must mature and accept the developments of the past several years, abandon the exclusionary attitudes formed in the rough and tumble dotcom era, realize the coming future of a wide variety of devices and platforms, and separate semantic markup from presentation logic and behavior.
31 |
32 | Like Tim Berners-Lee, Steven Champeon had experience of working with SGML, the markup language that would so heavily influence HTML. In dealing with documents that needed to be repurposed for different outputs, he came to value the separation of structure from presentation. A meaningfully marked up document can be presented in multiple ways through the addition of CSS and JavaScript.
33 |
34 | This layered approach to the web allows the same content to be served up to a wide variety of people. But this doesn't mean that everyone gets the same experience. Champeon realised that a strong separation of concerns would allow enhancements to be applied according to the capabilities of the end user's device.
35 |
36 | To paraphrase Karl Marx, progressive enhancement allows designers to ask from each browser according to its ability, and to deliver to each device according to its needs.
37 |
38 | ###Do websites need to look exactly the same in every browser?
39 |
40 | Some web designers were concerned that progressive enhancement would be a creative straitjacket. Designing for the lowest common denominator did not sound like a recipe for progress. But this was a misunderstanding. Progressive enhancement asks that designers *start* from the lowest common denominator (a well marked-up document), but there is no limit to where they can go from there.
41 |
42 | In fact, it's the very presence of a solid baseline of HTML that allows web designers to experiment with the latest and greatest CSS. Thanks to Postel's Law and the loose error-handling model of CSS, designers are free to apply styles that only work in the newest browsers.
43 |
44 | This means that not everyone will experience the same visual design. This is a feature of the web, not a bug. New browsers and old browsers; monochrome displays and multi-coloured displays; fast connections and slow connections; big screens, small screens, and no screens; everyone can access your content. That content *should* look different in such varied situations. If a website looks the same on a ten-year old browser as it does in the newest devices, then it probably isn't taking advantage of the great flexibility that the web offers.
45 |
46 | To emphasis this, designer Dan Cederholm created a website to answer the question, "Do websites need to look exactly the same in every browser?" You can find the answer to that question at the URL:
47 |
48 | dowebsitesneedtolookexactlythesameineverybrowser.com
49 |
50 | At the risk of spoiling the surprise for you, the answer is a resounding "No!" If you visit that website, you will see that answer proudly displayed. But depending on the capabilities of your browser, you may or may not some of the stylistic flourishes applied to that single-word answer. Even if you don't get *any* of the styles, you'll still get the content marked up with semantic HTML.
51 |
52 | ##Cutting the mustard
53 |
54 | Separating structure and presentation is relatively straightforward. You can declare whatever styles you want, safe in the knowledge that browsers will ignore what they don't understand. Separating structure and behaviour isn't quite so easy. If you give a browser some JavaScript that it doesn't understand, not only will it not apply the desired behaviour, it will refuse to parse the rest of the JavaScript.
55 |
56 | Before you use a particular feature in JavaScript, it's worth testing to see if that feature is supported. This kind of feature detection can save your website's visitors from having a broken experience because of an unsupported feature. If you want to use Ajax, check first that the browser supports the object you're about to use to enable that Ajax functionality. If you want to use the geolocation API, check first that the browser supports it.
57 |
58 | A team of web developers working on the BBC news website referred to this kind of feature detection as cutting the mustard. Browsers that cut the mustard get an enhanced experience. Browsers that don't cut the mustard still get access to the content, but without the JavaScript enhancements.
59 |
60 | Feature detection, cutting the mustard, whatever you want to call it, is a fairly straightforward technique. Let's say you want to traverse the DOM using querySelector and attach events to some nodes in the document using addEventListener. Your mustard-cutting logic might look something like this:
61 |
62 | if (document.querySelector && window.addEventListener) {
63 | // Enhance!
64 | }
65 |
66 | There are two points to note here:
67 |
68 | 1. This is feature detection, not browser detection. Instead of asking "which browser are you?" and trying to infer feature support from the answer, it is safer to simply ask "do you support this feature?"
69 | 2. There is no else statement.
70 |
71 | ##Aggressive enhancement
72 |
73 | Back when web designers were trying to exert print-like control over web browsers, a successful design was measured in pixel perfection: did the website look exactly the same in every browser?
74 |
75 | Unless every browser supported a particular feature—like, say, rounded corners in CSS—then that feature was off the table. Instead, designers would fake it with extra markup and images. The resulting websites lacked structural honesty. Not only was this a waste of talent and energy on the part of the designers, it was a waste of the capabilities of modern web browsers.
76 |
77 | The rise of mobiles, tablets, and responsive design helped to loosen this restrictive mindset. It is no longer realistic to expect pixel-perfect parity across devices and browsers. But you'll still find web designers bemoaning the fact that they have to support an older outdated browser because a portion of their audience are still using it.
78 |
79 | They're absolutely right. Anyone using that older browser should have access to the same content as someone using the latest and greatest web browser. But that doesn't mean they should get the same experience. As Brad Frost puts it:
80 |
81 | > There is a difference between support and optimization.
82 |
83 | *Support* every browser ...but *optimise* for none.
84 |
85 | Some designers have misunderstood progressive enhancement to mean that *all* functionality must be provided to *everyone*. It's the opposite. Progressive enhancement means providing *core* functionality to everyone. After that, it's every browser for itself. Far from restricting what features you can use, progressive enhancement provides web designers with a way to safely use the latest and greatest features without worrying about older browsers. Scott Jehl of the agency Filament Group puts it succinctly:
86 |
87 | > Progressive Enhancement frees us to focus on the costs of building features for modern browsers, without worrying much about leaving anyone out. With a strongly qualified codebase, older browser support comes nearly for free.
88 |
89 | Scott worked on the responsive website for the Boston Globe newspaper. His colleague at the time, Mat Marquis, noted:
90 |
91 | If a website is built using progressive enhancement then it's okay if a particular feature isn't supported or fails to load: Ajax, geolocation, whatever. As long as the core functionality is still available, web designers don't need to bend over backwards trying to crowbar support for newer features into older browsers.
92 |
93 | You also get a website that's more resilient to JavaScript's error-handling model. Mat Marquis worked alongside Scott Jehl on the responsive website for the Boston Globe. He noted:
94 |
95 | > Lots of cool features on the Boston Globe don’t work when JS breaks; “reading the news” is not one of them.
96 |
97 | The trick is identifying what it is considered core functionality and what is considered an enhancement.
--------------------------------------------------------------------------------
/markdown/chapter06.md:
--------------------------------------------------------------------------------
1 | #Chapter 6: Steps
2 |
3 | "Always design a thing by considering it in its next larger context", said the Finnish architect Eliel Saarinen. "A chair in a room, a room in a house, a house in an environment, an environment in a city plan."
4 |
5 | At first glance, web design appears to be a kind of graphic design. Using graphic design tools like Photoshop to design websites reinforces this view. But to get to the heart of a website's purpose, we should consider the interface in its larger context: what are people trying to accomplish?
6 |
7 | When designing for the web, it's tempting to think in terms of interactions like swiping, tapping, clicking, scrolling, dragging and dropping. But very few people wake up in the morning looking forward to a day of scrolling and tapping. They're more likely to think in terms of reading, writing, sharing, buying and selling. Web designers need to see past the surface-level actions to find the more meaningful verbs beneath.
8 |
9 | In their book _Designing With Progressive Enhancement_, the Filament Group describe a technique they call "the x-ray perspective":
10 |
11 | > Taking an x-ray perspective means looking "through" the complex widgets and visual styles of a design, identifying the core content and functional pieces that make up the page, and finding a simple HTML equivalent for each that will work universally.
12 |
13 | If you're not used to this approach to web design, it can take some getting used to. But after a while it becomes a habit and then it's hard *not* to examine interfaces in this way. It's like trying not to notice bad kerning, or tying not to see the arrow in the whitespace of the FedEx logo, or trying to not to remember that all ducks are actually wearing dog masks.
14 |
15 | Here's a three-step approach I take to web design:
16 |
17 | 1. Identify core functionality.
18 | 2. Make that functionality available using the simplest possible technology.
19 | 3. Enhance!
20 |
21 | Identifying core functionality might sound like it's pretty straightforward, and after a bit of practice, it is. But it can be tricky at first to separate what's truly necessary from what's nice to have.
22 |
23 | ##Information
24 |
25 | Let's say you're a news provider. That right there is the core functionality—to provide news. There are many, many other services you could also provide; interactive puzzles, realtime notifications, and more. Valuable as those services are, they're probably not as important as making sure that people have access to news.
26 |
27 | With that core functionality identified, it's time to move on to step two: how can you make that core functionality available using the simplest possible technology?
28 |
29 | Theoretically, a plain text file would be the simplest possible way of providing the news. But as we're talking specifically about the web, let's caveat this step: how can you make the core functionality available using the simplest possible **web** technology? That would be an HTML file served up at a URL.
30 |
31 | Even at this early stage it's possible to overcomplicate things. The HTML could be unnecessarily bloated. The URL could be unnecessarily verbose; hard to share or recall.
32 |
33 | Now that the news has been marked up with the appropriate HTML elements—articles, headings, paragraphs, lists, and images—it's time for step three: enhance!
34 |
35 | By default, the news will be presented using the browser's own stylesheet. It's legible, but not exactly pleasurable. By applying your own CSS, you can sculpt the content into a more pleasing shape. Whitespace, leading, colour and contrast are all at your disposal. You can even use custom fonts—an enhancement that was impossible on the web for many years.
36 |
37 | There's no guarantee that every browser will be capable of executing every CSS declaration that you throw at it. That's okay. Those browsers will ignore what they don't understand. Crucially, the news is still available to everyone, regardless of the CSS capabilities of their browser.
38 |
39 | For browsers on large-screen devices, you can introduce layout. It might seem odd at first to think of layout as an enhancement, but that's the lesson of mobile-first responsive design. Consider the content first, then mark it up with a sensible source order, then apply layout declarations within media queries.
40 |
41 | Thanks to ever-evolving nature of CSS, there are multiple ways of applying layout. Like Andy Tannenbaum said:
42 |
43 | > The nice thing about standards is that you have so many to choose from.
44 |
45 | ##Communication
46 |
47 | Applying the three-step process to a news site is relatively straightforward. Catching up with the news is a fairly passive act. To really test this process, we need to apply it to something more interactive.
48 |
49 | Suppose we were building a social network. The people using our tool need to be able to communicate with one another regardless of where in the world they are. The core functionality is sending and receiving messages.
50 |
51 | Displaying messages in a web browser isn't difficult. There might be a lot of complexity on the server involving databases, syncing, queueing, and load balancing, but the HTML needed to structure a reverse-chronological list isn't very different from the HTML needed for a news site.
52 |
53 | Sending a message from the browser to the web server requires HTML that is interactive. That's where forms come in. In this case, a form with a text input and a submit button should be enough, at least for the basic functionality.
54 |
55 | People can now receive and respond to messages on our social network, no matter what kind of device or browser they are using. Now the trick is to improve the experience without breaking that fundamental activity.
56 |
57 | If we were to leave the site in this HTML-only state, I don't think we'd be celebrating your company's IPO anytime soon. To really distinguish our service from the competition, we need that third step in the process: enhance!
58 |
59 | At the very least, we can apply the same logic we used for the news site and style our service. Using CSS we can provide colour, texture, contrast, web fonts, and for larger screens, layout. But let's not stop with the presentation. Let's improve the interaction too.
60 |
61 | Right now this social network has the same kind of page-based interaction as a news site. Every time someone sends a message to the server, the server sends back a whole new page to the browser. We can do better than that. Time for some Ajax.
62 |
63 | We can intercept the form submission and send the data to the server using Ajax—I like using the word Hijax to describe this kind of Ajax interception. If there's a response from the server, we can also update part of the current page instead of refreshing the whole page. This would also be a good time to introduce some suitable animation.
64 |
65 | We can go further. Browsers that support WebSockets can receive messages from the server. People using those browsers could get updates as soon as they've been sent. It's even possible to use peer-to-peer connections between browsers to allow people to communicate directly.
66 |
67 | Not every browser supports this advanced functionality. That's okay. The core functionality—sending and receiving messages—is still available to everyone.
68 |
69 | ##Creation
70 |
71 | What if our social network were more specialised? Let's make it a photo-sharing service. That raises the bar a bit. Instead of sending and receiving messages, the core functionality is now sending and receiving images.
72 |
73 | The interface needs to show a reverse-chronological list of images. HTML can handle that. Once again we need a form to send data to the server, but this time it needs to be a file upload instead of a text field.
74 |
75 | With those changes, the core functionality is in place. Time to enhance.
76 |
77 | As well as all the existing enhancements—CSS, web fonts, Ajax, WebSockets—we could make use of the File API introduced in HTML5. This allows us to manipulate the image directly in the browser. We could apply effects to the image before sending it to the server. Using CSS filters, we can offer a range of image enhancements from sepia tones to vignettes. But if a browser doesn't support the File API or CSS filters, people can still upload their duck-facing selfies.
78 |
79 | ##Collaboration
80 |
81 | There was a time when using software meant installing separate programs on your computer. Today it's possible to have a machine with nothing more than a web browser installed on it. Writing emails, looking up contact details, making calendar appointments, bookkeeping and other financial tasks can all be done without having to install bespoke applications. Instead, the act of visiting a URL can conjure up the tool you need when you need it.
82 |
83 | Delivering software over the web doesn't just replace the desktop-centric way of working. The presence of an internet connection opens up possibilities for all kinds of collaboration. Take, for example, the kinds of applications that were once called "word processors". As long as those programs were tethered to individual machines, trying to collaboratively edit a document was bound to be a tricky task requiring plenty of coordination, sending files back and forth. Using the web, the act of sharing a single URL could allow multiple people to work on the same document.
84 |
85 | Let's apply the three-step process to a web-based word processor:
86 |
87 | > Identify core functionality.
88 |
89 | The tautological answer would be "processing words." Not very helpful. What do people actual *do* with this software? They write. They share. They edit.
90 |
91 | > Make that functionality available using the simplest possible technology.
92 |
93 | Looking at our three verbs—writing, sharing, and editing—we get one of them for free just by using URLs: sharing. The other two—writing and editing—require the use of a form. A basic textarea element can act as the receptacle for the words, sentences, and paragraphs that will make up everything from technical reports to the great American novel. Submitting that content to a web server means it can be saved for later.
94 |
95 | Technically, that's a web-based word processor, accessible to anyone with a web browser and an internet connection. But the experience is clunky and dull. It would be a shame not to take advantage of some of slicker options available in modern browsers.
96 |
97 | > Enhance!
98 |
99 | Using JavaScript, the humble textarea can be replaced with a richer editing interface, detecting each keystroke and applying styling on the fly. Web fonts can make the writing experience more beautiful. Ajax will allow work to be saved to the server almost constantly, without the need for a form submission. WebSockets provide the means for multiple people to work on the same document at the same time.
100 |
101 | Both Ajax and WebSockets require an internet connection to work. There's no guarantee of a stable internet connection, especially if you're trying to work on train or in a hotel. Modern browsers provide features which, after the initial page load, can turn the network itself into an enhancement.
102 |
103 | If a browser supports some form of local storage, then data can be stored in a client-side database. Flaky network connections or unexpected power outages won't get in the way of saving that important document. Using Service Workers, web developers can provide instructions on what to do when the browser (or the server) is offline.
104 |
105 | These are modern browser features that we should be taking full advantage of ...once we've made sure that we're providing a basic experience for everyone.
106 |
107 | ##Scale
108 |
109 | Ward Cunningham, the creator of the wiki, coined the term "technical debt" to describe a common problem in the world of software. Decisions made in haste at the beginning of a project lead to a cascade of issues further down the line. I like to think of the three-step layered approach as a kind of "technical credit." Taking the time to provide core functionality at the beginning gives you the freedom to go wild with experimentation from then on.
110 |
111 | Some people have misunderstood progressive enhancement to mean foregoing the latest and greatest browser technologies, but in fact the opposite is true. Taking a layered approach to building on the web gives you permission to try cutting-edge JavaScript and APIs, regardless of how many or how few browsers currently implement them.
112 |
113 | We've looked at some examples of applying the three-step approach to a few products and services—news, social networking, photo sharing, and word processing. You can apply this approach to many more services: making and updating items in a to-do list, managing calendar appointments, looking up directions, making reservations at nearby restaurants. Each one can be built with the same process:
114 |
115 | 1. Identify core functionality.
116 | 2. Make that functionality available using the simplest possible technology.
117 | 3. Enhance!
118 |
119 | This approach works at different scales. It doesn't just work at the highest level of the service; it can also be applied at the level of individual URLs within.
120 |
121 | Ask "what is the core functionality of this URL?", make that functionality available using the simplest possible technology, and then enhance from there. This can really clarify which content is most important, something that's important in a mobile-first responsive workflow. Once you've established that, make sure that content is sent from the server as HTML (the simplest possible technology). Then, using conditional loading, you could decide to make Ajax requests for supporting content if the screen real-estate is available. For the URL of an individual news story, the story itself would be sent in the initial response, but related stories or comments could be pushed from the server only as needed (although you can still provide links to the related stories and comments for everyone).
122 |
123 | We can go deeper. We can apply the three-step process at the scale of individual components within a page. "What is the core functionality of this component? How can I make that functionality available using the simplest possible technology? Now how can I enhance it?"
124 |
125 | A component might be designed to be an all-singing all-dancing interactive map. With x-ray goggles, the core functionality reveals itself to be something much simpler: showing a location. Provide the address of that location in text: the simplest possible technology. Now you can enhance.
126 |
127 | It's worth remembering that enhancements can be provided on a sliding scale. The first enhancement for a text address might be to provide a static image. The next level up from that would be to swap out the static image with an interactive Ajax-powered slippy map. If a browser supports the geolocation API, you could show the distance to the location. Layer on some animations and transitions to help convey the directions better.
128 |
129 | Site navigation is another discrete component that lends itself well to a sliding scale of enhancements. The core functionality of navigation is to provide links to resources. The simplest—and still the best—technology to enable that is the humble hyperlink. A list of links should do the trick. With that in place, you are now free to enhance it into something really compelling. Off-canvas navigation, progressive disclosure, sliding, swiping, fading, expanding ...the sky's the limit.
130 |
131 | Because enhancements can be layered on according to the capabilities of each browser, it quickly becomes clear that this approach doesn't simply reduce down to having two versions of everything (the basic version and the enhanced version). Instead the service, the URLs, and the components you are designing could be experienced in any number of ways. And that's okay.
132 |
133 | Websites do not need to look exactly the same in every browser.
--------------------------------------------------------------------------------
/markdown/chapter07.md:
--------------------------------------------------------------------------------
1 | #Chapter 7: Challenges
2 |
3 | The sixth annual conference on hypertext took place in San Antonio, Texas in December 1991. Tim Berners-Lee's World Wide Web project was starting to take shape then. Thinking the conference organisers and attendees would appreciate the project, he submitted a proposal to Hypertext '91. The proposal was rejected.
4 |
5 | The hypertext community felt that the World Wide Web project was far too simplistic. Almost every other hypertext system included the concept of two-way linking. If a resource moved, any links pointing to that resource would update automatically. The web provided no such guarantees. Its system of linking was much simpler—you just link to something and that's it. To the organisers of Hypertext '91, this seemed hopelessly naive. They didn't understand that the simplicity of the web was actually its strength. Because linking was so straightforward, anyone could do it. That would prove to be crucial in the adoption and success of the World Wide Web.
6 |
7 | It's all-too tempting to quickly declare that an approach is naive, overly simplistic, and unrealistic. The idea that a website can simultaneously offer universal access to everyone while also providing a rich immersive experience for more capable devices ...that also seems hopelessly naive.
8 |
9 | This judgement has been handed down many times over the history of the web.
10 |
11 | ##"This is too simple"
12 |
13 | When the Web Standards Project ran its campaign encouraging designers to switch from TABLEs for layout to CSS, it was met with resistance. Time and time again they were criticised for their naivety. "Sure, a CSS-based layout might be fine for a simple personal site but there's no way it could scale to a large complex project."
14 |
15 | Then Doug Bowman spearheaded the CSS-based redesign of Wired.com and Mike Davidson led the CSS-based redesign of ESPN.com. After that the floodgates opened.
16 |
17 | When Ethan Marcotte demonstrated the power of responsive design, it was met with resistance. "Sure, a responsive design might work for a simple personal site but there's no way it could scale to a large complex project."
18 |
19 | Then the Boston Globe launched its responsive site. Microsoft made their homepage responsive. The floodgates opened again.
20 |
21 | It's a similar story today. "Sure, progressive enhancement might work for a simple personal site, but there's no way it could scale to a large complex project."
22 |
23 | The floodgates are ready to open. We just need you to create the poster child for resilient web design.
24 |
25 | ##"This is too difficult"
26 |
27 | Building resilient websites is challenging. It takes time to apply functionality and features in a considered layered way. The payoff is a website that can better react to unexpected circumstances—unusual browsers, flaky network connections, outdated devices. Nonetheless, for many web designers, the cost in time seems to be too high.
28 |
29 | It's worth remembering that building with progressive enhancement doesn't mean that *everything* needs to be made available to *everyone*. Instead it's the core functionality that counts. If every single feature needed to be available to every browser on every device, that would indeed be an impossibly arduous process. This is why prioritisation is so important. As long as the core functionality is available using the simplest possible technology, you can—with a clear conscience—layer on more advanced features.
30 |
31 | Still, it's entirely possible that this approach will result in duplicated work. If you build an old-fashioned client-server form submission process and then enhance it with JavaScript, you may end up repeating the form-processing on the client as well as the server. That can be mitigated if you are also using JavaScript on the server. It's theoretically possible to write universal JavaScript so that the server and browser share a single codebase. Even without universal JavaScript, I still think it's worth spending time to create technical credit.
32 |
33 | The UK's Government Service design manual provides an even shorter form of the three-step process I've outlined:
34 |
35 | 1. First, just make it work
36 | 2. Second, make it work better
37 |
38 | The design manual also explains why:
39 |
40 | > If you build pages with the idea that parts other than HTML are optional, you’ll create a better and stronger web page.
41 |
42 | This kind of resilience means that the time you spend up-front is well invested. You might also notice an interesting trend; the more you use this process, the less time it will take.
43 |
44 | Moving from TABLEs to CSS seemed like an impossibly idealistic goal. Designers were comfortable using TABLE and FONT elements for layout. Why would they want to learn a whole new way of working? I remember how tricky it was to make my first CSS-based layouts after years of using hacks. It took me quite some time. But my second CSS-based layout didn't take quite so long. After a while, it became normal.
45 |
46 | Designers comfortable with fixed-width layouts had a hard time with responsive design. That first flexible layout was inevitably going to take quite a while to build. But the second flexible layout didn't take quite so long. After a while, it became normal.
47 |
48 | It's no different with the layered approach needed for building resilient websites. If you're not used to working this way, the first time you do it will take quite some time. But the second time won't take quite so long. After a while, it will become normal.
49 |
50 | ##"How do I convince...?"
51 |
52 | The brilliant computer scientist Grace Hopper kept an unusual timepiece on her wall. It ran counter-clockwise. When quizzed on this, she pointed out that it was an arbitrary convention, saying:
53 |
54 | > Humans are allergic to change. They love to say, "We've always done it this way." I try to fight that. That's why I have a clock on my wall that runs counter-clockwise.
55 |
56 | Behaviour change is hard. Even if you are convinced of the benefits of a resilient approach to web design, you may find yourself struggling to convince your colleagues, your boss, or your clients. It was ever thus. Take comfort from the history of web standards and responsive design. Those approaches were eventually adopted by people who were initially resistant.
57 |
58 | Demonstrating the benefits of progressive enhancement can be tricky. Because the payoff happens in unexpected circumstances, the layered approach is hard to sell. Most people will never even know whether or not a site has been built in a resilient way. It's a hidden mark of quality that will go unnoticed by people with modern browsers on new devices with fast network connections.
59 |
60 | For that same reason, you can start to implement this layered approach without having to convince your colleagues, your boss, or your clients. If they don't care, then they also won't notice. As Grace Hopper also said, "it's easier to ask forgiveness than it is to get permission."
61 |
62 | ###Tools
63 |
64 | Changing a workflow or a process can be particularly challenging if it clashes with the tools being used. A tool is supposed to help people get their work done in a more efficient way. The tool should be subservient to the workflow. All too often, tools instead dictate a preferred way of working. Whether it's WYSIWYG editors, graphic design programs, content management systems, or JavaScript frameworks, tools inevitably influence workflows.
65 |
66 | If you are aware of that influence, and you can recognise it, then you are in a better position to pick and choose the tools that will work best for you. There are many factors that play into the choice of frameworks, for example: "Is it well-written?", "Does it have an active community behind it?", "Does it have clear documentation?". But perhaps the most important question to ask is, "Does its approach match my own philosophy?"
67 |
68 | Every framework has a philosophy because every framework was written by people. If your philosophy aligns with that of the framework, then it will help you work more efficiently. But if your philosophy clashes with that of the framework, you will be fighting it every step of the way. It might even be tempting to just give up and let the framework dictate your workflow. Then the tail would be wagging the dog.
69 |
70 | Choose your tools wisely. It would be a terrible shame if you abandoned the resilient approach to web design because of a difference of opinion with a piece of software.
71 |
72 | Differences of opinion often boil down to a mismatch in priorities. At its heart, the progressive enhancement approach prioritises the needs of people, regardless of their technology. Tools, frameworks, and code libraries, on the other hand, are often built to prioritise the needs of designers and developers. That's not a bad thing. Developer convenience is hugely valuable. But speaking personally, I think that user needs should trump developer convenience.
73 |
74 | When I'm confronted with a problem, and I have the choice of making it the user's problem or my problem, I'll make it my problem every time. That's my job.
75 |
76 | ###Future friendly
77 |
78 | In September of 2011, I was speaking at a conference in Tennessee along with some people much smarter than me. Once the official event was done, we lit out for the countryside where we had rented a house for a few days. We were gathering together to try to figure out where the web was headed.
79 |
80 | We were, frankly, freaked out. The proliferation of mobile devices had changed everything. Tablets were on the rise. People were talking about internet TVs. We were hoping to figure out what the next big thing would be. Internet-enabled fridges, perhaps?
81 |
82 | In the end, the only thing we could be certain of was uncertainty:
83 |
84 | > Disruption will only accelerate. The quantity and diversity of connected devices—many of which we haven't imagined yet—will explode, as will the quantity and diversity of the people around the world who use them.
85 |
86 | That isn't cause for despair; it's cause for celebration. We could either fight this future or embrace it. Realising that it was impossible to be future-proof, we instead resolved to be future-friendly:
87 |
88 | 1. Acknowledge and embrace unpredictability.
89 | 2. Think and behave in a future-friendly way.
90 | 3. Help others do the same.
91 |
92 | That first step is the most important: acknowledging and embracing unpredictability. That is the driving force behind resilient web design. The best way to be future-friendly is to be backwards-compatible.
93 |
94 | ###Assumptions
95 |
96 | "We demand rigidly-defined areas of doubt and uncertainty!" cried the philosophers in Douglas Adams' _Hitchhiker's Guide To The Galaxy_.
97 |
98 | As pattern-matching machines, we are quick to identify trends and codify them into assumptions. Here are just some assumptions that were made over the history of web design:
99 |
100 | * Everyone has a monitor that is 640 pixels wide.
101 | * Everyone has the Flash plugin installed.
102 | * Everyone has a monitor that is 800 pixels wide.
103 | * Everyone has a mouse and a keyboard.
104 | * Everyone has a monitor that is 1024 pixels wide.
105 | * Everyone has a fast internet connection.
106 |
107 | The proliferation of mobile devices blew those assumptions out of the water. The rise of mobile didn't create new uncertainties—instead it shone a light on the uncertainties that already existed.
108 |
109 | That should have been a valuable lesson. But before too long the old assumptions were replaced with new ones:
110 |
111 | * There are some activities that people will never want to do on their phones.
112 | * Every phone has a touch screen.
113 | * Everyone using a phone is in a hurry.
114 | * Every browser on every phone supports JavaScript.
115 |
116 | Assumptions are beguiling. If only we could agree on certain boundaries, then wouldn't web design be so much easier to control?
117 |
118 | As tempting as this siren call is, it obfuscates the true nature of the ever-changing uncertain web. Carl Sagan put it best in his book _The Demon-Haunted World_:
119 |
120 | > It is far better to grasp the universe as it really is than to persist in delusion, however satisfying and reassuring.
121 |
122 | ##The future
123 |
124 | I wish I could predict the future. The only thing that I can predict for sure is that things are going to change.
125 |
126 | I don't know what kind of devices people will be using on the web. I don't know what kind of software people will be using on the web.
127 |
128 | The future, like the web, is unknown.
129 |
130 | The future, like the web, will be written by you.
131 |
--------------------------------------------------------------------------------
/offline/index.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 | Sorry.
32 | 33 |There seems to be a problem with the network.
34 | 35 |