
Checked in at Jolly Brewer. Epic session! — with Jessica
5th | 10th | 15th | 20th | 25th | 30th | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
12am | |||||||||||||||||||||||||||||||
4am | |||||||||||||||||||||||||||||||
8am | |||||||||||||||||||||||||||||||
12pm | |||||||||||||||||||||||||||||||
4pm | |||||||||||||||||||||||||||||||
8pm |
Checked in at Jolly Brewer. Epic session! — with Jessica
Thank you! That really means a lot to me.
The hard part is trying to decide which of your excellent posts to link to—your output is so prolific!
Also: I’ve been listening to your voice in my earholes: https://huffduffer.com/adactio
Charlie’s thoughts on dev perception:
People speak about “the old guard” and “stupid backwards techniques”, forgetting that it’s real humans, with real constraints who are working on these solutions. Most of us are working in a “stupid backwards way” because that “backwardsness” WORKS. It is something that is proven and is clearly documented. We can implement it confident that it will not disappear from fashion within a couple of years.
Tough, but fair.
This is a fascinating look at how you can get the benefits of React and npm without using React and npm.
Here’s an accompanying article on the same topic.
What a wonderfully in-depth and clear tutorial from Cassie on how she created the animation for her nifty SVG logo!
Also: Cassie is on the indie web now, writing on her own website—yay!
Any plans to ever pay the invoice I sent you for this?
As it stands, with the travel costs I’m out of pocket for, I paid you to speak at your conference.
Do the right thing.
Wish I were there! #missyoutootorre
Take an interactive tour of our solar system’s many moons.
Did you know about console.time()
and console.timeEnd()
? I did not.
Your main concern should be user needs—not your own.
When I talk about over-engineering, I’m speaking from the perspective of end users, not developers.
Before considering your ease of use, and maintainability, consider users first.
The post specifically says “It feels ‘wrong’ when a powerful client-side JavaScript framework is applied to something that could be accomplished using HTML.” (emphasis mine)
Then it must be redirecting in the app, because that link goes to the canonical URL.
Ah, I see. Sounds like a shitty app. Or maybe it’s a shitty iOS-level sharing thing.
But where is that linked to from Medium? The two links back to my site from Medium in the article point to the regular URL.
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.
My main concern about this new generation of tools is that they require a specific toolchain in order to function. “If you just use this version of React and just use this styling library and configure things in exactly this way, your designers can play around with coded components.” It worries me that teams would end up choosing (and subsequently holding onto) specific tools not because they’re the best choices for our users but because the designers’ and developers’ workflow depends on a specific toolchain to work properly.
Where is this link?
I like good design principles. I collect design principles—of varying quality—at principles.adactio.com. Ben Brignell also has a (much larger) collection at principles.design.
You can spot the less useful design principles after a while. They tend to be wishy-washy; more like empty aspirational exhortations than genuinely useful guidelines for alignment. I’ve written about what makes for good design principles before. Matthew Ström also asked—and answered—What makes a good design principle?
- Good design principles are memorable.
- Good design principles help you say no.
- Good design principles aren’t truisms.
- Good design principles are applicable.
I like those. They’re like design principles for design principles.
One set of design principles that I’ve included in my collection is from gov.uk: government design principles . I think they’re very well thought-through (although I’m always suspicious when I see a nice even number like 10 for the amount of items in the list). There’s a great line in design principle number two—Do less:
Government should only do what only government can do.
This wasn’t a theoretical issue. The multiple departmental websites that preceded gov.uk were notorious for having too much irrelevant content—content that was readily available elsewhere. It was downright wasteful to duplicate that content on a government site. It wasn’t appropriate.
Appropriateness is something I keep coming back to when it comes to evaluating web technologies. I don’t think there are good tools and bad tools; just tools that are appropriate or inapropriate for the task at hand. Whether it’s task runners or JavaScript frameworks, appropriateness feels like it should be the deciding factor.
I think that the design principle from GDS could be abstracted into a general technology principle:
Any particular technology should only do what only that particular technology can do.
Take JavaScript, for example. It feels “wrong” when a powerful client-side JavaScript framework is applied to something that could be accomplished using HTML. Making a blog that’s a single page app is over-engineering. It violates this principle:
JavaScript should only do what only JavaScript can do.
Need to manage state or immediately update the interface in response to user action? Only JavaScript can do that. But if you need to present the user with some static content, JavaScript can do that …but it’s not the only technology that can do that. HTML would be more appropriate.
I realise that this is basically a reformulation of one of my favourite design principles, the rule of least power:
Choose the least powerful language suitable for a given purpose.
Or, as Derek put it:
In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.
ARIA should only do what only ARIA can do.
JavaScript should only do what only JavaScript can do.
CSS should only do what only CSS can do.
HTML should only do what only HTML can do.
We’ve got the soundtrack from the Apollo 11 documentary on in the background at Homebrew Website Club Brighton. Blogging has never felt more dramatic!
The story of Jack Garman and the 1202 alarm—as covered in episode two of the 13 Minutes To The Moon podcast.
Next time you’re faced with a decision, ask yourself: how can this decision be made on the lowest level? Have you given your team the authority to decide? If you haven’t, why not? If they’re not able to make good decisions, you’ve missed an opportunity to be a leader. Empower, enable, and entrust them. Take it from NASA: the ability to delegate quickly and decisively was the key to landing men on the moon.
Dave enumerates the things about Vue that click for him. The component structure matches his mental model, and crucially, it’s relative straightforward to add Vue to an existing project instead of ripping everything out and doing things a certain way:
In my experience Angular, React, and a lot of other frameworks ultimately require you to go all in early and establish a large toolchain around these frameworks.
Checked in at Jolly Brewer. 🎶 — with Jessica
Fast software is not always good software, but slow software is rarely able to rise to greatness. Fast software gives the user a chance to “meld” with its toolset. That is, not break flow.
This post was originally written in 2015, but upon re-reading it today, it still (just about) holds up, so I finally hit publish.
Jon’s ranting about Agile here, but it could equally apply to design systems:
Agile and design is like looking at a picture through a keyhole. By slicing big things into smaller things, designers must work incrementally. Its this incrementalism that can lead to what I call the ‘Frankensteining’ of a digital product or service.
Yeah, it’s one of the handful of elements allowed in head
. Most elements automatically trigger an opening body
element if you try using them in head
.
Having a beer on the beach.
I find myself doing pseudo code before I write real code, sure, but I also leave it in place sometimes in code comments.
Same!
Yes, probably still worth keeping a noscript
element around with a link
to the non-critical CSS.
If you missed out on Patterns Day this year, you can still get a pale imitation of the experience of being there by watching videos of the talks.
Here are the videos, and if you’re not that into visuals, here’s a podcast of the talks (you can subscribe to this RSS feed in your podcasting app of choice).
On Twitter, Chris mentioned that “It would be nice if the talks had their topic listed,” which is a fair point. So here goes:
It’s fascinating to see emergent themes (other than, y’know, the obvious theme of design systems) in different talks. In comparison to the first Patterns Day, it felt like there was a healthy degree of questioning and scepticism—there were plenty of reminders that design systems aren’t a silver bullet. And I very much appreciated Yaili’s point that when you see beautifully polished design systems that have been made public, it’s like seeing the edited Instagram version of someone’s life. That reminded me of Responsive Day Out when Sarah Parmenter, the first speaker at the very first event, opened everything by saying “most of us are winging it.”
I can see the value in coming to a conference to hear stories from people who solved hard problems, but I think there’s equal value in coming to a conference to hear stories from people who are still grappling with hard problems. It’s reassuring. I definitely got the vibe from people at Patterns Day that it was a real relief to hear that nobody’s got this figured out.
There was also a great appreciation for the “big picture” perspective on offer at Patterns Day. For myself, I know that I’ll be cogitating upon Danielle’s talk and Emil’s talk for some time to come—both are packed full of ineresting ideas.
Good thing we’ve got the videos and the podcast to revisit whenever we want.
And if you’re itching for another event dedicated to design systems, I highly recommend snagging a ticket for the Clarity conference in San Francisco next month.
Checked in at Miku Restaurant
Brad describes how he has found his place in the world of React, creating UI components without dabbling in business logic:
Instead of merely creating components’ reference HTML, CSS, and presentational JS, frontend designers can create directly consumable HTML, CSS, and presentational JS that back-of-the-frontend developers can then breathe life into.
What’s clear is that the term “React” has become as broad and undefined as the term “front-end”. Just saying that someone does React doesn’t actually say much about the nature of the work.
When you say “we’re hiring a React developer”, what exactly do you mean by that? “React developer” is almost as vague as “frontend developer”, so clarify. Are you looking for a person to specialize in markup and styles? A person to author middleware and business logic? A person to manage data and databases? A person to own build processes?
A case study from Twitter on the benefits of using a design system:
With component-based design, development becomes an act of composition, rather than constantly reinventing the wheel.
I think that could be boiled down to this:
Component-based design favours composition over invention.
I’m not saying that’s good. I’m not saying that’s bad. I’m also not saying it’s neutral.
In some situations, a date picker is overkill:
I have relied on plain text inputs as date fields with custom validation for the site, typically using the same logic on the client and the server. For known dates — birthdays, holidays, anniversaries, etc — it has tested well.
Some excellent explanations for these five pieces of sensible typography advice:
- Set your base font size in relative units
- Check the colour of your type and only then its contrast
- Use highly legible fonts
- Shape your paragraphs well
- Correctly use the heading levels
Scott re-examines the browser support for loading everything-but-the-critical-CSS asynchronously and finds that it might now be as straightforward as this one declaration:
<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">
I love the fact the Filament Group are actively looking at how deprecate their loadCSS
polyfill—exactly the right attitude for polyfills in general.
A look at all the factors that went into choosing the Apollo landing sites, including this gem:
Famous amateur astronomer, Sir Patrick Moore, also produced a hand drawn map of the moon from his own observations using his homemade telescope at his home in Selsey, Sussex. These detailed pen and ink maps of the Moon’s surface were used by NASA as part of their preparations for the moon landing.
Checked in at Jade Dynasty
Ribfest!
Yellow Dog Brewing Co.
Grilled cheese.
Thank you, @mezzoblue and @curio_research for a lovely day of cycling in the Canadian countryside.
They’re both such wonderful books—apart from the obvious microbial connection, there’s a refreshingly uncynical joy infusing the writing of each of them!
There’s a lovely resonance in reading @RobinSloan’s Sourdough back to back with @EdYong209’s I Contain Multitudes. One’s fiction, one’s non-fiction, but they’re both microbepunk.
After the conference.
Goodnight, Vancouver.
Reading I Contain Multitudes: The Microbes Within Us and a Grander View of Life by Ed Yong.
Ah, that’s a good point! JavaScript’s Response object can create HTML (without creating a DOM).
Chris succinctly describes the multiple-iframe
s-with-multiple-codebases approach to web development, AKA “micro frontends”:
The idea really is that you might build a React app and I build a Vue app and we’ll slap ‘em together on the same page. I definitely come from an era where we laughed-then-winced when we found sites that used multiple versions of jQuery on the same page, plus one thing that loaded all of MooTools and Prototype thrown on there seemingly by accident. We winced because that was a bucket full of JavaScript, mostly duplicated for no reason, causing bugs and slowing down the page. This doesn’t seem all that much different.
I’ve shaped this timeline over five months. It might look simple, but it most definitely was not. I liken it to chipping away at a block of marble, or the slow process of evolving a painting, or constructing a poem; endless edits, questions, doubling back, doubts. It was so good to have something meaty to get stuck into, but sometimes it was awful, and many times I considered throwing it away. Overall it was challenging, fun, and worth the effort.
Simon describes the process of curating the lovely timeline on his personal homepage.
My timeline is just like me, and just like my life: unfinished, and far from perfect.
Not quite. Both techniques create a Document Object Model. A DOM can be created with HTML or a DOM can be created with JavaScript. But JavaScript cannot create HTML. (I know it’s a pedantic distinction.)
What a lovely way to walk through the design system underpinning the Guardian website.
Bonus points for using the term “tweak points”!
When min()
gets better support (it’s currently in Safari), we’ll be able to create container queryish declarations like this:
grid-template-columns: repeat(auto-fill, minmax(min(10rem, 100%), 1fr));
Thoughts on frameworks, prompted by a re-reading of Resilient Web Design. I quite like the book being described as a “a bird’s-eye view of the whole web design circus.”
From Cork, too, like!
A delightful dialogue …on the moon!
Checked in at Quantum Coffee
Going to Vancouver. brb
Got a postcard from @ArielWaldman of the cutest tardigrade in all Antarctica.
Antarctigrade! 🇦🇶
Just watched the International Space Station fly past a partial lunar eclipse …on the fiftieth anniversary of Apollo 11’s launch.
Spaaaaaace!!!
Hi @Astro_Christina! Hi @AstroHague! Hi Alexey Ovchinin!
Fifteen years ago, I went to the Willie Clancy Summer School in Miltown Malbay:
I’m back from the west of Ireland. I was sorry to leave. I had a wonderful, music-filled time.
I’m not sure why it took me a decade and a half to go back, but that’s what I did last week. Myself and Jessica once again immersed ourselves in Irish tradtional music. I’ve written up a trip report over on The Session.
On the face of it, fifteen years is a long time. Last time I made the trip to county Clare, I was taking pictures on a point-and-shoot camera. I had a phone with me, but it had a T9 keyboard that I could use for texting and not much else. Also, my hair wasn’t grey.
But in some ways, fifteen years feels like the blink of an eye.
I spent my mornings at the Willie Clancy Summer School immersed in the history of Irish traditional music, with Paddy Glackin as a guide. We were discussing tradition and change in generational timescales. There was plenty of talk about technology, but we were as likely to discuss the influence of the phonograph as the influence of the internet.
Outside of the classes, there was a real feeling of lengthy timescales too. On any given day, I would find myself listening to pre-teen musicians at one point, and septegenarian masters at another.
Now that I’m back in the Clearleft studio, I’m finding it weird to adjust back in to the shorter timescales of working on the web. Progress is measured in weeks and months. Technologies are deemed outdated after just a year or two.
The one bridging point I have between these two worlds is The Session. It’s been going in one form or another for over twenty years. And while it’s very much on and of the web, it also taps into a longer tradition. Over time it has become an enormous repository of tunes, for which I feel a great sense of responsibility …but in a good way. It’s not something I take lightly. It’s also something that gives me great satisfaction, in a way that’s hard to achieve in the rapidly moving world of the web. It’s somewhat comparable to the feelings I have for my own website, where I’ve been writing for eighteen years. But whereas adactio.com is very much focused on me, thesession.org is much more of a community endeavour.
I question sometimes whether The Session is helping or hindering the Irish music tradition. “It all helps”, Paddy Glackin told me. And I have to admit, it was very gratifying to meet other musicians during Willie Clancy week who told me how much the site benefits them.
I think I benefit from The Session more than anyone though. It keeps me grounded. It gives me a perspective that I don’t think I’d otherwise get. And in a time when it feels entirely to right to question whether the internet is even providing a net gain to our world, I take comfort in being part of a project that I think uses the very best attributes of the World Wide Web.
Spanish Point, 15 years apart.
TLI plus 90.
T + 50 years - 2.5 hours to trans-lunar injection.
Repeat: two and a half hours to TLI.
T + 50 years - 30 minutes:
Greg has done a lot of research into developer frustrations with customising form controls.
My current thinking in this space, and I know some folks will find this controversial, but I think we should completely standardize in-page form controls with no limitations on their styling capabilities. What do I mean by in-page controls? I am referring to any form control or component that is rendered within the content process. This standardization would include the sub-parts and their related states and how these are exposed (probably through CSS psuedo classes or HTML attributes). This will enable the shadow-dom to be encapsulated while providing web developers with a consistent experience to adjust to match their brand and needs of their site/application.
An interesting look at the mortality causes for Internet Explorer 6 and Internet Explorer 8, and what they can tell us for the hoped-for death of Internet Explorer 11.
I disagree with the conclusion (that we should actively block IE11—barring any good security reasons, I don’t think that’s defensible), but I absolutely agree that we shouldn’t be shipping polyfills in production just for IE11. Give it your HTML. Give it your CSS. Withhold modern JavaScript. If you’re building with progressive enhancement (and you are, right?), then giving IE11 users a sub-par experience is absolutely fine …it’s certainly better than blocking them completely.
T + 49 years + 364 days + 19 hours and counting.
Counting down to T + 50 here: https://apolloinrealtime.org/11/
Happy launch day, everyone!
A short, snappy web book on product development from Ryan Singer at Basecamp.
Like Resilient Web Design, the whole thing is online for free (really free, not “give us your email address” free).
Brian found this scanned copy of a NeXT manual on the Internet Archive. I feel a great fondness for this machine after our CERN project.
This is a great how-to from Darius Kazemi!
The main reason to run a small social network site is that you can create an online environment tailored to the needs of your community in a way that a big corporation like Facebook or Twitter never could. Yes, you can always start a Facebook Group for your community and moderate that how you like, but only within certain bounds set by Facebook. If you (or your community) run the whole site, then you are ultimately the boss of what goes on. It is harder work than letting Facebook or Twitter or Slack or Basecamp or whoever else take care of everything, but I believe it’s worth it.
There’s a lot of good advice for community management and the whole thing is a lesson in writing excellent documentation.
Correlation does not imply causation.
Mike follows up on the changes made by email startup Superhuman after his initial post:
I will say this: if you were skeptical of Superhuman’s commitment to privacy and safety after reading the last article, you should probably be even more skeptical after these changes. The company’s efforts demonstrate a desire to tamp down liability and damage to their brand, but they do not show an understanding of the core problem: you should not build software that surreptitiously collects data on people in a way that would surprise and frighten them.
Reading Sourdough by Robin Sloan.
Farewell to Miltown Malbay.
Fiddler at Spanish Point.
Listening to Noel Hill and Paddy Glackin.
Noel Hill.
Checked in at Bellbridge Hotel. 🎵🎶 — with Jessica
Checked in at Miltown Malbay. 💃🏻 — with Jessica
Na píobairí.
Fiddletastic!
Checked in at Friels Pub. 🎵 — with Jessica
Playing The Maids of Mount Cisco.
Pádraic Mac Mathúna playing Seamus Ennis’s pipes and Paddy Glackin playing Seamus Ennis’s fiddle.
Checked in at Tom Malone’s Pub & Market House. 🎵 — with Jessica
Playing tunes with fellow members of https://thesession.org
Checked in at Tom Malone’s Pub & Market House. 🎶 — with Jessica
Checked in at Friels Pub. 🎵 — with Jessica
Checked in at Clery’s. 🎶 — with Jessica
The road to Miltown.
Scoil Samhraidh Willie Clancy.
Checked in at Armada Hotel. 🎶
Checked in at Hillery’s. 🎵 — with Jessica
Checked in at Friels Pub. 🎶 — with Jessica
It’s a nice day in county Clare.
Spanish Point.
Paddy Glackin playing Seamus Ennis’s fiddle.
Checked in at Friels Pub. 🎶 — with Jessica
I’m on tenterhooks listening to @Kevin_Fong’s #13MinutesToTheMoon podcast—so good!
Going to Miltown Malbay. brb
Robert McFarlane’s new book is an exploration of deep time. In this extract, he visits the Onkalo nuclear waste storage facility in Finland.
Sometimes we bury materials in order that they may be preserved for the future. Sometimes we bury materials in order to preserve the future from them.
This is a great piece! It starts with a look back at some of the great minds of the nineteenth century: Herschel, Darwin, Babbage and Lovelace. Then it brings us, via JCR Licklider, to the present state of the web before looking ahead to what the future might bring.
So what will the life of an interface designer be like in the year 2120? or 2121 even? A nice round 300 years after Babbage first had the idea of calculations being executed by steam.
I think there are some missteps along the way (I certainly don’t think that inline styles—AKA CSS in JS—are necessarily a move forwards) but I love the idea of applying chaos engineering to web design:
Think of every characteristic of an interface you depend on to not ‘fail’ for your design to ‘work.’ Now imagine if these services were randomly ‘failing’ constantly during your design process. How might we design differently? How would our workflows and priorities change?
Oh dear, it’s that time of the evening when @seb_ly gets his laser out.
Winding down the week at the @Clearleft summer party.
Don’t miss this—a masterclass in SVG animation with Cassie (I refuse to use the W word). Mark your calendar: August 20th.
It’s July, 2019. You know what that means? The 50th anniversary of the Apollo 11 mission is this month.
I’ve already got serious moon fever, and if you’d like to join me, I have some recommendations…
Watch the Apollo 11 documentary in a cinema. The 70mm footage is stunning, the sound design is immersive, the music is superb, and there’s some neat data visualisation too. Watching a preview screening in the Duke of York’s last week was pure joy from start to finish.
Listen to 13 Minutes To The Moon, the terrific ongoing BBC podcast by Kevin Fong. It’s got all my favourite titans of NASA: Michael Collins, Margaret Hamilton, and Charlie Duke, amongst others. And it’s got music by Hans Zimmer.
Experience the website Apollo 11 In Real Time on the biggest monitor you can. It’s absolutely wonderful! From July 16th, you can experience the mission timeshifted by exactly 50 years, but if you don’t want to wait, you can dive in right now. It genuinely feels like being in Mission Control!
I mentioned how much I enjoyed Mike Hill’s talk at Beyond Tellerrand in Düsseldorf:
Mike gave a talk called The Power of Metaphor and it’s absolutely brilliant. It covers the monomyth (the hero’s journey) and Jungian archetypes, illustrated with the examples Star Wars, The Dark Knight, and Jurassic Park.
At Clearleft, I’m planning to reprise the workshop I did a few years ago about narrative structure—very handy for anyone preparing a conference talk, blog post, case study, or anything really:
Ellen and I have been enjoying some great philosophical discussions about exactly what a story is, and how does it differ from a narrative structure, or a plot. I really love Ellen’s working definition: Narrative. In Space. Over Time.
This led me to think that there’s a lot that we can borrow from the world of storytelling—films, novels, fairy tales—not necessarily about the stories themselves, but the kind of narrative structures we could use to tell those stories. After all, the story itself is often the same one that’s been told time and time again—The Hero’s Journey, or some variation thereof.
I realised that Mike’s monomyth talk aligns nicely with my workshop. So I decided to prep my fellow Clearlefties for the workshop with a movie night.
Popcorn was popped, pizza was ordered, and comfy chairs were suitably arranged. Then we watched Mike’s talk. Everyone loved it. Then it was decision time. Which of three films covered in the talk would we watch? We put it to a vote.
It came out as an equal tie between Jurassic Park and The Dark Knight. How would we resolve this? A coin toss!
The toss went to The Dark Knight. In retrospect, a coin toss was a supremely fitting way to decide to watch that film.
It was fun to watch it again, particularly through the lens of Mike’s analyis of its Jungian archetypes.
But I still think the film is about game theory.
The first batch of #PatternsDay videos are up!
https://vimeo.com/showcase/4673650
Featuring @Yaili, @Amy_Hupe, @HeydonWorks, and @ThatEmil.
Brightonians with websites: remember that Homebrew Website Club is happening in the @Clearleft studio from 6pm to 7:30pm this evening.
It’s all fun and games until you realise that everything in here was inspired by actual interfaces out there on the web.
Back from a brilliant Wednesday night session at The Jolly Brewer. Transported by tunes.
Checked in at Jolly Brewer. 🎶 — with Jessica
My hypothesis: these algorithms — driven by the all-consuming need for engagement in order to sell ads — are part of what’s destroying western liberal democracy, and my app will not contribute to that.
A really excellent analysis by Mike of a dark pattern in the Superhuman email app.
That’s right. A running log of every single time you have opened my email, including your location when you opened it. Before we continue, ask yourself if you expect this information to be collected on you and relayed back to your parent, your child, your spouse, your co-worker, a salesperson, an ex, a random stranger, or a stalker every time you read an email.
Exactly! This violates the principle of least surprise. Also, it’s just plain wrong.
Amazingly though, Mike has been getting pushback from guys on Twitter (and it’s always guys) who don’t think this is a big deal.
Anyway, read the whole thing—it’s fair, balanced, and really well written.
This is a very cute offline page. Ali Spittel has written up how it was made too.
Chris describes exactly why I wrote about toast
:
But we should be extra watchful about stuff like this. If any browser goes rogue and just starts shipping stuff, web standards is over. Life for devs gets a lot harder and the web gets a lot worse. The stakes are high. And it’s not going to happen overnight, it’s going to happen with little tiny things like this. Keep that blue beanie on.
Ben shares the secret of SEO. Spoiler: the villain turns out to be Too Much JavaScript. Again.
Time to Interactive (TTI) is the most impactful metric to your performance score.
Therefore, to receive a high PageSpeed score, you will need a speedy TTI measurement.
At a high level, there are two significant factors that hugely influence TTI:
- The amount of JavaScript delivered to the page
- The run time of JavaScript tasks on the main thread
This is good to know! Because of a bug in Google App Engine, Brid.gy won’t work for sites using Brotli compression on HTML.
It seems that some code that I wrote in Going Offline is haunted. It’s the trimCache
function.
First, there was the issue of a typo. Or maybe it’s more of a brainfart than a typo, but either way, there’s a mistake in the syntax that was published in the book.
Now it turns out that there’s also a problem with my logic.
To recap, this is a function that takes two arguments: the name of a cache, and the maximum number of items that cache should hold.
function trimCache(cacheName, maxItems) {
First, we open up the cache:
caches.open(cacheName)
.then( cache => {
Then, we get the items (keys) in that cache:
cache.keys()
.then(keys => {
Now we compare the number of items (keys.length
) to the maximum number of items allowed:
if (keys.length > maxItems) {
If there are too many items, delete the first item in the cache—that should be the oldest item:
cache.delete(keys[0])
And then run the function again:
.then(
trimCache(cacheName, maxItems)
);
A-ha! See the problem?
Neither did I.
It turns out that, even though I’m using then
, the function will be invoked immediately, instead of waiting until the first item has been deleted.
Trys helped me understand what was going on by making a useful analogy. You know when you use setTimeout
, you can’t put a function—complete with parentheses—as the first argument?
window.setTimeout(doSomething(someValue), 1000);
In that example, doSomething(someValue)
will be invoked immediately—not after 1000 milliseconds. Instead, you need to create an anonymous function like this:
window.setTimeout( function() {
doSomething(someValue)
}, 1000);
Well, it’s the same in my trimCache
function. Instead of this:
cache.delete(keys[0])
.then(
trimCache(cacheName, maxItems)
);
I need to do this:
cache.delete(keys[0])
.then( function() {
trimCache(cacheName, maxItems)
});
Or, if you prefer the more modern arrow function syntax:
cache.delete(keys[0])
.then( () => {
trimCache(cacheName, maxItems)
});
Either way, I have to wrap the recursive function call in an anonymous function.
Here’s a gist with the updated trimCache
function.
What’s annoying is that this mistake wasn’t throwing an error. Instead, it was causing a performance problem. I’m using this pattern right here on my own site, and whenever my cache of pages or images gets too big, the trimCaches
function would get called …and then wouldn’t stop running.
I’m very glad that—witht the help of Trys at last week’s Homebrew Website Club Brighton—I was finally able to get to the bottom of this. If you’re using the trimCache
function in your service worker, please update the code accordingly.
Management regrets the error.
Proposal. Yes. That’s accurate.
Soooo …maybe don’t call it a web standard?
It me:
Writing comes naturally to me when I’m expressing myself on my own site, with no outside assignment and no deadline except my own sense of urgency about an idea. It’s easy when I’m crafting a brief text message or tweet. Or a letter to a friend.
But give me a writing assignment and a deadline, and I’m stuck. Paralysis, avoidance, a dissatisfaction with myself and the assignment—all the usual hobgoblins spring immediately to life.
It’s not a “web standard” when it’s unilaterrally shipped by one browser vendor prior to any standards discussion.
(I’m not necessarily saying don’t ship it; but calling it a “web standard” is disengenuous, and where the confusion lies.)
Checked in at The Lord Nelson Inn. The Bombadils — with Jessica
Yes, mostly links (https://adactio.com/links) and notes (https://adactio.com/notes) with some blog posts (https://adactio.com/journal).
Who says the sequels can’t be even better than the original? The second Patterns Day was The Empire Strikes Back, The Godfather Part II, and The Wrath of Khan all rolled into one …but, y’know, with design systems.
If you were there, then you know how good it was. If you weren’t, sorry. Audio of the talks should be available soon though, with video following on.
The talks were superb! I know I’m biased becuase I put the line-up together, but even so, I was blown away by the quality of the talks. There were some big-picture questioning talks, a sequence of nitty-gritty code talks in the middle, and galaxy-brain philosophical thoughts at the end. A perfect mix, in my opinion.
Words cannot express how grateful I am to Alla, Yaili, Amy, Danielle, Heydon, Varya, Una, and Emil. They really gave it their all! Some of them are seasoned speakers, and some of them are new to speaking on stage, but all of them delivered the goods above and beyond what I expected.
Big thanks to my Clearleft compadres for making everything run smoothly: Jason, Amy, Cassie, Chris, Trys, Hana, and especially Sophia for doing all the hard work behind the scenes. Trys took some remarkable photos too. He posted some on Twitter, and some on his site, but there are more to come.
And if you came to Patterns Day 2, thank you very, very much. I really appreciate you being there. I hope you enjoyed it even half as much as I did, because I had a ball!
Once again, thanks to buildit @ wipro digital for sponsoring the pastries and coffee, as well as running a fun giveaway on the day. Many thank to Bulb for sponsoring the forthcoming videos. Thanks again to Drew for recording the audio. And big thanks to Brighton’s own Holler Brewery for very kindly offering every attendee a free drink—the weather (and the beer) was perfect for post-conference discussion!
It was incredibly heartwarming to hear how much people enjoyed the event. I was especially pleased that people were enjoying one another’s company as much as the conference itself. I knew that quite a few people were coming in groups from work, while other people were coming by themselves. I hoped there’d be lots of interaction between attendees, and I’m so, so glad there was!
You’ve all made me very happy.
Thank you to @adactio and @clearleft for an excellent #PatternsDay. 🏆
— dhuntrods (@dhuntrods) June 29, 2019
Had so many great conversations! Thanks as well to everyone that came and listened to us, you’re all the best.
💜
Well done for yet another fantastic event. The calibre of speakers was so high, and it was reassuring to hear they have the same trials, questions and toil with their libraries. So insightful, so entertaining.
— Barry Bloye (@barrybloye) June 29, 2019
Had the most amazing time at the #PatternsDay, catching up with old friends over slightly mad conversations. Huge thanks to @adactio and @clearleft for putting together such warm and welcoming event, and to all the attendees and speakers for making it so special ❤️
— Alla Kholmatova (@craftui) June 29, 2019
Had such an amazing time at yesterday’s #PatternsDay. So many notes and thoughts to process Thank you to all the speakers and the folk at @clearleft for organising it. ♥️
— Charlie Don’t Surf (@sonniesedge) June 29, 2019
Had an awesome time at #PatternsDay yesterday! Some amazing speakers and got to meet some awesome folk along the way! Big thanks to @adactio and @clearleft for organising such a great event!
— Alice Boyd-Leslie (@aboydleslie) June 29, 2019
Absolutely amazing day at #PatternsDay. Well done @adactio and @clearleft. The speakers were great, attendees great and it was fantastic to finally meet some peers face to face. ❤
— Dave (@daveymackintosh) June 28, 2019
Had a blast at #PatternsDay !!! Met so many cool ppl
— trash bandicoot (@freezydorito) June 28, 2019
I’ve had a hell of a good time at #PatternsDay. It’s been nice to finally meet so many folks that I only get to speak to on here.
— Andy Bell (@andybelldesign) June 28, 2019
As expected, the @clearleft folks all did a stellar job of running a great event for us.
Patterns Day is an excellent single-day conference packed full of valuable content about design systems and pattern libraries from experienced practicioners. Way to go @clearleft! 👏🎉 #PatternsDay
— Kimberly Blessing (@obiwankimberly) June 28, 2019
Round of applause to @adactio and @clearleft for a great #patternsday today 👏👏👏
— Dan Donald (@hereinthehive) June 28, 2019
Big thanks to @adactio and @clearleft for a fantastic #PatternsDay. Left with tons of ideas to take back to the shop. pic.twitter.com/GwEtWrxbK8
— Alex 🇪🇺 (@alexandtheweb) June 28, 2019
@adactio thanks Jeremy for organising this fabulous day of inspiring talks in a such a humane format. I enjoyed every minute of it 😊 #patternsday
— David Roessli 🏳️🌈 (@roessli) June 28, 2019
An amazing day was had at #PatternsDay. Caught up with friends I hadn’t seen for a while, made some new ones, and had my brain expand by an excellent set of talks. Big hugs to @adactio and the @clearleft team. Blog post to follow next week, once I’ve got my notes in order.
— Garrett Coakley (@garrettc) June 28, 2019
When people talk about learning React, I think that React, in and of itself, is relatively easy to understand. At least, I felt it was. I have components. I have JSX. I hit some hiccups with required keys or making sure I was wrapping child elements properly. But overall, I felt like I grasped it well enough.
Throw in everything else at the same time, though, and things get confusing because it’s hard at first to recognize what belongs to what. “Oh, this is Redux. That is React. That other thing is lodash. Got it.”
This resonates a lot with Dave’s post:
React is an ecosystem. I feel like it’s a disservice to anyone trying to learn to diminish all that React entails. React shows up on the scene with Babel, Webpack, and JSX (which each have their own learning curve) then quickly branches out into technologies like Redux, React-Router, Immutable.js, Axios, Jest, Next.js, Create-React-App, GraphQL, and whatever weird plugin you need for your app.
At the start of the month, I like to look back at the previous month’s activity on my site. June was a busy month.
A showcase of fun experiments with variable fonts, courtesy of Mandy.
The Decolonial Atlas is a growing collection of maps which, in some way, help us to challenge our relationships with the land, people, and state. It’s based on the premise that cartography is not as objective as we’re made to believe.
For example: Names and Locations of the Top 100 People Killing the Planet — a cartogram showing the location of decision makers in the top 100 climate-hostile companies.
This map is a response to the pervasive myth that we can stop climate change if we just modify our personal behavior and buy more green products. Whether or not we separate our recycling, these corporations will go on trashing the planet unless we stop them.
Some time ago I was going through the backlog of around 90 unread articles on Design Systems. About 80 of those were Medium articles and about 40 of those took me to either their user-hostile “you ready a lot and we like that” pop-up or their money-grabbing “you’ve read lots this month, pay us to read some more.”, it turns out that Medium only likes you reading things when you give money to do so.
Therefore I’ve started to add a little warning notice to each article that’s on Medium.
Rachel makes the case for integrating content design patterns into component libraries:
Instead of content design systems and visual design systems existing in isolation, the ideal is one design system that accommodates everything, marrying the content and design together in the way it will actually be used and experienced.
Behind the scenes of #PatternsDay.
Mackerel sandwich.
District 9 (2009).
Soaking up the sun.
If you ignore the slightly insulting and condescending clickbaity title, this is a handy run-down of eight browser features with good support:
addEventListener()
,scrollTo()
,setTimeout()
and setInterval()
,defaultChecked
property for checkboxes,normalize()
and wholeText
for strings of text,insertAdjacentElement()
and insertAdjacentText()
,event.detail
, andscrollHeight
and scrollWidth
.Brand identity in sci-fi films, like Alien, Total Recall, Robocop, and Back To The Future.
This makes for a nice companion site to Sci-fi Interfaces.