The first time I retrofitted a URL scheme onto an existing web app, it wasn’t easy and the engineers on my team were reluctant. The work itself looked like engineering cleanup, but the problem was design debt: the product had no shared model for what its pages, states, and resources were called.

Routes accumulate around backend data models and frontend file conventions rather than the resource hierarchy a user or linking system would recognize. Ownership fragments across teams; each team names things for its own context. By the time someone wants to clean it up, the redirects are locked in by downstream dependencies and analytics instrumentation is tangled around the old slugs. The retrofix was necessary groundwork for new features that needed stable, meaningful URLs to work at all. The real lesson was that we should have had this conversation at the start, not mid-build.

JSTools.Space explains why that cleanup is so expensive:

A URL is part navigation, part application state, and part public interface. Once users bookmark it, search engines index it, monitoring systems record it, and other applications link to it, changing that URL becomes an architectural decision rather than a cosmetic edit.

Good URL design is therefore less about making every address look pretty and more about making it predictable, stable, and unambiguous.

The decision framework should be a team contract from day one: path for identity, query for optional state, fragment for in-page location or client-only state. Inconsistent routes are what make a migration touch everything. Designers should care because this is information architecture in production, not just routing syntax.

Christian Cleberg, an independent developer, traces the internet across his lifetime, from the family Gateway PC in 2001 to the 17-step obstacle course it takes to read a headline in 2026. The essay is nostalgic the way a good memoir is: it names real years and real machines.

Once upon a time, the internet didn’t even exist. When it did, the internet was a place. It was a place you went. You selectively chose to visit the internet, based on your own free will. If you wanted to visit a chat room, or perhaps preview a fancy new Flash game, you visited the internet for a few minutes in the evening before going back to your family or friends. This has changed dramatically in the last 20-30 years. Today, it’s 2026 and woven into nearly every part of daily life for the majority of the Earth’s population.

The transformation Cleberg describes is behavioral, not technical. The internet stopped being something you opted into and became the condition of modern life. The independent web is now infrastructure you rent through friction and attention extraction, not just because of how we use the internet, but because of who decided what it became.

However, there was a dark side to this revolution. As these apps progressed, and the underlying technologies progressed, the companies and investors driving these efforts took a turn. Efforts pushed into the world of micro-transactions, psychological rewards for utilizing a platform, profits over value, and a slow descent into a disregard for the users.

To me, that 2012 era was a turning point. You may personally love a different era (1980/1990s gamer, anyone? Any former phreaks out there?), but to me, it felt like we kept making leaps in technological capability until we reached the point of economic profitability in the 2000s-2010s era, where corporations, investors, and governments took a serious interest in controlling the internet.

Cleberg’s closing distinction: the internet didn’t disappear, the experience of it did. The infrastructure is still there; the sense of it as a place worth exploring is not.

That loss already had a response. Jeffrey Zeldman—web-standards pioneer, founder of A List Apart, and longtime open-web advocate—wrote on his own blog after attending a preview of filmmaker Bao Nguyen’s documentary Code for the People, a film about the builders of the open web:

The answer to this destruction of our shared digital commons by a handful of billionaires is the same as it has always been: own your content on the open web (your domain on a server, like mine on this one), and replace proprietary software with open source alternatives.

Cleberg is writing about the disappearance of a feeling. Zeldman’s post is smaller and more practical: own your domain, publish on the open web, choose tools you can keep. That does not solve the larger fight for the open web, but it does make the response personal. A domain is not nostalgia. It is a small claim of custody over your own work.

The web is forking. Sara Guaglione reports that publishers are starting to build one version of their sites for humans and another for agents. The phrase that matters is Time chief operating officer Mark Howard’s “separating out that traffic.”

“[The bots are] just getting the content itself and the metadata, but they’re not getting the full page experience, and we’re routing all the humans to the full page experience. So we’re separating out that traffic,” Howard said.

