Hovercards and Cover Images

I’ve been toying with the idea of adding hovercards to this site for quite some time now. Some things were holding me back, my lack of technical competence not the last among them, but I finally did it.

The final push was reading about the visible links idea which makes a lot of sense to me. As that article points out, Wikipedia does hovercards for a reason, and while I don’t claim my writing is similarly important, the general idea of giving a reader more context with less effort is rather appealing.

One thing that has been holding me from attempting to implement this feature earlier is mobile. Hovercards don’t make sense with touch-screen interfaces and I was reluctant to add to my website something that would be unusable on mobile. Not that I’m a huge mobile fan, but I try to make sure my site is available and accessible on mobile, too. On the other hand, the gitweb interface is hardly accessible on mobile, either, but nor does it make real sense to access it on mobile, so I have it on my site. Wikipedia doesn’t do hovercards on mobile either; what works for them is good enough for me, I suppose.

With these thoughts, I went on to get my hands dirty with the technical side of things. It was very nice of  capjamesg to have recently sorted out all the hard stuff (I know, I know, I need to teach myself JavaScript for real), so I didn’t have to start from scratch. Of course, I don’t use the backend James uses, so that’s what I needed to sort out on my own.

Where should the information for a hovercard come from? The most straightforward approach is to use the information that the linked page provides about itself. For the reasons I laid out earlier, I didn’t want to pre-fetch and store that information the way James does, so the obvious solution was to leverage indieweb-glue. Of course, it had to be taught to return the information about pages in addition to people. One form for a page to provide such information about itself is the Open Graph protocol, it is rather widely used, so that’s what I decided to start with.

After some mild code refactoring, I added Open Graph meta tags processing to indieweb-glue and modified James’s script to fetch the information from there. I also made it look for a specified class instead of an <article> tag since it gives me more control over which pages and parts of the pages hovercards appear on. With some CSS thrown into the mix, it’s all working quite to my satisfaction now. Surprisingly so, I must say.

As an added benefit, the same script can be used to produce hovercards for footnotes¹ on the fly, and that’s something I’m even more fond of. Footnotes have been my pet peeve for a long time. They are a really nice instrument to have when writing a text, allowing one to avoid interrupting the flow of thought with distractions and digressions. However, in digital media, footnotes are often hidden beyond the screen edge, and scrolling or following a link to look at them is usually too much distraction. On paper, all you need to do is look down, and we are good enough at returning our sight focus back to where it was on the page so that taking a look at a footnote doesn’t interrupt our reading process too much. Having footnotes in hovercards feels like a reasonable compromise.

The result is not yet perfect, and all this is still a work in progress. CSS needs more figuring out: my hovercards don’t always look good, especially when the image is in portrait orientation. Also, indieweb-glue could (and should) use things beyond the Open Graph protocol to extract useful info from web pages. A good example is Wikipedia: its pages lack og:description, but the first paragraph of the text itself looks like a perfect thing to have in a hovercard linking to a Wikipedia page². I also plan to modify the script so that it recognizes some special cases, such as person mentions, where populating the hovercard with H-Card data is appropriate, for example.

Of course, I’d highly appreciate any comments, advice or thoughts on how to make these things better. For a work in progress, these are always welcome.

As I was writing this post, I noticed that the first link (the one to  Maggie Appleton’s article) produces a hovercard with a nice cover image that is obviously autogenerated. Of course, I immediately wanted something like this for my posts that lack a cover image.

Technically, the Open Graph protocol lists og:image as one of the required properties, meaning that every page should have one. Of course, finding a good (or even acceptable) cover image for every post can be too much hassle. There are three possible ways to deal with it: have a generic site-wide image for all the pages lacking their own images, have the images autogenerated, or have no image at all for some pages. The latter option violates the protocol, obviously, but it is used widely enough, and I also resorted to it until now.

I asked around (in the Russian IndieWeb chatroom, naturally). The way most people (including Maggie) seem to go about it is by using Playwright, a headless browser developed for testing, to open the page and make a “screenshot”. This is a fascinating hack, but it doesn’t quite suit my workflow. I’ve also found a piece of software tailored specifically for Hugo, as well as some more general guidelines on how to generate cover images programmatically with JavaScript or Python. Those guidelines got me really thinking, and I ended up writing a Hugo template that generates a picture automatically for every page that doesn’t have a featured image.

It works, although it, too, is very much a work in progress. Image processing in Hugo is somewhat limited, and also I’m not a very visual person, so these things are always hard for me. It’s currently a very simple script that only uses the site’s favicon, the author information and the page title, and it does (almost) nothing to adapt to the title’s length (so the text would sometimes overflow or look out of place). The good thing is, most of it can be fixed with time, and the script expanded to take into account more information about the page. Still, even as it is, it’s better than nothing, I think. At least every page does have og:image property now.