A Clean and Friendly Website for 2022
Or how I got distracted updating my website’s HTML, CSS, and more.
Over the last month, I’ve been doing some housekeeping on my website. I’ve had a few lingering issues to take care of. Unsurprisingly, this led me down a few different paths. From simple fixes to big ones, I’ve made a few subtle changes that impact the feel of my site. Hinted at in my change log, I wanted to dive a bit deeper into the adjustments made thus far.
# Unicode for dummies.
For years I’ve complained about my site not working correctly with UTF-8. It may seem like a simple thing, but the code my site is built on was originally designed to use Windows encoding. That isn’t surprising given the mid-2000’s that the code originated from. Heck, when I started using it, the CMS was mostly leveraging table layouts and had a palm pilot mode.
Although WebApp would continue to modernize until it’s demise a few years ago, my code base was still on an older version. I had hacked and slashed so much of that code that it wasn’t very compatible with later releases. I had completely revamped a lot of the modules already. Upgrading would have been a step back for me. But the UTF-8 issue remained.
I was mostly able to work around the problem when it came up. Even during my migration to HTML5 and Bootstrap, I found clever hacks to keep the old encoding working. But, I was fed up. It was time to just bite the bullet and make the change. So I did.
Screen Shot 2022-02-06 at 8.20.07 PM by Steven Reid, on Flickr
And, to my surprise, it wasn’t as hard as I thought it would be. After some digging, I found the offending code that had happened my previous efforts. I did a site wide purge of its use and tested until satisfied that it didn’t break anything important. I’m still sure that my RSS feeds may need a little TLC, but the site validates and display correctly.
# Fixing articles.
Now, that did leave me with all my files using the wrong encoding. My initial tests were just editing files and resaving them in the correct encoding. That was tedious and would take way too long. I have over 360 articles still do do at this point. There had to be an easier way.
Doing some research, I found that UNIX has a couple of great commands to make conversion easier. The first was the file
command that will tell you the current encoding of a file. The second was iconv
that let me fix the encoding. After some testing, I whipped up a little perl program to make my life easier.
For those interested, here is the code for fixencode
. It basically takes anything that is Widows-1552 encoded and converts to UTF-8. As a precaution, I keep a back of the old file. Once done, I just delete the backups as I have a monthly archive of all the old articles and code. I’m sure this can be improved on.
#!/usr/bin/perl
### fixencode - converts old win-1552 files to utf-8 (us-ascii)
use strict;[br]
our @files = @ARGV or die "no filename(s) passed\n";
for (@files) {
chomp;
my $file = $_;
die "file ($file) doesn't exist!\n" unless -e $file;
# get current encoding
print "$file: testing - ";
my $curencode = `file --brief --mime-encoding $file` or die "error testing $file\n";
chomp $curencode;
if ($curencode eq 'unknown-8bit') {
print "converting - ";
`iconv -f windows-1252 -t utf-8 $file > $file.encode`; #or die "error converting $file\n";
`mv $file $file.org`; #or die "can't move file: $file.org\n";
`mv $file.encode $file`; #or die "can't rename file: $file.encode\n";
print "done!\n";
} else {
print "skipping ($curencode)\n";
}
}
# More fixes ahead.
Of course, if I couldn’t stop there. While testing and validating, I ran into some other minor issues and annoyances. These are things that I already knew about, but hadn’t gotten around to fixing. Since I was in the code, it was time to correct a few more issues.
One of those was the title slug. The slug code was supposed to expand ligatures and remove most punctuations. However, it wasn’t properly doing that. I thought that might have been because of the encoding, but turns out I was using the wrong unicode normalization.
When I first set it up, I used NKFD to normalize the unicode. That format seemed to not expand properly. Commenting it out, the problem went away because I would just throw away the character if it wasn’t ASCII. As I dug deeper, I realized that NFKC normalization would probably work better.
Now I haven’t tested it fully, but so far it seems to be working as expected. Plus, I learned more about how unicode works than I ever wanted to. At this point, I have two of the biggest issues on my site fixed. If things ended here, I’d be in a good place. But I was on a roll. There was more to do.
# Cleaning up styles and more.
Now, while doing this I decided to clean up some of the header and footer scripts. I had some style sheet issues and this was a good time to fix that. That included changing out fonts, cleaning up locations, etc. After some testing, I swapped a few things around and the site looks subtly better even if I have more work to do.
Digging through the CSS, I could clean up some sections and optimize the code quite a bit. I also need to redo how styles are injected as I have some inline styles that the current HTML standard bitches about. My plan is to do fix that when I get around to upgrading to the latest Bootstrap and theme code.
One area I did dig deeper was to remove all the deprecated styling where I could. As noted before, the site was built in HTML4 and was still using some older conventions such as FONT
tags. I dug into the code and started to remove those, replacing them with classes and styles. It isn’t pretty, but it works well enough.
Much of those issues were in the sites UBBC (Universal Bulletin Board Code or BBCode). After fixing some common mistakes, as well as finding a few more bugs, I decided to extend it. To make my life easier, I created a new [HEAD]
and [PIC]
. The first makes marking up my headers easier. The second creates some nice picture cards with titles.
Of course, as luck would have it, I keep finding issues with the doubbctopic
routine. While working on this routine, I needed to fix the [CODE]
routine. That caused me to go down a rabbit hole of despair and code unwrapping. It is fixed, I think, but these routines are on my list of completely rewriting.
# Fun with icons.
Okay, backing up a bit. I was looking to try to apply a monospace font to my ZX81 listing. This was back before I realized that I hadn’t ported over the updated listing from my old website. There was a great little class in Bootstrap called text-monospace
that would have worked perfect. Sadly, I needed to be in Bootstrap 4 or newer.
Now, since my site is still in Bootstrap 3, I could’t use it. As noted, it ended up not being an issue as I dumped the whole routine. But, it did allow me to revisit the updates to Bootstrap. I’d tried to upgrade to version 4 before with muddled results. At the moment, I’ll jump to 5 when I get around to updating.
Although not happy about the missing class, I did run across Bootstrap Icons again. The last time I looked, the number of icons were pretty anemic. Font Awesome has been great for me, but the latest version made a lot of changes that gave me grief. I would have swapped back then, but without the right icons I moved on.
Screen Shot 2022-02-06 at 8.09.55 PM by Steven Reid, on Flickr
Well, the anemic problem is pretty gone now. There are over 1,500 icons now in the library. Most of the ones it was missing when I first looked are now there. This sent me on a journey to see how hard it would be to convert. To my surprise, not very hard at all. In fact, the only hard part was finding all the places where I used icons.
# On to form fixes.
Of course, as I dug into the icons, this led me down a completely new path. I found that my use of icons wasn’t always consistent. For example, I used the pencil and the square pencil for edit. I used pencil for write, but then a square plus to add a record. In other cases, I used just a plus in a box with words. It was confusing.
In additional to the iconology, it made me wonder if I could improve my user interfaces. For years I’ve had the delete button pretty close to the edit. Since the routine didn’t validate the press, you could delete something by accident and it would be gone forever. Ouch!
This got me off doing research on button placement, icons and the like. I found an interesting article on button placement that got me thinking about the inconsistencies in my site. This prompted me to solve the problem and stop ignoring it.
Screen Shot 2022-02-06 at 7.45.58 PM by Steven Reid, on Flickr
As such, I decided on a few overall design decisions. First, I would remove all the delete icons. Since most places were they were used also had an Edit, I would move that functionally there. Second, I would verify a delete. This means two presses to delete something, but is far safer.
Although I’m pretty much the only person editing and adding items to my site, I still decided to focus first on the user side of things. That included the user menu, profile and race menu. Those all now have consistent icons and follow the new design philosophy.
Screen Shot 2022-02-06 at 7.46.12 PM by Steven Reid, on Flickr
The new delete button is now flush right, with the save and cancel buttons to the left. It might not follow Apple’s guidelines, but it is consistent. If you do hit delete, it will open a modal that verifies the decision. It works really well and will save me from making future mistakes.
Screen Shot 2022-02-06 at 7.46.19 PM by Steven Reid, on Flickr
I spent a few days fixing all the locations and buttons. Edit and add icons are pretty similar. There are a few places were I still use a button, but it made more sense to deviate where I did. I might still revisit that, but left it for now. Of course, making these changes prompted yet another path to follow.
# One less click.
Although I added two more clicks to delete, I wanted to remove a click when you added or edited an item. My site usually would drop you into a nice info screen once an action was complete. This is jarring next to how most sites work now. Usually they would reload the page or show what you just edited.
Now, I have a couple of options here, some easier than others. I could dynamically load the page, use modals, or some other crazy ideas. In the end, I went a simpler route. I print an info box and then the content as it would have been before.
This actually worked pretty well. I had a little bug in my Races script. When returning from edit or save, the code was missing if the they were public. This doesn’t impact the actual visibility as that check is done elsewhere. But it did break one of the icons. Luckily, that fix wasn’t too hard.
The cool part is that most of the public facing pages and custom scripts work pretty well. I really like the design. I do still have a few issues when editing large lists as you lose your filters. It usually isn’t a bit deal, but something I can work on in the future. But there are a lot of admin functions that sill need some work.
The one area that is still broken is the Gallery. I haven’t spent a lot of time updating that UI outside of adding an easy way to upload images. It is on my to do list to rewrite that entire script. A such, it is jarring and ugly next to everything else. Again, I doubt anyone will care. I should also add that the edit profile is still the original form as well. Sigh.
# Wrapping things up and looking forward.
As you can see, most of these changes are subtle. Most users probably won’t notice the changes, especially if they haven’t visited recently. For me, they add up to a lot of quality of life improvements that improve my productivity on my site. I really like how the site works.
On the other hand, it really exposes all the things I still need to work on. I’ve squashed a few bugs along the way, but there is still more to do. I’ve updated my Trello board with all the things I’ve run across. Right now I have more ideas than time.