Best way forward

Hey all, hope you’ve been well. I wanted to take a moment to talk about what I’ve been up to since the last post. Feel free to skip the rest of this explanation with an assurance that I have been busy albeit without much to show for it.

The general objectives of what I’m working for falls in two broad categories: 1) enhancements, new features and rehauls of user-facing stuff and 2) consistency and convergence. I’ll leave 1) aside for now, as I’ll likely talk about specifics when I roll out stuff and instead focus on 2), which has been a major blocker.

First, however, let’s take a step back and provide a refresher. THP’s board software works: for any given non-archived thread, the document page gets “generated” or renewed ever time a post is made. It is otherwise static HTML. For whatever changes I make to the site’s code, it won’t reflect on the pages unless someone posts or I run functions to regenerate board threads. Archived threads also run through board software for a final time, adding only the elements that are relevant for long-term storage.

The obvious downside to this is that really old threads are sort of stuck in time. Threads archived before many of the site’s overhauls feature old schemes and structures and don’t mesh as well with the rest of the site. In short, something from Missing in Gensokyowill be very structurally different to a recently-archived story.

Now, why am I bringing this up? Well, for starters, in order to implement some of the more modern accessibility options, such as posts lining up to the width of a screen on mobile devices, I have to write special rules for these old pages. They are separate from “current” code and things that require user scripts, such as calling up a list of story threads at a bottom of a page, have to be implemented from scratch, often in a different manner than the main block of code. In essence, these really old threads are their own thing code-wise and any small change in current code necessitates backporting or, at the very least, a minimum effort to avoid breakage.

So, if you’re quick on the uptake, you probably have figured out that 2) can be a very daunting task. Let’s say that I wanted to include many of the features available via the settings menu on the site; I would have to implement not only a menu with features that load up, but then each of those features into the old code as necessary. I’m skimming over the fact that the old code uses plain javascript as well; I don’t use libraries in old threads but that comes at a cost of verbosity.

Overall, I have to add exceptional code for a few… dozen? Hundred or more threads that were archived in the old system, before I had direct control over how the site dealt with that. Any change to them must also be tested manually, as I can’t render them in my test environment as such—as I’m only creating “new” content, old threads have to be manipulated manually.

Of course, there is a more universal way of approaching things. I could always regenerate those old archived threads using old database data using the newer parameters for archived threads. It would mean a clean reboot and a far more easily-manipulated dataset. It’s the best option, to be honest, instead of patching around old behavior or eccentric fancy.

The problems with that approach are, however, fairly obvious. First of all, I have to load up that deleted data from old database dumps in the first place. Possibly merge with newer dumps so I have all the data. Then, of course, apply many of the changes from years ago as to how special characters are treated and data are escaped—these being things that, historically, were different in 2009 for various reasons. Of course, after that, I would then have to have some sort of mechanism to check which posts within a thread to pull data for: wouldn’t want to accidentally pull in data for a post deleted by a mod or user for whatever reason!

And, well, even assuming I can automate a fair amount of that, it still needs human supervision. Fully automated plans like that are rarely flawless and there’s all sorts of format-specific exceptions that could crop up. Do you see yourself manually comparing hundreds of threads to see if there’s inconsistencies? Probably not. I don’t either, especially since I can’t really delegate an amount of the work to others. Even if I get past all the logistical/programmatic hassles, it’s still a stupid amount of man hours.

This all then circles back to what I’ve been working on. For all the cool shiny features I may have implemented or expanded, I’ve hit an impasse on the best way forward. The easier route is to add exceptions and work around old data as much as possible, even if it provides a subpar experience to the users. On the other hand, if I want things to look consistent and nice and whatever else, I have to make a bigger effort than I might have first expected.

Truth be told, I’m not sure what I’m going to do. I’ve spent the last few weeks prototyping things and trying out partial solutions without committing one way or another. I’m still not sure what’s best or more practical. As you may imagine, this has delayed my implementation of new shiny stuff. To the extent that I think that I’ll likely end up implementing new features and enhancements in the current version of the site without reaching an ultimate conclusion; I’ll punt on the rest.

Still, it’ll all depend on my free time and, perhaps, on random inspiration. It’s my goal to roll out a great portion of what I’ve otherwise worked on soon, though I’m not certain when exactly. Less than a month, for sure, but some of what I’ve worked on doesn’t make sense unless there’s a unified experience for users.

Now, certainly, this could all be avoided if I just overhauled THP on a bigger scale. But that’s an ambition for another time.

I hope to have good news soon. Until next time, take it easy!