“Now we’re starting to think about, as the volume of bot traffic continues to increase significantly – and we see through a number of our vendor partners that we have very high domain authority with AI bot traffic – there’s value in that,” he added.

Howard is making the operational case. Toshit Panigrahi, co-founder and CEO of TollBit, makes the economics explicit:

“Part of onboarding to TollBit is we create your agent site for you,” said Toshit Panigrahi, co-founder and CEO of TollBit. “It really comes down to the token economy. Websites have a lot of HTML tags and JavaScript and CSS and things that don’t have to do with the content. That creates a big bloat in the actual size of the page.”

Markdown can make websites “friendlier” to agents, he added. “AI can comprehend more of your article because they’re not spending money parsing out other HTML that’s on the page. We see, on average, a 90% reduction in tokens, because we have converted the content to markdown.”

That efficiency argument is real. But independent publisher consultant Scott Messer, principal of Messer Media, pushes back:

Yet, even as more publishers quietly spin up agent-friendly feeds, stripped down pages and custom schemes, not everyone is convinced they should be racing to re-architect the web for bots. Independent publisher consultant Scott Messer, principal of Messer Media, argues that building for agents should be a highly qualified decision, not the default. His reasoning: traffic isn’t the reward in an agentic environment – if there is no click, no ad impression and no check, the build is pure cost.

“If you believe there’s a value to being discovered by these bots and agents, then you should build them. If you don’t believe [that], I would ask, why would you build them?,” he said.

That is the question under all of this. The rendering layer—the HTML, CSS, and JavaScript that turn server content into pages—is exactly the surface designers build, and publishers and content creators are now deciding which parts of that surface matter when the visitor is no longer a person.

I’d argue that RSS can be easily consumed by agents too.

I wrote about who killed Google Reader because Reader’s shutdown felt like losing a whole way of using the web: the curation layer, the accidental social network, the daily habit. Matthew Guay, editor at Buttondown, is interested in the part that survived. His answer is blunt: nothing important died.

The feeds walked out intact: three million people moved to Feedly in two weeks, and the content never left the blogs. Guay’s point is that we were mourning the right thing—the curation layer, the accidental social network—at the wrong level of the stack: the aggregation service, not the open protocol underneath it.

Not an iota of data was lost, as the content that filled the feeds lived on individual blogs and websites. Google+ users wouldn’t be so lucky, six years later, when that network too was shuttered, taking with it their non-portable social graphs and ephemeral posts.

That contrast is the spine of the piece. Google+ and Google Reader died the same administrative death, both casualties of the same corporate pivot, but they died completely different technical deaths. Reader’s users lost a habit. Google+ users lost everything. The portability of the underlying protocol made the difference, and it’s why early RSS developer Dave Winer could be so clear-eyed about Reader’s shutdown at the time:

“I won’t miss it,” said early RSS developer Dave Winer more cantankerously—or, perhaps, more clear-eyedly—of Google Reader. “Never used the damn thing. Didn’t trust the idea of a big company like Google’s interests being so aligned with mine that I could trust them to get all my news.”

But that’s the thing about RSS. Winer didn’t need to love Reader for people to follow his writing there. And when it went away, those same readers could still follow him directly, could still read the words on his site that yesterday they’d read under Google’s auspices.

Designer and author Marcin Wichary picked up the same portability-survival thread in his blog Unsung, marking the 13th anniversary, and he quoted my February post in the process. His read: “I am worried about the open web, but excited seeing some resurgence in RSS usage, and more and more people wanting to come back to the feeling of control, care, and intentionality that using Reader represented.”

That resurgence Wichary is watching is what Guay’s closing points toward, too:

It was the open protocols, the RSS feeds and email, that alone offered a direct connection to your favorite writers and publications, unmediated by algorithms. Sure, they didn’t come with built in sharing features, they were harder to discover, they required more work to turn into a community. But once you did find them, they were sticky, a connection no one other than the publishers themselves could take away.

