■ ■ ■
Late one night in January 2014 the “parental filter” used by Sky Broadband—one of the UK’s largest ISPs (Internet service providers)— began classifying
With the domain so mischaracterized, Sky’s firewall leapt into action and began “protecting” the vast majority of their customers from this “malicious” code. All of a sudden, huge swaths of the Web abruptly stopped working for every Sky Broadband customer who had not specifically opted out of this protection. Any site that relied on CDN’s copy of jQuery to load content, display advertising, or enable interactions was dead in the water—through no fault of their own.
■ ■ ■
In September 2014, Ars Technica revealed that Comcast was injecting self-promotional advertising into websites served via its Wi-Fi hotspots.3 Such injections are effectively a man-in-the middle attack,4 creating a situation that had the potential to break a website. As security expert Dan Kaminsky put it this way:
Comcast isn’t the only organization that does this. Hotels, airports, and other “free” Wi-Fi providers routinely inject advertising and other code into websites that pass through their networks.
■ ■ ■
Get Familiar with Potential Issues so You Can Avoid Them#section2
Understand Your Medium#section3
In traditional software development, you have some say in the execution environment. On the Web, you don’t. I’ll explain. If I’m writing server-side software in Python or Rails or even PHP, one of two things is true:
- I control the server environment, including the operating system, language versions, and packages.
- I don’t control the server environment, but I have knowledge of it and can author my program accordingly so it will execute as anticipated.
In the more traditional installed software world, you can similarly control the environment by placing certain restrictions on what operating systems your code supports and what dependencies you might have (such as available hard drive space or RAM). You provide that information up front, and your potential users can choose your software—or a competing product—based on what will work for them.
On the Web, however, all bets are off. The Web is ubiquitous. The Web is messy. And, as much as I might like to control a user’s experience down to the pixel, I understand that it’s never going to happen because that isn’t the way the Web works. The frustration I sometimes feel with my lack of control is also incredibly liberating and pushes me to come up with more creative approaches. Unfortunately, traditional software developers who are relatively new to the Web have not come to terms with this yet. It’s understandable; it took me a few years as well.
First, a little about GDS’s methodology. It ran the experiment on a high-traffic page that drew from a broad audience, so it was a live sample which was more representative of the true picture, meaning the numbers weren’t skewed by collecting information only from a subsection of its user base. The experiment itself boiled down to three images:
- A baseline image included via an
imgcontained within a
noscript element entirely.
What could cause something like this to happen? Many things:
21 Reader Comments
As a web application developer, this is our only option. Yes, content publishers can produce something quite valuable in HTML since content production and distribution are paramount, but rendering the equivalent of a desktop application on the server is just out of the question. Separating content from presentation concerns is still a great idea everywhere though.
You made this case really well but it’s almost a shame it needs to be made at all anymore.
“Unfortunately, traditional software developers who are relatively new to the Web have not come to terms with this [lack of control] yet.”
When I first started out in the industry, there was some derision amongst Developers for the ‘Print Designer turned Web Designer’—largely because they designed for an environment they simply didn’t have. It looks a parallel can be made for certain ‘traditional’ Developers turned Web Developers, both in terms of status and mental models.
The best thing about the GDS experiment was not the results and conclusions, but that they actually showed the code they used.
The generated markup for the script-enabled test is also still on the http://www.gov.uk home-page. It is an **inline-script** with the following code.
For some reason 0.9% of browser visits didn’t successfully run this code (or utilize the noscript markup).
Because it is a simple **inline script with no dependencies** I think it is fair to conclude that:
– it probably doesn’t have any errors
– it won’t fail due to a library dependency
– it won’t fail due to a CDN outage
– it won’t fail due to a delayed or incomplete script download
– it won’t be broken by third party code
(There is a slim possibility that in the fraction of a second between the base img request and the script img request the user abandons the page or the network.)
I don’t think it safe to draw a strong conclusion from this experiment, but the explanation I find most likely is plugins or proxies that block all JS (including inline).
Another (slightly different) warning about depending on JS is the AngluarJS docs.
The latest stable version of Angular supports IE9:
But if you visit the docs in IE9 it won’t work (hasn’t worked for at least a year).
Well, the main factor is that no-one visits the docs site in IE9.
But the specific cause of the failure is that the *site-specific scripts* throw before configuring Angular.
And the actual error in the site-specific scripts is that they call `console.log()`, which only exists in IE9 **after** you open the console. No wonder the docs maintainers never found the error.
So the warning is, just because the framework you use supports all browsers you are interested in, this doesn’t guarantee your site is working in all those browsers (even if JS is enabled and loading).
It’s about knowing your context.
When writing a complex application, you can demand more from your users than if you’re writing a news site or blog. On a “read only” site, like most company websites and news sites, you should not need to rely on JS to read text. However, in a more interactive environment where you might trigger business processes, pass data around and talk to a database – things are a bit different, since you can, to a degree, control the execution environment (“Always use Chrome latest when at work”).
…and of course, then there are the blurry, grey areas that are hard to define.
Indeed. And that would be because web developers insist on building things (even reading **plain-text magazine articles**) to be a bad experience that way.
In many cases, I should put “building” in air-quotes.
Thank you, Aaron, for this enlightening piece.
A trivial misclosed html tag can make your site inoperable too. This is an indictment of bad development practices, not a technology. Most companies cannot afford to greatly increase their development efforts for 0.9 percent of potential users.
@JamieT “Worry about experience and quality.. not fundamental tech.”
Progressive enhancement leads to quality and good experience.
@JamieT, sure it takes more time. The result is a website better prepared for the world wide web though. I’d like to compare it to a wooden versus a stone house. A wooden house is cheaper, faster and easier to build than the same house made of stone. The stone version is more durable; it will not be blown away by a tornado, nor will it crumble as easily during an earthquake. The wooden version will rot away without maintenance, the stone version will be covered by plants and what not, but will still function as a house.
I wouldn’t want to live in a house that collapsed if a fundamental technology—say electricity—failed.
Don’t think of progressive enhancement as building the thing to be dependent on JS and then doing extra work to put in no-JS fallbacks for everything. Instead, try building for the no-JS case, and then putting in JS enhancements for users that do have scripting enabled.
What I can say is frontend development has always been tricky. It’s not because the client code runs on an unknown machine (that’s what VMs are created for), but rather ambiguous specs, incorrect implementation of those specs and flaky connections. Although we all know about this, but we sometimes have really high expectations from the web. Today people create native mobile apps just for a particular OS, a particular Api version, etc. They already know they are just aiming for say 60% of the market, but that is as much budget as they have. Of course they’ll expand when they grow. The same should be true for web too. You don’t have that much budget, drop support for ancient browsers. If under the same budget constraints you can achieve the same user experience for a greater audience with techniques such as PE or using better tools, then great, go for it, but if you can’t don’t get obsessed that there are 1% users I won’t be able to support. (Remember when this 1% is quite some number, more likely than not you will have quite some money to support them!)
I’ve recently seen another trend (by React fans) that CSS is the problem of the web by saying “the worst thing about CSS is cascading and stylesheets”. It seems that the next in line to blame is Html itself. I believe these approaches are not really constructive and web ecosystem is overall a great place. We just have learn from past mistakes and try solve them in the future.
Ultimately, it comes down to, do we even care about 1% of people? And unless you’re Google, the answer is often, “No”.
Max:”Don’t think of progressive enhancement as building the thing to be dependent on JS and then doing extra work to put in no-JS fallbacks for everything. Instead, try building for the no-JS case, and then putting in JS enhancements for users that do have scripting enabled.”
Or, build your house from the foundation up instead of from the roof down.
I can’t help but draw parallels with the fashion show
I’m right up there with @ Arve on this one and is one of the flaws I see in this article.
I think the context plays a key role in determining if interaction is simply an enhancement versus a necessity.
When you create a news or blog site you tend to be more focused on content which requires less input from the user.
If on the other hand you are building an app, interaction tends to be essential to building the unique interfaces you need to receive the input from the user and accomplish a given task.
I don’t think they were wrong with pushing for a more modern app feel out of a blog so long as you warrant the need as this article has kind of pointed out.
I don’t personally agree with their choice but hey I also don’t manage mega online content properties like they do. I give them props for experimenting and maybe it worked out better in the end for them.
I think with a content-rich blog it seems like its a high cost to pay a team of developers to shift to a dedicated JS framework. In a blogging context there is less of a need for JS so I agree the enhancement side of things makes sense in this context, but even that is transforming (as you’ll read below).
If you don’t build a highly interactive app experience will you disappear into oblivion? Not at all but you also won’t have as great of a user experience as your competitor who has put a lot of thought into the interactive elements and how the customer gets their data in and out of the app.
If you don’t value the user flows and essential forms of your users interactions going through your system you won’t be going anywhere real fast.
@cmart: Why wouldn’t you plan for a no-CSS scenario? That’s what a voice-based interface is and that’s likely the future of computing.
“A trivial misclosed html tag can make your site inoperable too. This is an indictment of bad development practices, not a technology. ”
“Most companies cannot afford to greatly increase their development efforts for 0.9 percent of potential users.”
Regarding costs, it is a lot cheaper to develop HTML content that is guaranteed consumable by all internet devices and then enhance for superior user experience on advanced devices than it is to start with the latest funkiness on the edge device and then find and fix the bugs and lack of support for other devices.
Good information in artikel, so heplful.. for more information..Harga Sepatu Converse Terbaru
Got something to say?
We have turned off comments, but you can see what folks had to say before we did so.
More from ALA
Personalization Pyramid: A Framework for Designing with User Data
Mobile-First CSS: Is It Time for a Rethink?
Designers, (Re)define Success First
Breaking Out of the Box
How to Sell UX Research with Two Simple Questions