Putting “preserve” back in the phrase “nature preserve”

Read last year’s post or view the updated photo gallery.

It would seem that this is becoming an annual report which is somewhat funny and also somewhat sad. I do like the aspect of reporting and in this age of propaganda, distortion and denial, it’s more important than ever to show the proof. The idea of an “annual report” is funny to me as it reminds me of the how it all started and the “local archeology” tagline. It’s a bit of dark humor pulling us out of the dismay. There is no corporation here, no investor relations, no government agency requiring a report of my activities. There’s just an art project tied onto the back of a hike while cleaning up the neighborhood.

So how did 2025 go?

The year was both more active and more focused. Last winter when the snow covered everything hiding man’s many sins, I used the time to scout for areas that needed attention. Turns out, this was time well spent and come summer, I was able to go back and tackle three or four problem areas leading to huge progress. These areas are spots of commercial dumping and led to an increase in trash volume and trash weirdness. I’ll still need to follow up on them as the forest continues to spit out and reveal more trash, but a significant amount of clean up reduced the obvious blight. Disappointingly, I also discovered some new trouble spots which will lead the 2026 adventures.

The Trash

In addition to the usual containers this year, I started using a couple of old masonry tubs on my hand truck to help carry out stuff that just didn’t fit nicely into a bag or bucket. These bins quickly became essential for large pickups in areas of commercial dumping. It’s also worth noting that as I ranged further I actually had to start to use our car. It was too far from the house and the terrain is too rough to physically carry out the trash. There were two car loads in December.

Using the same conservative estimates from 2023, 50 pounds per bag comes out to 2,900 pounds for the bags. For the buckets, using the conservative estimate of 20 pounds per bucket leads to a total of 820 pounds of trash put in buckets. The bins are a bit more awkward due to their shape, so estimate the trash weight by volume is difficult. They were often lighter, but held oversize items to keep them from falling off the hand truck. Let’s go with an estimate of 10 pounds per bin for a total of 330 pounds. Additionally, there’s also the category of the unwieldy and unweighted. Things like truck tires, large pipes or car transmissions just never get weighed or factored into these estimates. It would be cool one day to get an old large farm scale to just drop items onto for actual weights. Maybe one day.

This leads to a total estimate of 4,050 pounds of trash removed in 2025 surpassing the amounts collected in the previous two years. Over 2 tons (2.025) of trash removed from the forest without even factoring in many of the larger items.

Here’s a list of some of the items that jumped out

• Car batteries
• Concrete blocks
• Steel buckets
• Shovel heads
• Appliance motors and parts
• New York and Connecticut license plates
• Children’s pacifier
• Concrete parking blocks
• Car headrest
• Windshield wipers
• Pitchfork
• Styrofoam packing
• Lawnmower handle
• Box springs
• Automotive car seat
• Porcelain vase
• Heating vent cover
• Cast iron pipes
• Plastic green doormat
• Home stereo receiver
• Iron weight from a window sash
• Large truck inner tube
• Electric weed wacker string trimmer tool
• Car and truck tires
• Screen window
• Beach chair chaise lounge
• Carpet and foam padding
• Roof shingles
• Fluorescent light bulbs
• Insulation panels
• Garden hoses
• School bell
• Soccer balls
• Hypodermic needle
• Champagne bucket
• Axe head
• Car axles with transmission housings and drum brakes
• Metal shopping cart

Where’s it all go?

One thing I also wanted to answer in this year’s update is a question I sometimes get from folks: “What do you do with it?”.

For the trash, it easy, just put it out for the town to pick up. The really big, awkward or dangerous stuff gets loaded into the car and taken over to the county’s Household Materials Recovery Facility (H-MRF) which is really…the dump. It’s free for county residents and you don’t even have to get out of your car. Just pop open the back and they pull everything out, but you do have to make a reservation online beforehand. It’s also notable that in 2025, they are now required to track how many tires you bring over. I don’t think there’s a limit, but probably something the county needs to report on.

Alternatively, the town offers a bulk pickup service. It’s a bit random, so you never known when they’re going to show up. You just have to put the stuff out front and wait. They also have more restrictions on what they’ll take (no tires or batteries), so I’ve been using the service less and less. I also think it’s more neighborly to not leave a giant pile of rusting metal out front of my house for two weeks until the town comes by to pick it up.

For the recycling, there’s the trusty town bin and this is where the volume gets a bit crazy. We have a town provided 35 gallon blue wheeled bin for “co-mingled” recycling — basically plastic, metal and glass. In our house, there’s just no way my wife and I could ever fill the recycling bin that size on our own. With the large volumes of bottles and cans I’m pulling out of the woods, the 35 gallon bin is completely full almost ever week. Often times with 2-3 accompanying bags as well. The bin says it has a load rating of 122.5 pounds, but let’s dial that down a bit. If we estimate that the materials weight is 80 pounds and it’s full 35 weeks out of the year, we’re looking at 2,800 pounds of recycling. Subtracting the weight of our usual weekly household recycling of…maybe 15 pounds…and we’re looking at 2,275 pounds of recycling removed from the forest.

Remember kids, picking up the trash is only half the job. Packing it out of the woods and disposing of it properly is often to hardest part.