This blog is my version of that direct channel: a website, built one reader at a time, outside the platforms that decide what gets seen. I still miss Reader’s curation layer. The win is that the open-protocol layer underneath it—RSS, personal blogs, the direct connection—survived anyway.

Nolen Royalty, a software maker who writes at eieio.games, gets at a problem with AI-generated work that shows up before judgment: the effort signal. His examples include tldraw, the collaborative drawing tool, closing AI-generated pull requests, warm-cream Claude websites, and record collecting, but the point is simple. Polish used to be a proxy for care. Now it isn’t.

What software (and writing, to an extent) is missing now is legibility of effort - the ability to tell at a glance whether something took a human meaningful work.

Until recently, “someone cared enough to write this” was an ok heuristic. Plenty of writing on the internet was bad, but you could convince me that you cared about something just by writing it down.

Of course, generating plausible-looking text - or a plausible-looking website - is trivial now.

For designers, that broken proxy is already visible on the surface. We can all spot the default Claude style now, which is funny until you realize that a visual pattern has become an accusation about how much thought went into the site.

There’s nothing objectively wrong with making a website with a warm-cream background and hero text in a sans-serif font with a single accent word that uses an eye-catching color and a different font.

But when I see a website that has the default Claude style I assume that the author put ~no thought into how the site should look. And I often assume that the author didn’t put too much thought into the rest of the site either.

That’s not fair of me! But “someone made this website” is no longer enough to tell me that the website was important to them. So “default Claude style” is one of my new heuristics.

Taste sounds less mystical when you put it this way. A designer doesn’t make a screen human by avoiding beige or picking a stranger typeface. The work is in the decisions: why this hierarchy, why this contrast, why this interaction, why this amount of friction.

The proliferation of digital music and streaming made having a music collection easy and frictionless. And so a subculture evolved to re-add that friction.

And in small ways I think you see the same things happening now.

I’ve seen people joke about adding typos to emails to prove that they wrote them. MS Paint-style image macros read as more human than detailed, funny images (the image could be AI slop). Websites that look intentionally bad are more interesting than websites that look beautifully bland.

Alex Harper, writing for Web Designer Depot, describes the new baseline for web design work:

For decades, a significant portion of a web designer’s value was tied to the act of building: moving pixels in Figma, translating those pixels into CSS, ensuring the flexbox behaved, and troubleshooting why a specific button looked “off” in Safari.

But with the arrival of high-fidelity “Agentic UI” and the rise of what industry insiders are calling “Vibe Coding,” the barrier between a thought and a fully functional interface has effectively vanished.

Today, a founder can speak into a prompt—”Give me a high-end, minimalist FinTech landing page with a Swiss-style grid and a sense of ‘quiet luxury’ using deep emerald tones”—and receive a production-ready, accessible, and responsive site in seconds.

This is the AI design conversation with dollars attached. Once a small business owner can get a polished page for almost nothing, “pretty page” stops carrying much economic value.

Harper describes the commodity pressure as a loop:

The primary problem with Vibe Coding is that AI, by its very nature, is a statistical engine. It generates the most “probable” result based on your prompt. If you ask for a “Modern Minimalist” site, the AI isn’t going to innovate; it’s going to give you a composite of every modern minimalist site it has ever seen.

This creates a Feedback Loop of Averageness. 

1. Designers use AI to generate “vibey” layouts. 2. These layouts are published and become part of the web. 3. Future AI models are trained on these new layouts. 4. The aesthetic “mean” becomes tighter and tighter.

Designers have to take that feedback loop seriously. While the taste in the models are slowly getting better, AI nudges taste toward whatever the training set keeps rewarding. Notice a lot more serif fonts online recently?

That’s why “clean and professional” worries me less as a style than as a business model: if everyone gets the same acceptable answer for almost no money, the designer’s value moves into judgment, story, and constraints.

Harper adds:

To survive the Vibe Coding crisis, designers have to move away from the “Vibe” and toward the “Mechanism.”

