Link tags: process

Google’s Prompt API

No web standard should require you to agree to an advertising company’s “terms of use.”

I’m genuinely disheartened and angry that the Google Chrome team have done this. Never assume good faith from them again.

This is, hands-down, the most insultingly transparent attempt at web standards bullying I’ve ever seen, including past ones from Google, which is — and I cannot stress this point enough — a company that sells advertisements. This is miles more eyeroll-worthy than AMP, where you’ll recall that a legion of tight-smiling dorks wearing Alphabet lanyards tried to assure us that the only means of survival for the web itself was to funnel all of it through Google’s servers, and only use their very good advertisements instead of those bad other ones.

Design and Engineering, As One · Matthias Ott

A thoughtful piece by Matthias that’s a must-read for both designers and developers.

A considered approach to generative AI in front-end… | Clearleft

A thoughtful approach from Sam:

1. Use AI only for tasks you already know how to do, on occasions when the time that would be spent completing the task can be better spent on other problems.
2. When using AI, provide the chosen tool with something you’ve made as an input along with a specific prompt.
3. Always comprehensively review the output from an AI tool for quality.

Stop generating, start thinking - localghost

Generated code is rather a lot like fast fashion: it looks all right at first glance but it doesn’t hold up over time, and when you look closer it’s full of holes. Just like fast fashion, it’s often ripped off other people’s designs. And it’s a scourge on the environment.

Coding Is When We’re Least Productive – Codemanship’s Blog

I’ve seen so many times how 10 lines of code can end up being worth £millions, and 10,000 ends up being worthless.

Dithering - Part 1

A clear explanation of how image dithering works, illustrated along the way.

Most of What We Call Progress - Yusuf Aytas

Every engineer eventually overbuilds something. You think you’re being smart. You’re thinking ahead, building for growth and before you know it, you’ve created a system ten times heavier than your actual problem. That’s the trap. We keep designing for imaginary futures for scale that may never come and call it engineering. But it’s not engineering. It’s over-engineering.

The industry rewards it too. Nobody gets promoted for keeping things small and sane. You get promoted for complexity.

A cartoonist’s review of AI art - The Oatmeal

Stick with this. It’s worth it.

How to Make Websites That Will Require Lots of Your Time and Energy - Jim Nielsen’s Blog

1. Install Stuff Indiscriminately From npm
2. Pick a Framework Before You Know You Need One
3. Always, Always Require a Compilation Step

No build frontend is so much more fun

The joy came flooding back to me! It turns out browser APIs are really good now.

Close to the metal: web design and the browser

It seems like the misguided perception of needing to use complex tools and frameworks to build a website comes from a thinking that web browsers are inherently limited. When, in fact, browsers have evolved to a tremendous degree

Bias in Design Systems - bencallahan.com

Thoughtful analysis from Ben (as always).

Design for a Small Planet – Scott Jenson

So, let’s start with a simple premise: how can we make design less opaque and encourage teams to make small changes more efficiently? Not every product decision needs to be a big, complicated design process.

This checklist, in four parts, is meant to be a simple, lightweight way for the team to get the ‘gist’ of the issue and make a shared decision quickly. It’s a starting point, a way to get the critical information in once place so the entire team can understand and discuss. The four parts are:

• Gather: Bring the right info together into a single place
• Impact: List the size of the problem and possible risks
• Sketch: Create a preliminary sketch of a solution
• Team Huddle: Get the product team to discuss and agree on a solution.

Another uncalled-for blog post about the ethics of using AI | Clagnut by Richard Rutter

This is a really thoughtful piece by Rich, who’s got conflicted feelings about large language models in the design process. I suspect a lot of people can relate to this.

What I do know is that I find LLMs useful on occasion, but every time I use one I die a little inside.

Why I Like Designing in the Browser – Cloud Four

This describes how I like to work too.

Putting the ink into design thinking | Clearleft

The power of prototyping:

Most of my work is a set of disposables rather than deliverables, and I celebrate this.

I like the three questions that Chris asks himself:

1. What’s the quickest, cheapest thing I can create to help make the next design decision?
2. What can I create to best demonstrate the essence of the concept?
3. How can I most effectively share the thinking behind the design with decision-makers?

Elizabeth Goodspeed on the importance of taste – and how to acquire it

AI image generation is essentially a truncated exercise in taste; a product of knowing which inputs and keywords to feed the image-mashup machine, and the eye to identify which outputs contain any semblance of artistry. All that is to say: AI itself can’t generate good taste for you.

“‘AI’ is pretty much just shorthand for mediocre” — Piper Haywood

Continuous partial ick …or perhaps continuous partial cringe.

Anyways, maybe we’ll eventually get to the point where AI has that human “spark”, who knows. Maybe it’ll happen next month and I’ll eat my words. Until then, as most of the content we experience online becomes more grey and sludgy, the personal will become far more valuable.

Can Apple Win Back Music | Vulf Opinion | Brad Frost

There’s no AI substitute for a human-produced drawing of someone on the subway, even if a similar-or-even-better result could be produced in seconds by AI. The artifact is often less important than the process — the human process — that made it. That’s why I suspect videos of creative processes are so attractive; we are captivated by seeing humans doing human things.

Eigensolutions: composability as the antidote to overfit • Lea Verou

I love, love, love the deep thinking that Lea has put into this, really digging into the guts of what design does.

Overfitting happens when solutions don’t generalize sufficiently and is a hallmark of poor design. Eigensolutions are the opposite: solutions that generalize so much they expose links between seemingly unrelated use cases. Designing eigensolutions takes a mindset shift from linear design to composability.

Lea ties this into web standards too. It’s really helped clarify for me why I want more declarative options for common use cases (like a share button)—it’s about raising the ceiling without raising the floor.