The Design and Development

There were only a few development changes to the gallery this year. The majority of the effort was in processing and formatting the increased amount of photos. It seems I was much better in my documentation efforts in 2025.

Typography

I swapped out the typeface used for the bold subheads (Canada Type’s Gibson) due to license restrictions when I canceled my Adobe subscription. The new font (Argentum Novus) isn’t visually identical, but it’s close enough to fool most non-designers.

UX/UI

As the page was growing and growing longer, I realized it needed a couple of UI improvements to help the UX. Notably, a few navigation links so that visitors can quickly jump to a specific year. Likewise, since the new navigation links are not sticky and scroll off screen, I added a “return to top” button to allow visitors to jump back to the top of the page.

The links to each year’s blog post were also moved from the page header to under the heading for each year. I also added in some horizontal rules to help define each year’s section. They come in handy when scrolling along as there’s not a lot of visible space between each year’s images.

Looking Ahead

While on my winter snow hikes to scout for trouble spots, I also began expanding my range into another, larger, neighboring park. This one is managed by the county (not the town) and generally, is in better shape, but of course, my keen eyes can find a broken bottle or rusty beer can anywhere. There’s the opportunity that I may start pulling trash from this new park as I just can’t…leave it. But the work on the first park will take priority. There’s no reason to give up before the job is finished. Here’s to making your neighborhood a little cleaner, a little brighter and a little healthier for the future.

Please don’t litter.

View the updated photo gallery

Helping a Vietnam Veteran share his photos and stories from the war

View project

On March 8th, 2024 I was able to launch a side project for my father-in-law Bruce Tester that has been banging around between us for years. We get excited, get distracted, get busy, get back to it and the cycle would repeat. This post is a summary of the design and development of the site as well as the history of all our fits and starts.

The Background

Bruce is an accomplished photographer and with my design background, we’ve spent countless hours geeking out over Photoshop, the latest digital cameras, scanners, printers and all manner of photography related equipment. Many times, I’ve happily ended up being his de facto photographer’s assistant lugging around gear and setting up for a golden hour landscape shot or a time lapse night shoot. Bruce is humble about his photography and despite filling his house with gorgeous prints, he doesn’t really promote his photos. My wife and I have always loved his work and would (gently) push him to display them somewhere, but to no avail. Finally, for one holiday gift, I bought him his own domain, set up hosting on my account and volunteered to set up a site for his photos.

First Attempts

For quick setup and ease of use, I installed WordPress for him and threw a couple of his photos in place using a free photography theme. I tweaked the type a bit, created a quick logo of sorts and posted some photos to show him what was possible. And that’s was where it sat. For years. We both got busy with life and it was always more fun to take photos versus building a photography website.

Getting Serious

Once Bruce retired, he finally had the time to begin digging through his photo archives, retouching and organizing thousands of photos. This is when we came back to the idea of creating a web archive for his photos. The collection that was in many ways, most important to him, were his photos from his time in Vietnam. Since we already had WordPress installed, he began feeding my sample photos and I started setting up test pages.

Of course, like many projects, as we reviewed and discussed the test pages we found the site wasn’t quite accomplishing what he wanted. I had even given him some basic WordPress training, so he could upload photos and create pages, but it just wasn’t working out. He wanted to write more about each photo, write more about his time in the Marines and organize the photos into subsections to better tell his story. In short, the theme wasn’t working out. I searched for other themes and tried several, but the more we talked, the more it dawned on me — we needed to build it from scratch. It would certainly be a ton more work, but we create something unique, personalized and beautiful.

The Design

The decision to finally build the site by hand was in many ways, a huge relief. While I’ve used WordPress for years and years (and still do for this blog), I’ve grown beyond the framework and it’s limitations are now irritations. Starting from a blank page was freeing and more inline with the majority of my recent efforts. Hand crafted instead of framework dependency.

Overall, the design inspiration was really about the time period — the 1960s. And not the free love, hippie, psychedelic day glow lettering 1960s. The other America. The more conservative 1950s generation with buzz cuts and starched shirts. Looking through the command diaries and cruise book Bruce provided really got me thinking about what “official” document design looked like back then. I started researching other government publications.

The primary goal of the site was of course, to focus on the photos. The site hierarchy was a basic thumbnail gallery leading to individual photo pages. Nothing crazy there. Navigation is a simple masthead with a drop down menu along with a breadcrumb link navigation at the bottom of each interior page. The breadcrumb links expose the structure and allow for jump navigation. Within each photo page there is also a previous/next link navigation so you can alternatively progress through the site in a linear fashion.

Framing the photos and lifting them off the page a bit was another design choice to help separate and define the content, directing attention and focus. The site colors were all muted tones: blacks, whites and warm grays — all in service of the UI and not to interfere with the photos.

The typography was chosen to split between the site UI (menu, navigation, etc.) and the content. For the UI, the Inter font family was perfect. It’s got lots of options, it’s very legible and modern, but also not showy. Like the UI colors, it’s not going to distract from the content. For the text content itself, I loved the look and feel of the typewriter style fonts used in the command diaries. Going with a monospace font like Courier New helped anchor the content in it’s original time.