If the “look” of a website is now a commodity, where does a designer provide value? The answer lies in the areas that AI still struggles to grasp: Nuance, Narrative, and Friction.

AI can create a page that looks like a brand, but it cannot yet build a page that feels like a story. Vibe Coding creates “scrollytelling” templates, but it doesn’t understand the emotional arc of a user journey. A human designer understands that a specific user might need to feel “uncomfortable” or “challenged” at a certain point in the flow to make a realization. AI only knows how to please.

An AI can generate a screen, but can it generate a philosophy? Designing a design system in 2026 isn’t about making components; it’s about defining the “Ethics of Interaction.” How does this brand handle data privacy through UI? How does it signal inclusivity without being performative? These are high-level strategic decisions that a “vibe” prompt cannot solve.

Joost de Valk, creator of the Yoast SEO plugin for WordPress, has turned the “what should a good website do?” question into The Website Specification: a platform-agnostic checklist that puts HTML basics, SEO, accessibility, security, performance, privacy, internationalization, and agent readiness in one place.

The useful shift is that the AI-facing work is treated as normal website hygiene. Not a separate “AI strategy” project. Not a prompt-engineering side quest. Just another part of making the site understandable to the systems that now read, rank, quote, and retrieve it.

A platform-agnostic specification of the technical features every decent website should have — from <title> to /.well-known/security.txt, from WCAG contrast to llms.txt. Written for humans and agents.

Ten areas, mapped to widely-accepted standards.

Each topic links back to the source standard — WHATWG, W3C, IETF RFCs, WCAG, MDN, and the organisations defining the modern web.

Whether you ship WordPress, Drupal, TYPO3, Next.js, Astro, Hugo, a Django app, or plain HTML, the spec is the spec. Implementation hints follow it, not the other way round.

I like that standards-first posture. A lot of AI advice still treats the web like a pile of pages to be scraped, summarized, and maybe attributed later. De Valk pulls it back toward contracts: stable URLs, explicit policies, structured data, clean source material, and machine-readable ways to discover what matters.

From the Agent Readiness section:

Agent readiness is a loose umbrella term for the choices that make a website legible to AI agents — chat assistants, autonomous browsers, retrieval pipelines, and any other non-human client that reads the web at scale. None of it is a single formal standard. It is a collection of existing web fundamentals plus a few emerging conventions.

Agents read the same HTML as browsers, but they read it differently. They:

• Fetch a page, often without executing JavaScript.
• Strip away navigation, ads, and chrome to extract the main content.
• Follow links, structured data, and well-known endpoints to discover more.
• Cache and quote your content in answers, with or without a link back.

If your content is locked behind client-side rendering, your URLs change every release, or your robots.txt blocks the assistants your customers use, you are invisible in that surface. The pages that win in agent answers are the ones that are easy to fetch, easy to parse, and easy to trust.

That’s the part designers should pay attention to. We tend to think of the interface as the thing on the screen. But if agents are part of the audience now, the interface also includes off-screen surfaces: metadata that explains the page, feeds and sitemaps that expose what exists, crawler policies that say what can be read, and curated indexes like llms.txt that tell software what matters.

De Valk again:

There is no single switch. The items in this category each cover one part:

• Stable URLs so cached answers stay valid.
• Structured data (JSON-LD) so agents can extract entities without guessing.
• Clean semantic HTML so content extraction does not pull in navigation.
• A robots.txt that names AI crawlers explicitly so your policy is unambiguous.
• /llms.txt as a curated index of your most important content (emerging).
• Machine-readable endpoints — sitemaps, RSS, JSON feeds — where they fit.
• MCP server endpoints for sites that expose tools or actions (emerging).

Most of these also benefit traditional search engines and accessibility. Agent readiness rarely conflicts with the rest of the spec; it just raises the priority of things that have always been good practice.

De Valk’s point is simpler: agent readiness mostly means doing the old web discipline well enough that agents can actually read and trust the site.

