New release: a family descendancy list generator. (The first version of one, anyway. It’s still pretty new.) It’s a web app that lets you enter a descendancy list in a text-based format like this:
And you then get something like this when you print:
Seven years ago I started making these types of charts in Google Docs, which worked out okay, but I got tired of fiddling with tab stops and here we are.
This marks a change from how I’ve been building genealogy chart apps, by the way. CLI scripts are all well and good, but doing it this way should hopefully be a lot easier for people to use.
Because of that, I’ve always seen myself as a publisher first and then everything else second.
This, particularly the second point. I’ve seen myself as a publisher for a long time now as well, with all the books and language charts and magazines and even the art. And the web makes publishing so, so easy. It’s magical. Instant worldwide distribution. (Well, instant for the digital things I make.)
His first point has stuck with me as well — I’ve tended to think of my site mostly as a place to publish PDFs and EPUBs and images and other files I’ve made, but I like the idea of the web as the actual delivery mechanism, for more than just blog posts. This isn’t a new idea, of course; it’s just something I haven’t been thinking about as much till now. I’m looking over the type of things I’ve made — books, languages charts, etc. — and thinking what it would be like if the end product were a web page instead of a PDF or an EPUB. And of course nowadays I’m using HTML/CSS as the source for all three main formats for books (web, EPUB, PDF), so it doesn’t necessarily have to be either/or.
Anyway, nothing specific in mind yet. We’ll see what comes of it.
A short followup to what I wrote last year about Press, my abandoned typesetting engine project: I’m now fully convinced that the web platform is where I want to do typesetting. It’s open, programmatic, and capable. Source files are plain text, easy to version control, and fairly future-proof. And even though it’s not WYSIWYG — at least not the way I’m using it — it’s much more comfortable for me as a working environment.
For non-book work (charts, some kinds of documents), I’ve found that browsers already support everything I need (like @page). That’s how I’ve done all my recent genealogy design work, and it’s how I’ll do any language charts I make going forward. And for things like books where browser support isn’t quite there yet, Paged.js works well (and will presumably be phased out once browser support gets better).
Not to mention how nice it is for both print and digital workflows (EPUB, web) to all use the same technologies. I also love that the web is cross-platform. Something I ran into when I was making charts with PlotDevice (which is Mac-only) was that people on Windows couldn’t modify the charts even when I gave them the source. That’s not a problem with the web.
I’ve even started using the web platform for less webby things like making wallpaper for my phone:
Here’s the HTML (the 375×812px size is the CSS resolution of my iPhone 12 Mini — RIP — and also keep in mind that this was for a one-off never to see the light of day, so I took the liberty of cutting a few corners):
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no" />
<link rel="stylesheet" href="style.css" />
</head>
<body>
<div class="background">
<svg id="darknoise" viewBox="0 0 375 812" xmlns="http://www.w3.org/2000/svg">
<filter id="noiseFilter">
<feTurbulence baseFrequency="0.5" numOctaves="8" />
</filter>
<rect width="100%" height="100%" filter="url(#noiseFilter)" />
</svg>
<svg id="lightnoise" viewBox="0 0 375 812" xmlns="http://www.w3.org/2000/svg">
<filter id="noiseFilter2">
<feTurbulence seed="485" baseFrequency="0.005" numOctaves="12" />
</filter>
<rect width="100%" height="100%" filter="url(#noiseFilter2)" />
</svg>
</div>
<div class="quote">Come unto me, all ye that labour and are heavy laden, and I will give you rest.</div>
<div class="reference">Matthew 11:28</div>
</body>
</html>
It’s not the world’s most amazing wallpaper or anything, but I’m still pleased that I was able to make something I’m reasonably happy with using technologies I love. (I could have also used WebGL shaders or Canvas. Lots of options!)
Lately I’ve been playing around with implementing genealogy sparklines on the web. Still very much a work in progress, but I’m trying to do more working in public, so here’s the messy current status (and at some point I’ll post the actual HTML/CSS):
Ruby test
Implementation notes:
The sparklines use inline SVG
This test uses the <ruby> and <rt> tags, with ruby-position set to under and ruby-align set to start (though only Firefox supports it so it’s not sadly viable for actual use yet)
I don’t really like that it makes the leading uneven (lines that have ruby vs. lines that don’t)
Design notes:
Rather than having solid squares at the births and deaths, I’ve gone for vertical lines so they’re less obtrusive (and have also considered just getting rid of the vertical lines, though I haven’t tried it out yet)
Circles are simple so I went with them for marriages and children
Absolute positioning test
Implementation notes:
The names are wrapped in span tags with position: relative set, and the SVG gets position: absolute. Fairly simple.
Even leading!
There’s some wonkiness right now when the span is at the beginning of a line (the sparkline shows up at the end of the previous line), haven’t tried very hard to fix it yet
Tim Daub on how he builds JavaScript apps in 2021, which I suppose is also in a similar vein. Sensing a theme here. (And much of this resonated with me. The more minimal the build process, for example, the happier I am.)
I seem to have forgotten how to blog. (Actual blogging, as opposed to merely linking to new art.) In an attempt to get back on the saddle again:
Outside of art, my project time lately has primarily been swallowed up by some internal tooling changes. I alluded to this back in June, though the plan changed along the way. Rather than merging all those apps into one behemoth conglomerate, I decided it would be better (along at least a few axes) to follow the Unix philosophy and stick with smaller tools that do one thing well. Which conveniently lines up with the set of tools I’ve already built. Fancy that.
Arc is (was) my notes app, written using FastAPI. I wanted an app that felt more a wiki, and I wanted to move it to Django (easier to maintain, considering most of my other tools are also in Django). And I didn’t really like the name anymore. Thus Codex was born. Heretically, I built it using hardly any JavaScript — just a bit for keyboard shortcuts and another bit for the autosuggest when linking to another page. Everything else uses plain old HTML forms.
In fact, it was so liberating and fun that I plowed onward and decided to ditch Vinci (my internal blog/notebook app) and build a new app, Leaf, using the same technique; the only JS it uses is for keyboard shortcuts. It’s simpler, easier to maintain (I think? it’s still early on), and in a way it feels more in line with the grain of the web.
One other thing I did differently with both apps was to wait to write any CSS until after the functionality was all in place. It was disconcerting and delightful, building something with bare browser styles, and it certainly helped me focus on functionality first rather than getting distracted by layout.
Conclusion: while I doubt I would ever build apps at work this way, this old-school mode was invigorating and absolutely worth it for these personal projects.
