Aggregates

Evidence: High: 0 Medium: 2 Low: 0 No Data: 29

Theme Radar

Tepix 2026-02-23 07:54 UTC link

Concise URLs deserve more praise.

Also, when you look at a site and see URLs like /wiki/index.php/MyPage it tells you about the skill level and care of the site administrators.

akares 2026-02-23 13:53 UTC link

However, getting rid of the /photos prefix would be a terrible improvement.

Having the /{username} at the root of the routing logic means that every URL should either query the user database for a match or use /{username} as a catch-all fallback if no other patterns match. But this makes resolving real 404 pages much more expensive.

outofmyshed 2026-02-24 07:23 UTC link

The shift from URLs accessing resources on file systems to more abstract resources (implicitly HTML unless the headers said otherwise) occurred around 1999/2000. Suddenly we were all doing it once we’d figured out the necessary Apache directives. It wasn’t just Flickr, although it and its APIs were a good example of clean URL design

socalgal2 2026-02-24 07:45 UTC link

> I would also try to add a human-readable slug at the end, because…

No? Because what would it be based on and if you edited the thing that it's based on then the URL would either change, or get out of sync which woudl suck. You could ignore the suffix meaning flickr.com/mwichary/sets/72177720330077904-<everything-past-the-previous-dash-is-ignored> I'm not sure if that would be a positive, although I guess S.O. does something like that. The issue is other sites really want to know if it's a link to the same resource or a different resource. And while you could redirect to the new one that just makes more work for everyone.

> I would get rid of /photos

I wouldn't because then you'd had have https://flickr.com/settings but that would not be a user named "settings" and the same for every other alternate purpose URL

sixeyes 2026-02-24 07:54 UTC link

oh yeah i remember as a kid into webdev and php how some sites would have these CLEAN urls. seemed like magic to me.

KomoD 2026-02-24 07:56 UTC link

> Alternatively, I would consider getting rid of numerical ids altogether and relying on name alone. Internet Archive does it at e.g. archive.org/details/leroy-lettering-sets, but that has some serious limitations that are not hard to imagine

They don't rely on title alone, it's a separate identifier. You can set it to anything and you can't change it afterwards but you can change the title.

steerpike 2026-02-24 08:26 UTC link

Flickr deserves a lot of praise for a number of technical advances that I wish had seen wider adoption. Their API was one of the first and honestly still one of the most enjoyable to actually use as a developer. It's still full of incredibly interesting API calls that you wouldn't expect from it unless you read carefully. Did you know, for example, that flickr API will provide you with the bounding box co-ordinates of different types of places? From a neighbourhood all the way up to a continent?

They implemented the Where On Earth ID (WOEID) which was a super useful way of disambiguating different places that shared latitude and longitude (for example, being able to disambiguate the Sydney Opera House, Circular Quay and Sydney Harbour which all can potentially share the same lat/long co-ords).

They implemented machine tags which are tags in the form of -

namespace:predicate=value

Which, when it was implemented by other sites with machine tags allowed you to get and group all kinds of interesting combinations of content.

Yeah, honestly flickr had some incredible tech the was so much fun to explore and use. That their vision of what the web could be wasn't the one that won is one of the great losses of the web IMO.

amadeuspagel 2026-02-24 08:30 UTC link

> (Alternatively, I would consider getting rid of numerical ids altogether and relying on name alone. Internet Archive does it at e.g. archive.org/details/leroy-lettering-sets, but that has some serious limitations that are not hard to imagine.)

I could try to imagine these limitations and how the Internet Archive overcomes them, but I'd prefer reading about it.

NKosmatos 2026-02-24 09:59 UTC link

I agree 100% with the author, clean, easily readable and well structured URLs make the web a better place. URL is a hierarchical structure as introduced in the RFC1738 by a guy you might have heard, Tim Berners-Lee, the inventor of the World Wide Web :-) https://www.rfc-editor.org/rfc/rfc1738

Easily readable URLs is something I learned in the 90s and I still try to enforce in everything I create.

benterix 2026-02-24 10:04 UTC link

Unfortunately things are going in the opposite direction with media platforms creating an encoded blob impossible to edit by hand so that you (or a tool) cannot strip tracking etc.

nkrisc 2026-02-24 10:13 UTC link

Isn’t the /photos kind of necessary since usernames are UGC? What if a username is “about” or “contact”?

I would be very confused if flickr.com/contact went to a user page.

DonHopkins 2026-02-24 10:59 UTC link

Aww, they finally depreciated the .gne file extension? It was supposed to never end!

https://gamicus.fandom.com/wiki/Game_Neverending

antonyh 2026-02-24 11:23 UTC link

Flickr was a hero, then yahoo/smugmug killed it. It's still there, but along the way all changes reduced it to an also-ran. It's still a nice tool, but I just don't see myself using it again. The URL scheme, as neat as it was, I never noticed or cared to hack at. I just wanted to upload photos.

TrackerFF 2026-02-24 12:00 UTC link

I don't know how much Flickr is used these days, but I remember it was quite popular some 15 years ago. I decided to search around, and discovered that it is a treasure trove of photos from the period 2005 - 2015, and incredibly easy to search / filter.

Internet archeology is something I've always found fascinating, and I don't think people realize how much data has been lost after we moved to the modern "big tech" internet of today. So many data hosting services disappear back in the mid/late 00s, and with that, the data too. After social media exploded, many just stared storing all their photos there.

tenpa0000 2026-02-24 13:20 UTC link

The flip side is enumerable IDs. Back when I was scraping a site for a side project, sequential photo IDs were basically a free sitemap. YouTube's random-ish IDs aren't just branding — they at least make bulk harvesting annoying.

thesuitonym 2026-02-24 15:06 UTC link

I thought Photobucket did it better, with the exception of having to know which server an individual's bucket was on.

It's been a long while, but if I recall, the url schema was something like a00.photobucket.com/albums/username/someimage.jpg

But what was really cool about it was that you could change someimage.jpg to someimage.png and Photobucket would serve a PNG instead. Or you could change someimage.jpg to th_someimage.jpg and Photobucket would serve a thumbnail of the picture. It was very cool.

briandoll 2026-02-24 17:08 UTC link

Good post on URL design (GitHub design team): https://warpspire.com/posts/url-design/

pwdisswordfishy 2026-02-24 17:24 UTC link

What's so special about "https:"?

wackget 2026-02-24 17:35 UTC link

Strange, because I always remember Flickr having horrible UX. You could never just open an image file directly; if you tried, Flickr would always redirect you to a page which obscured the image behind an invisible layer which obscured pointer events such as right-click.

I learned quickly to avoid Flickr links.

mullingitover 2026-02-24 19:17 UTC link

Can't say enough good things about flickr. Those people nailed it in 2004 (I've been a paying subscriber since their first year) and everyone else has been making bad copies ever since. Tagging, friends (pretty much inventing social media without any of the diabolical dark patterns), full-resolution archival storage, a solid API, all over two decades ago. I'm frankly embarrassed for things like Instagram, it's like they're not even trying.