Nearly a thousand design studios across more than 50 countries, hand-picked by one person. Wences Sanz-Alonso runs Just a Design List, a directory that strips each entry down to a name, a city, a discipline, and a link. No hero image, no blurb, no star rating. The about page explains what it is:

Just a Design List is a personal reading list that grew too long to keep privately. It began in 2023 as a list of bookmarks, and is now a small, slow public archive — a place to point at studios whose work rewards close attention, without the obligation of a review.

It’s an excellent curated list full of inspo possibilities to close out the week.

Shubham Bose loaded a single New York Times article page and measured what happened:

With this page load, you would be leaping ahead of the size of Windows 95 (28 floppy disks). The OS that ran the world fits perfectly inside a single modern page load. […] I essentially downloaded an entire album’s worth of data just to read a few paragraphs of text.

The total: 422 network requests, 49MB of data. Ouch! Before the headline finishes loading, the browser is running a programmatic ad auction in the background on his computer. Bose found the Times named its consent endpoint purr. “A cat purring while it rifles through your pockets.”

Bose on the economics driving this:

Publishers aren’t evil but they are desperate. Caught in this programmatic ad-tech death spiral, they are trading long-term reader retention for short-term CPM pennies. […] The longer you’re trapped on the page, the higher the CPM the publisher can charge. Your frustration is the product.

The UX consequences are predictable. Bose tears down what a reader actually encounters: cookie banners eating the bottom 30% of the screen, a newsletter modal on first scroll, a browser notification prompt firing simultaneously. He calls it “Z-Index Warfare.” On The Guardian, actual content occupies 11% of the viewport. On the Economic Times, users face two simultaneous Google sign-in modals before reading a single sentence. Close buttons are deliberately undersized with tiny hit targets. Sticky video players detach and follow you down the page with a microscopic X.

And on how no one person decided to make it this way:

No individual engineer at the Times decided to make reading miserable. This architecture emerged from a thousand small incentive decisions, each locally rational yet collectively catastrophic.

text.npr.org is proof that a different path exists.

There’s a distinction between designers learning front-end engineering and designers directing AI agents that produce code against a design system. They sound similar. They share a prerequisite: understanding the material you’re working with.

Adam Silver builds his argument on Frank Chimero’s essential essay “The Web’s Grain”:

The web is a material. Like wood, it has a grain. You can work with it or fight against it.

Silver borrows Chimero’s term for what happens when you fight the grain:

It is very impressive that you can teach a bear to ride a bicycle, and it is fascinating and novel. But perhaps it’s cruel? Because that’s not what bears are supposed to do. And that bear will never actually be good at riding a bicycle.

He makes this concrete with native form controls:

Most designers I worked with hated how the native <select> dropdown looked. So they designed a custom one to make it look good and match the brand. But that meant having to abandon the native element and build a custom dropdown from scratch. Even if you ignore the extra work, you lose: Keyboard navigation, Screen reader support, Automatic form submission, The native iOS scroll wheel, Functionality without JavaScript. Some of this is hard to recreate, some of it is impossible.

This is one of those fights that never ends well.

I agree with the diagnosis. Material literacy matters. Where I part ways is the prescription. Silver’s answer is to design in code using the GOV.UK Prototype Kit. That made sense when writing code was the only way to feel the grain push back. But directing an AI agent to build against a design system gives you the same feedback. You see what the browser does with your layout. You discover where the grain resists. You just didn’t write the CSS yourself. And that’s where we’re headed.

The more interesting question is one Silver points toward without arriving at: AI is a new material with its own grain. It’s probabilistic. It favors volume over precision. Designers who fight that grain — demanding pixel-perfect fidelity from a generative tool — are making the same mistake in a different medium.

Weber Wong’s “artifact thinking” names the problem: creative work that produces one-off outputs, each beginning from scratch. Prompts are artifacts. Skills are not.

Nick Babich, following up his earlier roundup of Claude skills, looks at Anthropic’s skill-creator, a meta-skill that generates and evaluates new skills. His framing of what a skill actually is:

