Decoupling (Patreon)

I've referred a few times to the "decoupling" of the front-end and back-end of the website. I'd like to expand on what this means, why it matters and what it might make possible.

First, though, a one-paragraph summary: Pathfinder 2e is a very, very different game system from its predecessor. This is clear from the playtest. This means that the character sheets for PF2e will need to be designed from scratch, a much bigger break from the past than Starfinder. So I'm taking the opportunity of the playtest to rethink the entire process.

How does the website work?

The important part of the website is a form where you make your character choices. You pick classes and archetypes, select optional features, choose colour and language. Then you hit the big button.

When you hit that button, it sends all those selections to the server. The server picks them up and puts them into a character data object. From these choices is builds up a list of the pages it will need; then one by one it puts these pages into a single PDF, applying such things as colour effects etc.

The result is a single file that gets sent back to the client, and treated as a download.

What are coupling and decoupling?

Two systems are said to be tightly coupled if their behaviour is so closely connected that they're basically just one thing; every engineering choice on one side has effects on the other, and visa versa. Two systems are "loosely coupled" if they're isolated from each others details, so that even though they work together, they are free to run separately.

The current character sheets website is tightly coupled in that the client side - the part you see in the browser - sends through your choices to the server verbatim. "The user clicked this checkbox", "the user pressed this button", "the user selected this dropdown". The server knows all the names of these fields and where they live. This is tightly coupled in that the exact same field names need to be set on both server and client. If I switch a field in the form from using radio buttons to checkboxes, the server needs to know about that change.

What I'm working on doing is decoupling the two by isolating the server from the details. Instead of a stream of checkboxes and dropdowns, the website will wrap all of those up into a single JSON object that describes the character. There won't be a direct one-to-one correlation between the user interface and this JSON object, nor between the JSON object and the output the server produces.

Why does decoupling matter?

The server process for Pathfinder 2 will be very different, but so will the form. I expect to go through a lot of experiments before I settle on a design I'm happy with for it, and to do that I need to be able to quickly iterate. Similarly the back end will go through a lot of experimental changes. A tightly coupled form slows down both sides of that process, by requiring the front and back ends to move together.

It's like a three-legged race. Two moving together have to move more slowly to avoid tripping each other up.

The next year or so is going to be a big time for experimentation, and that's only going to be possible if each part is free to evolve without too much recourse to all of the others.

And once that process is done? A decoupled process is easier for other people to join in on. Imagine a third-party publisher who wants to contribute their content to the project. Right now they'd have to understand the entire project; a decoupled project means they only need to understand a small part of it.

What else might this enable?

There are some other side-effects of this decoupling. Once you have a single object representing a character request, you can do new things with that object on both the server and client side.

For example, you can save it in the browser's storage and come back to it later. Imagine coming back to the site and being able to bring back any of the characters you created recently in order to download them again - perhaps with changes, such as adding a second class or the "lycanthrope" template.

The server gains a powerful tool for logging and analytics. A few months ago I did some analytics on the data I had:
https://www.facebook.com/groups/dyslexiccharactersheets/1882929405331378/

I did the best analysis I could, but was hampered by the fact that a lot of the data I should have been collecting simply wasn't there. I had no clean way of knowing how many people selected which options, no data to analyse. Logging a full set of JSON objects for each downloaded character would give me much better tools to understand the audience.

And finally, it unlocks a truly long-term possibility: client-side generation. Download a Dyslexic Character Sheets app to your desktop, tablet or phone, and create character sheets without a net connection.