January 12, 2020

rewrite status: January 2020 – slow but steady progress

Hello! This is a semi-regular update on rewrite—an attempt by Chris Krycho (that’s me!) to build a best-in-class research writing environment. You can always unsubscribe either via this link right here or the one at the bottom of the email. Thanks for following along with this project!

One other house-keeping note: going forward, I will always split these updates into two parts—one for non-technically-minded readers who want to follow along with the progress, and one for the nerds and/or programmers who want to follow along with the development process.

---

Progress

A quick update this time around: I was hoping to have more to say (and show!) after my long Christmas break… but unfortunately, I got the flu in the middle of it, and then my wife got the flu after that, and now we’re both sick again. It’s made it hard to make sustained progress. However, I’m back on my normal schedule and hopefully on the mend, and am now figuring out how I’m going to break down the spring in terms of this project and a few others (which will let me dog-food this project!).

I did want to note what I’ve gotten done over the past few months (as well as let you know that yes, this is still making slow but steady progress!). I implemented a very basic view of tags for reference items:

The fact that you have to scroll to the side to view them right now is… not permanent. I know how to solve it (now!) and the next update should include visual evidence of said knowledge.

That’s a very small amount of visible progress since the last update (and keen-eyed observers may also spot some utility buttons at the bottom… but they don’t do anything yet!). That small amount of visual progress corresponds to my having learned a great deal. (More on the details in the Development Process section below!) Over time, I expect my progress to accelerate as I get over the initial hump of learning a brand new platform. For now: I’m getting close to the point where I can actually displays an entire BibTeX library (even if not as elegantly as I might like)!

I’ve also just started on the web user interface. I delayed starting this part because the web implementation is, at this stage of just displaying data, so much easier. I wanted to make sure I was actually making progress on the native version… and I am, even if it’s slow. This approach lets me take a “break” from the native work by switching to web stuff, my home territory so to speak. The net is that the next time I send you one of these updates, I expect the web version to be as far or perhaps even further along than the native version. There will be screen shots!

One of my goals for the spring is to get this reference management part of the app to a point where I can use it myself. My plan is for this ultimately to be folded into the larger application, but I am in need of a reference manager I don’t hate now: I have research I’m doing, and references to manage! And this remains the weakest point of my workflow today. (It’s also a much more attainable goal to build this than to try to build the entire app all at once!)

That’s about it for the progress report. The rest of this note will be getting into some of the details of iOS and web development—if you’re hopping off the train here, thanks for reading!

Development Process

Working on this project is a weird experience for me. It’s slower and harder even than I expected, and I expected it to be pretty hard and pretty slow! I’m picking up Swift and SwiftUI and UIKit and all the bits I need to build native apps about as fast as could be expected, given that I’ve never done any of it before and that I only have a relatively limited amount of time to get after it each week. But I’ve been doing web development for over a decade. At this point, I can pick up pretty much any web framework (or even language!) and be productive very quickly. I expected it to be at least a little bit like that picking up the native platforms… but not so much. I just don’t have the relevant experience!

What’s particularly challenging is that web UI and native UI frameworks actually are fairly similar… if you squint a little. SwiftUI looks a lot like Elm, and UIKit has a lot of similarities to Ember (the framework I’ve been working with every day for the last four years!).¹ But you do have to squint. The differences end up being profound at times. Things that are easy on native are hard on web, and vice versa.

For a prime example I ran into (juuuust before I got the flu): I wanted to build a nice visual display of the keywords associated with any given reference, as you see in the screenshot of the app at the top of the email. The original idea was to build something like this—but note the wrapping, unlike in the screenshot:

On the web, this is trivial for me at this point. It took me less than three minutes to build a basic version of this on the web:

I spent a lot of time on this with SwiftUI. You can get the nice little bubble effect easily enough (easier, arguably, than on the web!)… but getting it to wrap across lines nicely? Actually impossible to do natively in SwiftUI at present. It requires writing a custom UICollectionView and wrapping that up in a SwiftUI container to make it possible. I’m sure I’ll find a lot of places where native can do things trivially that are nearly impossible on the web, too, of course. The main point from my point of view is that this kind of transition has a lot of unknown unknowns: things that it’s impossible to know ahead of time are going to be hard.

I’ll get there. Hopefully for any of you who are thinking about picking up this kind of project yourself, it helps to see some of the hard parts along the way.