Many people explain the role of a skill as a set of instructions that Claude automatically activates for a particular task. While this is a correct way to describe its behavior, it’s better to think of a skill as a recipe. Just like when we cook something, we rely on a recipe to do the job correctly, Claude will rely on a dedicated skill.

Recipes compound. You refine them, share them, adapt them for new contexts. Prompts are disposable. Skills persist.

And now skills can write other skills. Babich walks through the full skill-creator setup, and the most interesting detail is the self-evaluation loop:

The great thing about Skill Creator is that it triggers a process that evaluates the quality of output a newly created skill will produce. This evaluation is exactly what helps you achieve better results with your skill.

Worth following along if you’re building your own. (And you should be!)

I’ve rebuilt my personal website more times than I can count. The tools and platforms change; the principle doesn’t: I own my content, and nobody gets to take it away. I have a Substack, but it’s a digest, a syndication channel. The canonical content lives on my site, on my domain. My website can’t be enshittified by anyone but me.

Henry Desroches makes the case through Ivan Illich’s Tools for Conviviality:

In his book Tools For Conviviality, technology philosopher and social critic Ivan Illich identifies these two critical moments, the optimistic arrival & the deadening industrialization, as watersheds of technological advent. Tools are first created to enhance our capacities to spend our energy more freely and in turn spend our days more freely, but as their industrialization increases, their manipulation & usurpation of society increases in tow.

Illich also describes the concept of radical monopoly, which is that point where a technological tool is so dominant that people are excluded from society unless they become its users. We saw this with the automobile, we saw it with the internet, and we even see it with social media.

That’s social media in one paragraph. You don’t join Instagram because you want to; you join because opting out means opting out of the conversation. Desroches argues personal websites are the answer:

Hand-coded, syndicated, and above all personal websites are exemplary: They let users of the internet to be autonomous, experiment, have ownership, learn, share, find god, find love, find purpose. Bespoke, endlessly tweaked, eternally redesigned, built-in-public, surprising UI and delightful UX. The personal website is a staunch undying answer to everything the corporate and industrial web has taken from us.

The practical argument is strong enough on its own. Own your content. Own your platform. Syndicate outward. The moment you frame it as reclaiming the soul of the internet, you lose the people who most need to hear the boring version: just put your stuff on a domain you control.

Last September I wrote about why we still need a HyperCard for the AI era—a tool that’s accessible but controllable, that lets everyday people build and share software without needing to be developers. John Allsopp sees the demand side of that equation already arriving.

Writing on LinkedIn, he starts with his 13-year-old daughter sending him a link to Aippy, a platform where people create, share, and remix apps like TikTok videos. It already has thousands of apps on it:

Millions of people who have never written a line of code are starting to build applications — not scripts or simple automations, but genuine applications with interfaces and logic and persistence.

The shift Allsopp describes isn’t just about who’s building. It’s about how software spreads:

This pattern — creation, casual sharing, organic spread — looks a lot more like how content moves on TikTok or Instagram than how apps move through the App Store. Software becomes something you make and share, and remix. Not something you publish and sell. It surfaces through social connections and social discovery, not through store listings and search rankings.

And the platforms we have aren’t built for it. Allsopp points out that the appliance model Apple introduced in 2007 made sense for an audience that was intimidated by technology. That audience grew up:

The platforms designed to protect users from complexity are now protecting users from their own creativity and that of their peers.

This is the world I was writing about in “Why We Still Need a HyperCard for the AI Era.” I argued for tools with direct manipulation, technical abstraction, and local distribution—ingredients HyperCard had that current AI coding tools still miss. Allsopp is describing the audience those tools need to serve. The gap between the two is where the opportunity sits.

I started my career in print. I remember specifying designs in fractional inches and points, and expecting the printed piece to match the comp exactly. When I moved to the web in the late ’90s, I brought that same expectation with me because that’s how we worked back then. Our Photoshop files were precise. But if we’re being honest—that the web is an interactive, quickly malleable medium—that expectation is misplaced. I’ve long since changed my mind, of course.