The one page where I did have a bit of fun was on the About page. I was able to grab a few of the military stamps (“Confidential”, “Unclassified”) from the command diaries along with a bit of texture to add to the background. I think these little touches help to keep the page from being too clean and sterile.

The Development

The site is super old school in terms of development — semantic HTML with CSS for style. The only Javascript used is for the main drop down menu and that’s just for the button event to show and hide the menu. Choosing this direction rather than the latest framework flavor was important as the site is a historical document. I always had to keep in mind that i was building for the future. Keeping it simple and using the proven standards that the web was founded on would help ensure that the site would work well into the future. The entire project is essentially a library archive to help tell part of American history. It was a responsibility I did not take lightly.

Accessibility and the Audience

Accessibility is always a requirement, but as we worked through initial pages, it became even more important as we really considered the potential audience. Given the historical content (and using Bruce himself as a tester), we realized we needed to add design elements to cater to an older audience. Adding numbers to each photo in a category, not only helped us in production, but also gives a reference anchor for visitors. The same is true with the text overlay that appears on hover for each thumbnail. The “click to view” instructions help guide visitors to the full size photos. This was a great exercise in recognizing and adjusting our bias — just because we’re click happy youngsters doesn’t mean folks over the age of 70 would understand the implied navigation. Similarly, adding some “how-to” text to the home and about pages helps to make it obvious.

Education and Production

One of the other parts of the development process was education. Bruce has no idea about the mechanics of good website structure, accessibility or SEO and nor should he. He’s the photographer. This lead to some back and forth as I taught him about <h1> tags, why they were important and why we needed one written for every page. All 400 plus pages. So the production process was Bruce writing and reviewing test pages while I focused on batch image formatting, resizing, optimization and even naming for better SEO. The same was true for the HTML side. Sessions of duplicating files, updating the content and links while capturing and handling any unique content that a specific page might have.

One production and accessibility aspect that I also tackled was writing the alt text for the photos. This let Bruce focus on the photos, titles and the overall story. Now, writing descriptions for 400 photos was no small task and at times it did seem overwhelming. After about twenty, you start to burn out and your eyes blur over. Admittedly, some of the descriptions might sound a bit lazy and in a twist, the WebAIM WAVE tool flags some of them as being too long. I do take a bit of pride in providing good alt text, so it’s a warning I’m willing to set aside especially as this is a photography site.

Other production notes include creating open graph images and the site’s favicon. The challenge for the open graph image was to come up with the text to help “package” the entire project. Given Bruce’s other landscape photography work, I could envision adding new sections to the site and moving this entire project to a sub directory. Thinking about that possible future helped me to consider this project a “collection” which then made the open graph designs fairly easily. Designing the favicon, on the other hand, was much more difficult. The site is personal, so it doesn’t have a logo per se. With no logo and a fairly subdued color palette, there wasn’t any material to rely on. I wanted something dramatic, probably because I suffer from too many browser tabs being open at a time. Initial inspiration came from the Marine Corp itself. Namely, the colors. The red and yellow combination is certainly dramatic and jumps out in a browser tab. The second bit of inspiration was the idea of old camera lens iconography. I worked through a few different, more classical lens shutter icons before settling on an abstract approach.

Performance

Things could always been improved and you can chase down minor improvements for a long long time. Overall though, Google PageSpeed is happy with scores of nearly 100 across the board for desktop (the intended profile). The results for mobile are also impressive if a bit lower for the performance metric.

Performance reports from GT Metrix and YellowLabs also confirm the site is doing pretty well.

Likewise, the site HTML and CSS both validate without issues. Interesting to note that the WebAIM WAVE tool shows the thumbnail hover text as failing color contrast even when the color combination is well above the WCAG 2.2 Level AA ratio. Turns out it’s due to the opacity being zero. Once the thumbnail is hovered, the text opacity changes to 100%, so the error is a bit of a false positive.

Conclusion

Overall, I’m really happy with the way the site turned out. It feels very professional and I think I’ve lived up to the responsibility to tell the story. As the grandson of a history teacher and as a child born during the Vietnam War, I feel passionately about accurately telling stories like this for the future. Heck, I think I bought Bruce the web domain for Christmas back in 2008! It only took us 16 years to build something really great. Hopefully, it’s also worthy of Bruce and the all men and woman who served in the war.

View project

Updating my library for a better future

Visit the library

Now, I’ve been around the web a while and I’ve played the SEO game with many different search engines. Consequently, along the way, I became a big fan of structured data. It just clicked in my head as an easy way to provide additional context to our content. A way to enable a richer experience without mucking up the presentation.

Of course, with the big boy on the block, that meant using the JSON-LD as that’s what they “recommend.” And to be fair, it is easy to add to a page and then to update and maintain — especially on large websites.

Of course, on my own little website, there’s not a whole bunch of data to…well…structure, so the JSON-LD is more of a general description of ownership. Still, I’ve been adding it to all my pages for a long time.

<script type="application/ld+json"> 
{
	"@context": "http://schema.org"
	"@type": "WebSite",
	"name": "Strength of One // Library",
	"url": "http://strengthofone.com/library/",
	"image": "http://strengthofone.com/soo-icon.png",
	"description": "Find out more about my virtual library.",
}
</script>

