Edward Oliver Greer

BLOG

Wednesday 15 June 2016

Development, Essays

0 comments

Design decisions

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.

Design
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

Styles
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.

Responsive Grid
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.

Restrictions
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.

Initially, I made the header of the site sticky with CSS and added JavaScript to trigger an animation to fade in my name on the homepage when scrolling down. I removed all this before launch to reduce differences in the behaviour between browsers.

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.

Widgets
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.

Edd

Comments

No comments yet

Leave a comment

Your email address will not be published. Required fields are marked *