Mobilizing for mobile

With the mobile navigation for the site mostly sorted out, barring one or two small kinks, I thought I’d do a write up on how it came about and why it’s implemented the way it is.  

First of all, I’ve alluded to this in other things I’ve posted on both Patreon and on the site itself, but a fair chunk of traffic coming to THP these days comes from mobile devices. It’s been like that for a good while, actually, and I’ve been keenly aware of the need to cater to mobile users properly. The site’s design plan is over a decade old and there is almost nothing in the way of optimizations or even compatibility with mobile devices. Plain websites work great on any device but something like an image board, with all its fancy bells and whistles, can be nearly unreadable on a small screen.  

I did try the slightest of tweaks here and there over time but I knew that I would eventually have to settle on a more comprehensive solution.  

So, I spent a long time thinking and assessing the state of things and any possibly limitations in implementing ideas. Here’s three things that I considered and a few of the more important pros and cons:

1) Rewriting how a lot of content is served on the site, making sure that it is more or less uniform across all devices

+Little in the way of unique code, flexible and easy to maintain

+Remove a lot of legacy code, possibly making future work easier

+Would be intimately familiar with how it all works since I wrote it

-Massive undertaking. Would basically have to rewrite the site to such a degree that I might as well do everything else from scratch

-Might still end up breaking things, perhaps making a more radical overhaul desirable anyhow

-Neckbeards might complain about new appearance and way to interact

While this was probably the option I wished I could do most, the sheer scale of things was staggering. I’m not that great of a programmer and I’d rather have a few things working adequately “now” than in a year or so. A major rewrite is inevitable but that’s no reason to leave mobile users in the cold for now. I did prototype some things and explore how feasible it all was, which is part of the reason why it’s taken so long to actually implement things on the site.  

2) Creating a special mobile-only site

+Avoids the need for a major rewrite by having an only partial rewrite for special cases when serving content

+Could easily use a subdomain or thp.moe to segregate users

+ Allows a certain amount of freedom when it comes to implementing new features, as they can be wholly independent of the main site

-It’s a different codebase to maintain

-A fair amount of work for something that will only last as long as the inevitable rewrite

-Likely inefficient resource-wise as the “simplest” way without touching the rest of the site would be leaning on dynamic pages (read: php or something like flask) instead of the main site’s html

Ultimately I decided against this because I plan to redo the site anyhow. It could have been an interesting warmup exercise but mimicking a lot of the site’s formatting and way of replying/quoting/etc was labor-intensive work. This one I didn’t even make a basic prototype for, but I did study a few APIs and things that could have been useful.  

3) Injecting the current site with client-side scripts that alter the page

+Technically simplest option

+Requires relatively little in the way of editing existing site code

+Quick to do

-Dependent on users accepting scripts to begin with (most people don’t care and have them on, but some don’t)  

-Pushes the burden of extra processing time and resources to the user’s device instead of the server

-Needs somewhat messy modifications to the already byzantine site’s code for the hacky workarounds  

This is what I went with because it was I could deploy comparatively quickly and easily. It still requires quite a lot of work in terms of testing, validating errors and creative thinking for getting around the limitations of the site code. As an example, the drop down list that appears in the mobile view is there in every page’s source code as well, it’s just that it’s hidden by default. The special script and mobile css enables it as well as hide certain other elements. Yeah, this isn’t proper coding and is honestly a bit shit but I was more concerned about the end result without upending the figurative apple cart.  

As it currently stands, if you visit the front page of THP and you’re on a mobile device, a cookie ought to be set in your browser. A script is inserted in every imageboard page that checks for the presence of this cookie. If it detects that it’s been set, it does a whole bunch of magic and brings in a special mobile-only style sheet as well as reorganizes elements on the page and deletes others. It’s powered by code by yours truly, of course, but it also depends on an external library that simplifies a lot of the otherwise complex code process. I may feel slightly clever for doing my best but Free and Open Source Software also deserves a fair share of the credit. Looking at and using parts of other people’s work avoids the duplication of effort and allows people to learn how code works.  

By the way, you can also access the mobile view by hitting a button at the bottom of each imageboard page that sets the mobile cookie.  

There is a bit of a performance hit (noticeable when you load up the page for the first time without any caching) but early tests convinced me that it was an acceptable amount. Especially if I compared it to other websites I looked at. There’s still a bit of optimization that I can do as of the time of writing this post but it’s nothing game-changing. It seems to work well and, unless you’re on a phone a decade old on a connection whose transfer speed is in the single digits, you won’t really notice much.  

Aside from the workarounds to fix some things (like hitting reply and going to the postbox), I also had to remove a few things in the mobile view. Most of it was not being able to figure out a good way to display all that information. Some of it simply wasn’t relevant to a mobile user. Either way, things like the watched thread box is a necessary victim until I get around to redoing some of the other elements on THP.  

In the coming days and weeks, I’ll likely tweak a few things here and there. But the overall results are more than satisfactory in my assessment. Then again, I don’t really browse much on my phone. I’ve asked for feedback on the site (and here) and gotten a limited amount so, if you feel like something needs to be changed, you ought to say something in the feedback thread. If no one says anything, I work under the assumption that it’s good enough.