Feature First Websites: Graceful Degradation
- It’s simple, we kill Progressive Enhancement
--
The purpose of this article is to go from:
Client: “It doesn't look right in IE”, Dev: (hesitation) “Um, I’ll take a look…”.
to
Client: “The IE version doesn’t look the same as the others”, Dev: “Because it’s legacy”
Disclaimer: On the web, “Regressive Enhancement” can be perceived as an abstraction layer on top of “Progressive Enhancement” techniques, as the concept of polyfills prioritizes out-of-date browsers. To simplify the article, when I refer to progressive enhancement I am also referring to regressive enhancement alike.
Stop Using Progressive Enhancement
(on the web)…There’s a time and place for everything, and in 2015 it’s that time to “gracefully” break away from Progressive Enhancement as a fundamental web development principal:
Progressive Enhancement is detrimental to the web
Before you raise hell and stone me to death, you may have a preconceived opposing view, you may be advocating that everyone’s web & development experiences are rainbows & unicorns. (Chill for a second!)
The more we use “Progressive Enhancement” techniques on the web, the slower web technologies progress to a consistency, websites become inefficient for legacy & modern systems and browser vendors become less accountable for their ridiculous self-harming web strategies.
If your face is not screwed up yet, consider this, in the general sense: The websites we design today are not “enhanced” for i.e,..
- People with the latest Mac Book Air. Because likely our libraries, (i.e., AngularJS, Bootstrap, jQuery, etc) were built with regressive enhancement in mind and rightly so. But at the same time…
- People using IE8 on Windows XP. Because we can not feasibly make a less powerful legacy platform emulate modern powerful features, entirely.
- People with old Android devices or the latest iPhone. For equivalent reasons to the above.
So if progressive enhancement is not maximizing any aspects of the user experience, then who are we enhancing it for?
Progressive enhancement benefits the vendor ONLY!
This is not a capitalism rant, behave! But here’s my message to these vendors:
THERE IS NO MONEY IN BEING INCONSISTENT
A browser vendor has one job, to display a website as it was intended to be displayed.
Fortunately, we no longer need to use progressive enhancement to clean up after vendors. We can take care of all our users, whilst giving them better experiences and at the same time reduce development time?
I know, control your rainbows ;-D
The Damage
Progressive enhancement benefits only a small minority of user, in a region between modern and legacy users. But how can this be true?
Bad for legacy / mid-way users
Lets look at the resistance that is rarely considered during development & testing:
- SPYWARE, MALWARE — About 32 % of computers are infected with some sort of malware, consider this performance resistance coupled with the strains of polyfills that usually overwork old browsers as a unit.
- SLOW PERFORMANCE — Many have slow computers, with out-dated OSs, not enough memory & a lack of GPU acceleration, (the progressive enhancement workflow encourages regressive enhancement, hope you can read between the lines).
- MULTITASKING — Someone on the other side of the world is running IE8, via windows XP, with MS Office opened, two Facebook tabs, a twitter tab, study resources and your company’s website. Not to mention spyware & ad-ware. It’s all miserably slow. IMHO I believe it’s less feasible for a user with an outdated browser to prefer a slow website solely for the sake of appearing modern.
- BANDWIDTH — At the time of this article, the world average is roughly 4.5 Mbps (562 kB/s), and the average web page is approximately 2MB, although realistically a 2MB web page will take significantly more than 4 seconds to load on average, (Double or quadruple that duration on a good day).
If it is possible to not use JavaScript in browsers such as, ie9–32bit< , Safari 5< and Android browser then do not. Minimal, clean CSS can be hundreds of times faster than a typical JavaScript implementation.
For legacy browsers a lack of “enhancements” in a web app should be considered as an enhancement.
Bad for modern users
There is a sacrifice to progressive enhancement, there is a performance cost, feature cost, development time maybe lost to the lower end of the scale, and the business focus resides away from maximum potentials. Despite development teams saying, “We’re focusing on modern users” it’s already out of their hands.
Evergreen Browsers
An evergreen browser is a browser that auto-updates with web features. This includes IE10 + 11, Edge, Chrome, Firefox, Opera and Safari 7 +8. Some browser brands are not platform version dependent, which includes Chrome, Firefox, Opera & Edge. Let me be clear when I say this article is not about vendor preference, it’s about understanding agendas and encouraging a web that is more enabling.
Features First
Let’s recap; “Progressive Enhancement”…
- Hurts users on legacy systems,
- Hurts users on modern systems,
- Ignores vendors accountability,
- Slows progression of the web,
- fatality ☠
Building a feature-first web
Graceful Degradation is the way to achieve a feature-first web. If every major browser vendor agreed upon a consensus to keep features in sync then this would be the default approach. Though even though they’re inconsistent amongst each other, with the arrival of evergreen browsers at the fore-front this approach is now feasible as it confirms the extinction of legacy browsers.
More or less, everybody wins
Nobody wants a pretty website that is unbearably slow, nor do they want to load resources dedicated to the debt of outdated browsers, devs hate being told (“Don’t use that, it’s not supported in IEx”). So let’s abolish these concerns, practically.
How Should Graceful Degradation Work?
Via some form of “Feature Discrimination”
You must make assumptions about users who use old browsers like IE9, and Safari 5. Assume they are using underpowered devices, assume that your modern website will not perform as fluid on those devices.
Legacy State
The legacy user experience has little to no JavaScript, looks nothing like the present state with exceptions to branding & content. It may have all the functionalities of the present state, it may not. The CSS is minimal. There are little to no animations and only necessary media content.
Present State
This is what the majority of people see with modern browsers, the site in all its glory. Considerate to low bandwidth and high in performance with as close to zero legacy debt as possible.
Feature detect your fellow legacy users
Use feature detection, to target browsers & users relative to your low-performance generalizations. Under no circumstances should you use non-related or depreciating features to outcast certain browsers or legacy users, this is dangerous and unpredictable.
e.g., To exclude IE9 and below from the “present state” do not feature detect i.e. the Autofocus attribute, use a more prominent feature such as 3D Transforms.
e.g., For an SVG project: To target all IE versions as legacy do not feature detect SMIL as it is considered depreciating. Instead feature detect something like the foreignObject API, which is featured in all evergreen browsers on the front-line of the future.
With “Graceful Degradation” via feature detection always settle for desirable features , not the browsers you despise.
Once you are satisfied with your feature-first set-up you can use forbidden user-agent techniques to clean up any remaining legacy who should experience the “legacy” state. This is very safe because now there is a distinction between two states not several.
Generalizing with Graceful Degradation
In regards to the concepts in this article, the aim is to generalize users who use old browsers or lack needed features. That’s perfectly fine, as the intentions of users with out-dated browsers & hardware are usually predictable and mostly revolve around necessities. As long as the legacy-state of the website is functional and snappy, it’s adequate.
Functionality is way more important than replication.
The Legacy State Of Feature-First Sites
- First rule of legacy club: If you can easily produce the content and main functionality without JavaScript, then don’t use any JavaScript.
- Legacy In Mind: Always check reliable browser usage stats & any relevant or current users analytics.
- Weight: If you must use JavaScript keep it light-weight and relative. Aim for around 100kB if possible. Avoid including entire libraries, keep the memory heap low. Avoid animations if unless necessary.
Legacy JavaScript
Only include what you need, surprisingly many people are not aware of this:
- jQuery Builder — Only include the components you need
- lodash modularized — Only include the modules you need
- Modernizer — Build your library …you get the picture.
Legacy CSS
Do not use Bootstrap, as it goes against the entire purpose of Graceful Degradation. In fact, rule any other bloated CSS frameworks.
Frameworks like Yahoo’s Pure are lightweight, easy to learn, stable, JS free, modular and supports IE8. Beware, many recent CSS frameworks do not declare their browser support so be cautious as the purpose is for Legacy!
Ok I’m done! … .. … .. …
but one more thing
This is slightly off-topic but a sense of reasoning. Graceful Degradation with this feature-first approach is about future-proofing and enabling the developer with a modern workflow so he or she can enable the users and behind the scenes shape a more consistent and, creation focused web.
This is Mark Cerny, system architect of the PlayStation 4. Sony tried to encapsulate their market share of exclusive games by making it difficult for devs to port PS3 titles to other platforms. (Partially by use of that nasty Cell processor) overall it was a detrimental approach.
As you may know, Sony was in a very bad place before the PS4 boom. It took 15 presentations for Mark to convinced the execs not to commit corporate suicide with the new architecture.
He took a developer centric approach
which consisted of a general purpose x86 processor, 8GB of crazy fast GDDR5 and an entire set of new APIs that was pretty much unicorns and daisies for PS4 developers.
The gaming industry is just a stone throw away from the web development industry, there is clearly no money in crippling or hindering software development as Mark Cerny has proven immaculately.
Feature first is a methodology that constrains vendors to jump on board and become more feature-oriented to enable developers to just make kick-ass websites with fewer compatibility woes.
Here’s a more formal follow-up: FEATURE-FIRST WEBSITES — EXPLAINED.
