Redesigning my portfolio from the ground up

My selfie

James Turner,

Tags: Web design Web development

This very site was once a salad of disconnected and disorganised web pages, and for a long time, I felt it needed a redesign. When I finally had space in my schedule, I got started, not with HTML and CSS, but with a lot of soul-searching, self-reflection and the most fundamental question of all: “Why?”

The brief

My personal website had started life as an online CV, and over time I had bolted on a blog and an assortment of other static HTML pages. The content had become scrappy and disjointed, there were three or four stylesheets competing over the layout, and the manual process for deploying changes to the site was becoming increasingly onerous and error-prone.

My goal in this redesign, then, was to give the content some structure that would allow for future growth, to make the look of the site more unified, and to come up with a process that would enable me to deploy new content and structural changes more easily.

Content strategy & information architecture

It's tempting to start a redesign by cracking open a text editor and chopping up the code. I've learnt, though, that a lot of questions need to be answered before we should even think about HTML and CSS.

For example, who is the website for, and what problem is it trying to solve? All kinds of people need help with the web, and finding someone trustworthy with web expertise isn't easy. This website, then, is a place where potential employers and clients can get the information they need to judge whether I'm that person. They can see examples of my work, decide whether they want to take me on, and if so, find out how to contact me. That's the main purpose of the site.

The second purpose is to serve as a home for my blog. I've found that writing a couple of blog posts every month is a great way for me to sharpen my thinking about web design, learn new tricks, and share my ideas with colleagues around the world. I suppose future clients and employers can also get a sense of what stage my skills are at.

Thirdly, it's a place to put scraps of work that I've produced which need to be online, but don't deserve a domain name of their own, or aren't appropriate for an external site like Codepen. For example, there's my CV, there's a list of resources and links from a course I did last year, and there are a couple of mini-projects I've worked on to practise my web design skills.

It could be argued that this is a bit ‘soupy’—many experts warn against building a site that tries to do more than one thing—but I feel it's appropriate for my needs as they currently stand. There were many more questions that I needed to answer:

All this may sound like overkill for a simple portfolio site. I would argue that without asking these questions, the site would have developed without a coherent vision, and it would have ended up resembling a teenager's bedroom floor, much the way it was before the redesign.

Jekyll, the static site builder

For this redesign, I could have used a dynamic tool like Wordpress, which is, after all, first and foremost a blogging platform. There were some good reasons why I didn't want to go down the Wordpress route, though. Firstly, I didn't know how to integrate a development version of a Wordpress site, which I could tinker with freely without breaking the live site. Second, I would have had to get into theme development, which was on my list of things to learn, but which I wasn't quite ready for. Third, being the performance-conscious web designer that I am, I felt that all the whistles and bells that come with Wordpress were too much for my site. Another slightly egotistical reason was that I love being hands-on with HTML, CSS and JavaScript, and I was worried that Wordpress would have taken this away.

After some research, I discovered Jekyll, a static site generator. This looked perfect for my needs—once the structure of the site is set up, the production of HTML documents is automated. Goodbye onerous and error-prone deployment process! Jekyll's templating language, Liquid, is so easy that it took me just a few hours to learn the basics, and to get on with setting up the structure of the site and refactoring the existing blog posts. Within a weekend, the bare bones of my new powered-by-Jekyll site were ready.

A problem that I encountered with Jekyll was its built-in insistence on putting blog posts into a date-related file structure. For example, a blog post published on 1 January 2016 will appear in the folder 2016/01/01/index.html. If I had been setting up a new blog from scratch, I might have used this structure, but I already had quite a few posts and I didn't want to change their location. I discovered that it is possible to override this behaviour, but it's not straight­forward.

Re-usable chunks

A talk by Dave Redfern at Staffs Web Meetup started me thinking about how I can use atomic design to improve my web design process. Atomic design involves breaking content down into ‘chunks’, which you design once and then reuse as many times as you need. An example of this on my site is the blog post summary, or ‘teaser’, which consists of the title of a blog post, the date it was published, the summary, and a list of tags. These teasers appear on several pages, including the blog index (Figure 1), the work write-ups index, the tag pages, and the landing page. The layout varies depending on the width of the screen and how many other teasers there are around it. I only needed to code this once, and then tell Jekyll where to put it on each page.

At desktop size, the recent blog posts page on my site has a three-by-three grid of teasers.
Figure 1: At desktop size, the ‘recent posts’ page has a three-by-three grid of teasers, which are all generated from one small chunk of HTML in a Jekyll include.

Spring cleaning the stylesheets

At the time when I started my blog, I didn't know about atomic design, using consistent naming conventions, and using DRY coding principles. My CSS needed a thorough spring clean, and this was a great opportunity to do it.

I started by reorganising my style rules according to Harry Roberts' ITCSS architecture (see ‘Manage large CSS projects with ITCSS’ in Net magazine #267) and the BEM naming convention. The advantage of ITCSS is that it encourages you to work with, not in opposition to, CSS's specificity rules. The result is a stylesheet that is, on the one hand, much leaner (see How I shrank my CSS by 84kb by refactoring with ITCSS [no date] for an anecdotal example) and, on the other hand, incredibly easy to maintain. Meanwhile, BEM is a great way to avoid naming clashes, and to identify quickly what purpose a class serves and how it relates to other elements on the page.

Jekyll has built-in support for Sass, so I took advantage of this by breaking down the stylesheet into individual CSS files that group styles according to what they target. At the top are global styles, followed by styles for generic elements (paragraphs, generic headings, and so on), then objects (such as the reusable ‘teaser’ chunks), then one-off components (e.g. the toggling menu), then utilities, helper classes, and trumps. I could probably improve it even more, but here are my Sass includes as they currently stand (Apr 2016):

@import
  "settings__main",
  
  "generic__resets",
  "generic__main",
  
  "elements__main",
  "elements__nav",
  "elements__figure",
  
  // Objects can appear several times on one page
  "objects__structure",
  "objects__external-links",
  "objects__buttons",
  "objects__update",
  "objects__a11y-links",
  "objects__teasers",
  "objects__aria-hidden",
  "objects__syntax-highlighting",
  "objects__data-table",
  "objects__calculation",
  "objects__edit",
  
  // Components appear once on a page,
  // or once on the whole site.
  "components__header",
  "components__menu-toggle",
  "components__first-paragraph",
  "components__paddles",
  "components__archive",
  "components__back-to-top",
  "components__footer",
  "components__glossary",
  "components__all-posts-btn",
  "components__welcome",
  "components__home-featured-work",
  "components__home-page-teaser",
  "components__cv",
  
  "trumps__main";

If I find a bug or if learn a more efficient, accessible or progressively enhanced way to code something, it's no problem to locate the relevant styles and alter them. I also know with some confidence whether it will affect just the current page or whether it will have site-wide implications.

Conclusion

The redesigned site is a vast improvement on its predecessor. I feel the message is much clearer, and is supported through the content. Of course, as time goes by, new ideas and tweaks occur to me. Shall I add a Twitter widget to display my latest social media gem? What about some funky animations to show off my latest animation skills? In the past, I would have just thrown them in without a second thought. Now, thanks to the content strategy and information architecture groundwork that I did, I have a framework for selecting, rejecting and prioritising additional features. And when I do make changes, I can code and style them with confidence, and I can deploy them to the live site within minutes. All in all, I'd say this redesign has been a fantastic training ground for working on bigger projects.

Skip to navigation