When I was in Amsterdam I was really impressed with the code that Rose was writing and I encouraged her to share it. Here it is: drop this script into a web page with a form to have its values automatically saved into local storage (and automatically loaded into the form if something goes wrong before the form is submitted).
You are viewing a humanly curated list of fine personal & independent email newsletters that are updated regularly. No algorithms ever!
And remember: you can subscribe to most newsletters via RSS rather than email.
I might just be pattern-matching, but I recognise myself in what Robin describes here:
No one can explain what you do. Let’s face it, you don’t do a great job explaining it either. People come to you for advice on issues that they introduce with “I’m not entirely sure how to describe this problem or what exactly I’m looking to do here, but…” Your colleagues and your communities genuinely value your contributions even as they remain entirely mystified by the exact contour of your position.
If you’ve made a computer do something - anything - in a logical fashion, you’re a programmer. Scratch? Programmer! CSS? Programmer? Conditional formatting in Excel? Programmer!
Twitter is a chatroom, and the problem that Twitter really solved was the discoverability problem. The internet is a big place, and it is shockingly hard to otherwise find people whose thoughts you want to read more of, whether those thoughts are tweets, articles, or research papers. The thing is, I’m not really sure that Twitter ever realized that this is the problem they solved, that this is where their core value lies. Twitter kept experimenting with algorithms and site layouts and Moments and other features to try to foist more discoverability onto the users without realizing that their users were discovering with the platform quite adeptly already. Twitter kept trying to amplify the signal without understanding that what users needed was better tools to cut down the noise.
Twitter, like many technology companies, fell into the classical trap by thinking that they, the technologists, were the innovators. Technologists today are almost never innovators, but rather plumbers who build pipelines to move ideas in the form of data back and forth with varying efficacy. Users are innovators, and its users that made Twitter unique.
A handsome web book that’s a collection of thoughtful articles on technology, culture, and society by Jasmine Wang, Saffron Huang, and other young technologists:
Letters to a Young Technologist is a collection of essays addressed to young technologists, written by a group of young technologists.
After writing about a declarative Web Share API here yesterday I thought I’d better share the idea (see what I did there?).
I opened an issue on the Github repo for the spec.
(I hope that’s the right place for this proposal. I know that in the past ideas were kicked around on the Discourse site for Web platform Incubator Community Group but I can’t stand Discourse. It literally requires JavaScript to render anything to the screen even though the entire content is text. If it turns out that that is the place I should’ve posted, I guess I’ll hold my nose and do it using the most over-engineered reinvention of the browser I’ve ever seen. But I believe that the plan is for WICG to migrate proposals to Github anyway.)
I also realised that, as the JavaScript Web Share API already exists, I can use it to polyfill my suggestion for:
<button type="share">
The polyfill also demonstrates how feature detection could work. Here’s the code.
This polyfill takes an Inception approach to feature detection. There are three nested levels:
button type="share". Great! Don’t do anything. Otherwise proceed to level two.mailto: link to prefill an email with the page title as the subject and the URL in the body. Ya basic!The idea is that, as long as you include the 20 lines of polyfill code, you could start using button type="share" in your pages today.
I’ve made a test page on Codepen. I’m just using plain text in the button but you could use a nice image or SVG or combination. You can use the Codepen test page to observe two of the three possible behaviours browsers could exhibit:
button type="share". Currently that’s none because I literally made this shit up yesterday.button type="share" nor the existing JavaScript Web Share API. This is Firefox and Chrome on desktop (and Edge if you’re on a Mac).See the Pen Polyfill for button type=”share" by Jeremy Keith (@adactio) on CodePen.
The polyfill doesn’t support Internet Explorer 11 or lower because it uses the DOM closest() method. Feel free to fork and rewrite if you need to support old IE.
I’ve signed this letter.
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.
This is an interesting tool: mess around with styles on any site inside Chrome’s dev tools, and then hit a button to have the updated styles saved to a URL (a Gist on Github).
In chapter two of Going Offline, I talk about registering your service worker wrapped up in some feature detection:
<script>
if (navigator.serviceWorker) {
navigator.serviceWorker.register('/serviceworker.js');
}
</script>
But I also make reference to a declarative way of doing this that isn’t very widely supported:
<link rel="serviceworker" href="/serviceworker.js">
No need for feature detection there. Thanks to the liberal error-handling model of HTML (and CSS), browsers will just ignore what they don’t understand, which isn’t the case with JavaScript.
Alas, it looks like that nice declarative alternative isn’t going to be making its way into browsers anytime soon. It has been removed from the HTML spec. That’s a shame. I have a preference for declarative solutions where possible—they’re certainly easier to teach. But in this case, the JavaScript alternative isn’t too onerous.
So if you’re reading Going Offline, when you get to the bit about someday using the rel value, you can cast a wistful gaze into the distance, or shed a tiny tear for what might have been …and then put it out of your mind and carry on reading.
I really, really like service workers. They’re one of those technologies that have such clear benefits to users that it seems like a no-brainer to add a service worker to just about any website.
The thing is, every website is different. So the service worker strategy for every website needs to be different too.
Still, I was wondering if it would be possible to create a service worker script that would work for most websites. Here’s the script I came up with.
The logic works like this:
So HTML files are served network-first, while all other files are served cache-first, but in both cases a fresh copy is always put in the cache. The idea is that HTML content will always be fresh (unless there’s a problem with the network), while all other content—images, style sheets, scripts—might be slightly stale, but get refreshed with every request.
My original attempt was riddled with errors. Jake came to my rescue and we revised the script into something that actually worked. In the process, my misunderstanding of how await works led Jake to write a great blog post on await vs return vs return await.
I got there in the end and the script seems solid enough. It’s a fairly simplistic strategy that could work for quite a few sites, but it has some issues…
Service workers don’t perform any automatic cleanup of caches—that’s up to you to do (usually during the activate event). This script doesn’t do any cleanup so the cache might grow and grow and grow. For that reason, I think the script is best suited for fairly small sites.
The strategy also assumes that a file will either be fetched from the network or the cache. There’s no contingency for when both attempts fail. So there’s no fallback offline page, for example.
I decided to test it in the wild, but I expanded it slightly to fix the fallback issue. The version on the Ampersand 2018 website includes a worst-case-scenario option to show a custom offline page that has been pre-cached. (By the way, if you haven’t got a ticket for Ampersand yet, get a ticket now—it’s going to be superb day of web typography nerdery.)
Anyway, this fairly basic script seems to be delivering some good performance improvements. If you’ve got a site that you think would benefit from this network/caching strategy, and it’s served over HTTPS, then:
serviceworker.js,script element at the bottom of your HTML pages:
if (navigator.serviceWorker && !navigator.serviceWorker.controller) {
navigator.serviceWorker.register('/serviceworker.js');
}
You can also use the script as a starting point. You might find issues specific to your particular website. That’s okay—you can tweak and adjust the script to suit your needs.
If this minimal service worker script proves in any way useful to you, thank Jake.
An up-to-date list of Brighton design and dev meet-ups. There’s quite a few!
Hmm …seems like I should probably wait for the load event before triggering navigator.serviceworker.register().
Ooh, this is a tricky scenario. If you decide to redirect all URLs (from, say, a www subdomain to no subdomain) and you have a service worker running, you’re going to have a bad time. But there’s a solution here to get the service worker to remove itself.
The server-side specifics are for NGINX but this is also doable with Apache.
Toilet paper, barbed wire, shipping containers, and replicants.
The life cycle of a Service Worker—with all its events and states—is the one bit that I’ve never paid that much attention to. My eyes just glaze over when it comes to installation, registration, and activation. But this post explains the whole process really clearly. Now it’s starting to make sense to me.
Something to remember the next time someone describes an experience as “seamless” and means it to be positive:
This is the Amazon move: absolute obfuscation of labor and logistics behind a friendly buy button. The experience for a Sprig customer is super convenient, almost magical; the experience for a chef or courier…? We don’t know. We don’t get to know. We’re just here to press the button.
I feel bad, truly, for Amazon and Sprig and their many peers—SpoonRocket, Postmates, Munchery, and the rest. They build these complicated systems and then they have to hide them, because the way they treat humans is at best mildly depressing and at worst burn-it-down dystopian.
What would it be like if you didn’t have to hide the system?
Tim Maughan reports on the same container ship trip that Dan W. is sending his postcards from.
I like the idea of there being an Apollo-sized project all around us, if you just know where to look.
First, towering above and over the ship, are the loading cranes. Vast structures mounted on huge, four-legged frames, they resemble the naked scaffolding of unbuilt skyscrapers, and trigger nostalgic reminders of Saturn V rocket launch towers from the 1960s.
Once in port at night I saw one suddenly fire into life next to the ship in a stroboscopic explosion of lights, before it tracked slowly above my high vantage point, bathing me in the orange glow of a dozen small halogen suns.