Creating a catalog of the movies in our video library

View the project

My wife is a big movie buff and so over the years we’ve amassed a large amount of videotapes, DVDs, BluRays and streaming service purchases. It was way back in 2004 that I first got her a Netflix account as a Christmas gift back when they would mail DVDs to your house based on your selections. It might be the best gift I’ve ever given her as we’re still members after 21 years. We’ve certainly gone through the tech conversion process as well — buying DVD versions of videotapes and then buying digital downloads of DVDs. All of which means we have a mishmash of movie formats scattered around — binders full of DVDs, boxes full of videotapes and digital purchases across a variety of streaming services. It’s a bit of a mess despite her valiant attempts to organize the collection to make finding a particular title easier.

So recently…while I was digging around deep in the archives of some old hard drives, I came across an unfinished attempt to build out a movie catalog for us. From the file dates, it looks like I grabbed a design concept from 2008 and used it as a basis for an initial catalog build in 2011. With the recent (somewhat) build (success?) of the virtual library of all our books, I decided to revive this old movie project and finally to bring it to life.

The Design

I’ve been kind of in love dark UI color themes recently — grabbing screenshots and building out example palettes for using in some future project. Finding this old design file turned out to be the perfect project to scratch that dark UI color itch and better yet, it came with a preset colors. Turns out long before theme switching became a thing on the web, I was designing dark UI patterns.

The design is a centered, basic table with the data surrounded on the left, right and bottom with artwork. The artwork style is very much of the early 2000s or at least, very much of the style I was drawing back then. I guess you could call sort of a floral trash glitch. Lots of scroll work with tech elements with noise and grime textures overlapped on top. The bottom artwork is a silhouette of an industrial building, but flipped upside down so that the scaffolding and smoke stacks point downwards.

The Development

The two development challenges were converting the old HTML to a modern layout and switching out of the obsolete Adobe Spry framework the original page was using. Keen readers may remember that I used the Spry framework for the retro client list page I created way back when.

The Colors

Working through all the colors led me down a side quest to create swatch cards for each color. This is not a new idea as I’ve done it before for other projects such as the Pattern Pattern project. This time around though, I wanted to replicate a tool I built for use at work. Namely, incorporating some data attributes and a bit of Javascript to allow for visitors to copy the color values for use elsewhere. Taking it a step further, I converted the hex color values over to OKLCH which is a bit of an aspirational nod to the future (present) to remind myself to really start exploring and using OKLCH values. I’ve tried to make it a bit generic for use with other projects and I’ll probably continue to tweak it and make it a template of sorts. For example, the buttons probably could use some announcement UX improvement.

The Layout

Back on track, I stared updating the HTML structure and layout. The original old file has a single background image. The image pushed the art to each side leaving the middle as a single flat color. The HTML then centered the data table in the center of the page and therefore, on top of the center of the background image. It was a common technique back then, but obviously not relevant today. Centering the HTML on the page is trivial, but updating the layout mean breaking up the single background image. Of course, in the original old files I could only find a Photoshop source file and not the individual illustrations used to create it. Since I wanted to update the raster image to SVG, this led me to reverse engineering the original to convert it back to vector. Maybe someday I’ll find the original files and recreate the complete vector illustration, but for expediency, the new version is not technically identical to the old version.

The Typography

The original used Arial because custom fonts and font loading were in their infancy while services like Google Fonts weren’t even available. System default font stacks were still the quickest option for little projects like this concept. The one trick in the original design was to reduce the type size of Arial significantly which gave it an almost bit mapped or mono space appearance. For the new version, I took this visual quirk and better defined it by switching to an actual mono space font, specifically one of my new favorites, Space Mono. It’s still small to help maintain the look and actually works better as the characters forms are more legible increasing readability and accessibility.

The Content

With the graphics, layout and basic HTML structure updated and in place, it was time to get the massive list of movies into the HTML table. It only took a few minutes of copy pasting movie details into HTML blocks, duplicating the HTML and repeating it all over again for me to realize the manual process was too cumbersome for me to ever finish the project.

