A few lifetimes ago, I had a rather sizeable Flickr library. It grew over many years, from many vacations, many photos of my growing kids and extended family, and more than a few company events.
I liked what Flickr did at its core: share pictures. It added on all kinds of nice functionality, notably putting things on maps, but it also read the data stored in your images, turning it (in part) into an educational tool – you could learn from other photographers what settings could give a desired result. That it created a community along the way was a nice bonus
I had friends at Flickr, too – Jude and Scott – and in their earlier days, a Pro membership could be given for free, which I got, and I used. The “unlimited” aspect was particularly appealing and I went all-in, paying for Pro for years, building up the library. I got a lot of hits every month, not bad for a mere amateur.
Then Flickr was sold. Initially, it was zero change, but the new owner, SmugMug, started futzing with the pricing. Presumably, running Flickr was more expensive to run than expected and the only option was to insert ads and jack up the price of the Pro level. For me, the Pro fee was pretty reasonable at first, but SmugMug didn’t tack on a couple of bucks, they doubled, then tripled the cost. It was more than too much to take. I abandoned ship.
Now, in hindsight, I wish Present Me could talk to Past Me and tell Past Me to chill out, $80/year – although high – is still really reasonable. It’s just that the tripling of costs had driven a stake in my heart and I didn’t want to deal with them anymore.
I say this because, well, I still wanted to share my pictures. But where to go?
I had some requirements, most notably: I didn’t want to host my own website. That’s maintenance I don’t need to deal with. Online services aplenty, there are, but many of them I deemed too expensive and/or didn’t deliver on what I wanted, which at it’s (and my) heart was really just Flickr.
Being an Adobe Photography subscriber, I opted to use Adobe Portfolio as my solution. And, to be fair, it seemed pretty decent: via Lightroom (I use CC on my computer, which syncs to Lightroom in the cloud), I could select pre-defined albums, add them to my page, and presto!, I had an image sharing website again! Yayyyyywaitaminnut.
No titles. No descriptions. No map. No EXIF. Not even an individual page I can actually share. And those albums don’t update automatically, I had to manually trigger those updates, which sometimes involves removing and re-adding them, because the sync is pretty horrid. So, really, Portfolio became nothing more that a dumping ground for a URL while I resumed my search.
I eventually ended up on 500px.com, which is best described as “Flickr-like”. But it feels more like Flickr’s step-cousin: it’s from the same family, has some of the same facial features, but it’s somehow just wrong enough that it sits wrong with me, every time I look at it. And I’ve tired of it far faster than I expected.
One more thing I liked about Flickr was the workflow I’d gotten into. Via their Uploadr app, I could drag-and-drop dozens of new photos, assign folders, provide titles and descriptions, and then fire the whole batch up at once. While the web interface worked just fine, I liked the more fire-and-forget aspect of Uploadr. 500px didn’t have that, and I found the upload process a bit arduous.
I’ve come to understand my requirements as such:
- A bucket in which to place my (organized) photos
- A UI that will display the picture, its EXIF data, and a map of where I took it
- A sharable URL
Not much, really, but that first one is really the big requirement: I want a simple place to put my pictures. I don’t want a website, or a framework, or anything else complicated. Just a bucket.
Following our return from the UK on the 4th, I wanted to share my new pictures, because I’ve got a few real doozies in there that I quite like. But what I had to use for sharing wasn’t sitting with me. And, suddenly, I felt the need to build something.
But.
I wanted something simple. Remember, I just wanted a bucket. So whatever I came up with had to read that bucket, understand its contents, and display accordingly. I shouldn’t ever need to touch the actual “app” part, except for bug fixes and the periodic enhancement. Once the app was developed and stable, all I wanted to do was add new images, nothing more.
The discovery of a JavaScript library that could read EXIF data settled my plan: an HTML page with some JavaScript, an Amazon Web Services S3 bucket, and I would be done.
To be fair: it almost worked, too. The internet is replete with documentation and examples, and while AWS’s documentation is pretty horrid (guys, seriously, clean your shit and have someone actually test what you wrote), and I got it working. I was really impressed and happy and immediately shared my results with my friends and the first response I got was: “Blank?”
Wut?
Google Chrome on my Mac was fine. Safari on my iPhone – which I had not checked – had no images to speak of. Nor did Safari on my Mac … or Firefox … or Chrome on my iPhone. I had committed the most egregious of developer habits: “It works on my computer.” Sigh.
Three versions of the code later, and it still didn’t work. I kept getting CORS (Cross Origin Resource Sharing) errors that I could not find, nor did any of the documentation indicate the source. Worse still, all the steps I had taken to set up the S3 bucket had all the supposed CORS issues resolved. There was just something I could not pin down.
Okay, fine, maybe it’s an issue with the AWS SDK, which is decidedly more aimed at NodeJS developers. Based on Jeremy’s recommendation, I thought I’d give Cloudflare’s R2 product a shot; my site runs there, anyway, so why not keep it in the family, right? Except Cloudflare is even more slanted to NodeJS, actually uses AWS’s SKD, and browser support is … I’m not sure it’s even possible. Azure? I made it about five steps into the process before realizing that the overhead was too high, and browser support wasn’t really considered. I even looked at Dropbox.
Every time, I ended up back at square one: where was the bucket? I genuinely cannot believe it’s so damned difficult to have a simple file bucket to share files. Every solution seems terribly overthought, at least for my simple needs. I’ve definitely strayed into an edge case for most of these services.
Here’s where I ended up:
- A single HTML page (with inlined CSS and JavaScript) that loads a JSON file of the images and their creation dates (so I can sort the newest ones)
- A simple processor that finds all the images and builds the JSON file
- A “bucket” directory of images
- A redirect that sends all URL requests to the HTML page for processing
It’s a bit ugly – the image URLs are nothing more than the album they sit in and the image’s file name (which is the highly unoriginal “_DSC012356789.jpg” pattern) – but now all I have to do is add images to a directory, commit to Git, and push. Github Actions takes care of building the JSON for me and pushing the files to production. It’s not perfect, but it’s an improvement, at least.
The tricky part, at least for now, is trying not to rabbit hole on this. Since getting this going last night, I want to add some more features and maybe even make the JSON a bit more fulsome so I can do searches.
But, deep breath. I have an image sharing tool I’m actually (somewhat) happy with. It ain’t perfect, not by a long shot, but with the result I have, I’m at least able to share pictures again. And that’s what’s most important…
…for now…
