A few weeks ago, I was asked to explain some of my decisions and reasoning I used while rebuilding this website. I wrote quite a long document and have decided to reproduce an edited version for you here. My thanks go to Sheila Shu Cheung who worked with me as the designer on the project.
The 2016 redesign of eogreer.me aimed to fix some of the design faults with the previous version and to provide a fresh slate for this blog when I decided to relaunch it. Shu created some content wireframes as a starting point from which we worked together to create a draft design. The primary font and colours where to be kept as close as possible to the earlier site to ensure some consistency with printed work such as my business cards.
The blog design in particular evolved during the building phase. Initially articles would be limited to a few lines with a click through required to read the rest. It was deemed after discussion with various individuals that as content is rarely more than twice a week, articles should run full length on the main page with pagination after every 10. In doing so, I opted to contain each post in a box, with a small border-radius to make it more pleasing to the eye. The original design was just to have a horizontal rule, but with a lot of text this got lost and blurred the break between articles
When it came to writing the CSS, it was almost a given that I would use SASS, more specifically the SCSS markup that is closer to normal CSS by retaining the braces. I have used SASS on a vast majority of projects although the framework used to compile varied. This time I elected to use Compass again, simply for it’s ease. I broke the style sheet out into various sub sheets and compiled them together. To begin with a reset based on one by Eric Mayer that I keep at hand for all projects. A variables file contains the colour hex codes and baseline measurements for the grid. Typography was kept together, as were mixins. Each page as well as the header and the footer has it’s own file too with components that work across the site in a ‘generic’ file to avoid code duplication.
I knew that I wanted this version of the site to be responsive but as it was a very small site I didn’t want to import a massive grid system. Searching around the internet for ideas, I developed a small set of rules that give a limited amount of columns, but these were all that I needed. A media query collapses the columns into 1 when it hits the variable for max screen width that is declared globally so that other styles may alter on mobile too. The header file also includes the viewport meta tags to ensure that mobile ‘retina’ devices do not show desktop sizes.
Because the site is a WordPress template, the code is not as clean as I would have liked with many concessions having to be made. Using functions such as strip_tags on the navigation, for example, allowed me to clean things up. I favour the clean markup of <a> tags inside a
<nav>tag, where as WordPress nests <ul> tags inside both other <ul>s and <div>s.
Testing and feedback
When I reached a point where I was happy and I had tested on my devices, I launched the site and got some design and developer friends to make suggestions. Through this process I made some tweaks to the typography, in particular where different sizes of headings sit next to each other. Some copy was also changed to better reflect the new layout.
About a week after launching, I decided to add another page that I could use to easily show my progress completing certain walking routes as well as linking to the relevant blog posts about them. To do this, I decided to teach myself something new and build a WordPress widget to make updating the progress easy. As a visualisation I wanted to have a progress bar so opted to use the relatively new progress markup. Due to it being so new, I had to allow various fallbacks for older browsers and even modern ones that do not support it so well. Firefox for example does not have the ability to style the background whereas Webkit browsers have separate pseudo classes for the progress and the background. IE only supports progress from 10 upwards and even then only supports the ability to change the colour. For older browsers, I elected to include a textual representation underneath which also helped to clarify the bar for those which were able to see it. I wrote a blog post explaining more about these widgets when they launched.
This morning I found myself at a loss for what to write today. This afternoon I found myself with a bit of free time to spare between projects. So I built myself some widgets.
You may have noticed that a new tab has appeared in the menu. You may also notice that a lot of my blog posts are about walks Soph and I have done. So I thought to myself, what would be a really nice way to visually show how far we have walked on various trails. So I built myself a little widget that will render me a progress bar. It’s pretty bog standard and my code is far from pretty but I hadn’t built a widget for a long time so it was a good way to refresh and test my skills.
Uncle Bob, of Clean Coders fame, tells us that part of being an Agile developer is practicing at home away from your work environment. As someone who now works from home, that is a bit strange to say as I don’t quite escape; but you get the drift. This was my practice session for the week and I feel so much better for it.
So, back to the walking widget. What does it show you? Well, not that much. I might add links to blog posts at some point or even make it show progress in kilometres rather than just the stages which are often irregular (the LOOP for example has much shorter stages in it’s northern half than it’s southern), but for now it is just a very nice visualisation of how far we have walked and just how far we still have to go.