All fine and good. I was recently plugging along making updates to the library (to add and update links) when I came across an article on microdata for books. Andy Dalton‘s article for the HTMLHell advent calendar switched on the light bulb and I realized I had the perfect page for playing around with structured data in a more expansive way by incorporating microdata directly in the HTML.

When I first started learning about structured data (long ago), I remembered thinking microdata actually made more sense than JSON-LD because it was more closely aligned with the actual content. The main reason I never started incorporating it into my pages (beyond the Google influence) was that my content didn’t seem appropriate. I wasn’t writing up recipes, movie reviews, promoting events or anything that really fit the value pairs approach. With my library though, adding the microdata directly inline made perfect sense. Each library card is already presenting information that could be connected to a Schema.org value.

I started slowly with a few entries and validating each as I completed it, quickly getting the hang of it and gaining confidence. I think the only edit to the HTML structure I had to make was to wrap the author in a <span> element so that it connected with the itemscope in the parent <p> tag. From there, it became a production chore to copy/paste/find/replace for each book as I watched some football and relaxed. Here’s a sample book entry with the microdata in bold. (And yes, the fact that the code is not indented drives my designer brain crazy, but in this narrow blog column, it’s easier to read when the lines don’t wrap so much. I’ll probably write another post about the woes and wails of code formatting for designers.)

<article class="book-card fiction paperback" itemscope itemtype="https://schema.org/Book">
<div class="book">
<h2 class="title"><cite itemprop="name">The Lord of The Rings</cite></h2>
<h3 class="subtitle">Special Edition</h3>
<p class="author" itemprop="author" itemscope itemtype="https://schema.org/Person"><span itemprop="name">J.R.R. Tolkien</span></p>
</div>
<div class="book-details">
<ul>
<li class="category">F</li>
<li class="category" itemprop="bookFormat" itemscope itemtype="https://schema.org/Hardcover">HC</li>
<li class="link">
<a itemprop="url" href="https://openlibrary.org/books/OL38062258M/Lord_of_the_Rings" title="View at the Open Library">
<svg viewBox="0 0 24 24" aria-hidden="true"><title>View at the Open Library</title><path fill="currentColor" d="M3.9,12C3.9,10.29 5.29,8.9 7,8.9H11V7H7A5,5 0 0,0 2,12A5,5 0 0,0 7,17H11V15.1H7C5.29,15.1 3.9,13.71 3.9,12M8,13H16V11H8V13M17,7H13V8.9H17C18.71,8.9 20.1,10.29 20.1,12C20.1,13.71 18.71,15.1 17,15.1H13V17H17A5,5 0 0,0 22,12A5,5 0 0,0 17,7Z"></path></svg>
<span class="visually-hidden">View at the Open Library</span>
</a>
</li>
</ul>
</div>
</article>

I also took the opportunity to clarify the difference between “authors” and “editors” for several books. I removed the distinction from the content and put it into the microdata instead. This does seem wrong in a certain sense — providing the value for machines and obscuring it from humans, but it does make the design cleaner and more consistent. It’s probably something I’ll have to tackle in a future update though. The same is true with some of the other UI details such as the category labels in each book card. Looking at them with fresh eyes, I should probably include some sort of legend or maybe a tooltip. Along the same lines, I can now probably refactor the CSS a bit to style the content using the microdata attribute selectors instead of my custom classes (eventually).

Using structured data in this way also tracks with the “less Javascript is more” idea I’ve been working towards. Adding a <script> tag to the HTML for JSON-LD still feels like regular ol’ Javascript and as such, overkill (even if it isn’t).

Working through all the books, I then circled back for the comics which had a similar pattern but with a few differences unique to them. Namely involving how to indicate each issue number in the series. One or two more production sessions and I was able to update all those entries as well. Again, like with the author’s name, the only change to the HTML was adding an extra <span> for the issue number. Here’s an excerpt from one of the comic book cards.

<article class="book-card fiction comic" itemscope itemtype="https://schema.org/ComicSeries">
<div class="book">
<h2 class="title"><cite itemprop="name">The Uncanny X-Men</cite></h2>
<h3 class="subtitle" itemprop="hasPart" itemscope itemtype="https://schema.org/ComicIssue"><span itemprop="issueNumber">#170</span></h3>
<p class="author" itemprop="author" itemscope itemtype="https://schema.org/Person"><span itemprop="name">Chris Claremont</span></p>
</div>

<!-- more stuff -->

</article>

One of the weird things I noticed when reading up about using microdata versus JSON-LD was the criticism based solely on the the microdata making the HTML “messy.” And by weird, I mean ridiculous. Given the popularity of utility based CSS frameworks (ahem, Tailwind) filling HTML elements with long strings of classes, it’s a bit silly to criticize microdata for “messy” HTML. And by silly, I mean stupid.

Opinions aside, I’m really excited to get this all in place and to keep using it as I add more books. Even though search engines seem to be dying of self-inflicted AI wounds, I’m still a firm believer that structured data will always be beneficial. Somehow, adding this microdata makes the me feel like the the page is more robust and future-proof. Heck, if it helps one person find a book, it’s all worth it.

