Tags: urls

I’ve always liked the idea that your website can be your API. Like, you’ve already got URLs to identify resources, so why not make that URL structure predictable and those resources parsable?

That’s why the (read-only) API for The Session doesn’t live at a separate subdomain. It uses the same URL structure as the regular site, but you can request the resources in an alternative format: JSON, XML, RSS.

This works out pretty well, mostly because I put a lot of thought into the URL structure of the site. I’m something of a URL fetishist, but I think that taking a URL-first approach to information architecture can be a good exercise.

Most of the resources on The Session involve nouns like tunes, events, discussions, and so on. There’s a consistent and predictable structure to the URLs for those sections:

• /things
• /things/new
• /things/search

And then an idividual item can be found at:

• things/ID

That’s all nice and predictable and the naming of the URLs matches what you’d expect to find:

• tunes
• tunes/new
• tunes/search?q=Ireland
• tunes/320

Tunes, events, discussions, sessions. Those are all fine. But there’s one section of the site that has this root URL:

/recordings

When I was coming up with the URL structure twenty years ago, it was clear what you’d find there: track listings for albums of music. No one would’ve expected to find actual recordings of music available to listen to on-demand. The bandwidth constraints and technical limitations of the time made that clear.

Two decades on, the situation has changed. Now someone new to the site might well expect to hit a link called “recordings” and expect to hear actual recordings of music.

So I should probably change the label on the link. I don’t think “albums” is quite right—what even is an album any more? The word “discography” is probably the most appropriate label.

Here’s my dilemma: if I update the label, should I also update the URL structure?

Right now, the section of the site with /tunes URLs is labelled “tunes”. The section of the site with /events URLs is labelled “events”. Currently the section of the site with /recordings URLs is labelled “recordings”, but may soon be labelled “discography”.

If you click on “tunes”, you end up at /tunes. But if you click on “discography”, you end up at /recordings.

Is that okay? Am I the only one that would be bothered by that?

I could update the URLs to match the labelling (with redirects for the old URLs, of course), but I’m not so keen on this URL structure:

• /discography
• /discography/new
• /discography/search
• /discography/ID

It doesn’t seem as tidy as:

• /recordings
• /recordings/new
• /recordings/search
• /recordings/ID

But if I don’t update the URLs to match the label, then I’m just going to have to live with the mismatch.

I’m just thinking out loud here. I think I should definitely update the label. I just won’t make any decision on changing URLs for a while yet.

This is going to make me sound like an old man in his rocking chair on the front porch, but let me tell you about the early days of Twitter…

The first time I mentioned Twitter on here was back in November 2006:

I’ve been playing around with Twitter, a neat little service from the people who brought you Odeo. You send it little text updates via SMS, the website, or Jabber.

A few weeks later, I wrote about some of its emergent properties:

Overall, Twitter is full of trivial little messages that sometimes merge into a coherent conversation before disintegrating again. I like it. Instant messaging is too intrusive. Email takes too much effort. Twittering feels just right for the little things: where I am, what I’m doing, what I’m thinking.

That’s right; back then we didn’t have the verb “tweeting” yet.

In those early days, some of the now-ubiquitous interactions had yet to emerge. Chris hadn’t yet proposed hashtags. And if you wanted to address a message to a specific person—or reply to a tweet of theirs—the @ symbol hadn’t been repurposed for that. There were still few enough people on Twitter that you could just address someone by name and they’d probably see your message.

That’s what I was doing when I posted:

It takes years off you, Simon.

I’m assuming Simon Willison got a haircut or something.

In any case, it’s an innocuous and fairly pointless tweet. And yet, in the intervening years, that tweet has received many replies. Weirdly, most of the replies consisted of one word:

nice

Very puzzling.

Then a little while back, I realised what was happening. This is the URL for my tweet:

twitter.com/adactio/status/69420

69420.

69.

420.

Pesky kids with their stoner sexual-innuendo numerology!

Eleven years ago, I made a prediction:

The original URL for this prediction (www.longbets.org/601) will no longer be available in eleven years.

One year later, Matt called me on it and the prediction officially became a bet:

We’re playing for $1000. If I win, that money goes to the Bletchley Park Trust. If Matt wins, it goes to The Internet Archive.

I’m very happy to lose this bet.

When I made the original prediction eleven years ago that a URL on the longbets.org site would no longer be available, I did so in a spirit of mischief—it was a deliberately meta move. But it was also informed by a genuine feeling of pessimism around the longevity of links on the web. While that pessimism was misplaced in this case, it was informed by data.

