Tangled knots

It’s been a while since the last one of these, I thought it would be interesting to share a few thoughts about some of the behind-the-scenes things and considerations when it comes to working on the site.

First, some news: about a month ago the newest version of Debian released and I upgraded the server accordingly. For those of you who aren’t familiar with it, Debian focuses on stability and only really brings in large changes and newer software versions with each major release. This means a new kernel, among many other things, but most importantly a new version of PHP. Without having to do any special optimization, web software such as THP will run better with PHP 7.   

As you may also be aware, I introduced a mobile-friendly style sheet for the site last month. I requested feedback on it but have gotten only very limited amounts thus far but am still planning to work on improving it in the near future. The problem isn’t as simple as it might seem, and I wanted to take the opportunity to explain a little the development process for THP.  

In evaluating whether to change or add something to THP, there’s a few things I think about:

• Whether it’s technically doable (with the resources and tools the site uses)
• Whether it’s something people would use (no point in coding something with only novelty value)
• How it would likely work from a code point of view  
• If it requires modifying existing site code or if it’s something standalone
• The fashion which it would be integrated with existing code
• How complex the undertaking is, overall
• How much time and effort it would take to implement

If something that passes the first two points, I generally start writing down a rough plan in a notebook. It helps organize my thoughts and this outline can serve as a bit of a checklist once I’m actually writing code. It also helps identify potentially tricky points and that, in turn, leads to analysis on what, if anything, I need to do to prepare myself for it. I spend a lot of time looking at documentation and examples on the internet before committing to any one idea.

You may have also noticed, that looking at whether or not existing code is modified and how the resulting code is integrated are two steps. In truth these are among the more complicated things to think about these days. I’ve stated it before, but the site code base is about a decade old and is not very well documented. There are a lot of non-intuitive decisions and variables in many different files that can be overwhelming to wrap your head around.  

In essence, even the most simple of additions can be a nightmare to implement when you have to deal with this old code. More than once I’ve changed something only to find that something not-very-obvious has broken as a result. It feels like disentangling a giant knot made of thousands of different strings at times.  

Bringing it back to the mobile-friendly version of the site: a style sheet is only part of the solution. Navigation is also important and implementing something like a ‘sticky’ menu that follows your scroll is a logical addition. Having a menu like that isn’t that hard in of itself—I had a proof of concept on my local machine within a few hours of working on it. The problem is integrating it with the rest of the site. How do you make it so this menu is only visible for mobile users? cookies are an obvious answer, you dynamically provide content as is appropriate depending on if the user has a cookie indicating he’s a mobile user or not. But, uh, what if the board software is designed about being as static as possible? Save for the front page and story list, most of what you see on the site is static html.

Without getting too technical about it, when someone posts or the board is manually updated by an admin, content from the database is queried and then passed through a template which then outputs the html. So if you wanted to have dynamic content delivered from the server-side you’d have to rewrite all of that to output per request. Putting aside the increased strain on resources and design discussions, it means that the only way of serving dynamic content without changing this fundamental property of the board software is through client-side scripts.  

The site doesn’t use much javascript. Only relatively few things, like hiding threads, some formatting, rotating the banner on every page and backlinks wholly depend on these scripts. So, you might be thinking, what’s the problem with adding something new? The answer is that JS can get very unwieldy, very fast. Not to mention that more scripts to load can make a page slower and harder to use, especially on mobile platforms. But, most importantly, because of the nature of something like a sticky menu, it’s easiest to do while calling certain external libraries. These can conflict with the older versions called by existing scripts and require heavy testing and possible rewriting of old scripts to accommodate 10-odd years of development.

Dealing with all these different strings takes time and patience. Sometimes I’m forced to return to the drawing board, as it were, and think of another method that I can try instead when working on something. Couple that with the fact that I can’t work full-time on the site and you get the slow roll out speed for changes and features. It’s why I prefer to announce things only when they’re nearly done, so as not to get expectations too high.  

I’ll try to work this week some more on the mobile version for the site, as I’ve got a more or less clear idea of how to proceed. But I still can’t set a hard date for new versions as it’ll depend not only on my free time, but how much old code chooses to cooperate.

By the next time another one of these posts has been written up, I hope to have the mobile stuff nice and finished. Then maybe work on the mystery box can resume in earnest.  

Hope you enjoyed reading this!

Love, Teru