Bookshelf, my reading tracker, which I’ve been using pretty much daily over the past fifteen years to keep track of which page I’m on in each book and also (via the automatically generated stats) as strong motivation to reach my per-day and per-book page count reading goals. I love it. No plans to move to something else.

Cast, my static site generator, used to build this site for the last year and a half. Glad I finally put in the time to make this happen, because I love static files and having fewer moving parts, and I’ve been very happy with Cast itself. No plans to move to a third-party SSG like Origami or Hugo. (Nothing against those, to be clear.)

Codex, my notes app, which I use daily to track which books I want to read, notes on house and car maintenance, tracking progress on my journal transcription work, story outlines, genealogy research notes, blog drafts (I’m writing this post in it), and more. I like it a lot, but lately I’ve gotten back into taking notes by hand in my Field Notes and other pocket notebooks (as mentioned in the last links post, and probably in other posts before that), and I’m now figuring out when I want to use this app vs. paper notes. Long-lived notes that I modify a lot over time still seem like a better fit for digital, for example. Anyway, no immediate plans to move to something else, though I imagine more types of notes will probably move to paper over time.

Digest, my static RSS reader. It’s been six months so far, and this way of reading feeds still works really well on my brain — the self-contained nature of bundling posts by day is soothing, and instead of feeling anxious that I need (“need,” I should say) to keep up with an endless stream of new posts, I feel like I can read at whatever pace I want to, which usually ends up being every few days instead of daily. I love that each day is its own static HTML file that I rsync up to my server. I also have really loved reading posts on their original sites instead of in a homogeneous design of my own make. Feels much more human and more delightful.

Gate, my quick entry app. I use it dozens of times a day to send to-dos to Liszt and journal notes/entries to Leaf, and it’s working really well. No plans to move away from it.

Leaf, my journal app, where I keep my daily journal and my project logs. While it’s tempting to write paper journals again, I’ve been transcribing my older journals and it’s nice being able to read older entries and search through all of them to find out when something happened, and I don’t see myself wanting to give that up. The app automatically exports each day’s entries to a day-specific text file for extra preservation beyond the database itself, which I love and plan to do in other applicable apps of mine. No plans to move to something else, though I do write some types of entries in my Field Notes.

