The web historically moves in waves.
Libraries are created to push complex features in an easier way. Then the libraries themselves get complicated, often more so than the benefits they provide.
Eventually, (some of) the core features of those libraries make their way into the browser itself, but the libraries linger like water on the shore, slowly receding.
And before the sand has a chance to fully dry, a new set of libraries washes in to push the web even further.
The paradox of performance:
This era of incredibly fast hardware is also the era of programs that take tens of seconds to start from an SSD or NVMe disk; of bloated web applications that take many seconds to show a simple list, even on a broadband connection; of programs that process data at a thousandth of the speed we should expect. Software is laggy and sluggish — and the situation shows little signs of improvement. Why is that?
Because we prioritise the developer experience over the user experience, that’s why:
Although our job is ostensibly to create programs that let users do stuff with their computers, we place a greater emphasis on the development process and dev-oriented concerns than on the final user product.
We would do well to heed Craig’s observations on Fast Software, the Best Software.
Yes! Yes! Yes!
Our efforts to measure and improve UX are packed with tragically ironic attempts to love our users: we try to find ways to improve our app experiences by bloating them with analytics, split testing, behavioral analysis, and Net Promoter Score popovers. We stack plugins on top of third-party libraries on top of frameworks in the name of making websites “better”—whether it’s something misguided, like adding a carousel to appease some executive’s burning desire to get everything “above the fold,” or something truly intended to help people, like a support chat overlay. Often the net result is a slower page load, a frustrating experience, and/or (usually “and”) a ton of extra code and assets transferred to the browser.
Even tools that are supposed to help measure performance in order to make improvements—like, say, Real User Monitoring—require you to add a script to your web pages …thereby increasing the file size and degrading performance! It’s ironic, in that Alanis Morissette sense of not understanding what irony is.
Stacking tools upon tools may solve our problems, but it’s creating a Jenga tower of problems for our users.
This is a great article about evaluating technology.
A nicely documented pattern library.
All the videos from the excellent Responsive Field Day are now available. Even better, the audio is also available for your huffduffing pleasure!
All the presentations and panels were great. Sophie Shepherd’s terrific talk has really stuck with me.
Here’s the 20 minute talk I gave at the inaugural Responsive Field Day in Portland.
Proving something that Derek Powazek told us 15 years ago:
When we clearly show what is and is not acceptable, the tone does change. People who want to share thoughtful comments start to feel that theirs are welcome, and people who want to spew hatred start to realize theirs are not.
D’hear that, Reddit?
Oh, Jesus Christ!
A great short talk from Clare about Code Club.