The lifetime of a URL on the web remains shockingly short. What I think has changed in the intervening years is that people may have become more accustomed to the situation. People used to say “once something is online it’s there forever!”, which infuriated me because the real problem is the exact opposite: if you put something online, you have to put in real effort to keep it online. After all, we don’t really buy domain names; we just rent them. And if you publish on somebody else’s domain, you’re at their mercy: Geocities, MySpace, Facebook, Medium, Twitter.

These days my view towards the longevity of online content has landed somewhere in the middle of the two dangers. There’s a kind of Murphy’s Law around data online: anything that you hope will stick around will probably disappear and anything that you hope will disappear will probably stick around.

One huge change in the last eleven years that I didn’t anticipate is the migration of websites to HTTPS. The original URL of the prediction used HTTP. I’m glad to see that original URL now redirects to a more secure protocol. Just like most of the World Wide Web. I think we can thank Let’s Encrypt for that. But I think we can also thank Edward Snowden. We are no longer as innocent as we were eleven years ago.

I think if I could tell my past self that most of the web would using HTTPS by 2022, my past self would be very surprised …’though not as surprised at discovering that time travel had also apparently been invented.

The Internet Archive has also been a game-changer for digital preservation. While it’s less than ideal that something isn’t reachable at its original URL, knowing that there’s probably a copy of the content at archive.org lessens the sting considerably. I couldn’t be happier that this fine institution is the recipient of the stakes of this bet.

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…

Apollo 8

• Earthrise by Emmanuel Vaughan-Lee on Vimeo, 2018.
• Earthrise by Amanda Gorman on YouTube, 2018.
• They Saw Earth From Space. Here’s How It Changed Them by Nadia Drake in National Geographic, 2018.
• Seeing the Whole Earth from Space Changed Everything by Ahmed Kabil for The Long Now Foundation, 2018.

Hypertext

• As We May Think by Vannevar Bush in The Atlantic Monthly, 1945.
• The Demo by Douglas Engelbart, 1968.
• Information Management: A Proposal by Tim Berners-Lee, 1989.

The World Wide Web

• proposed new tag: IMG by Marc Andreessen to www-talk, 1993.
• What is a Polyfill? by Remy Sharp, 2010.
• Stop solving problems you don’t yet have by Rachel Andrew, 2012.
• Re: More granularity for font-weight? by Håkon Wium Lie to www-style, 2015.
• Clean advertising on adactio.com, 2020.
• 2021 Predictions for UX and Front-End Experts (PDF) by Ire Aderinokun et al. for An Event Apart, 2021.

NASA

• Poppy Northcutt: The Woman Who Took Us to the Stars by Apriya Rai, 2020.
• Katherine Johnson Biography by Margot Lee Shetterly, 2020.
• Margaret Hamilton interview by Zoë Corbyn in The Guardian, 2019.

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.

References

• Page Weight Matters by Chris Zacharias
• Systems, Mistakes, and the Sea by Robin Rendle
• Patterns Day videos on Vimeo
• Workplace Topology by Danielle Huntrods
• The Design Squiggle by Damien Newman
• The Double Diamond by Design Council
• Canvassing a project by Andy Thornton
• How to run a premortem workshop by Rachel McConnell
• 5 Steps To Better Research by Benjamin Parry
• Design Principles collection
• Design Principles collection by Ben Brignell
• What makes a good design principle? by Matthew Ström
• Priority of Constituencies from HTML Design Principles
• The Eponymous Laws of Tech by Dave Rupert
• Principles of Design by Sir Tim Berners-Lee
• CERN 2019 WorldWideWeb Rebuild
• Data attributes and progressive enhancement by Derek Featherstone
• Government Design Principles by Government Digital Service
• Over-engineering is under-engineering by Baldur Bjarnason
• This Web App Best Viewed By Someone Else presentation by Eric Meyer on YouTube

adactio.com

• The top four web performance challenges
• Principle
• Ubiquity and consistency
• Principles and priorities
• Putting design principles into action

Wikipedia

• Survivorship bias
• Hanlon’s razor
• Occam’s razor
• Robustness principle
• Rule of least power
• Hofstadter’s law
• Sturgeon’s law
• Murphy’s law
• Atwood’s law
• Cole’s law

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.

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:

• example.com
• example.github.io
• github.example.com

Whereas Firefox displays them as:

• example.com
• example.github.io
• github.example.com

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 https change.

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.