Liszt, my to-do list app, which I use dozens of times a day, and it’s working well. I love being able to quickly add items via Gate, including multiple items at a time (each on its own line). I love the text-based annotations. (Write that blog post ! #writing 5m marks it as important, tags it, and indicates I should spend five minutes on it.) I love having my daily routine autopopulated in the list each morning. All of that said, however, I do find myself thinking about going back to pen and paper for to-do lists, because I don’t know that I strictly need any of the extra functionality the app is giving me. Also, for the past few years I’ve been using a plain text Markdown file on my work laptop for my work to-do list, and that same model could easily work for my projects where I’m almost always working on them mainly on my laptop. In fact, as I write these words I’m now remembering that when I was younger I used to keep my to-do lists as plain text files. (Part of these thoughts, by the way, come from wanting to move more analogward, and part come from wanting fewer dependencies, fewer moving parts, fewer things to maintain on my server.) Not sure yet what I’ll do.

Momentum, my time tracker, which I use daily to track time (go figure) for scripture study and conference talk study and, primarily, to make sure I’m walking enough each day (for my back pain). It’s nice being able to just tap a button to start or stop tracking, and to see the recent history of how much time I’ve spent per category, but I’ve also been thinking I could probably do this via pen and paper, or via the stopwatch on my phone. We’ll see.

Saturn, my quick launcher web page, which I use daily for fast access to notes and other bookmarks and as a quick search entry point — I type in a query and then choose where I want to search (my journal, Project Gutenberg, Standard Ebooks, eReaderIQ, my library, etc.). Works great, love it, no plans to move to something else.

Scroll, my ebook reader. An absolute win in my book. It’s been almost two years now and I still love it and use it almost every day and wish I’d made the move earlier. I love having full typographic control, bleedthrough and paper backgrounds, autoscroll (and scrolling in general, instead of swiping), and the lightweight feel of knowing it’s just static HTML files with some JavaScript. There are admittedly some things I still want to fix — changing pagination from percentage-based (which is unstable across font changes) to statically built in (which has the extra advantage of being usable in other apps and devices, like the Xteink X4) (which I got for my birthday, by the way; been meaning to post about it), and using publisher styles instead of overriding everything like the madman that I am — but overall I’d say it’s perhaps my favorite among all the things I’ve built.

Storybook, my fiction writing app. It’s working fine, though I don’t use it often enough — and wish I did, so I would be finishing stories more often. The daily word count tracking is nice. Per that Neal Stephenson link earlier today, though, the idea of writing more by hand has intrigued me, and if I do that (and even if I don’t), I think plain text files are fully adequate for story drafts. (As opposed to using a database in an app.) So…we’ll see.

Reply by email

Initially I considered baking the bleedthrough images onto the backgrounds in advance, but since the font can change (family, size, leading) and I wanted the bleedthrough to match, and since baking (whether directly onto the background textures or as transparent images to be layered on in the client) would mean dozens of permutations and images, I ended up doing this instead:

• On load, create a new canvas in memory (leaving it out of the DOM)
• Get the font information, padding, etc. from the DOM
• Render the lines of bleedthrough sample text onto the canvas, at a light opacity, flipping the canvas horizontally and applying a mild blur filter (noting that mobile Safari doesn’t yet support canvas filters, so the blur doesn’t work there)
• Export the canvas to a data URL
• Set that data URL as a second background image on the content area (where the first background image is the paper texture), with the blending mode set to multiply

It’s working fairly well, I think, and seems performant enough so far.

Potential future work:

• Get the bleedthrough to line up better with the text. While the leading stays more in sync in Firefox, in mobile Safari it drifts off within a few lines and I don’t know why. That said, for some reason I don’t mind that it doesn’t line up, and I’m not sure getting things aligned would be worth all the effort.
• Use the text of the book itself instead of a hardcoded sample text. Also may not be worth it, since the bleedthrough is subtle and isn’t meant to actually be read.

Reply by email

Thus far I’ve read two books using it, and while there are still a few small issues, overall I’m very happy with it. I don’t plan to release it anytime soon, but as a not-even-close-to-the-same-thing substitute, here are some notes:

• I’d made decent enough progress with epub2pdf that it was usable, but reflowability and theme-changing are nice, and having quick navigation between books is even nicer, and printing a book to PDF in Firefox is slow, and browsers already natively support the HTML that’s inside EPUBs, so I abandoned the PDF route.
• Scroll (after both the noun and the verb) is a PWA without a backend. It’s actually just static HTML files: I wrote a script that concatenates all the HTML in an EPUB into one long HTML file, with some processing to fix links and wrap things and bake the table of contents out. Then there’s a little bit of vanilla JS for the reader functionality (saving the debounced current scroll location to localStorage (I wish Safari supported scrollend), restoring it on the pageshow event, calculating pagination, jumping to pages, switching themes, etc.), and another vanilla JS file listing the current books (so that I don’t have to re-build all the other book files when I start reading a new book).
• While I said “pagination” above, I’m not actually chunking the book into pages; I’ve chosen to stick with vertical scrolling for now instead of horizontal paging, primarily because being able to make sub-page progress is nicer than I realized. That said, I still want to know how many “pages” I’ve read, so I use the scroll percentage (scrollTop divided by scrollHeight, super simple) multiplied by a rough heuristic of 1,200 characters per page, ignoring whitespace. It’s not perfect but it’s good enough for my needs.
• I added a slight blur to the text so that it feels a little less digital. For now I’ve opted against a background image, but I may change my mind about that.
• Whenever I add/remove a book, I copy the baked files to a private directory on my server
• I’ve saved the root HTML file (which is just a list of the current books, loaded via JS) to my home screen as a PWA

Reply by email