Here’s a nifty little service from Zach: pass in a URL and it returns an image of the site’s icon.
Think of it as the indie web alternative to showing Twitter avatars.
An Event Apart Spring Summit is happening right now. I opened the show yesterday with a talk called The State Of The Web:
The World Wide Web has come a long way in its three decades of existence. There’s so much we can do now with HTML, CSS, and JavaScript: animation, layout, powerful APIs… we can even make websites that work offline! And yet the web isn’t exactly looking rosy right now. The problems we face aren’t technical in nature. We’re facing a crisis of expectations: we’ve convinced people that the web is slow, buggy, and inaccessible. But it doesn’t have to be this way. There is no fate but what we make. In this perspective-setting talk, we’ll go on a journey to the past, present, and future of web design and development. You’ll laugh, you’ll cry, and by the end, you’ll be ready to make the web better.
I wrote about preparing this talk and you can see the outline on Kinopio. I thought it turned out well, but I never actually know until people see it. So I’m very gratified and relieved that it went down very well indeed. Phew!
Eric and the gang at An Event Apart asked for a round-up of links related to this talk and I was more than happy to oblige. I’ve separated them into some of the same categories that the talk covers.
I know that these look like a completely disconnected grab-bag of concepts—you’d have to see the talk to get the connections. But even without context, these are some rabbit holes you can dive down…
I got a text this morning at 9:40am. It was from the National Health Service, NHS. It said:
You are now eligible for your free NHS coronavirus vaccination. Please book online at https://www.nhs.uk/covid-vaccination or by calling 119. You will need to provide your name, date of birth and postcode. Your phone number has been obtained from your GP records.
Well, it looks like I timed turning fifty just right!
I typed that URL in on my laptop. It redirected to a somewhat longer URL. There’s a very clear call-to-action to “Book or manage your coronavirus vaccination.” On that page there’s very clear copy about who qualifies for vaccination. I clicked on the “Book my appointments” button.
From there, it’s a sequence of short forms, clearly labelled. Semantic accessible HTML, some CSS, and nothing more. If your browser doesn’t support JavaScript (or you’ve disabled it for privacy reasons), that won’t make any difference to your experience. This is the design system in action and it’s an absolute pleasure to experience.
I consider myself relatively tech-savvy so I’m probably not the best judge of the complexity of the booking system, but it certainly seemed to be as simple as possible (but no simpler). It feels like the principle of least power in action.
SMS to HTML (with a URL as the connective tissue between the two). And if those technologies aren’t available, there’s still a telephone number, and finally, a letter by post.
This experience reminded me of where the web really excels. It felt a bit like the web-driven outdoor dining I enjoyed last summer:
Telling people “You have to go to this website” …that seems reasonable. But telling people “You have to download this app” …that’s too much friction.
A native app would’ve been complete overkill. That may sound obvious, but it’s surprising how often the overkill option is the default.
Give me a URL—either by SMS or QR code or written down—and make sure that when I arrive at that URL, the barrier to entry is as low as possible.
Maybe I’ll never need to visit that URL again. In the case of the NHS, I hope I won’t need to visit again. I just need to get in, accomplish my task, and get out again. This is where the World Wide Web shines.
In five days time, I will get my first vaccine jab. I’m very thankful. Thank you to the NHS. Thank you to everyone who helped build the booking process. It’s beautiful.
The Long Now Foundation is dedicated to long-term thinking. I’ve been a member for quite a few years now …which, in the grand scheme of things, is not very long at all.
One of their projects is Long Bets. It sets out to tackle the problem that “there’s no tax on bullshit.” Here’s how it works: you make a prediction about something that will (or won’t happen) by a particular date. So far, so typical thought leadery. But then someone else can challenge your prediction. And here’s the crucial bit: you’ve both got to place your monies where your mouths are.
Ten years ago, I made a prediction on the Long Bets website. It’s kind of meta:
The original URL for this prediction (www.longbets.org/601) will no longer be available in eleven years.
I made the prediction on February 22nd, 2011 when my mind was preoccupied with digital preservation.
One year later I was on stage in Wellington, New Zealand, giving a talk called Of Time And The Network. I mentioned my prediction in the talk and said:
If anybody would like to take me up on that bet, you can put your money down.
Matt was also speaking at Webstock. When he gave his talk, he officially accepted my challenge.
So now it’s a bet. We both put $500 into the pot. If I win, the Bletchly Park Trust gets that money. If Matt wins, the money goes to The Internet Archive.
As I said in my original prediction:
I would love to be proven wrong.
That was ten years ago today. There’s just one more year to go until the pleasingly alliterative date of 2022-02-22 …or as the Long Now Foundation would write it, 02022-02-22 (gotta avoid that Y10K bug).
It is looking more and more likely that I will lose this bet. This pleases me.
I’m speaking today at an online edition of An Event Apart called Front-End Focus. I’ll be opening up the show with a talk called Design Principles For The Web, which ironically doesn’t have much of a front-end focus:
Designing and developing on the web can feel like a never-ending crusade against the unknown. Design principles are one way of unifying your team to better fight this battle. But as well as the design principles specific to your product or service, there are core principles underpinning the very fabric of the World Wide Web itself. Together, we’ll dive into applying these design principles to build websites that are resilient, performant, accessible, and beautiful.
That explains why I’ve been writing so much about design principles …well, that and the fact that I’m mildly obsessed with them.
To avoid technical difficulties, I’ve pre-recorded the talk. So while that’s playing, I’ll be spamming the accompanying chat window with related links. Then I’ll do a live Q&A.
Should you be interested in the links that I’ll be bombarding the attendees with, I’ve gathered them here in one place (and they’re also on the website of An Event Apart). The narrative structure of the talk might not be clear from scanning down a list of links, but there’s some good stuff here that you can dive into if you want to know what the inside of my head is like.
Back in February, I wrote about an excellent proposal by Jake for how browsers could display URLs in a safer way. Crucially, this involved highlighting the important part of the URL, but didn’t involve hiding any part. It’s a really elegant solution.
Turns out it was a Trojan horse. Chrome are now running an experiment where they will do the exact opposite: they will hide parts of the URL instead of highlighting the important part.
You can change this behaviour if you’re in the less than 1% of people who ever change default settings in browsers.
I’m really disappointed to see that Jake’s proposal isn’t going to be implemented. It was a much, much better solution.
No doubt I will hear rejoinders that the “solution” that Chrome is experimenting with is pretty similar to what Jake proposed. Nothing could be further from the truth. Jake’s solution empowered users with knowledge without taking anything away. What Chrome will be doing is the opposite of that, infantalising users and making decisions for them “for their own good.”
Seeing a complete URL is going to become a power-user feature, like View Source or user style sheets.
I’m really sad about that because, as Jake’s proposal demonstrates, it doesn’t have to be that way.
Personal website owners – what do you think about collecting all of the feeds you are producing in one way or the other on a
/feedspage?
Sounds like a good idea! I’ll get on that.
Everything you ever wanted to know about window.location in JavaScript, clearly explained.
This is a wonderful deep dive into all the parts of a URL:
scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]
There’s a lot of great DNS stuff about the host part:
Root DNS servers operate in safes, inside locked cages. A clock sits on the safe to ensure the camera feed hasn’t been looped. Particularily given how slow DNSSEC implementation has been, an attack on one of those servers could allow an attacker to redirect all of the Internet traffic for a portion of Internet users. This, of course, makes for the most fantastic heist movie to have never been made.
Last month I wrote some musings on default browser behaviours. When it comes to all the tasks that browsers do for us, the most fundamental is taking a URL, fetching its contents and giving us the results. As part of that process, browsers also show us the URL of the page currently loaded in a tab or window.
But even at this fundamental level, there are some differences from browser to browser.
Safari only shows you the domain name—and any subdomain names—by default. It looks like nice and tidy, but it obfuscates what page you’re on (until you click on the domain name). This is bad.
Chrome shows you the full URL, nice and straightforward. This is neutral.
Firefox, like Chrome, shows you the full URL, but with a subtle difference. The important part of the URL—usually the domain name—is subtly highlighted in a darker shade of grey. This is good.
The reason I say that what it highlights is usually the domain name is because what it actually highlights is eTLD+1.
The what now?
Well, if you’re looking at a page on adactio.com, that’s the important bit. But what if you’re looking at a page on adactio.github.io? The domain name is important, but so is the subdomain.
It turns out there’s a list out there of which sites and top level domains allow registrations like this. This is the list that Firefox is using for its shading behaviour in displaying URLs.
Safari, by the way, does not use this list. These URLs are displayed identically in Safari, the phisherman’s friend:
Whereas Firefox displays them as:
I learned all this from Jake on a recent edition of HTTP 203. Nicolas Hoizey has writen a nice little summary.
Jake acknowledges that what Apple is doing is shi… suboptimal, what Firefox is doing is good, and then puts forward an idea for what Chrome could do. (But please note that this is Jake’s personal opinion; not an official proposal from the Chrome team.)
There’s some prior art here. It used to be that, if your SSL certificate included extended validation, the name would be shown in green next to the padlock symbol. So while my website—which uses regular SSL from Let’s Encrypt—would just have a padlock, Medium—which uses EV SSL—would have a padlock and the text “A Medium Corporation”.
Extended validation wasn’t quite the bulletproof verification it was cracked up to be. So browsers don’t use that interface pattern any more.
Jake suggests repurposing this pattern for all URLs. Pull out the important bit—eTLD+1—and show it next to the padlock.
I like this. The full URL is still displayed. This proposal is more of an incremental change. An enhancement that is applied progressively, if you will.
I also like that it builds on existing interface patterns—Firefox’s URL treatment and the deprecated treatment of EV certs. In fact, I think the first step for Chrome should be to match Firefox’s current behaviour, and then go further with something like Jake’s proposal.
This kind of gradual change was exactly what Chrome did with displaying https and http domains.
Jake mentions this in the video
We’ve already seen that you have to take small steps here, like we did with the
httpschange.
There’s a fascinating episode of the Freakonomics podcast called In Praise of Incrementalism. I’ve huffduffed it.
I’m a great believer in the HTML design principle, Evolution Not Revolution:
It is better to evolve an existing design rather than throwing it away.
I’d love to see Chrome take the first steps to Jake’s proposal by following Firefox’s lead.
Then again, I’d love it if Chrome followed Firefox’s lead in implementing subgrid.
I feel there is something beyond the technological that is the real trick to a site that lasts: you need to have some stake in the game. You don’t let your URLs die because you don’t want them to. They matter to you. You’ll tend to them if you have to. They benefit you in some way, so you’re incentivized to keep them around. That’s what makes a page last.
It looks (a more complex version of) fragmention might be coming to Chrome.
This is my kind of URL nerdery. Remy ponders all the permutations of URLs ending with slashes, ending without slashes, ending with with a file extension…
A fellow URL fetishest!
I love me a well-designed URL scheme—here’s four interesting approaches.
URLs are consumed by machines, but they should be designed for humans. If your URL thinking stops at “uniquely identifies a page” and “good for SEO”, you’re missing out.
URLs are the single greatest feature of the web.
The latest version of Chrome is removing seams by messing with the display of the URL.
This is a bug.
My reaction to that somewhat sensentionalist Wired article was much the same as Charlie’s—seeing it on the same day at the latest AMP sneakiness has me worried.
The hiding of URLs fits perfectly with AMPs preferred method of making sites fast, which is to host them directly on Google’s servers, and to serve them from a Google domain. Hiding the URL from the user then makes a Google AMP site indistinguishable from an ordinary site.
As well as sharing Charlie’s concern, I also share her hope:
I really hope that the people who are part of Google can stop something awful like this from happening.
Change will be controversial whatever form it takes. But it’s important we do something, because everyone is unsatisfied by URLs. They kind of suck.
Citation very fucking needed.
I’m trying very hard to give Google the benefit of the doubt here, but coming as it does on top of all the AMP shit they’re pulling, it sure seems like Google are trying to remake the web in their image.
Oh, and if you want to talk about URLs confusing people, AMP is a great example.
I know many people love Medium’s editing interface, but I just can’t believe that so many writers and publications have turned toward a single centralized commercial entity as a proposed solution to what ails the publishing industry. There is tremendous strength in independence and decentralization.
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).