Flickr’s URL Scheme ⇥ unsung.aresluna.org
Half of my education in URLs as user interface came from Flickr in the late 2000s. Its URLs looked like this:
flickr.com/photos/mwichary/favorites
flickr.com/photos/mwichary/sets
flickr.com/photos/mwichary/sets/72177720330077904
flickr.com/photos/mwichary/54896695834
flickr.com/photos/mwichary/54896695834/in/set-72177720330077904
The persons responsible for this URL scheme thought well enough ahead for the complexity and scope it could encapsulate, yet kept it remarkably simple.
It is the kind of logical directory-style scheme I wish I would see in library-based desktop applications, too. I still have copies of my libraries for Aperture and iPhoto on the same Mac as I use for Photos. Each of those has a pretty understandable structure within the library package: the most substantial part is a “Masters” folder containing a year, month, day, and then project folder hierarchy; among others, there is also a “Database” folder with nondestructive edit operations, though that becomes less intelligible structure if you drill down to the project level.
For contrast, the library structure for the Photos app has no such logic. The “originals” folder contains fifteen subfolders labelled 0–9, then A–F. Each photo’s filename is a unique alphanumeric code, and there is no discernible logic or structure to which photos end up where. I found an image from 2012 following one from 2023, then another from 2022, all in the same folder. This feels undesigned, yet it is far more recent than any of the structures that preceded it.