Redesigning my portfolio from the ground up
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?”
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:
- What kind of designer am I? What are my values? How can I reflect this in the look and content of my site?
- What content do I already have? Is it still relevant and appropriate?
- If new content needs to be produced, how much does there need to be, and how long will it take to produce?
- What are other web designers doing on their portfolio sites? Should I copy them, or try to be original?
- How often will I produce portfolio write-ups and blog posts?
- What tone of voice should I use? Should I be chatty and familiar, or serious and formal?
- How will the site evolve after one month, six months, one year or three years?
- How will the site navigation be organised?
- What content will I include on the home page?
- Which key content should appear above the fold?
- How will I use social media to bring traffic to my site? Is it even a priority?
- How will visitors be able to find specific portfolio write-ups and blog posts, or read posts on a similar topic?
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
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 straightforward.
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.
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.
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.