Folk Interfaces

Folk creations fill a gap. They solve problems for individuals and small communities in a way that that centralised, top-down, industrial creations never can. They are informal, distributed practices that emerge from real world contexts.

Folk Interfaces, Maggie Appleton

So my mom calls me the other days and says “how long does it take to build an API?”. I mean, it depends right? The scope of that could be one minute or one year. I’d need more information than a quick phone call could deliver. She does give me some insights though.

She works for a printing company, so getting printing jobs from clients and delivering them is the whole game. Anything they can do to help their customers place printing jobs is probably worth doing, up to and including writing software. Any given printing job might be a little complicated, for example, involving variable data. Imagine a brochure that could include a local sales persons name, address, and phone number incorporated onto the design. But there could be two sales people also. Or two sales person and one agent.

So here’s what the customer is going to do: build and maintain an Excel spreadsheet.

This spreadsheet is going to have all the possible information on it for a print order. Which base print item, how many, where they are to be shipped, what variable data is going on it, etc. It’s fairly complicated. The spreadsheet is going to “live” on the customers computer network.

Every day, twice a day, the spreadsheet is to be examined for new entries, and if there are any, automatically turned into print jobs and put through the printing process. The part where it turns this data into a print job is done by a third-party bit of software.

So this “API” is actually fairly complex in my mind:

  • On a cron…
  • Connect to an companies internet network.
  • Retrieve an Excel file
  • Parse/read the Excel file
  • Determine if there are an new/unseen rows that represent print jobs
  • Extract the data.
  • Format the data in a way the third-party software expects it
  • Send the data to the third-party

Not to mention, handle any errors that might happen along the way, like bad data, unresponsive servers, etc. This seems … kinda hard? Like at least on par with the kind of professional web development work that I do. It also seems kinda like a “folk interface” to me. I have a feeling this workflow will probably work fine for everyone involved, but to me, totally outside of all this, it feels like a very, uhhh, folky approach.

In my bubble, we’d probably have meetings about the data model and stakeholder expectations. We’d build a form-heavy design system so we could build a bespoke order form with live previews. We’d build a cloud database that would accept the validated data. We’d build cloud functions that would run on a schedule to pluck the data out and pass it to the third party, but we’d probably put that job on a queue in case it fails, so we could re-run it if so. We’d track and report all errors carefully. We’d build a custom app to deploy it behind that company firewall — and have a release pipeline so it could be proper CI/CD.

It would probably take 4 months, then there would be turnover and nobody would know how the machine works, and at the end they’d be like… can we just put stuff in an Excel file?

Leave a Reply

Your email address will not be published.