This post is part of The Shift: a writing project designed to help us produce and consume unique perspectives on topics relevant to the Web industry. Follow along with #startYourShift.
Fault tolerance: “the property that enables a system to continue operating properly in the event of the failure of (or one or more faults within) some of its components.”
The Web has always had a level of fault tolerance. Think about it—if you miss a closing angle bracket in your HTML, the browser still renders the page. If you misspell a CSS property, the browser still renders the page. This is one of the things we love about the web: it’s scrappy, it’s robust, and its default position is that people should get access to the content we publish using it.
Enter the web designer. A creature many of you are familiar with. We’ve had a long history of breaking things. When we couldn’t get the crazy layouts we wanted, we used tables to do so. When we got frustrated with text wrapping and line-length, we fixed the width of everything. And when we created ways to load content with JS, many of us stopped caring about fault tolerance.
This month, the topic for The Shift is “Progressive Enhancement.” At its core, this idea is about embracing the fault tolerance of the Web. Start with the simplest of acceptable experiences (typically static content via HTML), layer on the design or presentation of that content (typically using CSS), then layer on interactions (typically using JS). But there is a cost to working this way, and it can be difficult to make the case for this approach to business owners.
Because there are so many perspectives out there on this topic (and Sparkboxers love to debate), we invited a handful of folks from our team to share their thoughts. Our hope is that this spurs you to consider these various perspectives, to challenge what you’ve always believed, and—perhaps—even to change the way you work. Read on…
A Project Manager’s Perspective
Emily Gray
When I reflect on Progressive Enhancement as a project manager, the order work is done feels like a major driving force. The order you do things is important beyond just developer workflow. I (and Sparkbox) want to make good decisions with our clients. We want to set them up for success. And the truth is that on essentially all projects, scope creeps and timelines and budgets have to adjust in some way. What you leave for later stands the best chance of being taken out of the project. Picture being told the following versions of a project update:
“We have this thing working precisely like you wanted. Now it’ll just be another 15 hours to get it working in all those less desirable places you only partially care about.”
versus
“We have the core basics of this working everywhere. Now it’ll just be another 15 hours to make it do all the super fancy stuff we talked about as enhancements.”
And imagine you have 12 other items on the to-do list that are just as big. How easy is it to decide that a certain browser or noJS solution just isn’t worth the time and investment in version 1 compared to version 2? If you want to purely and naturally achieve Progressive Enhancement without arguing about why it needs done, you need to take care of the basics first and put off the stuff everyone gets excited about for later; otherwise, you’re going to leave some people out of enjoying any of it. At Sparkbox, project managers are the ones who are going to have the scope/budget conversations with a client and help give direction to the team. If you set the expectation with everyone that you’ll start with the basics and enhance, you’ll stand a much better chance of achieving Progressive Enhancement team harmony.
A Web Designer’s Perspective
Marshall Norman
The Web is a huge world with people who use it in so many different ways. Designers like me use the Web at full throttle—nice computer, lots of bandwidth, riding the tech wave to Net Town. Those with sensory disabilities use the Web in an entirely different way, relying on assistive technologies like screen readers to access information. And then there are those in second-world countries using the Web for a more narrow purpose and relying on QWERTY keyboards on next-to-no bandwidth. Yet, all of us have the same goal when we get to our keyboard: we are all accessing content.
At the heart of Progressive Enhancement is the idea that we need to get content to our users, no matter what. We want to start with a site that is accessible to anyone, anywhere. Many technologies, ideologies, and techniques have sprung from this idea. Responsive websites get content to users despite their screen size. Performant sites get content to users despite their bandwidth. Accessible sites get content to users despite their disabilities. These things are all considerations in Progressive Enhancement.
Progressive Enhancement is about providing access to everyone using the Web, and leveraging accessibility techniques is a necessary first step in Progressive Enhancement. Creating a site with a baseline of content that has been run through the accessibility ringer, markup that’s using ARIA elements, alt tags, all the good stuff—Progressive Enhancement moves forward from this launching pad. If our site isn’t accessible to everyone from the start, then what’s the point?
A JavaScript Developer’s Perspective
Rob Tarr
If your primary role is to write JavaScript, then you should probably start with how your site works without it. We often think of Progressive Enhancement as what kicks in when a user has turned off JavaScript. Sure, this is part of it, but there are others who would argue that Progressive Enhancement doesn’t apply to users who have intentionally turned off JavaScript. I’m the first to admit that I’m a JavaScript guy—I love creating really cool things on the web with JavaScript.
With the rise of so many JavaScript frameworks and the lines between app and document being blurred, it feels harder to say that things need to work without JavaScript enabled. However, the part of me that says without JavaScript the content needs to be available is louder than the lazy part of me that doesn’t want to put in the effort to make things work without JavaScript.
Our JavaScript could fail for a whole host of reasons. Let’s give our users a solid experience, no matter what unexpected thing happens. Create pages that work without JavaScript by using the HTML features the Web was built on: standard links, images, and form posts. Then let’s add functionality and zing to make the experience better, but not broken if it doesn’t load.
This all starts with writing really good markup and CSS that will work for everyone, and then adding in really well-tested JavaScript for a little extra spice.
A CSS Developer’s Perspective
Philip Zastrow
The beautiful thing about the cascade is its inherent progressiveness. As the browser travels down the stylesheet, it applies properties it recognizes and skips the rest. Writing CSS that progressively enhances is a natural part of the language. But to write effective CSS that enhances well requires having a good grasp on older approaches and techniques. As Carl Sagan stated so well, “You have to know the past to understand the present.”
Let’s take a look at how we handle layout these days. We have been using floats as our primary way to control layout for many, many years, which has been somewhat problematic since floats were not initially created to control layouts. We’ve had to figure out ways to clear those floats and be very specific with container dimensions, and then there are those weird wrapping bugs. That is where flexbox comes in: it’s a solution to float layouts and other layout inefficiencies of the past. A particularly fantastic aspect of flexbox is that it‘s designed to respect the cascade. Its properties can largely live alongside other properties. Flexbox overrides floats, so the old way of aligning content can still be used, and then the new way can refine and enhance that alignment.
See the Pen Flex Progressive Enhancement with Float Fallback by Philip Zastrow (@zastrow) on CodePen.
You may have noticed the doubled display properties in the CodePen above. This gets into what I love about the cascade for Progressive Enhancement. Properties, if supported by the browser, are overwritten the further down the cascade they reside. So in the above case, if a browser does not support flexbox,it will apply the display: block; however, if the browser does support flexbox, that browser will understand and apply display: flex;.
Now if we continue with this example we will run into situations where browsers get weird. Sometimes browsers half-implement a property, which can wreak havoc on an otherwise peaceful cascade. Or perhaps adjustments are needed on other styles when a particular property is supported. This could certainly happen with flexbox, as refinements to the column may include adding some margins. A great detection tool for browser features, like flexbox, and one that’s amazing for Progressive Enhancement is Modernizr. We can enhance our styles based on the presence of classes Modernizr adds to the html tag. The CSS from above could be enhanced with Modernizr classes like so:
See the Pen Flex Progressive Enhancement with Float Fallback (with Modernizr Classes) by Philip Zastrow (@zastrow) on CodePen
This will apply a margin-left: 1em and a dark grey left border to .right if Modernizr detects that flexbox is supported by the browser. Otherwise, these properties will be skipped since the browser cannot find an element with that scope. Modernizr is a unique and useful tool that allows precise control over progressive enhancements without relying on hacks.
Progressive Enhancement is an important part of building an inclusive website. Reliance on the cascading structure of CSS makes Progressive Enhancement easily attainable.
A React Developer’s Perspective
Adam Simpson
As the introduction so eloquently outlined in the beginning of this post, Progressive Enhancement is about embracing the inherent “fault-tolerance” of the Web. JavaScript has traditionally been not-so-great about this. Any errors in your script? Down goes your entire script. Error loading your script? No script for you. JavaScript is the least tolerant of the three core languages of the Web. It’s also the most powerful. Because of this, developers have always been searching for a way to leverage the inherent power of JavaScript in this muddled world of browsers and crappy connections. Enter React.
React has been making waves in the frontend community for a couple years now. It began its life inside Facebook as a way to address a few core problems its web teams were facing:
Integrate whatever solution they came up with into their existing codebase incrementally without having to do a full re-write.
Allow rapid development of self-contained components that are easy to understand.
To address these issues, React is primarily concerned with outputting DOM (or Android/iOS primitives via React Native) given two things: a component’s internal state and parameters passed in from the parent component. A component’s state is mutations to the component over time like a button click or text typed into an input. Component properties are passed into the component that can be any Javascript primitive: a string, a function, a boolean, etc. React’s strict focus on outputting DOM means that it can not only be used inside browser-loaded JavaScript, but also on the server via Node.js as it doesn’t have a dependency on the browser itself. This means React applications can serve up a React-rendered DOM in the initial HTML payload and then run the React client app on top of it. Serving up React-rendered DOM means your JavaScript has already run once, albeit on the server. Your app becomes less brittle and fragile when loaded this way. Consumers of your app will always get the initial content for that page or screen or widget—no more white screen of death when your JavaScript fails to load due to network failure or some other unforeseen error in the delivery or execution of your Javascript.
Server-rendered React apps unlock a more fault-tolerant approach to building JavaScript Web applications. Since React introduced server-rendering components, Ember has embraced this idea and started working hard on its Fastboot feature, which enables this same kind of content-first approach.
A Technical Director’s Perspective
Ryan Cromwell
As Technical Director here at Sparkbox and consultant before, my goals shuffle between giving our super-talented team an opportunity to shine and helping our clients make informed decisions. While the latter might not always seem to align with the former, I believe building the right product is the best way for us to shine, and I’d like to talk about why Progressive Enhancement is an important tool in making smart business decisions.
We should be past the point of convincing readers of the importance of the web to our economy. Suppose that we also agree that the Web will continue to influence markets, which so far, felt immune. More interesting than if, is how a business should effectively leverage the Web to build and grow a place in their market.
The last few years, much of the web industry’s work has been focused on supporting the myriad of devices in use. In 2014, we saw a 20% growth of smartphone sales. Fast forward just a few short years and we can expect a third year of declining smartphone sales growth to 7%, while connected “things” will grow 30%. With those devices people are purchasing less of, more of them are being used to search via voice and engage in augmented reality-based marketing.
At the same time, we can expect demographics to change. In 2014, the fastest-growing internet population actually lost ground in broadband performance and capability. Heck, even suburbia has a poor connection upstairs.
While the Internet around us continues to evolve, a few things remain consistent: humans are impatient, and computers prefer structured data. Progressive Enhancement is an invaluable set of principles that help businesses play in a shifting sandbox with fickle customers using feature enhancements prioritized for devices and conditions that deliver the most value to our business. Toss aside the dogma and begin making clear, conscious choices about features that are worth the cost of optimizing for a market segment.
It Takes a Village
To do this stuff right, it takes commitment and buy-in from the entire team. Progressive Enhancement is not something you can tack onto the end of a project. In fact, you’ll struggle if you try to do it without involving your client or stakeholders.
But it’s so important.
The fault tolerance of the Web gives it more power than any other communication technology, but we are responsible for following patterns that allow this power to surface. Yeah, you and I can totally ruin it, but we can also make it beautiful!
So take the time to understand how you can use Progressive Enhancement techniques in your next project, and get to work.