Visit the library

A review of the progress and discoveries.

Read last year’s inaugural post or view the updated photo gallery.

Coming out of last year’s post on the project and my efforts, I was feeling a bit defeated. There’s just so much to clean up that the task seems insurmountable and the effort insignificant. But I still love going out in the woods and I’m not going to ignore a problem I could help to solve. Overall progress was a bit lighter in 2024 for two main reasons.

1. Recovery: After 2023’s massive effort, we needed to let the forest heal from the scars of removing all that large scale commercial debris. Overall, less disturbance to the forest meant less trash removed. This was particularly true over the summer.
2. Terraforming: It seemed like the maintenance and upkeep of our own little forest wildflower yard garden took a lot more time than in 2023. I imagine this is somewhat cyclical and 2024 was just one of those years where the long term tasks all needed attention. It also seemed like a really hot summer which led to exhaustion earlier in the day and less hikes into the forest.

The Trash

With the reduced emphasis on tackling the commercial dumping, I was really just picking up small loose items to fill my pair of trusty five gallon buckets.

Using the same conservative estimates from 2023, 50 pounds per bag comes out to 650 pounds for the bags. For the buckets, 5 gallons at 8.33 pounds per gallon comes out to 41.65 pounds. The more conservative estimate per bucket is probably around 20 pounds. This leads to a total of 1,060 pounds of trash put in buckets. All combined for a total estimate of 1,710 pounds of trash removed in 2024. Nearly one ton (0.855) of trash removed from the forest. Not bad at all.

Given that the effort was not on the large scale commercial dumping grounds, but rather on the small bits of trash and debris, there weren’t many “wow” items pulled out. This also led to fewer photos in the gallery, because…once you’ve seen a photo of a beer can, you don’t need to see them all. One fun item was the cast iron water main cap that I’m now using as a cigar ashtray.

• Car seat (2): Not a child safety seat, but actual seats from cars with metal frame, fabric, foam, etc.
• Bottles
• Cans
• Plastic
• Styrofoam
• Broken glass
• Paper
• Scrap metal
• Construction debris
• Golf balls
• Toys
• Balloons
• Tools

The Design

No significant changes to the design of the gallery this year. I’m still happy with the look and feel, so it was just a matter of updating the typography for the year subheads.

The Development

The code for the gallery did get an overhaul this year, most notably from my recent foray into using srcset on the img tags. Taking what I learned from building my new photo page, I started creating the different necessary image sizes, but decided not to go as crazy. The grid items in this design are much more consistent across larger viewports, so I didn’t need to create as many image options for the browser. I settled with three sizes: 220px, 460px and 1440px for the modal.

<img srcset="img/02-10-2024-220w.webp 220w, 
    img/02-10-2024-460w.webp 460w" 
    sizes="(max-width: 479px) 460px, 220px" 
    loading="lazy" src="img/02-10-2024-220w.webp" 
    data-img="img/02-10-2024.webp" 
    alt="A silver dented car wheel hubcap." class="thumb" loading="lazy">

I also found another responsive image testing tool, but it seems…too opaque? There’s really no indication what it’s testing against or what’s going on. I remain skeptical.

This change also meant a rewrite of the Javascript for the modal popup. Previously, the modal grabbed the image source path and used it. With multiple image sources — and wanting to have a larger image size just for the modal — I switched to pulled the correct image path from a new data attribute. Data attributes are great and I really find them to be helpful in connecting the dots between design and function.

This works great, but does introduce a bit of a delay as the image loads — particularly on subsequent images. The first time you click on an image, it loads fine, but close it and click on a second image and you’ll see the first image appear briefly before the second image loads. I’m not sure if it’s due to the lazy loading I added to all the images or just a caching issue or something more granular with the JS where data attributes take longer to load than a direct image path. In any case, it’s something I can live with (for now). Perhaps I can modify it with a CSS transition to make the image swap seamless instead of so jarring.

As an aside:

This is a common scenario for web designer/developer/engineers in the corporate world. “I can’t change the functional code, so I’ll try to improve the interface with a bit of slight of hand to make the experience less irritating.”

There were also some other small performance upgrades as well.

• Switched to serving the main typeface locally rather than via a third party.
• Changed all the image formats from JPG to WebP. (I kind of wish we could start using the JPEG XL format, but there’s not enough browser support.)

All of these updates also meant going back and updating all of last year’s content. All new images sizes and code edits for all of the 2024 images. Not difficult, just work. Good to do while watching sports or binging some other trash TV. Just a little visual/auditory ambient distraction as you tackle each little production task.

Looking Ahead

The new year has started with a burst of renewed energy and it looks like I’ll be able to clear out a ton (literally) more trash this year including more of the large scale commercial debris items. Although, it’s harder to find ground items in the winter, the lack of vegetation allows for more visibility into areas that are completely overgrown in summer. Plus, there’s no (or very little) home terraforming chores to handle. I’ve already scoped out two new areas in need of help and added them to my ongoing list. I’m mostly waiting for the ground to thaw out before starting. Here’s to making your little piece of the world a little cleaner, a little brighter and a little healthier for the future.

