In the works: a file manager, Android bookmarking, a SaaS, and doodles


Normally, I try to share finished work of substance. But honestly, software is never finished. And people enjoy watching other people work with the garage door up. So here are some projects that I've got simmering:

FMIN (github) a

What it does: file management like fman, except in the terminal.

Why am I making it? I hop around lots of directories and work with lots of files. fman served me well in the past, but now I'm in the terminal all the time and I need something similar.

I've tried alternatives: walk, ranger, fff, cd + ls, ... But none of them combine fman's best features:

  1. Type to filter directory contents
  2. Jump to frecent (frequently or recently visited) directory
  3. Command palette of actions. I like calling commands by name rather than looking up bespoke keybindings
  4. Dual-pane display. I like seeing source and destination directories in front of me instead of holding them in my brain

What's left: I just finished the preliminary code to navigate directories and render the UI (screenshot.png). Now I'll focus on implementing features 2-4.

GIMME THAT (demo.mp4) a

What it does: If you select text and share to this app, it saves the text to file.

Why am I making it? I need a new notetaking system because Simplenote wants me to pay $200/yr. I'm ready to replace Simplenote with text files + vim + Syncthing, but I'm missing a mobile frontend. I need a text editor, and I need a quick way to save links and text snippets. I want minimal thinking and minimal button presses between "I'd like to save this piece of information" and "saved".

So far, the quickest action I've found for saving information is screenshotting. It's just one hardware button press; no menus to navigate, no options to find, no thinking. It's always available. It doesn't interrupt the flow of reading, unlike the copy/paste dance (select text, copy, switch app, paste, switch app).

But I have too_many_screenshots.jpg, and I want the text to go into notes, not an image gallery. So the next best mobile action is sharing. A share menu is always 1-2 taps away. I made the app icon bright yellow so it's easy to find in the menu. It's as mindless as possible.

What's left: The app forks Ɓukasz Adamczak's absolutely minimal Android project, having added only an app icon, an intent, and a toast message. It doesn't actually save to file yet. It also needs a feature for choosing the destination folder. And I might work on the name some more; I've considered TextHole, SaveMe, TextDump, Download That, ShareToNote, ShareToFile, NoteGobbler, Gobbler, NoteEater, CopyTaste...

NOTEBOOK LOVE (/unlisted/notetaking) a

What is it? A playful webpage about enjoying notebooks and doodling.

Why am I making it? A few reasons:

  1. (boring) I want to improve my web design skills: copywriting, images, layout, typography
  2. (vague but true) I want to make something more playful and less useful
  3. (inspiration) I want to make a webpage with handrawn elements; something with texture like zachkatz.me, the uncolouring book, and stagfoo's page
  4. (love) Porkbun had a sale on .love domains. I started coding in anticipation of buying notebook.love. Whoops, turned out to be a pricey one
  5. (last but not least) I like my notebook

I'm glad I have a place to upload random doodles. And I'm glad I have an excuse to use a big, juicy Garamond header.

What's left: I'm not sure how to layout the scans at the bottom of the page. I think I need to refine the categories so there's the same number of scans in each category. Then I'll revisit the writing, add links (inline or endnotes ??), and share with people.

INS.REPORT (ins.report) a

What it does: It's a form that helps inspectors write home insurance reports.

Why am I making it? For the past two years, I've worked as an assistant home inspector. I spend most of my time filling out PDFs like this one. It's painful and difficult:

Of course, it's not literally painful or difficult like, I don't know, crawling through an attic for an inspection. But the process is full of inefficiency and incidental complexity. Imagine writing on a PDF directly. Then compare that to using an HTML form that spits out a PDF. Reports could be so much easier.

I'm also making ins.report because I might sell it or charge a subscription. I feel it would be an easier sell than the typical SaaS:

I'd be happy with 5 users - overjoyed, even, if there'd be enough users to pay rent. But I'm not sure that I want to pursue entreprenuership. Managing a business takes a lot of time and energy. Marketing, accounting, and customer support don't appeal to me. And home inspections don't interest me as much as programming does.

Anyway, here's what I've accomplished so far: I spent a lot of time thinking about the data model. You can see it in the JSON on the main page. I made an image2pdf widget that has already replaced an inferior desktop equivalent. I started writing a training manual to link with different sections of the form. I iterated through several form designs and HTML inputs. I tested several client-side PDF libraries. And I've planned a lot more - I just have to put it together and start shipping a minimum viable product.

What's left: a lot of work. It's very scrappy right now. I spent too much time waffling between Elm and Svelte (hence the subdomains). I'm still learning how to cut scope and prototype quickly and make tradeoffs in favor of shipping, rather than in favor of developer happiness. I'm very far away from needing a landing page. And I might abandon it all in favor of a programming job (hire me?) So I'm not sure where ins.report will be in 6 months...