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.
And a bit about the skill of whoever made the wiki software, they need better documentation and automation to help even less-skilled admins to have clean URLs
> 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
> 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 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
> (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.
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.
> 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.
I've gone back to flickr for my photo sharing, I've had a pro account for, checks account, oh jeez, 20 years. I stopped using facebook and meta, and it's a solid photo sharing service. I can send links and people just get the photos, imagine that!, no ads, clean interface, lovely.
Stopped caring about them when they cancelled their 1TB free storage after 5 years, company which can't be trusted long term with your data. Plus the UI was horrible anyway.
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.
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.
And a bit about the skill of whoever made the wiki software, they need better documentation and automation to help even less-skilled admins to have clean URLs
> 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
> 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.
That's usually how people do it.
Yes, I saw that multiple times in blog engines, with the entry title being the optional part.
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
> (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.
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.
If you delete the photos path element they do actually have a fallback resolver that redirects you to the appropriate path under photos.
E.g. flickr.com/mwichary/sets/72177720330077904 does take you to flickr.com/photos/mwichary/sets/72177720330077904
> 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.
i don't understand the heat under ?&
?set=2546&pic=8597 is much easier to decipher than /2546/8597
From my experience, query param is usually optional, also `?foo=1&bar=2` and `?bar=2&foo=1` should open the same page.
I've gone back to flickr for my photo sharing, I've had a pro account for, checks account, oh jeez, 20 years. I stopped using facebook and meta, and it's a solid photo sharing service. I can send links and people just get the photos, imagine that!, no ads, clean interface, lovely.
In one of their transitions, they seemed to somehow deleted most of my photos. I don't know which one exactly, maybe it's my fault somehow.
I just know I didn't log in for 10+ years and now when I do, most of my photos are gone. Oh well
They're also holding the photos that are left hostage; unless you pay them, you can't download the photos you have left there.
oh yeah i remember as a kid into webdev and php how some sites would have these CLEAN urls. seemed like magic to me.
TIL Flickr still exists
Stopped caring about them when they cancelled their 1TB free storage after 5 years, company which can't be trusted long term with your data. Plus the UI was horrible anyway.