Please don’t litter.

View the updated photo gallery

Another step in recapturing content: Bringing photos back in-house.

With the ongoing enshittification of the platforms we once trusted, I took another step towards untangling myself from corporate social media. I finally committed to stop posting on Instagram and return to posting my photos on my own site.

View the photo page.

Background

After years of immersing these platforms into out digital lives, it’s unsurprisingly tedious to extract yourself from their tangled grasp. I’ve been dutifully moving certain projects off of Instagram and over to their own pages. The one big theme that is still hanging around is…the more general “photo” theme.

Design

Nothing too fancy in terms of the page design: fit into the site’s theme, basic full width grid for the photos and easy to update. Luckily, I’ve been enamored with the square aspect ratio for a while, so the layout was simple. Letting the photos stand on their own was also the point, so there’s no titles or copy to account for in the design.

Development

Since the design is so simple, I did want to add a bit of complication to the development side. I’ve been playing around with a few image gallery options, but didn’t really want to add the overhead of Javascript. Instead, I decided to use the page as an opportunity to once again tackle the image srcset property. Now, I’ve used srcset in production before with the picture element, but it’s always been confusing. In this case, I wasn’t interested in art directing the photos across viewport sizes or layouts, but merely trying to provide alternative sizes for better performance. This made adding the srcset property to the img element the best option.

As I mentioned, the spec for the property never seems to stick in my head. The production part is easy enough: create different sizes of each photo based on what size is needed in the layout for different viewports. For the code itself: add a list of source paths to the images along with media queries in the sizes attribute to give the browser a hint as to which image to use. Plus, provide a default fallback image path. It looks fairly straight forward, but there’s a bunch of interacting parts that always confuse me. Here’s my initial attempt with two image sizes for 480px wide and 720px wide. (Don’t forget the alt text either!)

<img srcset="blue-420w.webp 420w, blue-720w.webp 720w" 
    sizes="(max-width: 768px) calc(100vw - 4rem), calc(100vw - 6rem - 224px)"
    loading="lazy" src="blue-420w.webp" 
    alt="A dark blue sky in the top left with the silhouette of bare trees coming in from the bottom right.">

But…once you try to test it out, things start getting more complicated. Looking at the browser dev tools as you resize the window appears to load the correct image, but it also seems to show the incorrect size when you hover over the img element. The dev tools network tab does a better job, but still doesn’t adjust on resize or provide any insight into how the browser is processing the srcset setup.

It’s worth mentioning that the other reason I started with two sizes is…laziness. The performance value of srcset (and the picture element) run up against the additional production work of creating all the different image sizes. After 14 years on Instagram, the sheer volume of photos to process is daunting. Even discounting some of the other themes and culling many photos altogether, it was a bit to much to think about at the start. Starting small, cherry picking just a few images and just tackling two sizes kept the project moving.

Right. Basic layout and images formatted and set up in the HTML. Now on to that testing conundrum. It quickly became clear that the combo of my two images sizes and the media queries weren’t really helping anything. Turns out the layout didn’t really help simplify things either. The three column layout necessitated smaller images at larger viewport widths and the one column layout (below 768px wide) required large images initially — and then smaller images as the viewport shrank. So…two layouts needing three (or more) media queries to load two (or more) image sizes. This is where my head starts to hurt and I start to think, “there should be a tool for this”.

A bit of research and luckily, I was able to find this linter for responsive images to help my debug and build better media queries. Just run the bookmark (or Chrome extension) on your page and it will run through the images and conditions to make recommendations. In looking at my page, it recommended two different sets of potential image sizes and a new set of media queries. As I suspected, it meant creating more than just two image sizes, so I relented and braced myself for more production work. I went with the more lengthy size list recommended by the linter which meant abandoning my previous two sizes. Here’s the new code:

<img srcset="blue-256w.webp 256w, 
    blue-609w.webp 609w, 
    blue-888w.webp 888w, 
    blue-1240w.webp 1240w, 
    blue-1510w.webp 1510w, 
    blue-1740w.webp 1740w, 
    blue-1940w.webp 1940w" 
    sizes="(min-width: 780px) calc(33.33vw - 32px), 
	(min-width: 380px) calc(100vw - 64px), 
	calc(60vw + 80px)" 
    loading="lazy" src="img/photos/blue-609w.webp" 
    alt="A dark blue sky in the top left with the silhouette of bare trees coming in from the bottom right.">

So now there are seven image sizes to pair with the three media queries. A bunch more production work indeed. This immediately took me back to using the picture element in production, i.e., creating tons of different sizes for each image. I ran the linter again and it was happy, but I’m still not satisfied with the testing scenario. I think there’s an opportunity for browsers to really clarify which condition is being met and why it’s choosing a particular image size. Maybe I just need to start using a browser just for development.

The linter did seem to get confused on a couple of occasions. The first issue occurred as I added more and more images. Using the bookmarklet in Firefox caused the linter to hang and eventually crash. I suspect it’s just trying to handle too many options and runs out of memory. Switching over to Chrome and using the extension worked fine and didn’t crash. The other issue was a bit more esoteric. For a few of the images, the linter gets confused and thinks I’m using the srcset image list for art direction (using images with different content) when I’m not.