So what’s the solution? Like any good craftsmen, it’s to build your own tools, your own jigs. It’s a common enough approach in the carpentry and the idea is finally coming around to web development. Here’s a good post about the connection between craft, tools and jigs and another post with an example jig a designer built for their use. I can relate to both posts as I’m now finding new little parts of the design/build process that need a custom tool or jig to make things easier (and often better). Realistically, I’ve been doing this forever. Every time, you learn a new code pattern, you often reuse the pattern elsewhere. Code building upon code. The color swatch panel is an example. I made it for one specific use case, but I keep finding other opportunities to use it as well as continuing to tweak the features.

In order to speed up the data entry, I built a form. A regular old HTML form with some PHP to handle the inputs and dump them in to a JSON file. This was the jig, the single purpose tool to help me craft the final output. With the form up and running, things became much easier. I was able to flip through binders of DVDs and then tab through the form fields to quickly enter the data. I kept a browser tab open with our Prime video account so that I could jump over there to figure out a movie genre, double check spelling or look up a title. It was a tremendous time saver to say the least. Using the form got quicker with each entry as the browser remembers previous inputs and then allows you tab through the entries. After a few times, I didn’t have to type in the genre anymore, but merely tab through the browser suggestions. Super quick and easy.

For testing, I wrote up a script that took the JSON file and generated the HTML table. This helped catch any errors and typos before they got hidden too deep in the list. Of course, the page was then dependent on the Javascript. No Javascript (due to loading error or visitor setting) and then there’s no table. For the final production page, I took the testing page live output and copied the entire table, pasting it into a new HTML file. This extra step keeps the page static eliminating the table build step. The only Javascript then is for the extra functional upgrades and if it doesn’t load, the table data is still available. This also let me alphabetize the list by title prior to creating the new static page which was handy as the data as originally entered was anything but organized. And yes, that does mean that the build process for this static page is…me, building the page. I’m the build process.

Sadly, I do have to add an aside here: “building your own tools” is not a “website builder,” “vibe coding” or any other artificial “intelligence” no code bullshit. I hand code the tool to help me hand code the output.

The Upgrades

As the list got longer and longer, I took the opportunity to add a few features to help my one potential user, my wife, find a film. This meant two upgrades: search and sorting the table by columns.

The search was a modified version of the one I built for the virtual library. Again, another example of reusing (and modifying) a code pattern for a new project. For this version of the search, I switched from using data attributes to just the text values of the table cells.

For the sorting, I’m not sure where I dug up the script, but it’s certainly a pattern I’ve used before in other projects. Nothing fancy, just a little text comparison, but definitely can help with such a long list.

Summary

Overall, it’s nice to get this project up and running to bring this design to life. I find there’s something really attractive about the table cell separation. It just feels…right. A bit of extra polish for an otherwise ordinary table. The same is true for the mouse over / hover effect on the table rows. It doesn’t do anything, but it’s fun. It’s almost a functional deceptive pattern although I wouldn’t go that far. The cursor doesn’t change indicating a hyperlink and the text itself can still be selected. But it’s a fun highlight effect that might help with readability. It also fits with the retro style. I can almost hear the small beep, chime or click sound as you move up and down the table rows. Hmm…maybe I should add in a sound effect and some tab key navigation in the next revision.

View the 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

 

In these heady days of web design and development, with multiple screen sizes, tablets and smarphones, it can be difficult to get proportions and spacing correct. Of course, one would expect a major retailer to have the resources (and care) to get it right. This screenshot was taken on my laptop with a resolution of 1440 x 900 running Firefox 5 on OSX. Nothing too crazy in terms of a web user profile.

Beyond any aesthetic issues with the check box label being too far to the right, the functional issues (or non-functional as the case may be) are what should be of primary concern here. I suspect many users would stumble over connecting these two parts of the form. If it takes folks an extra few seconds to fill out your form, it takes away from the shopping experience and therefore it impacts your brand.

Will it take away from sales? Maybe not initially. I certainly continued with my purchase, but if users are left remembering that the checkout process was annoying, weird, or heaven forbid, difficult, they may be more likely to head to your competitor’s better designed site.

Small improvements can build up to increase satisfaction and in this case, it seems like an important (and easy) fix – especially as this is one of the very last steps in the check out process – right before you click the “purchase” button.

Seems simple enough – in both common sense and in design – but the evidence is clear.