A timeline showing the history of non-digital dataviz.
Tess calls for more precise language—like “site” and “origin”—when talking about browsers and resources:
When talking about web features with security or privacy impact, folks often talk about “first parties” and “third parties”. Everyone sort of knows what we mean when we use these terms, but it turns out that we often mean different things, and what we each think these terms mean usually doesn’t map cleanly onto the technical mechanisms browsers actually use to distinguish different actors for security or privacy purposes.
They came for the writers of car brochures, but I wasn’t a writer of car brochures, so I said nothing.
This was an absolute delight to read! Usually when you read security-related write-ups, the fun comes from the cleverness of the techniques …but this involved nothing cleverer than dev tools. In this instance, the fun is in the telling of the tale.
The problem is that most websites will adapt to the ever faster connections, which makes them gradually inaccessible for people with slower connections. Today, most websites are impossible to download with a dial-up connection, because they have become too corpulent.
This speaks to me:
Everything we do to make it harder to create a website or edit a web page, and harder to learn to code by viewing source, promotes that consumerist vision of the web.
Pretending that one needs a team of professionals to put simple articles online will become a self-fulfilling prophecy. Overcomplicating the web means lifting up the ladder that used to make it possible for people to teach themselves and surprise everyone with unexpected new ideas.
There’s a list of links at the end of this piece to help you reach this goal:
It is vital that the web stay participatory. That means not just making sites small enough so the whole world can visit them, but small enough so that people can learn to build their own, by example. Bloat makes the web inaccessible.
What a brilliant homage! And what a spot-on pop-cultural reference for The Situation.
2020: an isolation odyssey is a reenactment of the iconic finale of 2001: A Space Odyssey (Stanley Kubrick, 1968). Restaged in the context of home quarantine, the journey through time adapts to the mundane dramas of self-isolation–poking fun at the navel-gazing saga of life alone and indoors.
A really lovely unmonetisable enthusiasm:
All 2,242 illustrations from James Sowerby’s compendium of knowledge about mineralogy in Great Britain and beyond, drawn 1802–1817 and arranged by color.
Recreating Wildlife Photographer of the Year online – part 1 – Introduction and technical approach – Blogs from the Natural History Museum
Now here’s the story from the team that made the website. It’s a great walkthrough of thoughtfully evaluating technologies to figure out the best approach.
This is a nifty visual interactive explainer for the language of CSS—could be very handy for Codebar students.
A good explanation of the hydration problem in tools like Gatsby.
Smart thoughts from Ethan on how design systems can cement your existing ways of working, but can’t magically change how collaboration works at your organisation.
Modern digital teams rarely discuss decisions in terms of the collaborative costs they incur. It’s tempting—and natural!—to see design- or engineering-related decisions in isolation: that selecting Vue as a front-end framework only impacts the engineering team, or that migrating to Figma only impacts designers. But each of these changes the way that team works, which impacts how other teams will work and collaborate with them.
I’m very selective about how I depend on other people’s work in my personal projects. Here are the factors I consider when evaluating dependencies.
- Complexity How complex is it, who absorbs the cost of that complexity, and is that acceptable?
- Comprehensibility Do I understand how it works, and if not, does that matter?
- Reliability How consistently and for how long can I expect it to work?
I really like Rob’s approach to choosing a particular kind of dependency when working on the web:
When I’m making things, that’s how I prefer to depend on others and have them depend on me: by sharing strong, simple ideas as a collective, and recombining them in novel ways with rigorous specificity as individuals.
Nice and straightforward. Locally:
git branch -m master main
git push -u origin main
Then on the server:
git branch -m master main
git branch -u origin/main
On github.com, go into the repo’s settings and update the default branch.
Thanks for this, Scott!
P.S. Don’t read the comments.
I must admit I’ve been wincing a little every time I see a graph with a logarithmic scale in a news article about COVID-19. It takes quite a bit of cognitive work to translate to a linear scale and get the real story.
I’ll be speaking at this online version of An Event Apart on July 20th, giving a brand new talk called Design Principles For The Web—’twould be lovely to see you then!
Designing and developing on the web can feel like a never-ending crusade against the unknown. Design principles are one way of unifying your team to better fight this battle. But as well as the design principles specific to your product or service, there are core principles underpinning the very fabric of the World Wide Web itself. Together, we’ll dive into applying these design principles to build websites that are resilient, performant, accessible, and beautiful.
Ultimately, however, our decision to switch was driven by our difficulty in hiring new talent for $UNREMARKABLE_LANGUAGE, despite it being taught in dozens of universities across the United States. Our blog posts on $PRACTICAL_OPEN_SOURCE_FRAMEWORK seemed to get fewer upvotes when posted on Reddit as well, cementing our conviction that our technology stack was now legacy code.
This is all just mwah—chef’s kiss!—perfect:
Every metric that matters to us has increased substantially from the rewrite, and we even identified some that were no longer relevant to us, such as number of bugs, user frustration, and maintenance cost.
I think Simon is onto something here. While the word “performance” means something amongst devs, it’s too vague to be useful when communicating with other disciplines. I like the idea of using the more descriptive “page speed” or “site speed” in those situations.
Web Performance and Web Performance Optimization are still valid and descriptive terms for our industry, but we might benefit from a change to our language when working with others. The language we use could be critical to the success of making the web a faster and more accessible place.
- Which jig will be next?
- What instrument?
- What shirt will he wear next?
- Will a shirt make a repeat appearance?
- Will he shave his wiseman beard?
- Possibly a haircut or trim?