Images in srcset attribute must not be different

It seems the image name-609w.webp doesn’t show the same contents as name-1940w.webp does, the determined difference is 5%.

This is an issue I wasn’t able to resolve. Recreating the image sizes didn’t help. I can only suspect that the linter is choking on the pixels values between the small and large sizes. Perhaps it has something to do with the compression.

From there, it was just a ton of art direction to curate the next row of images, size them all, compression, format swap, update the HTML and repeat, repeat, repeat. Perhaps at some point, I set up a Photoshop action or Automator workflow to batch process the images, but that’s another project. I think the hardest part has actually been finding the original files. I end up cross referencing my phone with my export from Instagram and various external hard drives only to often discover a specific photo is only in one or two of those locations. Sigh.

Testing & Next Steps

Looking at the PageSpeed performance and it seems like Google is happy. Here’s the desktop score. The mobile score is almost identical with only the performance score being a tiny bit lower at 94.

PageSpeed is still mad at me (naturally) as the volume of photos keeps adding up to a large payload, but whatever, it’s my page, the images are set to lazy load and hopefully visitors are taking their time to actually look at the photos. Perhaps, I’ll limit the amount of images on initial page load and add a “show more” button to reveal more. Might be a good UX update to play around with in a future update.

I’m also not sure if PageSpeed is accurately evaluating the responsive images sizes. It’s still saying I need to size the images properly. Admittedly, I will need to go back and work on the image compression again to help reduce the overall page weight. I suspect I may need to add another image size to the srcset list and adjust the media queries to handle it. I’m just not convinced its working at it’s optimal best yet. I’ll also do more extensive performance testing with other tools to get comparison metrics.

Looking ahead, there’s still many more photos to process, so like the virtual library, I’ll add this page to my monthly backlog to update as I find time. I’m sure I’ll also need to adjust the layout for photos with different aspect ratios as I’m hoping to dive back into actual film photography soon. For now, this page is just one small step ahead to reclaim my content so keep checking back to see what I post.

View the photo page.

Drawing (and redrawing) the patterns from some old favorite clothes.

View project page

Digging around the dusty corners of an old hard drive when I came across a pattern I had drawn way back when. The pattern on the left was actually from one of my favorite 1950s style jackets. I don’t know where the jacket went, but I do still love that pattern. The one on the left is from a shirt I still own. More on that pattern later.

When these were originally drawn, I did them in Adobe Illustrator and saved them as Illustrator swatches which is kind of telling as to how long ago it was. Repeating patterns as swatches were new and exciting and Illustrator was the main tool of choice in my work. There wasn’t a whole lot of web design work back then and print ready vectors were mandatory.

Like a lot of my recent archive discoveries, once again, the project was how to update these files for the web.

The Design

Since the patterns were originally swatches, I used that idea as the main design feature. I’ve been creating a few varieties of UI cards for work, so I had a head start on what I needed. Card interfaces are all over the web, but I definitely wanted these to be closer to Pantone or paint chips. There’s a couple of different card options to show the pattern specs, the full repeating pattern and then the individual colors.

For the typography, I wanted something a bit retro to reflect the 1950s period, but without looking too stylistic. I also wanted to branch out from the usual sources and find some new fonts. Being able to self-host the files and if possible, use a variable font were also on my requirement list. Luckily, I found everything over at Fontshare. The main heading is set in New Title and the subheads are set in Clash Grotesk. The really narrow letterforms of New Title definitely had that retro feel I was looking for. I’m also still completely enamored with big chunky sans serif faces, so Clash Grotesk definitely caught my eye. All the rest of the text is set to a general system sans serif for speed and ease (or laziness while coding if you like).

For the colors, I’m still stuck on using the Flexoki palette as I love the warmer print-like tones. Once again, I didn’t really use the full palette, but that’s okay. I also didn’t go overboard and create multiple color themes. Just dark theme for this page, thank you very much. Now, the colors used in the patterns themselves are not from Flexoki and were eyeballed from the clothes themselves as part of the drawing process. It’s also worth noting that the color names used in the patterns are totally made up marketing copy. They’re not accurate in any way. I just wanted some fancy titles for them. Use the actual color values if you want to replicate them.

The page design is also the same basic template I’ve been using for these little projects: header, main, footer. Nothing crazy as it let’s me quickly get to the fun stuff.

The Patterns

The quickest way to get the patterns ready for the web was to export them out of Illustrator as SVG files. Add in a bit of compression and optimization and the SVGs were ready. I’m using the plural “patterns” here, but I should clarify. The whole project idea started when I found the first jacket pattern, but as I started working, I found I had previously drawn another textile pattern back in 2012. This was the shirt pattern. Turns out my love of patterns has taken many forms. Even though I had blogged about the shirt pattern, I had only provided it as an Illustrator swatch, so including in this new page seemed like an obvious next step. Creating SVGs for the web is pretty standard fare these days and while it’s one of my favorites, I did want to push things a bit further. Hence, some code exploration.

The Code