Web developer Amit Sheen, writing for Smashing Magazine, articulates the problem with “pixel perfect” better than I’ve seen anyone do it:

When a designer asks for a “pixel-perfect” implementation, what are they actually asking for? Is it the colors, the spacing, the typography, the borders, the alignment, the shadows, the interactions? Take a moment to think about it. If your answer is “everything”, then you’ve just identified the core issue… When we say “make it pixel perfect,” we aren’t giving a directive; we’re expressing a feeling.

According to Sheen, “pixel perfect” sounds like a specification but functions as a vibe. It tells the developer nothing actionable.

He traces the problem back to print’s influence on early web design:

In the print industry, perfection was absolute. Once a design was sent to the press, every dot of ink had a fixed, unchangeable position on a physical page. When designers transitioned to the early web, they brought this “printed page” mentality with them. The goal was simple: The website must be an exact, pixel-for-pixel replica of the static mockup created in design applications like Photoshop and QuarkXPress.

Sheen doesn’t just tear down the old model. He offers replacement language. Instead of demanding “pixel perfect,” teams should ask for things like “visually consistent with the design system” or “preserves proportions and alignment logic.” These phrases describe actual requirements rather than feelings.

Sheen again, addressing designers directly:

When you hand over a design, don’t give us a fixed width, but a set of rules. Tell us what should stretch, what should stay fixed, and what should happen when the content inevitably overflows. Your “perfection” lies in the logic you define, not the pixels you draw.

I’m certain advanced designers and design teams know all of the above already. I just appreciated Sheen’s historical take. A Figma file is a hypothesis, a picture of what to build. The browser is the truth.

Really cool interactive playground by designer Braz De Pina to create and remix futuristic interfaces—you know, that stuff you see on sci-fi shows and movies.

“I want my MTV!” That is the line that many music artists spoke to camera in a famous campaign by George Lois to get fans to call their cable companies to ask for MTV. It worked.

While MTV’s international music-only channels went off the air at the end of 2025, its US channels still exist. They’re just not all-music all the time like it was in the 1980s.

That’s where MTV Rewind comes in. It’s a virtual TV where you can relive MTV programming as it was. Built by an artist going by FlexasaurusRex, it’s an archive of Day 1 programming, and then different channels (YouTube playlists) to shuffle through the different shows, including 120 Minutes.

“Size of Life” is a fun comparison of the different sizes of living things by Neal Agarwal and illustrated by Julius Csotonyi. In case you don’t know the Agarwal, he’s created a dazzling collection of fun/funny minisites. Reminds me of “Powers of Ten” by Charles and Ray Eames.

I’ve linked to a footer gallery, a navbar gallery, and now to round us out, here is a full-on Component Gallery. Web developer Iain Bean has been maintaining this library since 2019.

Bean writes in the about page:

The original idea for this site came from A Pattern Language2, a 1977 book focused on architecture, building and planning, which describes over 250 ‘patterns’: forms which fit specific contexts, or to put it another way, solutions to design problems. Examples include: ‘Beer hall’, ‘Positive outdoor space’ and ‘Light on two sides of every room’.

Whereas the book focuses on the physical world, my original aim with this site is was focus on those patterns that appear on the web; these often borrow the word ‘pattern’ (see Patterns on the GOV.UK design system), but are more commonly called components, hence ‘the component gallery’ — unlike a component library, most of these components aren’t ready to use off-the-shelf, but they’ll hopefully inspire you to design your own solution to the problem you’re working to solve.

So if you ever need a reference for how different design systems handle certain components (e.g., combobox, segmented control, or toast ), this is your site.

It’s always interesting for me to read how other designers use AI to vibe code their projects. I think using Figma Make to conjure a prototype is one thing, but vibe coding something in production is entirely different. Personally, I’ve been through it a couple of times that I’ve already detailed here and here.

