This article is going to go over the first things I’ll do when logging into a Debian server for the first time. For me, this will be a VPS that has been deployed by a web host, almost always with the latest Debian release. The first things I want to do are update and secure it. Much of should apply to other Linux Distributions.
(Continue reading…)With the recent changes I’ve made to the site and in particular the goal of making the site more responsive, I’ve gone back and looked at how I display text. Until now I’ve gone by what looked good to my eye, with no real consideration for established accessibility guidelines. This led to the previous setup where I had a ‘hero container’ of 1100px with a default font size that by default would be around 16px. It’s largely been something I got away with ignoring as I wasn’t concerned about mobile experience, but as soon as that became a concern, I discovered my current font setup was not scaling well to mobile.
Turns out that best practices for prioritisation of readability is to have lines of text that are roughly 45 to 75 characters long. This is noted time and time again on the web as something to aim for, and the more I see examples of the more I agreed there may be some merit to that guideline. The layout I used previously far exceeded this and was running at lines of around 120 characters per a line. It wasn’t horrendous as the page was clean, but other sites were easier to follow. To try and get closer to this target I’ve made the following changes:
- Reduced the site hero container to 900px.
- Increased the padding between the main container and text, effectively making the text region around 800px.
These two actions decreased the amount of horizontal space for text. As I have no plans for vertical navigation, multiple columns or lots of graphics, it was necessary to drastically reduce the canvas width. So far, I think it looks fine and the extra white space frames the text well. Even with these changes lines were running long, so I additionally:
- Increased the desktop font size.
Right now, I have fonts set on desktop to the equivalent of 20px. The blog is largely just written content so having larger more present text allows that to take centre stage and makes the articles in turn very readable (in my opinion). A blog post, 4 Reasons I Use Large Type by Mike Anderson, lead me down that path and I think it has worked well for me.
After making those changes, I found that when I flipped to mobile that text was now much too large. To fix that I’ve decreased the root font size that all text scales against on mobile is 80% of what is used on desktop. I also drastically reduce the page borders on mobile.
The net result of the is that currently on desktop lines are around 80 characters while on mobile it’s around 55. I’m happy with the result.
Counterintuitively, and probably to my detriment, I haven’t settled on a font yet. Depending on whether I change that then I may be forced to experiment with the above numbers some more, although the targets will remain the same.
Something to note is that I’m also using scalable font sizes where previously these were fixed. This was important to allow people to scale text if they so desire. While above I noted 16px and 20px as the target output, this assumes a default text zoom at the browser. Actual fonts are being rendered using rem versus px, which makes the sizing relative to a base sizing to improve scalability. The text should scale gracefully for people with non-standard text settings.
Lastly, another useful tool for web development and font layout is this golden ratio tool. Recommend using this as a starting point as it helps to inform vertical spacing and other layout elements that I’ve begun to consider and also contribute to the presentation of text.
New website content is coming along. I’ll be updating this post as I go to list changes, as well as where my priorities are. As it stands, I’m largely making this up as I go and haven’t gone in with any sort of prototype, so there might be some back and forth on design and some pages will be broken for a bit.
Priorities
- Fast (Performance)
Looking to massively improve site performance with a lighter design and better server setup (more considered caching and optimisations). Pretty much there already but will strive to not let that slide. Ohh, and I’ve moved the site to a much faster VPS instance. All in all the previous homepage was very graphic heavy and slow to load, and I’m looking to get away from that. - Good page benchmark in general
Along with the actual speed, I’m looking to ensure accessibility and other factors that Google Page Insights or GTmetrix might measure. - Responsive design
I’ll be giving attention to mobile that I didn’t previously. - Blogging content back to the front
With the previous redesign I removed emphasis on the blog component of the site. Thing is, I never could think of much static content to include. I’m bringing the blog content back. - Non ‘article’ blog post
Following the previous point, I’d like to post more but I’ll hopefully look to have support for a few post types that aren’t full articles. Something I can churn out quickly. Not sure how these will look, and it may just be a templated blog post with stock images. We’ll see how that plays out.
Changes
- Brand new header, which is responsive and scales to mobile
- Retired old homepage and brought blog to front
- New blog template
- Removed contact page (I’d never have answered these anyway!)
- New caching. Now using FastCGI via NGINX and Hummingbird Pro (possibly don’t need both, but we’ll see).
- Cleaned up image optimisation, fixed some lazy loading etc
- New Single Post page
- Fixed spacing under bullet list
To Do
- Improve mobile performance
- Disable unnecessary Javascript (Including theme elements)
- Review column use of flex
- Fast (Performance)
I’ve been required to oversee a bulk update of a few thousand users into a manually managed portal group for which the FIM Portal is authoritative. Anyone who has had to add more than a few users knows this can be a cumbersome process by hand via the UI. To save time from doing this manually through the Portal interface I’ve thrown together a PowerShell script that will read a CSV file of users and operations (add or remove) and process those requests against a group.
Just finished Captain Toad: Treasure Tracker (with the exception of time trials) and I must say that overall that was one fantastic experience. The game is definitely up there with the best on the Wii U and well worth your time.
All in all it wasn’t too hard to 100% most levels if you bypass the before mentioned time trials (which are absolutely brutal in many cases). The difficulty does go from a five to eleven for the final two bonus levels which I found to be an absolute pain thanks to a certain character named Mummy-Me. Those who played Mario 3D Land’s later levels will remember certain stages contained a shadow Mario that would follow your every move and prevent you from ever stopping, while making back tracking more difficult and was generally there to force the pace of the game. Mummy-Me is Toad’s shadow Mario, and really made the final few bonus stages incredibly tense for what was generally otherwise a very relaxed game.. The last level in particular is a 50 stage maze(/gauntlet) with these guys and a bunch of other enemies all trying to get you, resulting in one rather tense finale.