A cornucopia of interactive visualisations. You control the horizontal. You control the vertical. Networks, flocking, emergence, diffusion …it’s all here.
Wednesday, May 22nd, 2019
Tuesday, May 21st, 2019
This is a really great, balanced profile of the Indie Web movement. There’s thoughtful criticism alongside some well-deserved praise:
If we itemize the woes currently afflicting the major platforms, there’s a strong case to be made that the IndieWeb avoids them. When social-media servers aren’t controlled by a small number of massive public companies, the incentive to exploit users diminishes. The homegrown, community-oriented feel of the IndieWeb is superior to the vibe of anxious narcissism that’s degrading existing services.
Tantek’s barnstorming closing talk from Beyond Tellerrand. This is well worth 30 minutes of your time.
Own your domain. Own your content. Own your social connections. Own your reading experience. IndieWeb services, tools, and standards enable you to take back your web.
This is an utterly fascinating interactive description of network effects, complete with Nicky Case style games. Play around with the parameters and suddenly you can see things “going viral”:
We can see similar things taking place in the landscape for ideas and inventions. Often the world isn’t ready for an idea, in which case it may be invented again and again without catching on. At the other extreme, the world may be fully primed for an invention (lots of latent demand), and so as soon as it’s born, it’s adopted by everyone. In-between are ideas that are invented in multiple places and spread locally, but not enough so that any individual version of the idea takes over the whole network all at once. In this latter category we find e.g. agriculture and writing, which were independently invented ~10 and ~3 times respectively.
Play around somewhere and you start to see why cities are where ideas have sex:
What I learned from the simulation above is that there are ideas and cultural practices that can take root and spread in a city that simply can’t spread out in the countryside. (Mathematically can’t.) These are the very same ideas and the very same kinds of people. It’s not that rural folks are e.g. “small-minded”; when exposed to one of these ideas, they’re exactly as likely to adopt it as someone in the city. Rather, it’s that the idea itself can’t go viral in the countryside because there aren’t as many connections along which it can spread.
This really is a wonderful web page! (and it’s licensed under a Creative Commons Zero licence)
We tend to think that if something’s a good idea, it will eventually reach everyone, and if something’s a bad idea, it will fizzle out. And while that’s certainly true at the extremes, in between are a bunch of ideas and practices that can only go viral in certain networks. I find this fascinating.
Monday, April 15th, 2019
New Ways of Seeing considers the impact of digital technologies on the way we see, understand, and interact with the world. Building on John Berger’s seminal Ways of Seeing from 1972, the show explores network infrastructures, digital images, systemic bias, education and the environment, in conversation with a number of contemporary art practitioners.
Monday, April 8th, 2019
An online documentary series featuring interviews with smart people about the changing role of design.
As technology becomes more complex and opaque, how will we as designers understand its potential, do hands-on work, translate it into forms people can understand and use, and lead meaningful conversations with manufacturers and policymakers about its downstream implications? We are entering a new technology landscape shaped by artificial intelligence, advanced robotics and synthetic biology.
So far there’s Kevin Slavin, Molly Wright Steenson, and Alexandra Daisy Ginsberg, with more to come from the likes of Matt Jones, Anab Jain, Dan Hill, and many, many more.
Saturday, March 30th, 2019
These diagrams of early networks feel like manuscripts that you’d half expect to be marked with “Here be dragons” at the edges.
Friday, March 15th, 2019
Saturday, March 9th, 2019
I like Tim’s definition here:
A performance budget is a clearly defined limit on one or more performance metrics that the team agrees not to exceed, and that is used to guide design and development.
And I agree about the four attributes required for a performance budget to succeed. It must be:
The point is not to let the performance budget try to stand on its own, somewhere hidden in company documentation collecting dust. You need to be proactive about making the budget become a part of your everyday work.
Saturday, February 16th, 2019
I linked to this a while back but now this great half hour documentary by Jessica Yu is ready and you can watch the whole thing online: Tim Berners-Lee, the birth of the web, and where the web has gone since.
In the scenes describing the early web, there’s footage of the recreated Line Mode Browser—how cool is that‽
Wednesday, January 9th, 2019
When you stop to consider all the implications of poor performance, it’s hard not to come to the conclusion that poor performance is an ethical issue.
Wednesday, December 19th, 2018
Friday, December 14th, 2018
GitHub - GoogleChromeLabs/quicklink: ⚡️Faster subsequent page-loads by prefetching in-viewport links during idle time
This looks like a very handle little performance-enhancing script: it attempts to prefetch some links, but in a responsible way. It won’t do any prefetching on slow connections or where data saving is enabled, and it only prefetches when the browser is idle.
Saturday, November 10th, 2018
Harry takes a look at the performance implications of loading CSS. To be clear, this is not about the performance of CSS selectors or ordering (which really doesn’t make any difference at this point), but rather it’s about the different ways of getting rid of as much render-blocking CSS as possible.
…a good rule of thumb to remember is that your page will only render as quickly as your slowest stylesheet.
Friday, October 26th, 2018
Service workers and browser extensions
I quite enjoy a good bug hunt. Just yesterday, myself and Cassie were doing some bugfixing together. As always, the first step was to try to reproduce the problem and then isolate it. Which reminds me…
There’ve been a few occasions when I’ve been trying to debug service worker issues. The problem is rarely in reproducing the issue—it’s isolating the cause that can be frustrating. I try changing a bit of code here, and a bit of code there, in an attempt to zero in on the problem, butwith no luck. Before long, I’m tearing my hair out staring at code that appears to have nothing wrong with it.
And that’s when I remember: browser extensions.
I’m currently using Firefox as my browser, and I have extensions installed to stop tracking and surveillance (these technologies are usually referred to as “ad blockers”, but that’s a bit of a misnomer—the issue isn’t with the ads; it’s with the invasive tracking).
If you think about how a service worker does its magic, it’s as if it’s sitting in the browser, waiting to intercept any requests to a particular domain. It’s like the service worker is the first port of call for any requests the browser makes. But then you add a browser extension. The browser extension is also waiting to intercept certain network requests. Now the extension is the first port of call, and the service worker is relegated to be next in line.
This, apparently, can cause issues (presumably depending on how the browser extension has been coded). In some situations, network requests that should work just fine start to fail, executing the
catch clauses of
fetch statements in your service worker.
So if you’ve been trying to debug a service worker issue, and you can’t seem to figure out what the problem might be, it’s not necessarily an issue with your code, or even an issue with the browser.
From now on when I’m troubleshooting service worker quirks, I’m going to introduce a step zero, before I even start reproducing or isolating the bug. I’m going to ask myself, “Are there any browser extensions installed?”
I realise that sounds as basic as asking “Are you sure the computer is switched on?” but there’s nothing wrong with having a checklist of basic questions to ask before moving on to the more complicated task of debugging.
I’m going to make a checklist. Then I’m going to use it …every time.
Tuesday, October 9th, 2018
Great ideas from Addy on where to start with creating a performance budget that can act as a red line you don’t want to cross.
If it’s worth getting fast, it’s worth staying fast.
Friday, September 28th, 2018
Service Workers have such huge potential power, and I feel like we (developers on the web) have barely scratched the surface with what’s possible.
Needless to say, I couldn’t agree more!
Trys is thinking through some of the implicatons of service workers, like how we refresh stale content, and how we deal with slow networks—something that’s actually more of a challenge than dealing with no network connection at all.
There’s some good food for thought here.
I’m so excited to see how we can use Service Workers to improve the web.
Tuesday, August 7th, 2018
This is a heartbreaking observation by Eric. He’s not anti-HTTPS by any stretch, but he is pointing out that caching servers become a thing of the past on a more secure web.
Can we do anything? For users of up-to-date browsers, yes: service workers create a “good” man in the middle that sidesteps the HTTPS problem, so far as I understand. So if you’re serving content over HTTPS, creating a service worker should be one of your top priorities right now, even if it’s just to do straightforward local caching and nothing fancier.
Oh, this is magnificent! A rallying call for everyone designing and developing on the web to avoid making any assumptions about the people we’re building for:
People will use your site how they want, and according to their means. That is wonderful, and why the Web was built.
I would even say that the % of people viewing your site the way you do rapidly approaches zilch.
Thursday, August 2nd, 2018
Smart thinking—similar to this post from last year—about using the
navigator.connection API from a service worker to serve up bandwidth-appropriate images.
This is giving me some ideas for my own site.