Building An Art Site

[Well, it's official, I've started marketing on Instagram (or Insta as the crossword puzzles like to say the kids say), which also immediately cross feeds into Facebook, so I can now no longer claim that it's been more than 10 years since I posted on Facebook.  All that's left is Blue Sky.  I'm not going to deal with MechaHitler.  I'm not sure the audience would be all that interested in art history anyway.]

I'm using today's post to delve into some of the technical details I used to create Exhibit Meh.  I knew from the outset that I was going to use Astro JS for the framework.  It powers a recipe site I created, my company's homepage, and some other small projects that constitute the hoarder's dream space that is my GitHub account.  It also served as a good template for a proof of concept I helped someone else with recently.  I also knew I was going to use _hyperscript for the client-side JavaScript functionality.  I've used it on something like 4 projects now, and it continues to impress me with its functionality and expressiveness.

Otherwise, I really had no concrete plans for site design.  I knew I wanted to overlay some sort of indicator on the artwork image to indicate CLICK HERE FOR MORE INFORMATION, and knew that I'd be using modals (pop-up windows) to display the information when someone clicked on the indicator, but my original intention was simply to use HTML to write the content.

Except that, to quote Mike Tyson, everybody has a plan until HTML punches you in the face.  Well, I think that's what he said.  It's obviously what he meant.

HTML, as a language, is nice for basic structure when creating a web page, even after 40ish something years.  Whatever weird JS language you're using with reactive state-this or promises-that, all wind up being HTML at the end of the day, anyway.

However, if you want to create a lot of similarly formatted content with relative ease, it is, as the kids say these days, "the pits" (It is the 20s, right?  Wait, the 2020s?!?! No cap? And thus ends my familiarity with any slang past 1993. Dope.)  If I want to italicize specific content, I need to write

<span class='italic'>My italicized content</span> 

in order to format things appropriately.  For someone who unnecessarily italicizes things a lot, this can get tedious.  It's crazy that HTML was supposed to make formatting easier back in the days of fax machines.  But I guess it's similar to people inventing the new-fangled horse and marveling at its efficiency when, previously, they needed to wander across continents on foot to find the nearest fax machine.

Luckily, Astro supports Markdown, which makes writing content easier.  I can italicize something simply by doing *this*.  The problem is that Astro also has no inherent system for allowing me to customize the style or structure of my Markdown in different parts of the site.  

I eventually settled on splitting the content for a given painting into separate Markdown files with separate templates to apply against each file to follow a consistent style.  Coupled with a few site-specific conventions, it's easy to simply assemble the content and publish it quickly.  This is good, because most of the work should go into writing the content rather than formatting it.

So, for each art piece, I have something that resembles the following structure:

mona-lisa/

    index.md

    triangle.md

    smoky.md

    hands.md

All of my content for a given piece is collected in one directory.  Each directory has to have an index.md file with the basic copy attached to the page's title as well as some other meta information.  Here's the index.md for the mona-lisa:

Mona Lisa index.md

The image comes from another location on the site, but it's easy enough to find and render as long as I provide the image location as shown above.  The slug, if you're unfamiliar is a term that originates in journalism but in blogging/website terms is the relative URL for specific site content.  At first, I just created it from the directory name, but I ran into issues when testing it on my laptop vs. deploying it with my provider (aka GitHub Pages).  My provider would alter the directory structure in unanticipated ways, thus making it impossible to render the page.

An additional slug field is a slight overhead that has the risk of diverging from the name of the directory and making it harder to find information or fix problems, but it's worth it to keep myself from being outwitted by two systems at once, which is a much bigger pain.

The four fields below the slug attribute display proper attribution for the photo taken on the page.

The content associated with each of the blue dots on a page is very similar to the title content:

Mona Lisa triangle.md

Those fields at the top indicate where to place the pulsing blue dot in relation to the painting and where to place the pop-up box when someone clicks on the dot (it's specified in TailwindCSS for the technically curious).

When I ask Astro JS to build the site, it uses the following template to generate everything the way I like it, without requiring me to hand-code every little thing:

Site template page

On line 47, I take the content from the index.md page and use it to construct a modal page with the id of 'title'.  Then, starting on line 52, I find all of the other files in the directory and use their names as identifiers for the modal pages associated with the blue dots (so, triangle.md will become a modal page named 'triangle', smoky.md will become a modal page named 'smoky', and so on).  In case you're wondering, I built a component named Modal to further modularize the work I had to do.  It's just some parameterized HTML that makes code reusability a snap.

There are some other supporting files and code I created, but they're very similar to this.  I'll probably mention a few of them, as well as my pet peeves (well, really only one pet peeve) with Astro/GitHub pages in the next post.

Until next time, my human and robot friends.