A few quick links and thoughts on big web problems
I’m in the middle of a short vacation but can’t resits the urge to pull these points and links into a post.
Jeremy Keith posted a talk of his from 2013 on the long web (with transcript, audio, and video versions). Fittingly for its subject matter (long web) it remains quite relevant.
I see this kind of stuff all the time, this assumption that JavaScript will be available; this reliance on JavaScript which, like I said, just from a purely engineering perspective doesn’t make sense because of the error-handling in HTML and CSS. If you make a mistake in your HTML, the browser’s going to be very forgiving. If you make a mistake in your CSS, the browser’s going to be very forgiving. They just ignore stuff they don’t understand. If you make a mistake in your JavaScript, the browser is not going to be forgiving; it will throw an error, it will stop the render parsing at that point. So just from Occam’s razor, from an engineering perspective, if you want a robust page, it makes sense not to rely on JavaScript.
Don’t get me wrong: I’m not saying, don’t use JavaScript. I love JavaScript. It’s just how you use it, how you deploy it, as an enhancement, not this or this on Flickr, this JavaScript pseudo-protocol. Or this on Foursquare. It’s not even a link or a button: it’s a span where they’ve got styles to make it look like a link, and they’ve probably got JavaScript to make it act exactly like a link. Just use a link! Or a button. This stuff makes me angry, it really does!
The Long Web by Jeremy Keith (10401 words).
And…
But the most important thing is to just be thinking about this stuff. Next time somebody says to you, “The internet never forgets”, just call bullshit on that. It’s absolute bollocks! Look at the data. The internet forgets all the time. The average lifespan of a web page is months, and yet people are like, “Oh, you’ve got to be careful what you put online, it’ll be there forever: Facebook never forgets, Google never forgets.” No, I would not entrust our collective culture, our society’s memory to some third party servers we don’t even know. Certainly not to the Cloud, whatever that means, the Cloud. What a bullshit term! I mean, it’s just…(applause) it’s just another word for somebody else’s server. Next time somebody talks about the Cloud, just substitute Somebody Else’s Server. It’s on a hard-drive somewhere. What I do is I mentally substitute the word “Moon” when someone says “Cloud” and it makes just as much sense but it’s way more entertaining!
The Long Web by Jeremy Keith (10401 words).
It’s quite long but makes for a good read.
Don’t blame the web for poor development and testing.
— Jeffrey Zeldman (@zeldman) May 28, 2015
The frustrating truth of "modern tooling" is that I can't style a simple html/css document with a hotel wifi. NPM install timeouts.
— Christian Heilmann (@codepo8) May 28, 2015
From John Gall’s Systemantics:
Systems-functions are not the result of human intransigeance. We take it as given that people are generally doing the very best they know how.
When websites fail, it isn’t because people are dumb—not smart enough—or lazy.
As I and others have said before, people aren’t doing progressive enhancement because it is harder than not doing it.
‘Hard’ in this context isn’t a measure of how much intelligence or skill is required to solve the problem. ‘Hard’ here is a description of the volume of effort required, namely that it’s more than you would have otherwise needed to make a passable website.
It’s the system that guides the effort and controls which problems are worth expending that effort on.
We have the websites we have because of the systems that make them. It isn’t just a question of what the managers decide. A single person doesn’t bear the blame for The Verge’s scroll-jacking Apple Watch review (which I find to be unreadable on my iPhone 6+). To create a page like that you need an entire organisation’s values to be aligned exactly that way.
Again from Systemantics:
In cold fact, a system is building ships, and the system is the shipbuilder. In brief: people in systems do not do what the system says they are doing.
The system makes the website. Don’t blame the web developer, blame the organisation. A web developer embedded in a large system isn’t the one making the websites.
To make a progressively enhanced website that performs well and loads quickly even on slow connections, you need to first make an organisation that values those qualities over others.
Which will only work if that organisation is structured to directly benefit from those qualities.
Jeremy Keith, again, pulls at all of the threads, links to all the tings, and writes the blog post I wish I had written.
Y’see, what attracted me to the web—to the point where I have this blind spot—wasn’t the opportunity to make money. What attracted me to the web was its remarkable ability to allow anyone to share anything, not just for the here and now, but for the future too.
Web! What is it good for? by Jeremy Keith (2311 words).
Finally, I’m confident this tweet will be perennially relevant.
The biggest mistakes are made when a known-known is really a known-unknown, but you never realized it.
— Thomas Baekdal (@baekdal) May 27, 2015