Running your own microblog status widget for your blog

After about three months tinkering with the new site template, when I finally launched on a Sunday night, I decided to spend at least a week letting it sit before I did anything else — give the brain some time to recharge and see the new template with fresh eyes.

But of course, cleaning up gathered links and samples from the process, I was reminded of Mu-An Chiou’s site — wonderfully minimal, open source, and with the understated status “microblog” sentence at the top.

There’s something that feels charming about being able to say, however old what you’re reading on the site is, here’s what I’m doing right now (or, lifting entirely Mu-An Chiou’s elegant relativeDate script, X many hours ago).¹ Your solitary visit to this website perhaps isn’t so solitary. It feels a little arrogant — does anyone actually care what I’m reading this weekend, I ask myself — but I know I like it when I encounter this kind of thing on other websites.²

So Mu-An Chiou’s site reminded me I wanted to make a microblog status widget “one day.” The answers to how to go about it, however, came to me swiftly enough that indeed, come the following Tuesday, I had failed to take a break from the site and instead gone ahead and added that widget. These were my operative questions:

1. How to host the text for the status widget?
2. How to present the status widget on the page?
3. How would I keep the status widget updated?

Hosting the Status Widget

Mu-An Chiou hosts her status information as a text file on GitHub Pages. There’s one line for the timestamp and one line for the status itself, which is split and processed by a JavaScript function. GitHub Pages is a good option, but I don’t currently have an account there, and I was looking for a solution that didn’t add to my stack, so to speak.

I do, however, have an account with Google’s Firebase, using their Realtime Database to serve the “New Collections This Week” box you’ll see on the site. I have no idea if I’m doing this right, but I think if I want to serve dynamic content (a list of comics collections being released in the current week) across a variety of posts (probably 100+) without hard-coding it in each post and changing it each week (an impossible task), then I need to store that information in a database and use JavaScript to fetch it on page load and serve it to the site. I am wary of adding too much JavaScript to the site and sensitive to the needs of users who might have JavaScript turned off, but this is for an additive function and not for the main content itself (and I provide alternate non-JavaScript content in the same space).

So, Firebase. I’m on the free “Spark” plan, and again, while my understanding is tentative, usage statistics suggest that with both the “New Collections” material and the microblog status widget, I’m using less than 1% of the free plan’s storage and download limits. This makes sense, since for the status widget we’re essentially talking about storing/serving a timestamp and maybe 50 or fewer characters, so less than 100 bytes. Hardly a big load (I imagine a more significant usage would involve letting users store data), with the result that hosting the microblog status widget information as JSON on Firebase doesn’t cost me anything.

Presenting the Status Widget

I’ve done my “New Collections” box for a while as a shadow DOM (which sounds creepy but is perfectly innocuous), but I recently changed it to a more straightforward JavaScript DOM update. Seemingly the real value of shadow DOM content is easily serving dynamic code from a third-party (whereas this is my own content) and also separating the component’s styles from the site styles (whereas it would actually be easier to write the component styles into my own style sheet). An early draft of the microblog status widget added it to the site via shadow DOM, but then I ran up against styling issues, so the current iteration simply fetches the microblog status information from Firebase and then adds it as text content to designated “status-update” tags.

My navbar section was already a CSS grid, so it was just a matter of adding another row to the grid, initially populating it with a non-breaking space, and if the user has JavaScript enabled, that non-breaking space changes to the status update. The presence of the grid row irrespective of whether the user has JavaScript enabled or not means that the content doesn’t “bounce” and the bottom of the page doesn’t move depending on whether you have JavaScript enabled; it’s only that the white space between the navbar and the first post title is “emptier” if you’re not seeing that extra line of status text. I’m not thrilled with having a blank grid row but it seems like the best solution for now, short of having X margin for one occasion and Y margin for another.

How to Update the Status Widget

Everything I ever learned from James Clear’s Atomic Habits told me that updating the microblog status widget needed to be simple (a quick and seamless process) and easy (at my fingertips). Another checkmark for Firebase is that it has a REST API, which I was already using for updating the “New Collections” boxes. There, however, because it involves pulling book data out of another one of my databases and then having to cross-reference for delayed titles, etc., I use an intermediate text editor to hold the JSON while I check it. For the microblog status widget, I wanted a one-step process and not a two-step process.

Another wrinkle was that, while the status updates are meant to be ephemeral on the site, I did want some kind of historical record of them. So, I needed a simple and easy way to write (essentially “overwrite”) to the Firebase database and also write to my own record.

This one wasn’t too hard: Shortcuts for iOS and macOS. Among its foibles, Shortcuts is rather handy at writing to REST APIs; the shortcut prompts me for the microblog status update text, I write it, it grabs the current timestamp on its own, and it sends it along. The process is quick for me and the site is immediately updated on next page load. For historical record, the shortcut at the same time appends the status update and timestamp to a Markdown file within my Obsidian vault, still with the only interaction from me being writing the microblog status update in the first place.

Ultimately, what seemed a daunting task — how to have a dynamically updating piece of text on my site separate from the main post flow — didn’t turn out to be that hard at all. The simple(?) stack for the status widget is Firebase, JavaScript, Shortcuts, and Obsidian.

Mostly I use the microblog status widget to keep a running message on the site as to what comics I’m reading or writing about. I see it as bridging what’s sometimes a disconnect between when I review a book and when I post that review, which might be weeks (and a number of subsequent books) later. You haven’t been reading in real-time with me before; now you are.

---

1. I have a strong memory of encountering a feature like this on another website, though I don’t seem to have it bookmarked like I did Mu-An Chiou’s. The status is up at the top, and maybe it rolls out with a kind of faux cursor typewriter effect. Ring any bells? I thought about doing a typewriter effect here but decided it was more than was needed, though I do like the additional illusion of immediacy.  ↩︎

2. Thinking about this a half-second longer, I’m reminded this site already had a microblogging widget of this type in an earlier iteration. Two of them, in fact – RSS-type embeds from Facebook and Twitter. Which I removed when each of them stopped working. Given the current climate of things, I much prefer serving JSON content through a REST API, something that’s eminently transferable if Firebase weren’t an option. The ultimate reliance on plain text is why I like Obsidian, too.  ↩︎