This is the second post describing the process of redesigning my own website. See part 1 for the planning steps (1-4). This post describes the design and implementation steps.
Step 5. Designing on Paper
Like many others, my design process begins on paper. I sketch out parts of the page for different sizes, test out grid ideas and layout page elements. Here are a few images of what I did for my site…
Note: For client sites, I might use a wireframing app (like MockingBird or OmniGraffle) to share wireframes.
Step 6. Creating Assets in Fireworks
Fireworks is a great piece of software for web design. I know a lot of people use Photoshop, but apart from personal preference, there are many reasons why Fireworks is better for people like me. You can pretty much sum it up by saying that each feature has been built with the web in mind.
Now, sometimes I create full page mockups using Fireworks. I used to do this for every site, but now I evaluate whether it is really necessary before diving in and doing it. As many others have discussed, the value of a pixel-perfect desktop-sized mockup has been much reduced. First of all, we have a whole range of screen sizes we have to cater for, and a range of web browsers and operating systems that will render the typography slightly differently. This is something we have to embrace, abandoning pixel-perfection and focussing instead on the user experience and the visual language we want to convey. Don’t get me wrong – I still value these mockups, but a full page mockup is sometimes too specific, too complete, for the modern web.
Instead, I often create a bunch of assets to try to convey the kind of feel I am looking for. This includes any logos, typography, lines and boxes, headings etc, but not necessarily laid out as a working design (I create layout/grid ideas on paper if necessary). The idea is to develop a consistent feel before digging into code. This kind of process has been formalised by Samantha Warren into something called the style tile. You can read more about style tiles here or on styletil.es.
Here was my tile for this site. It’s a bit basic compared to what I would normally do for a client, and usually I would produce a few alternative takes.
About That Logo
I guess you’ve seen my new logo. I actually skipped the paper on this one, because I had a pretty clear idea in my head of how I wanted it to look, so I just worked on it directly in Fireworks. It’s built as a series of overlapping triangle vectors, some of which are partly transparent. You can read about the thinking behind it on my Dribbble shot.
Step 7. Building the Site and Responsive Design in the Browser
Here’s where the geekery begins. My first priority was to install and set up WordPress and initialise my base theme, which is a very basic starter theme I have developed. Once I had that in place, I spent some time figuring out what I practically needed to achieve, based on steps 1-4.
Mobile Small Screen First
To my mind the mobile first approach is just common sense if a site is intended for small screens. It’s a fair assumption that a small screen will present the most basic layout. Usually columns are collapsed into one stream and navigation is simple and touch-friendly. By starting small, it forces you to focus on what is really necessary and the order of the page content. It also means that the site can be engineered UP to the large screen layout, meaning that small screens don’t have to load any resources that aren’t used by small screen devices, such as multi-column grid styles and large background images.
Building content and content ordering
I always spend a bit of time in WordPress entering real content into pages, and setting up menus. It’s ideal to work with real content. As I had drafted some text for my new homepage, that’s what I did here. I also started thinking about what I wanted in the sidebar, so I started adding widgets to that. With few test posts in my Blog, I had a functional, yet ugly site. At this point I started changing theme files, focussing on the order of the page content. I see this as a critical step, before any styling work starts. The order I went for was as follows…
On the front page…
- Menu
- Introduction
- Latest Projects
- Latest Blog Posts
- Footer
And for the inner pages…
- Menu
- Page/post content
- Sidebar
- Footer
So, pretty standard stuff. My menu was tiny – About, Portfolio and Blog. With only three items and no expectation that that would increase, I reasoned that I didn’t need to create a special menu for small screens, and that the menu could come first in the content order.
Responsive Design in the Browser
Now for the fun part. I usually style the header and footer first, and then work on the content, typography and grid. For the geeks out there, I use LESS to write CSS, a Mac app called LiveReload to compile the LESS and automatically refresh my Chrome browser when I make changes. This means I don’t have to keep manually refreshing the browser every time I update a style in my text editor.
I usually start by bringing in any existing assets from Fireworks. In this case it was pretty much only my logo that needed to be pulled into the header. Generally, I am trying to move away from image sprites (pixel-based background images) and towards SVG (vector-based images) for UI elements. Why you ask? So that these elements are razor sharp on any screen, even on the retina iPhone and Mac, and also to save on HTTP requests. My logo is a regular image, but I serve a double sized image to hi-res screens. The icons on the front page (from the excellent Iconic set) are done in SVG, so IE8 users won’t see them. But that’s ok with me. I’ll specify a regular image fallback for that when I get around to it. The point is that I do a lot less image slicing in Fireworks these days.
After that I started filling up the styles that were intended for all screen sizes (in a base styles.css file). Once that was in reasonable shape, I added styles for larger screen sizes, served with media queries. There are loads of resources about this so I won’t go into it here, but it’s important to note that I work on the main universal styles first, and then screen-size-specific styles after. If you don’t do it, you get into an inefficient mess of styles that override each other.
Now, by thinking responsively and small-screen first, I spend a lot of time resizing my browser window, made easier by this nice Chrome extension. As I work in the browser building the design, there are always design changes that arise.
The processes of web design and development must run side by side.
On this site, I made quite a few adjustments to the typography. First, I changed the font to something with a bit more personality and a more modern, technical feel. FF Tisa and its sans equivalent were the perfect choice, served up by Typekit. Secondly, like many sites, the heading and body text sizes needed adjusting for different screen sizes. Notably, the headings on larger screens looked good at a big size (like on the style tile), but on smaller screens the headings and body font sizes needed to be closer together, otherwise the headings would only contain one or two words on each line. Similarly, many sites have tiny font sizes when viewed on small screens, so those might need bumping up. In this case I chose a generously-sized body text to start with, so this wasn’t necessary.
Another example of how the design changed to meet responsive requirements is in the header. On small screens, I wanted it to be slimmer. The logo could be smaller, freeing up more space for content when the page loads. On larger screens, the logo has room to grow and the menu gets more whitespace blackspace.
Here’s a side point for you to think about: These typographical and header size changes are perfect (albeit simple) demonstrations of something I’ve known for several years. The processes of web design and development must run side by side, especially on responsively-designed sites and apps. If you are building a website or web app, you can’t design everything in advance. You discover things as you go along. Split these processes, and you’ll end up with a sub-optimal result. That’s why some say the best web designers are also front-end developers.
Step 8. Testing and Launching the Site
Finally, I had a site that was ready to test. I moved the site from my machine to a staging area on my web host, and tested on…
- IE8-9, Chrome, Firefox, Safari and Opera on Windows
- Chrome, Firefox, Safari and Opera on Mac
- Firefox on Linux
- iOS and Android
I then optimised the site using various WordPress plugins (WordPress SEO by Yoast, LazyLoad and W3 Total Cache) and tested again. Finally, I added Disqus comment support and a few social sharing plugins.
Launching the site was a quiet affair. I made it live without any big announcement, so as to catch any spelling mistakes or unforeseen problems. After a few days I started spreading the word. I typically employ this soft-launch approach unless there is a good reason not to.
That’s It
Phew, that was a long one! I hope that’s given you a glimpse into how I work on a simple brochure site like this one. Obviously, the steps and process is a bit different for client work or larger projects. I have jumped between all kinds of different topics here haven’t I? Please do share your thoughts and questions in the comments.