A plea to let users do web things on websites. In other words, stop over-complicating everything with buckets of JavaScript.
Honestly, this isn’t wishlist isn’t asking for much, and it’s a damning indictment of “modern” frontend development that we’ve come to this:
- Let me copy text so I can paste it.
- If something navigates like a link, let me do link things.
- …
I believe that we haven’t figured out when and how to give a developer access to an abstraction or how to evaluate when an abstraction is worth using. Abstractions are usually designed for a set of specific use-cases. The problems, however, start when a developer wants to do something that the abstraction did not anticipate.
Smart thoughts from Surma on the design of libraries, frameworks, and other abstractions:
Abstractions that take work off of developers are valuable! Of course, they are. The problems only occur when a developer feels chained to the abstractions in a situation where they’d rather do something differently. The important part is to not force patterns onto them.
This really resonated with parts of my recent talk at CSS Day when I was talking about Sass and jQuery:
If you care about DX and the adoption of your abstraction, it is much more beneficial to let developers use as much of their existing skills as possible and introduce new concepts one at a time.
This is a terrific resource! A pattern library of interactive components: tabs, switches, dialogs, carousels …all the usual suspects.
Each component has an example implementation along with advice and a checklist for ensuring its accessible.
It’s so great to have these all gathered together in one place!
A lot of folks assume that progressive enhancement means having to write the same code twice, but often, it can be as simple as extending the pattern you already have once the JS loads.
We may not live in the best of all possible worlds, but we have dodged some bullets:
In the annals of environmental history, humanity’s response to the ozone crisis stands out as a rare success story. During the 1970s and ‘80s, evidence started to mount that certain household chemicals used in refrigerators, air conditioners, and aerosol cans like hairspray were eating a giant hole in Earth’s ozone layer, which prevents harmful ultraviolet radiation from reaching the surface. Facing the terrifying prospect of a future without any atmospheric sunscreen at all, in the late 1980s nations came together to sign the Montreal Protocol, a global treaty to phase out so-called ozone-depleting substances like chlorofluorocarbons.
But if things hadn’t turned out that way—if the scientific evidence linking man-made chemicals to ozone depletion wasn’t strong enough, or if ozone deniers (yes, there were ozone deniers) successfully stymied the Montreal Protocol—the world might look very different.
I’ve been having some really interesting chats with Brian about tabs, markup, progressive enhancement and accessibility. Here’s a braindump of his current thinking which is well worth perusing.
Flat, minimalist, clean, material - whatever you want to call it - is an annoying antipattern. Computers are here to make life easier for humans. Removing affordances is just a nasty thing to do to your users.
Denise shares a cautionary tale of service design gone wrong.
Jesse has his Oppenheimer moment, with much wailing and gnashing of teeth.
What got lost along the way was a view of UX as something deeper and more significant than a step in the software delivery pipeline: an approach that grounds product design in a broad contextual understanding of the problem and goes beyond the line-item requirements of individual components. Also lost along the way were many of the more holistic and exploratory practices that enabled UX to deliver that kind of foundational value.
This is a truly wonderful web page! It’s an explanation from first principles of how cameras and lenses work.
At its most basic, it uses words which you can read in any browser. It also uses images so if your browser supports images, you get that enhancement. And it uses interactive JavaScript widgets so that you get that layer of richness if your browser supports the technology.
Then you realise that every post ever published on this personal site is equally in-depth and uses the same content-first progressive enhancement approach.
Cassie’s enthusiasm for fun and interesting SVG animation shines through in her writing!
James has penned a sweeping arc from the The Mechanical Turk, Sesame Street, and Teletubbies to Instagram, Facebook, and YouTube.
By using static wireframes and static layouts, by separating design and development, we are often limiting our ability to have that creative dialogue with the Web and its materials. We are limiting our potential for playful exploration and for creating surprising and novel solutions. And, most importantly, we are limiting our ability to make conscious, well-informed decisions going forward. By adding more and more layers of abstraction, we are breaking the feedback loop of the creative process.
Van11y (for Vanilla-Accessibility) is a collection of accessible scripts for rich interfaces elements, built using progressive enhancement and customisable.
More on battling entropy:
Ever needed to change “just a small thing” on an old page you build years ago? I recently had the pleasure and the simple task of changing some colors in CSS lead to a whole day of me wrangling with old deprecated Grunt tasks and trying to get the build task running.
The solution:
That’s why starting with HTML, CSS and JavaScript without the need to ever compile anything on your local machine is a good idea. Changing some colors on such a page would indeed only take minutes and not a whole day.
I like this mindset:
Be boring by default and enhance on the way.
This post really highlights one of the biggest issues with the convoluted build tools used for “modern” web development. If you return to a project after any length of time, this is what awaits:
I find entropy staring me back in the face: library updates, breaking API changes, refactored mental models, and possible downright obsolescence. An incredible amount of effort will be required to make a simple change, test it, and get it live.
Take a moment and think about this super power: if you write vanilla HTML, CSS, and JS, all you have to do is put that code in a web browser and it runs. Edit a file, refresh the page, you’ve got a feedback cycle. As soon as you introduce tooling, as soon as you introduce an abstraction not native to the browser, you may have to invent the universe for a feedback cycle.
Maintainability matters—if not for you, then for future you.
The more I author code as it will be run by the browser the easier it will be to maintain that code over time, despite its perceived inferior developer ergonomics (remember, developer experience encompasses both the present and the future, i.e. “how simple are the ergonomics to build this now and maintain it into the future?) I don’t mind typing some extra characters now if it means I don’t have to learn/relearn, setup, configure, integrate, update, maintain, and inevitably troubleshoot a build tool or framework later.
Ah, look at this beautiful timeline that Cassie designed and built—so many beautiful little touches! It covers the fifteen years(!) of Clearleft so far.
But you can also contribute to it …by looking ahead to the next fifteen years:
Let’s imagine it’s 2035…
How do you hope the practice of design will have changed for the better?
Fill out an online postcard with your hopes for the future.
This is great! Ideas for allowing more styling of form controls. I agree with the goals 100% and I like the look of the proposed solutions too.
The team behind this are looking for feedback so be sure to share your thoughts (I’ll probably formulate mine into a blog post).
Some interesting research in here around user expecations with the back button:
Generally, we’ve observed that if a new view is sufficiently different visually, or if a new view conceptually feels like a new page, it will be perceived as one — regardless of whether it technically is a new page or not. This has consequences for how a site should handle common product-finding and -exploration elements like overlays, filtering, and sorting. For example, if users click a link and 70% of the view changes to something new, most will perceive this to be a new page, even if it’s technically still the same page, just with a new view loaded in.
An intro to Stimulus, the lightweight JavaScript library from Basecamp that takes a progressive enhancement approach, as seen with HEY.
One aspect I really like about the approach Stimulus encourages, is I can focus on sending HTML down the wire to my users, which is then jazzed up a little with JavaScript.
I’ve always been a fan of using the first few milliseconds of a user’s attention getting what I have to share with them — in front of them. Then worrying setting up the interaction layer while the user can start processing what they’re seeing.
Furthermore, if the JavaScript were to fail for whatever reason, the user can still see the content and interact with it without JavaScript.