A Complete Redesign in Twelve Hours

Over the last few days I have received a ton of great feedback on both a number of my articles and my site’s design as well. While the former has remained consistently positive, the latter refrain almost invariably included the same two criticisms: that I had set the font too small, and that every line contained too many words spread much too far across the screen for a comfortable reading experience. Others recommended that I find a way to differentiate linked list items from my own posts, but by and large the most common suggestion advocated a larger font size and decreased content column width. Today, I have addressed those issues and many others with my latest redesign, live with this article.

Contrary to what I may have alluded to when responding to those offering feedback with regards to my site’s design, I had only thought about it in the abstract up to that point. I had created no wireframes, selected no color schemes, and had not even begun thinking about a particular font — besides knowing that I did, in fact, need to design a new website, I had not fleshed out any of the implementation details whatsoever. Busy with writing and working on First Crack, I just did not have the time.

Thankfully, that did not keep me from trying.

With the exception of some minor styling code for block quotes, links, and footnotes, I deleted every CSS definition until I had a blank, plain text-esque layout. Then the fun began: I needed to decrease my main column’s width, so I pushed it down to 50 and centered it. Looking good so far. With my old code gone, the font already rendered at a much larger size than it had previously; both here and in the default color scheme of black text on a white background, the automatic browser styling would do. However, everything looked too squished: I needed more whitespace, so I upped the line height to 200 and added a generous margin around every article and the top and bottom of the screen. Mostly satisfied with the layout, I moved on to fonts.

I follow a number of well-read writers who place great stock in good font choices, so I realized the significance of a great typeface early on as one of the most important aspects leading to an enjoyable experience. With this in mind, I turned to my trusty sidekick Google Web Fonts in search of an attractive option that would lend itself to both a visually pleasing design and an easy reading experience. With more than six hundred choices just for the Roman alphabet though, I quickly became overwhelmed. Unsure where to begin, I decided to see what everyone else used in the hopes of stumbling across something I really liked. I looked to Marco Arment first and then Shawn Blanc, where I thought to explore potential options on Typekit.

Given the importance of a great font, I had prepared myself to pay handsomely for one; however, when I discovered that Typekit charged for variants I could find on Google Web Fonts for free, I turned my attention back to Google and eventually decided on the smooth sans serif Roboto. Although I tried a number of others, everything paled in comparison to Roboto. With a font in place, then, I went back to tweaking layout and spacing. As the day wore on and it grew steadily darker outside, I became increasingly less satisfied with my chosen color scheme: it reminded me of a comment Tweetbot’s developers had retweeted of someone complaining that the bright white layout made their eyes bleed at night. Hoping to save my readers some pain, I began exploring a dark mode.

Ever since starting my site, I had done constant battle with two warring factions within my mind: one advocated an incredibly minimalist design featuring nothing but the absolutely necessary HTML and CSS, while the other wanted to include jQuery pursuant of some really neat ideas I could not implement otherwise. Partway through December, the latter prevailed when I shipped an incremental update featuring Chris Sauve’s jQuery plugin Bigfoot after Marco began using it on his site. Having crossed the proverbial Rubicon, I also included a slick trick for enabling faster, smoother scrolling, which also necessitated a bit of scripting. Given that I already imported jQuery and ran some Javascript upon each page load without a significant performance hit, it made my decision to go with a scripting-based option much easier instead of the convoluted CSS workaround I would have otherwise attempted to implement.

I could have easily added a “Display Preferences” page similar to John Gruber’s, but I wanted to do something much more elegant. Ideally, I wanted to toggle a light and dark mode with a single key press; thankfully, Javascript could not only do this, but I could do it with relatively few lines of code and without a plugin bringing along hundreds of extra lines and features I would never use. While this made for a great experience on my computer, iOS devices, famously, do not have keyboards. It seemed I would have to forfeit my goal of an elegant implementation not requiring that I add an entire page devoted to one tertiary feature. In fact, I had almost unzipped a past project that would let me use iOS-style toggle switches when I had a crazy idea: what if I could give my phone a good shake to trigger a dark mode? Twenty minutes and one GitHub project later, I had a rudimentary beta working.

I spent the rest of the evening tweaking shake sensitivity until it worked well enough on my iPhone to detect intentional shakes and disregard most unintentional ones resultant of normal usage; however, that left me with the much larger iPad to contend with. To make a long and tedious story short, I ended up using different settings depending on the device, which I differentiated using a wonderfully simple trick I found on Stack Overflow. From those who have checked out the beta, it works like a charm on both devices.

After finalizing this feature I made a few more small changes like centering headlines and prepending linked list items with a “>” sign, but focused most of my efforts on optimizing performance. Leading up to my decision to finally bundle jQuery with every page, an unwillingness to increase load times served as my primary motivation behind eschewing Javascript of any kind: I wanted my site to respond quickly irregardless of device or internet speed. Bundling external scripts would increase latency, I reasoned, and I could not accept such a tradeoff. As I said though, I eventually overcame that aversion and started implementing some neat tricks here and there. In order to keep the associated performance hit at a minimum, I consolidated external files as much as possible, and minified everything. For example, using Javascript compressors like the Online Javascript Compression Tool, I cut Bigfoot down to 1/3 its original file size, and saw similar reductions in size — and, by extension, load times — in my other scripts and stylesheets as well. Now, with an empty cache and a fresh browser instance, it takes less than half a second to open my home page, and ~1 second to open my archives with more than four hundred entries. I can live with that.

Incredibly — to me, at least — I did all this yesterday in around twelve hours from start to finish, and spent today writing this before and after work. I cannot, nor do I mean to, take all the credit for this great turnaround time though: I could not have done it without the feedback of my Twitter followers giving me direction as to what I needed to work on next. In particular, I would like to say a special “Thank you!” to @typistX on Twitter for all his help: when asked he took our conversation out of Twitter and in to email, where we made a great deal of progress. I could not have done this so quickly and to such splendid results without him, nor without the input of my newfound friends on Twitter. To all of you: thank you; to everyone else, I hope you enjoy the new design.