Quarto

Quarto was born of a surprising problem: my wife and I, both architects by training, were unable to find a simple iPad app that served our needs for an architecture portfolio. We wanted an app with absolutely no cruft that could safely be handed over to an interviewer without worrying that they would push the wrong button (ie, zero admin UI). Similarly, all of the interactions needed to be completely expected. It should work like the “Photos” app, but give better controls for organizing which photos appear and, ideally, be built on a laptop and sync’d to the iPad (rather than trying to build on the iPad itself).

It didn’t exist, so I built it. Quarto is live and available for download in the App Store.

The app is straightforward. The web application is programmed in JavaScript (Parse-Server backend with MongoDB, Mailgun, Stripe, and S3 integrations, Jimp built using Browserify), and the iPad app is programmed in Objective-C (I had learned Objective-C for Instructables, so I went ahead and programmed natively).

Perhaps the most interesting technical detail is that the numerous thumbnail and alternate image sizes are generated client-side in pure JavaScript (not using the canvas!) in a web worker.

Similarly to my work compiling a CAD kernel to JavaScript, here I started with an open-source library called Jimp (to which I was briefly a main contributor) which provided a collection of Pure-JavaScript image manipulation functions meant to run in NodeJS… resize, crop, blit, blur, brightness/contrast, rotate, posterize, etc.

My work involved creating a build process for Jimp which would allow it to run in the browser, in a web worker, so that I could use it in Quarto (and save having to pay for a real server!). This actually works surprisingly well. Though it pushes the bounds of what browsers can do these days (and indeed, I see occasional browser crashes while uploading large numbers of large image files), client-side image transforms turn out to be a practical reality in cases where upload speed is critical (time is saved because there’s no “processing” step) or server-side resources are limited. Performance is considerably better than canvas, and not as crash-prone.