It’s fantastic that our web plumbing has gotten more powerful—tooling today is capable of so much. But all too often, that power comes with increased complexity that negatively impacts developer efficiency. Sometimes that’s unavoidable. The simplest approach doesn’t always win. But that should be the goal—to make things as simple as possible while still accomplishing what needs to be done. Like excellent plumbing, these systems should be as mostly invisible—chugging along, doing what we need them to do without getting in our way.
1,841 instances of dark patterns on ecommerce sites, in the categories of sneaking, urgency, misdirection, social proof, scarcity, obstruction, and forced action. You can browse this overview, read the paper, or look at the raw data.
We conducted a large-scale study, analyzing ~53K product pages from ~11K shopping websites to characterize and quantify the prevalence of dark patterns.
Each typeface highlights a piece of history from a specific underrepresented race, ethnicity, or gender—from the Women’s Suffrage Movement in Argentina to the Civil Rights Movement in America.
This is how it goes. We put a load of shit into a single web page. This makes the page slow. Slow to load, slow to render. Slow.
Instead of getting rid of the shit, we blame the page refresh.
I would urge front-end developers to take a step back, breathe, and reassess. Let’s stop over engineering for the sake of it. Let’s think what we can do with the basic tools, progressive enhancement and a simpler approach to building websites. There are absolutely valid usecases for SPAs, React, et al. and I’ll continue to use these tools reguarly and when it’s necessary, I’m just not sure that’s 100% of the time.
This is a bit ranty but it resonates with what I’ve been noticing lately:
I’ve discovered how many others have felt similarly, overwhelmed by the choices we have as modern developers, always feeling like there’s something we should be doing better.
I think we’re often guilty of assuming that because our tools are great solutions for some things, they’re automatically the solution for everything.
Let’s take a meandering waltz through what other people have to say about simplicity.
Onboarding. Reaching out. In terms of. Synergy. Bandwidth. Headcount. Forward planning. Multichannel. Going forward. We are constantly bombarded and polluted with nonsense speak. These words and phrases snag and attach themselves to our vocabulary like sticky weeds.
Words become walls.
I love this post from Ben on the value of plain language!
We’re not dumbing things down by using simple terms. We’re being smarter.
Read on for the story of the one exception that Ben makes—it’s a good one.
Tales of over-engineering, as experienced by Bridget. This resonates with me, and I think she’s right when she says that these things go in cycles. The pendulum always ends up swinging the other way eventually.
A really terrific piece from Garrett on the nature of the web:
Markup written almost 30 years ago runs exactly the same today as it did then without a single modification. At the same time, the platform has expanded to accommodate countless enhancements. And you don’t need a degree in computer science to understand or use the vast majority of it. Moreover, a well-constructed web page today would still be accessible on any browser ever made. Much of the newer functionality wouldn’t be supported, but the content would be accessible.
I share his concerns about the maintainability overhead introduced by new tools and frameworks:
I’d argue that for every hour these new technologies have saved me, they’ve cost me another in troubleshooting or upgrading the tool due to a web of invisible dependencies.
We assume that complex problems always require complex solutions. We try to solve complexity by inventing tools and technologies to address a problem; but in the process we create another layer of complexity that, in turn, causes its own set of issues.
The Principle of Least Power looms large over this:
Some of the most important things in the world are intentionally designed “stupid”. In any system, the potential for error directly increases with its complexity - that’s why most elections still work by putting pieces of paper in a box.
The cosmonaut counterparts of the Mercury women astronauts: Zhanna Yorkina, Irina Solovyova, Tatyana Kuznetsova, Valentina Ponomareva, and Valentina Tereshkova.
Ponomareva recalled there being no envy between the women in the squad. According to her, it was a healthy spirit of competition. Everyone did their best to be number one, but also supported each other’s efforts.
One of those cosmonauts went to space: none of the women training for the Mercury missions did. There would be a shockingly gap of twenty years between the launch of Valentina Tereshkova and the launch of Sally Ride.
This is an excellent case study!
The technical details are there if you want them, but far more important is consideration that went into every interaction. Every technical decision has a well thought out justification.
One facet of this whole CSS debate involves one side saying, “Just learn CSS” and the other side responding, “That’s what I’ve been trying to do!”
I think it’s high time we the teachers of CSS start discussing how exactly we can teach a correct mental model. How do we, in specific and practical ways, help developers get past this point of frustration. Because we have not figured out how to properly teach a mental model of CSS.
I just binge-listened to the six episodes of the first season of this podcast from Stephen Fry—it’s excellent!
It covers the history of communication from the emergence of language to the modern day. At first I was worried that it was going to rehash some of the more questionable ideas in the risible Sapiens, but it turned out to be far more like James Gleick’s The Information or Tom Standage’s The Victorian Internet (two of my favourite books on the history of technology).
There’s no annoying sponsorship interruptions and the whole series feels more like an audiobook than a podcast—an audiobook researched, written and read by Stephen Fry!
Rush hour. The worst time of day to travel. For many it’s not possible to travel at any other time of day because they need to get to work by 9am.
This is exactly what a lot of web code looks like today: everything runs on a single thread, the main thread, and the traffic is bad. In fact, it’s even more extreme than that: there’s one lane all from the city center to the outskirts, and quite literally everyone is on the road, even if they don’t need to be at the office by 9am.
I tried very hard in that book, when it came to social media, to be platform agnostic, to emphasize that social media sites come and go, and to always invest first and foremost in your own media (website, blog, etc.) and mailing list.
I still stand by that advice, but if I re-wrote the book now, I would encourage artists to use much more caution when it comes to using social media websites like Facebook, Twitter, and Instagram.
This is really good breakdown of what’s different about CSS (compared to other languages).
These differences may feel foreign, but it’s these differences that make CSS so powerful. And it’s my suspicion that developers who embrace these things, and have fully internalized them, tend to be far more proficient in CSS.