Monday again, again

A dark, rainy and slow day

17:57. Time for beer and brain dump. A change of scenery often helps shake off 'code-head' – the mental tension that can build up after having one's head full of code and logic all day. It might take a little longer this evening though. The weather is grim, the only pub that's open is piping middle of the road out at an unnecessarily intrusive level, and today has been a bit of a drag.

Images again, again

I've recently added a new way to select images – a 'flyout'. Like the previous 'modal' method, the image candidates are presented as 'cards' which results in a regular grid of uniform square images. Or it would if the images are cropped square or are made square by having white space added.

I could simply create an extra 'always square' version of each image, but adding to the list of image variations isn't something I want to do without digging into the issue a bit deeper.

Database versus config file

Images can be included in pages in many different ways, from tiny, icon-sized low-res in a row of table data, to large high-res versions that cover the entire screen. The view with probably the most potential different variations is 'card' view. The number of cards per row can vary upwards of 1. Each choice of cards-per-row generates columns of different width which change depending on the width of the browser, and how the columns collapse.

Apparently, in order for your website to be regarded as efficient, you need to provide an optimised version of every image that your page could call depending in the viewable screen width.

I've been through all this before, and setup a widget that chooses and create some images on a per view basis. In order to stop automatic on-demand, image creation from initiating a surge in demand for resources when an SEO scraper bot decides to ask for 1000 pages per second, I added some logic which defers a lot of it.

The recent question about whether or not to create yet more 'flyout' variations just for use when selecting images led to me setting up a database and work through as many variants as I can without giving up and retraining as architect. The database tool has not made things easier, but it should result is an a big list that can be turned into a shorter one. I've been through a set of column views and the number of records is over 100, and the number of different image width is about 50, equivalent to about 3Mb of image variations per image.

On the plus side, once I've worked though the set of 'standard' views that my preferred frontend framework uses, I can at least publish a demo page.

Tuesday follow up

After working through the standard view options I've ended up with 430 criteria combinations that want to use 63 different image widths from 19px to 1200px. There are still a few special cases to look at, but they shouldn't increase the numbers by much. Eg email header image, which won't use a scrset.

So, back to the question that started this 2 day melon-twister. To create a special square image for use by flyouts and modals or not? And if so, what size? Is there any image variations already being created that will always be square? I suppose they don't have to be high-res if they're just for using as part of a selection process. I think the answer – at least in the short term – is to create 200x200 square images. The file size should be relatively small, and I can't see any other views using 200px as a width value. Or, I suppose, I could look at using a background image. That way any existing image could be used. It feels like more work, but – hey – what else are cold, wet Tuesday evenings good for?