Structured
January 25, 2025
Updating my library for a better future
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.
