An example of a not-so-great URL design: Amazon product links have an optional slug before everything else like `{slug}/dp/{id}`. So you end up copying a gigantic URL everytime you wish to share a product unless you use the share product button to get the shortened link.
> So you end up copying a gigantic URL everytime you wish to share a product
Yeah, when I used Amazon I found this incredibly annoying. When I wanted to share a link, I'd have to spend a few minutes figuring out how much of that stuff I could remove and testing the resulting URL before sharing it. A relatively minor irritation, but an irritation nonetheless.
Note, if you are using optional slugs or otherwise, you should have a canonical url in the header so that search results will be collated to a single canonical url.
I think this is actually a really great design in that the name of the product can always be in the URL. The "slug" is completely ignored and just there for SEO/humans. If you send a link I instantly know what it's for -- that's pretty useful! I also like that the "id" which is an ASIN (Amazon Standard Identification Number) which is a superset of all ISBNs. This means you can just enter any book ISBN directly into t…
While the slug helps someone know what they're opening before reading it, most apps have link previews which give you just enough information you need.
I dont know if I'm in the minority but I really dislike link previews the vast majority of the time. They take up too much space and offer to little value. In discord I often x out of the preview and I know lots of others who do too.
Maybe on some sites it's fine but I feel like link previews need more modularity on size or something. Perbaps even configurable both host and client
I guess this reflects a view of blogging that maybe is more what people today would use twitter or mastodon for, with lots of blogposts with the same title like "open thread" or "links for sunday". Today people mostly use blogs to publish essays, and then a slug based on the title should be sufficient, since you're not going to publish two essays with the same title. That's what substack uses.
I think the date is still extremely valuable. Knowing whether something is from last month or a decade ago makes a huge difference. It's also useful so that URL's can be sorted by date. Also, "you're not going to publish two essays with the same title" feels false. If you write 1,000 pieces and use short titles and tend to write about the same subjects, it feels extremely likely that you'll wind up repeating titles.
I agree, but I think it's important to note that the date in the URL can also be misleading. For example, it's often assigned at time of creation. If that page or post gets updated years later, even if almost entirely rewritten, it still has the original date in the URL
Back when I was working on GOV.UK Verify we had URLs that looked something like /verify-passport for English and /cy/verify-passport for Welsh. I made the decision that if readable URLs was a design goal they should be readable in both languages, and ended up localising them all to (for example) /verify-passport and /gwirio-pasbort. No idea if anyone ever noticed, but sometimes it’s nice to sweat the small stuff.
I really like this - because technology is for everyone but can end up being harder to use because of design decisions. Thanks for sharing this.
He calls file extensions cruft, but i've come to value them. They are a simple way to indicate file type - desired or offered - which is easily understood by machines and people. I currently work with an API which does a bit of content negotiation using the Accept header, so clients can request data in various formats - application/json for a snapshot, text/event-stream for an updating feed, or text/html for an inter…
That's fine (and already common) for images, JSON, etc. But nobody wants webpage URL's that randomly end in .php, .htm, .html, .aspx, and so forth. That's just noise that is both gibberish and entirely irrelevant to the user.
.htm and .html is relevant just like .pdf and .zip etc etc
But I agree about .php, .aspx and other extensions that are telling something about the server side. That’s irrelevant for the user.
I found Notion's URL schema interesting as well. They have to contend with renames of pages, reorganisation of the hierarchy and all that. So they have something like: notion.so/:account/Current-Name-of-Page-:pageid where the name changes if the page is renamed, but the redirect works, as the page ID is unchanged. In fact, one can just use notion.so/:account/:pageid and gets redirected to the right page, or even noti…
I don't understand why the :pageid needs to be prefixed with anything here.
It’s for SEO. Perhaps it’s a historical concern and no longer relevant, but the URL is/was used by Google to understand what the page is about.
I don't understand why the :pageid needs to be prefixed with anything here.
its for humans I would expect, to know what the page refers to without opening it. Kinda smart. Also; taking it from the end means you only need to parse the string as an offset from the end. It can make load balancing much faster in theory.
It's also for crawlers. When doing technical SEO, having a human readable slug in the URL is low hanging fruit that is often overlooked. This, as well as having a structure of `CURRENT_CONTENT_TITLE | WEBSITE_NAME` are things that are quite trivial to implement and provide a significant uplift in both SEO and UX.
I guess this reflects a view of blogging that maybe is more what people today would use twitter or mastodon for, with lots of blogposts with the same title like "open thread" or "links for sunday". Today people mostly use blogs to publish essays, and then a slug based on the title should be sufficient, since you're not going to publish two essays with the same title. That's what substack uses.
I think the date is still extremely valuable. Knowing whether something is from last month or a decade ago makes a huge difference. It's also useful so that URL's can be sorted by date. Also, "you're not going to publish two essays with the same title" feels false. If you write 1,000 pieces and use short titles and tend to write about the same subjects, it feels extremely likely that you'll wind up repeating titles.
And it's sad how often one needs to use the URL to find the date, since many authors just don't put it on the page (corporate sites are particularly scared of dating their stuff)
Others seem to think just day and month is fine, as if the year isn't the most significant part. And if both numbers are <=12 then you have to go and find out what locale the author formats their dates in...