June 27
Hi everyone, hope you're doing well! Long update - I've been busy, though I got COVID this week. It hasn't been too bad - it's mostly just making me tired and coughing as I've had 4 vaccines (yes 4, my immune system is weakened so I have more vaccines due to higher risk). More problematic is that my immune system doesn't like me very much, so COVID gave it an excuse to flare up all my allergies, bah.
Anyway, onto update things: I've been making a fair bit of progress on the site design.
Artwork overlays (text that appears on hovering over the image to show you the name, artist etc)
Done in a basic form, though I need to add icons to them and such. Getting them to sit on top of the artworks neatly in a dynamically shifting gallery took a little time. I'm also in the middle of implementing overlays for the main "display a single artwork" page, which needs more complex overlays to add download buttons, next/previous artwork buttons, etc.
Speaking of that, the "display one artwork" page is partially done. I need to add next/previous image overlays perhaps, and an options area for deleting/editing an artwork submission, but most of the difficult stuff is sorted out: just a bit of work to do on it now.
Proper "unique artwork IDs"
Done. For testing purposes I was just using an ordinary ID column that goes 1, 2, 3..., but in a production environment that isn't acceptable (it would make it very easy for a scripting bot to scrape all artwork pages).
There's two trains of thought one can take when it comes to unique IDs, and ArtStation vs DeviantArt links sum it up pretty well. The links below are examples that are not valid links on those sites (they'll go to a 404 page), but show the syntax.
Example AS link: https://www.artstation.com/artwork/ABc12d
Example dA link: https://www.deviantart.com/artistname/art/Title-of-Artwork-123456789
The first idea - a short string of letters and numbers - makes for short URLs, but in my opinion I don't feel that is a good reason to use it. Short, but unreadable: the URL tells us nothing about which artwork this is, which in situations where a link is embedded on an external site, isn't very helpful.
Twitter often embeds links, but for places where a link isn't embedded or a picture stops it from being embedded, someone writing "check out my artwork at <art site/bunch of unreadable letters>" isn't quite as enticing or helpful as "<art site/title of art-bunch of numbers>".
Resized images for CDN
In order to efficiently display images on the website without consuming massive bandwidth, it's necessary to resize artworks more than once. For example, let's say a user uploads an artwork at 6000x4500px. That's far bigger than anyone's screen is going to view in normal browsing; it still needs to be available for download, but it also needs at least two resizes:
Display size: max 1080p, for displaying the artwork inside single-image pages, like a "display artwork details" page.
Gallery size: max something between 480-720p, for displaying the artwork in galleries with many images, and where the image will never be bigger than that size.
This has two benefits: firstly, the site will incur fewer bandwidth costs (which are significantly smaller than the higher file storage costs of storing the resized versions), and users will experience faster loading times. Making the user download a 6000x4500px image (27 megapixels) just to view it in 1080p (2 megapixels) means they wait far longer for the page to load. I considered looking into a solution where the CDN can dynamically resize the image to suit a request, but I don't think it's necessary, and it adds some additional costs that probably aren't worth the savings in bandwidth.
Getting artwork descriptions to upload and display correctly is done. This is a bit more complex than it sounds, since they need to be able to include formatted text and links, so I decided to use the QuillJS library which has some very bizarre quirks that had to be figured out.
Effectively, it's a text editor you can embed in the page. It stores this text as a "delta" - a kind of JSON subset - but for reasons unknown, it's pretty difficult to parse said delta without using the same Quill editor to display it again. It took some research and experimentation to find a way of making the Quill editor display in a manner that looks like an empty div, so that it can display the content on pages without looking weird.
I'll upload some previews of how the website is going in a later post.