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:
- What’s the quickest, cheapest thing I can create to help make the next design decision?
- What can I create to best demonstrate the essence of the concept?
- How can I most effectively share the thinking behind the design with decision-makers?
I’ve always maintained that prototyping and production require different mindsets. Trys suggests it’s not as simple as that.
I agree with much of what he says about back-end decisions (make it manual ‘till it hurts—avoid premature optimisation), but as soon as you’re delivering HTML, CSS, and JavaScript to real people, I think you need to meet certain standards when it comes to accessibility, performance, etc.
If you’re a fan of gratuitous initialisms, you’ll love Google’s core web vitals. Just get a load of the obfuscation in the important-sounding metrics like CLS, FCP, LCP, and more.
To be fair to Google, this is a problem in the web performance world in general. Practioners prefer to talk about TTFB rather than “time to first byte” even though both contain exactly the same number of syllables.
The big news in the web performance community this month is the arrival of a new initialism. INP sounds like one of those pseudo-scientific psychologic profiles but it’s meant to stand for Interaction to Next Paint (even if they were to swear off pointless initialisms, you’d still have to pry Pointless Capitalisation from Google’s cold dead hands).
This new metric is a welcome one. It’s replacing first input delay. Sorry, First Input Delay, or FID, one of the few web vital initialisms that can be spoken as a word, making it a true acronym (fortunately fid’s successor, inp, also works as an acronym).
First Input Delay has long outstayed its welcome. It was always an outlier in the core web vitals. It didn’t seem to measure anything actually useful. I know it sounds like it’s measuring the delay until the user can interact with a web page, but when you dive into what it actually does, it’s a mess:
FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.
See that word “begin” in there? It’s doing a lot of work. First Input Delay doesn’t measure the lag between the user interaction and the browser response; it only measures the lag between the user interaction and the browser beginning to respond. The actual response could take ages, but that lag doesn’t get measured. Unlike the other core web vitals, this metric is very far removed from what actually matters to the user’s experience.
What the fid where they thinking? How the fid did this measurement ever get included in core web vitals in the first place?
Well, feel free to take what I’m about to say as pure gossip, but I have my sources, I trust ’em, and no, I’m not going to reveal ’em…
It’s because of AMP.
Remember Google AMP? An acronym so pointless they eventually just forgot it ever stood for anything?
The AMP project ended up doing incredible damage to Google’s developer relations. By colluding with the search team to privilege the appearance of AMP pages in the top news carousel, Google effectively blackmailed the entire publishing industry into using their format.
In the end, it didn’t work. It was a shit format. All they did was foster resentment and animosity:
AMP seems to have faded away. Most publishers have started dropping support, and even Google doesn’t seem to care much anymore.
It turns out that Google search wasn’t the only team infected by AMP. The core web vitals team also had to play ball.
Originally they had a genuinely useful metric for measuring the lag between input and response. But guess which pages did terribly? That’s right: AMP pages.
Rather than ship an actually-useful measurement, the core web vitals team instead had to include the broken First Input Delay, brainchild of a certain someone on the AMP team.
Now it all makes sense.
So good riddance to FID. Welcome to INP. And here’s hoping it won’t be much longer till we’re finally burying AMP.
We also have a culture in which arrogance is rewarded rather than kept in check, and people can see that with enough shameless bluster you might become the richest person in the world or the president of the United States. There is no quick fix for the problem—if I offered one, I would be the very kind of bullshitter I strive to avoid being—but we at the very least need to recognize what it is we are trying to change. We are trying to create a culture of thoughtfulness and insight, where people check carefully to see whether what they’re saying is true, and excessively egotistical people are looked upon with deep suspicion. With time and patient effort, perhaps we can create a world in which the people who rise to the highest offices and reap the greatest rewards are not also the ones who are most full of shit.
I can forgive our answer machines if they sometimes get it wrong. It’s less easy to forgive the confidence with which the bad answer is presented, giving the impression that the answer is definitive. That’s a design problem.
This is nice example of a web component that degrades gracefully—if custom elements aren’t supported, you still get the markdown content, just not converted to HTML.
<ah-markdown>
## Render some markdown!
</ah-markdown>
Be willing to look like a dork:
Embarrassment about what others think has to be the biggest block to any learning. Embarrassment of looking silly. Embarrassment of looking stupid for asking the question everyone else is wondering about but no one is willing to make.
Chimes nicely with Charlotte’s recent piece, Be comfortable looking like an idiot.
I was talking to Charlotte recently about public speaking, confidence, and overcoming fear. She really hit the nail on the head when she said “I need to get comfortable with feeling like an idiot.”
Words to live by—especially if you’re working on the web.
Following on from her great conversation with Jen on The Web Ahead podcast, Rachel outlines a strategy to avoid feeling overwhelmed by the deluge of tools, frameworks, libraries, and techniques inundating front-end developers every day:
Learn your core skills well. Understand HTML and CSS, be able to build a layout without leaning on a framework. Get a solid understanding of how a website actually gets from the server to a browser, an understanding of security and accessibility. These are the basics, the constants. These things change slowly. These things sit underneath all the complexity and the tooling, the CMSs and the noise of thousands of people all trying to make their mark on this industry.
She also makes this important point:
As you are doing this don’t forget to share what you know.
This is so nifty! A combination of the Radiodan, Huffduffer, and RFID, all wrapped up in a box.
Scott writes up some of the things he talked about at the Breaking Development conference: the just-in-time interactions that are inevitable in a heavily-instrumented world.
Matt Jones on sociality, data, radio and time.
Social networking for dogs through RFID. Spimy animals FTW!
Reading through some of the things that peope have made with these RFID tags is making me itchy to hack something tangible.