There might come a time when your personal website doesn't reflect your work or especially yourself anymore. At this point you have to think about changes and probably a redesign is what will solve all your problems. At least this is what was best in my case. This article will give you an overview of the process of redesigning christoph-rumpel.com. It will show you how I planned this project and what I have learned on the way. But let us start at the beginning. This is what my site looked like in December 2012.
It was my first usage of a CMS and was built in 2009. I was using a ready WordPress template which I modified a little bit. The goal back then was to test WP and start a little blog. It was right before my first internship as a web developer and I wanted to improve my skills. After a year I started concentrating on other projects and neglected this site.
December 2012 I decided to build a new site which
shows who I am and what I do. Additionally I wanted to use this project to learn new technologies and to improve my skills. It is always a good idea to use such projects to test a new frameworks, CMS or to get yourself familiar with other techniques.
For myself these things were important:
- building a new personal website
- making a responsive WordPress theme from scratch
- using Sass as a CSS pre-processor
- working with the CSS framework inuit.css by Harry Roberts
It is exciting to try new stuff but you have to be careful. Working with too many new components can get a pain in the ass.
I separated the project into
maintenance. Every time I spent on my site I tracked with the app Timings. I totally recommend using any sort of time tracking in order to see how much you spend on which phases or features. I will show you this list at the end of the article.
My website is a small one and therefore the concept was quite clear.
Here is what my sitemap looks like:
- Home (introduction to myself)
- Blog detail site
Pretty everything here is self explaining. I wanted to keep it simple. Additionally I listed the website components in a content inventory to get a feeling for where I need which element. (logo, navigation, copyright etc.)
Since I wouldn't call myself a good designer, this was the hardest phase of the whole project. Fortunately my friend Markus Jürgensen from Complemind did a great job in supporting and motivating me. Thank you so much Markus :-)
I started with a mood board where I collected inspiring images of website components, fonts and other design stuff. This really helped me figure out what I actually wanted for myself. That time I did not know that i'll end up a with a modern flat design. I just figured out that I like simple structures and playing with typography. That was enough for starting to play in Illustrator. I rebuild my favorite collected components and tried to migrate them in order to find my own style. Here is just a lithe insight to my Illustrator playground mess.
This was really a hard time for me and there were like a dozens of moments when I wanted to give up. As a developer it is just frustrating when you cannot create something you see so clearly in your head. Somehow I managed to hang on and ended up with a quite nice design for my site. I would love to hear you opinions so make sure to leave some comments below.
This is what my
final designs looked like before I started to code. As you can see they still look a bit different to what my sites looks now. This is a luxury I probably couldn't have afford if had to work for a real client.
As I already mentioned it was clear to me that I would work with WordPress. Some people recommend to build the needed templates directly in your WordPress theme, but I decided to build the complete site templates first, before implementing them. I liked the feeling of separating the logic from the code at the beginning.
Inuit.css provides a great responsive grid for managing your layouts. What I love about it is that it works with percentages and therefore is more device-independent. Harry Roberts is explaining his grid here.
For my CSS and markup it was
important to me to write scalable and modular code. As a front-end developer I know how hard it can get to maintain code when you do not think about it from the start. Of course that should be always your approach but I know that every beginning can be tricky.
I definitely recommend reading "Scalable and Modular Architecture for CSS" by Jonathan Snook. It is really a great help and I am glad Harry recommended it to me some time ago too. As recommended in his book I separated my CSS files. Due to the fact I am working with Sass it was easy to combine and minify my stylesheets on the fly.
These are my CSS files:
This way my code is organized logically and I still end up with one style.css file which is needed by WordPress.
Sass is just great!
I also try to
check out my complete theme and within all files on Github.
There are a bunch of "blank" WordPress themes out there to help you start building yours. I used HTML5 Reset which is a style-free theme designed to help get your custom project off the ground. It contains a lot of useful functions and definitely is a great starting point.
This brings me to the next point:
deployment workflow. I have spent hours in reading articles about WordPress deployment workflows and best practices. This really can be difficult at the beginning. The workflow I am using is a mixture of some other's but here I got out the most.
These are the important steps of my one:
- doing some changes locally on my WP site
- commit them through Git
- push them to Github
- pull the latest version of my theme in from my server
Looks quite simple and it is indeed. I am also doing an automatically backup of the database every time I push to GitHub. This is also described in the article mentioned above.
Advantages of this workflow:
- working locally I do not need Internet and I am really fast
- additionally I always have a backup from the site locally
- through Git and Github I am versioning my site and can pull the latest changes easily to the server
- i am also able to share my code with you on GitHub
disadvantage I see is that I have to commit, push and pull every time I need to change something. In the process of development this is no problem, but while maintaining the site this can get annoying.
As you all know there is no site that is 100% finished by its release. There are always already plans for further features and other improvements. Furthermore there might be some bugs you need to fix. I have a long list with both! Of course major bugs are hopefully fixed by now, but it isn't easy to find time for the small ones too. So keep a list and go step by step. This list will probably never be empty and your website will never be finished too. But that is ok.
So this was the whole process of redesigning my personal site. Hopefully some parts will help you with your future projects. I definitely learned a lot while working on this site. Sass is super powerful and should be part of every project. I cannot live without it anymore. I also fell in love with inuit.css and its grid system. Absolutely worth a try! Git is something you have to get yourself familiar with too. Bigger projects will need a versioning system and Git is my system of choice.
Please let me know about your experiences with your sites and your workflows. Of course I would
love to hear what you think about my site too.
Below I list you my tracked times as promised. Keep in mind that I am not a designer and that you will spend so much more time on your personal projects than on other ones.
- concept: 1h
- design: 40,5h
- development: 88,5
- maintaining: 33,5