Photo Gallery Test 1

Shirley, dear librarian, no doubt by now you know how much I must love publishing text on the web. Isn't it divine? Now it is time for you to know that I also believe the web is a great place for publishing and preserving all sorts of visual information as well. I have some strong opinions about how text and visual information should be presented, and I do like the idea of publishing pictures in the right context.

But what is "the right context" for publishing pictures or images? I'll skip to the end and tell you now: I'm not yet completely sure. I believe it will require more experimentation to discover the best path for me. Here I want to document my latest step in this exploratory experimentation to discovery.

Let's get a wider view of things first. There are different tiers to this research and development. Each test and sub experiment will support the overall goal. The overall goal is to determine an ideal medium for publishing images to the web. Ideal in this case will mean that the publishing medium does what it should while also avoiding the pains that I've encountered with current systems for publishing images to the web.

Let's start with what it should do, which seems pretty straightforward.

1. Present images to the user through their web browser.
2. Images are visually accessible (minimal styles and responsive layouts)
3. System is easy to navigate
4. System architecture is efficient
5. System can be hosted independently; built with only free and open technologies.

Now we can list some painful things that it needs to avoid:

1. Disproportionate expense. All current systems seem to be disproportionately expensive in either monetary expense or by dark patterns that expend personal attention and data.
2. Ads or ad integrations. Do they EVER look ok? Does anyone EVER not bounce when they see it? Is it EVER not a signal of a product that is actively dying? I absolutely can't stand 3rd-party ad integrations on independent sites. Aside from being a security risk, they also ruin the efficiency of the systems they run on because they require great resources (resources that need to be paid for in one way or another, which will either slowly kill the venture or be an expense passed to the user). Other overt ads on platforms aren't much better and have the same issues at a different scale. There will be no excuse to add ads if the system is virtually free to run.
3. Addictive patterns and dark engagement patterns. A broad and indefinite field whose avoidance may be primarily driven by sense and feeling.
4. Closed or expert-only software. Inexpensive web development can be far more accessible to the hobbyist than the public is made to believe. Systems should empower people to innovate instead of locking them in to technologies that are expensive and excessively difficult to understand. There is a complex storm of gatekeeping and profiteering that helps drive this social phenomena; it is important to condemn all of it.

The last point is important to reemphasize, and to put it into context as a higher-level goal. Before I make the system something that can be reproduced by non-experts, first I need to design the ideal base photo publishing system. By nature this initial system will involve custom software that takes expertise to reproduce; another layer of work is required to make it into something that doesn't require much learning to customize and deploy.

This is the same process that I followed for developing the webbook system and then the build-a-book tool that you can find at the King Book web library. The first several books that I published there, I published in custom webbook systems that I built from hand. Once I figured out my ideal webbook system, I made a higher-level system that automated away all of the expert requirements, thereby making webbook publishing more accessible to hobbyists and non-technical authors. The build-a-book tool also makes it much easier and speedy for me to publish webbooks! There is still room to make this higher-level system even simpler to use, but the current version is open for public testing now.

Alright that's enough background. Now you know where I'm coming from. Right now I'm focused on determining the design for the base photo publishing system. Once developed, I'll be able to build it into a higher-level tool that will help the non-technical reproduce the base system. Let's call this phase of the development, "base system development".

So, what is the current state of base system development? What is it that I just did do? Who knows where the adventure started or what the smaller steps were to get here; now I'll just show you what came out last.

I've just developed a simple test photo gallery. We'll call this "Photo Gallery Test 1", in honor of this article's title.

Check it out now: Photo Gallery Test 1 Demonstration

As you can see, it is maximally minimal and super simple. This version attempts to express the ideal vision with as little as possible. It has one home page and one gallery "view" (a programmatically-loaded page) that presents some of my photos.

I am happy with its visual and navigational accessibility. Vue (the JavaScript framework technology it is built with) and Tailwind CSS (the lovely inline CSS abstraction) work together very well to make this easy.

Architecturally speaking, this is a static single-page-app website. It can be hosted for little to no cost. I have it hosted by my static website server system "lightbook", a custom thing that I built with Django. Static websites have pushed forward to the industry standard for a good reason; they are fast and cheap and have endless hosting options. Neocities, GitHub Pages, Azure Static Websites, make your own static server, etc, etc... everyone has a cheap to free static hosting solution!

Aside from hosting efficiency, I've also ensured basic data efficiency by constraining the image sizes and format. I built a separate tool to make this easy to do in bulk (by the way, this new batch image conversion tool is now available at our web library). On top of that, Vue naturally hashes its assets – a practice that ensures another level of efficiency by playing nicely with the browser's file caching mechanisms.

All in all, I'm happy with this first test! I see where I want to take it for the next version. I feel the next version will be very similar, except it will have several categorized galleries.

In a farther-future version, I may also consider another custom background file caching layer that I can build with the Origin Private File System. This would make certain situations more efficient. The impact of this efficiency would be unnoticeable for most, but if a site had a ton of recurring visitors it could make a significant difference in the overall amount of data that needs to be transmitted from online file storage.

That's all the docs for now folks.

Now let's give you somethings to ponder. Think about images you have published online. Are there some images you haven't published online, for some reasons? Is it hard? Is it easy? Do you wish something was different? Do you want more control over things? Do you like the side-effects of giant social photo platforms? How do you wish the world of online photo publishing looked? Given your particular experience, what parts do you want to keep, and what parts would you change?

Thanks y'all. Talk soon.

<3 Grant