I joke often about my product prioritization heuristic for Buttondown being “work on the thing that I’m most embarrassed at not having.” This heuristic has led me to my work for the past week: support for multi-factor authentication (now live for Authenticator apps!)
This is long overdue (and perhaps a little accelerated by a recent enterprise sell whose conversation soured when I said it was merely ‘on the roadmap’.) It’s also been, frankly, pleasant to work on — I get a lot of decision fatigue when it comes to designing relatively complicated UX flows from whole cloth, and I don’t really have to worry about that here because:
we As A Society have pretty well narrowed in on what the right MFA registration & input flow should be, and leaning into that is a good thing;
Buttondown’s design system now has rigorous and easily extendible answers for “how should I display a multi-step modal?” and “how should I display a rich table of primitives”?
Instead, the exploration has been more on the “wait, how does MFA actually work?” front. Django has a third party package that handles some of these details, but since Buttondown has some bespoke auth code I wanted to roll my own integration with Yubico and authenticators. This has been fairly painless, but the most actual research I’ve needed to do from a backend perspective in quite some time.
On the other end of the spectrum, I’ve also spent two days working on support for adding attachments to drafts and emails. This has always been a reasonable feature that did not feel too heavy but never felt quite urgent enough to prioritize; neither of those things changed, but I wanted to balance out the power-user-ish nature of MFA with something that lent itself a little more naturally to feature pages and launch posts and all of that hoopla.
I say on the other end of the spectrum because where MFA is a solved UX problem with some interesting technical details, attachments are a solved technical problem with some interesting UX details.
Uploading a file to S3, marking it as related to a given email, and attaching it to outgoing emails is simple; the PR implementing the backend is sitting at around two hundred lines of code. Actually displaying it, though, reveals this screenshot which makes me cringe: exactly four types of buttons now on the main drafting page:
I’m not sure how many times I can justify punting on rebuilding the architecture of the writing view by saying “well, I’ve got a PR that changes the architecture of the entire app”; this might be the proverbial straw that breaks the camel’s back. I’d like to move the toggles above the writing pane and then fold the other ‘customization’ buttons like scheduling and recipients into the same UX as Customize web archives, but that’s a lot of scope creep.
Speaking of scope creep — the initial launch of attachments is going to be fairly limited by design. There are a lot of bells and whistles that I can imagine people wanting (download analytics, an attachments view, that sort of thing) that I am going to explicitly ignore until the clamor is too loud. My suspicion is that this is a feature whose quality will be maximized by its light weight.