Building the site (part 3)
January 9, 2023 10:21
Part 3: Updated design and Photo Gallery
Part of the impetus for finally completing the previous post on how the site was built was that I recently made a number of changes to modernize the site. While the design remains mostly unchanged, it was at long last necessary to make a few improvements. I mainly wanted to make it more accessible for reading on smaller-size screens (like a phone), but cleaning up a bit to take advantage of advances in design languages like CSS was also a part of it. Fortunately those two went hand in hand, since naturally many of the developments in CSS were meant to make adaptive designs easier to manage.
The previous design had a rather straightforward, somewhat strict design approach. Since almost all of the site’s content is in the posts, I decided on a fixed ‘optimal’ page size for a post, and everything was measured out according to those rules. It made it easy for me to deal with the CSS. If I needed to size an element, I could choose the exact pixel height and width. About the only concession was that I tried to handle font size adjustments a bit better, since I often resize text depending on my viewing device. That’s not to say I did it well, just that I didn’t really attempt to make any other adjustments.
Of course such a site had the advantage that it always would stay the same, no matter what device you viewed it with. I didn’t need to worry about elements appearing in wrong places or being squished or distorted. However, that also meant that anyone trying to read it would have to keep scrolling around the page. It would end up appearing like a snapshot of a page in a book, or a newspaper, or a PDF file, with only a tiny window into it a time if you had a smaller screen. There were probably portions of it that were almost hard to find at times, and it was possible to scroll over to a largely blank section in places.
To replace it, I wanted something that would make it possible to preserve the traditional view, without necessarily forcing it as the only ‘correct’ way to view the site. It turned out to be not all that difficult. I chose to define a ‘smaller’ size at about half the previous size’s view, with a larger size that would be more adaptable from the fixed width of the older design. Setting that up was done using a CSS grid layout. It’s a fairly simple one, since I don’t have very many page elements. That required some adjustment as well to the pages that weren’t just an article (in particular, the topic sections), but moving away from the fixed pixel sizes made it possible to clean up the layout a bit. It also allowed for the page to work well when expanded to even larger sizes, which I found to be a nice bonus.
The ‘smaller’ size naturally required the most re-designing, since some elements had to be repositioned without disrupting the general style I want. It did introduce a few design bugs, and some things that I’m still noticing. I can no longer expect the design to always look the same on all devices, and especially not on all browsers. That may never really have been the case, anyway, and hopefully it is all still usable on any device, but now easier to use on smaller ones.
I still wanted something that could run without having to tweak too much, and generate galleries in much the same way Rhotoalbum did. However, there don’t seem to be that many projects that do quite what I wanted. I tried several, and they were either non-functional, or required more configuration of the images, or configuration on their own in order to work. The farthest I got was with Sigal, a static generator written in Python. However, I found that trying to customize it to the way I actually wanted to lay out the gallery did not quite work, the biggest issue being trying to skip over certain directories in the image folders. It had already been a struggle to get it even working properly, possibly due to Python versions (or dependencies), and since I’m fairly unfamiliar with using Python, it was becoming an uphill battle.
However, I did like one of the galleries that Sigal has as an option, namely Photoswipe. It occurred to me that the side of Sigal that I was wrestling with — configuring the images and loading them into a gallery format — was something that it would not be too hard to script on my own. It was the controls and interface of the gallery that I didn’t know how to do, but since Photoswipe appeared to be a distinct project, it seemed like I could find some way to incorporate it on my own pages. Not to mention that I already was using something that could generate static pages — Jekyll.
I abandoned the attempts to use static gallery generators, and relied on Jekyll instead, with a custom script to bridge the gap of making an index of image files. I used a Jekyll collection with a bit of custom front matter. This has the distinct advantage of allowing me to structure the gallery entirely how I want, as the Jekyll collection does not have match the file structure (or the directory names, another issue I was having). The only restriction is that each gallery references a single directory of images, although technically I could probably work around even that. The custom script runs through the image folders and generates a YAML index file that provides all the image information that Jekyll and Photoswipe need (image size and location); it will generate thumbnails as necessary, and it will also try to preserve any existing index files.
That does make it slightly more work than any of the gallery generators, but not by much. Adding a new gallery means adding a new file to the Jekyll collection (I have a ‘galleries’ folder), which includes the source directory, the gallery description, and where the gallery should appear in the hierarchy of the site. The way it is set up, my galleries can have photos of their own as well as sub-galleries, and each sub-gallery has a parent that it can link back to (the ‘to upper gallery’ link at the top of the page). About the only disadvantage is that the gallery description is not located with the folder of images, but that could even be seen as a feature if I want to reconfigure the gallery for some reason. The index of photos stays with the folder, since that makes more sense as the image details will stay with the image, regardless of the gallery they end up in. This index file is also where I can add alt text/titles to the photos as needed, which is another feature I wanted to make relatively painless.
Once I had the Jekyll collection generation set up, it took only a little more work to get Photoswipe running properly. This was mostly down to working out a few details with the options. The biggest headache was with gallery names, as certain things would not be processed properly, such as spaces in names. As a result, I simply needed to use a distinct ‘gallery name’ that Photoswipe could use if the original directory could not be used. It appears that it is all working correctly now, and as an added bonus the gallery pages are styled more in the way the rest of the site is, instead of being distinctively different as they were when I used Rhotoalbum’s defaults.
All of these changes are relatively new, and I haven’t really had a chance to test what it will be like to modify the photo galleries yet. That will indeed be the way to see if what I’ve done was a good idea or no better than before. I am, however, hoping for the best.