General page design is still based on a responsive CSS grid with three columns and a few column/row spans for the larger cards. Nothing fancy. The real challenges came when I started looking closer at the jacket pattern. It’s essentially a pixel pattern — which made me thing of a grid pattern — which made me think of CSS grid — which made me do something silly. I created the entire pattern as a CSS grid with each cell representing a pixel on the pattern. Of course, the pattern is 17 x 17 for a total of 289 squares.

(Why the original pattern was 17 x 17 is beyond me, but it made the math more painful than necessary. I actually typed up a cheat sheet with the numbers for easy reference.)

Yep, that’s right. I created a grid with 289 empty <div> elements. Genius, I know. I then set up background colors for the red and black squares with a massive list of :nth-child() statements. Being responsive, it does get squashed when the viewport is resized, so beyond the insanity and performance issues with all those DOM nodes, it’s not an ideal method. The SVG is still better.

Just because it’s possible, doesn’t mean it’s a good idea. But knowing that didn’t stop me from trying another crazy idea. I’ve been playing around with creating background images with multiple linear gradients. Knowing that we can create hard lines between colors with stops in the gradient, I set out to draw the 17 x 17 jacket pattern as a gradient. This method, like the massive <div> list, was an effort in persistence. Getting the pixels lined up was a complete pain, not to mention all the sizes for the 17 gradient rows, but I did learn a bit more about these complex background images. I even went a step further and created a version of the gradient using percentages instead of pixels. This certainly helped and brought closer to the CSS grid version in terms of flexibility, but also the same limitations. In the end, I didn’t even include an example of the gradient on the page although I did keep it in the CSS file for reference later.

Learning all those lessons, coupled with the more intricate pattern of the shirt, I didn’t even attempt either a grid or gradient solution for the second pattern. It might be possible, but after all that experimentation, I didn’t have the patience for more.

Overall, I’m happy with the lookbook design and chip cards. Getting these old projects some new life in a new format is always fun too. Head on over check it out and download the pattern files.

View project page

Redrawing the original set of civil defense badges from the United States Civil Defense Corps created in the 1940s.

View the project page.

As has become apparent over the last few years (and even decades and centuries before), we are each responsible for our own safety as well as the safety of our communities. It seems this is a lesson we forget and relearn in a cycle of storms, accidents and tragedies. This concept of mutual aid is once again in vogue and becoming more prominent as we begin to see epic environmental changes occurring in our own neighborhoods. When “once in 100 year” events start happening every year, we’ll need to pool our resources and efforts to survive the floods, droughts, storms, fires and freezes.

Luckily, we’ve done this before. During WWI, the U.S. government started what would later become known as the Civilian Defense Corps.

Reading up on the history, I was excited to see that each group had their own badge and more importantly — they were awesome. Really great, simple yet functional pieces of graphic design united in theme and purpose. Unfortunately, as I searched further, I couldn’t find much about the logos nor could I find the badges themselves. So I set out to redrawn them based on an original document from the period. And that inspiration provided another opportunity to work on a little web design and development to showcase the badges.

The illustrations

Redrawing the badges looked difficult at first, but creating a base template for the logo with the appropriate shapes and colors streamlined the process. Are the final results 100% identical to the originals? No, but they are very close and faithful. I didn’t make any creative or editorial decisions (suppressing all my art director experience — I really wanted to realign each). Each was then exported to SVG and optimized for the web.

Design and development

Now that I’ve got a few of these one off pages created, the ramp up process is much quicker. It’s not quite a template, but it is a starter pack of sorts. The Rorsch project was a great starting point given the retro vintage styles used. But…I didn’t want that much retro. I didn’t need the super distressed paper, but did still want the look and feel of that old manual. I pulled a sample of the paper from the manual to set as a background-image and then applied a background-blend-mode of multiply against the base background color. I did the same for one of the standard grit textures I have on file, but with a different blend mode. Being able to set multiple background images via CSS is a real game changer in terms of design possibilities. I’ve used the same technique, but with gradients, in other projects to draw complex backgrounds instead of using a raster file.

The big change for this project was to try out using an SVG filter to add a layer of noise over the entire page. I tried a couple of different ways to get it to work properly and finally ended up putting the SVG filter into the CSS as a background image and then setting the mix-blend-mode to hard-light. I dropped the CSS class onto the html element so that it covered the entire page. Along with the fractal noise distortion, the hard light mode did change the colors a bit, but it works as it almost de-saturates them a bit enhancing the retro style.

For the type, I wanted to match the styles in the PDF source, but…I couldn’t go as far as to use that cursive subhead font. It was just too much. The sans serif headers are Alternate Gothic to get that compressed letter width. The serif is FF Seria and despite only being used once for the intro text, I still wanted to try to match the style of the manual. Both are served via Adobe fonts which isn’t ideal from a performance standpoint, but it is convenient. I do wish Adobe would come up with a self-hosting option for customers.

All the SVG files are loaded via a standard img tag with a figure tag which allows adding a figcaption tag inside to drop in the badge name.

Packaging up the set of SVG files for a download was the final step. Hopefully, we don’t need them in the future, but it’s always a good idea to be prepared!

View the project page