Anton Sten recently wrote about his process. Like me, he starts in Figma:

This might be the most important part: I don’t start by talking to AI. I start in Figma.

I know Figma. I can move fast there. So I sketch out the scaffolding first—general theme, grids, typography, color. Maybe one or two pages. Nothing polished, just enough to know what I’m building.

Why does this matter? Because AI will happily design the wrong thing for you. If you open Claude Code with a vague prompt and no direction, you’ll get something—but it probably won’t be what you needed. AI is a builder, not an architect. You still have to be the architect.

I appreciate Sten’s conclusion to not let the AI do all of it for you, echoing Dr. Maya Ackerman’s sentiment of humble creative machines:

But—and this is important—you still need design thinking and systems thinking. AI handles the syntax, but you need to know what you’re building, why you’re building it, and how the pieces fit together. The hard part was never the code. The hard part is the decisions.

Designer and front-end dev Ondřej Konečný has a lovely presentation of his book collection.

My favorites that I’ve read include:

• Creative Selection by Ken Kocienda (my review)
• Grid Systems in Graphic Design by Josef Müller-Brockmann
• Steve Jobs by Walter Isaacson
• Don’t Make Me Think by Steve Krug
• Responsive Web Design by Ethan Marcotte

(h/t Jeffrey Zeldman)

Website screenshot SaaS company Urlbox created a fun project called One Million Screenshots, with, yup, over a million screenshots of the top one million websites. You navigate the page like Google Maps, by zooming in and panning around.

Why? From the FAQ page:

We wanted to celebrate Urlbox taking over 100 million screenshots for customers in 2023… so we thought it would be fun to take an extra 1,048,576 screenshots evey month… did we mention we’re really into screenshots.

(h/t Brad Frost)

Ryan Feigenbaum created a fun Teenage Engineering-inspired color palette generator he calls “ColorPalette Pro.” Back in 2023, he was experimenting with programatic palette generation. But he didn’t like his work, calling the resulting palettes “gross, with luminosity all over the place, clashing colors, and garish combinations.”

So Feigenbaum went back to the drawing board:

That set off a deep dive into color theory, reading various articles and books like Josef Albers’ Interaction of Color (1963), understanding color space better, all of which coincided with an explosion of new color methods and technical support on the web.

These frustrations and browser improvements culminated in a realization and an app.

Here he is, demoing his app:

Make no mistake: Democracy in America has been under threat. The Executive branch continues to accrue and abuse power, much of it willingly given up by Congress, and the Supreme Court has largely given deference to this president.

In a beautiful, yet somehow haunting visualization, Alvin Chang for the Pudding went back and analyzed speeches in Congress from 1880 onward to show the growth of mentions about democracy being under threat.

Scroll through the interactive data viz and see the numbers tick up over the years, along with select quotes from speeches.

Chang ends with this reflection:

I grew up in an immigrant family, and I was constantly reminded of how powerful these values are. Sure, my family had some allegiance to their home country. Sure, we were constantly reminded of ways in which the country failed to live up to these ideals. However, I was told that we live in a country that is united not by the color of our skin or the origins of our families, but rather a belief in how humans should live together.

Americans have always argued about what it means to strive toward these democratic ideals. This pursuit of democracy is who we are; it’s who we want to be.

If we stop now, who are we as a people?

(h/t Nathan Yau / FlowingData)

Someone on X recently claimed they “popularized” dithering in modern design—a bold claim for a technique that’s been around since Robert Floyd and Louis Steinberg formalized it in 1976 and Bill Atkinson refined it for the original Macintosh. The design community swiftly reminded them that revival isn’t invention, and that dithering’s current moment owes more to retro-tech aesthetics meeting modern GPU pipelines than to any single designer’s genius.

Speaking of which, here’s a visual explainer by Damar Aji Pramudita that’s worth your time on how dithering actually works. Apparently it’s only part one of three.