Redesigning a WordPress site from the ground up

I’ve written here a little before about my football blog, provenquality.com

The site started on the 3rd of February 2013, and for the recently passed first ‘birthday’ of the site, I wanted to create an all new, custom design.
When we started the site, we wanted to just get up and running as quickly as possible, so having acquired the domain name, I spun up a server, installed wordpress, bought a ‘premium’ theme and got writing. We got a logo designed and for the first year of the site it was running the hades theme from themeforest.com.

Here’s a gallery of how the site looked for the first year :


Now, running the site with a decent purchased theme was a good way to bootstrap the site in its first year, but using someone else’s theme comes with a few problems :

  1. Branding – Obviously, the site is not completely unique in style, there are other sites out there using the same theme
  2. Unless you rip deep into the theme, you are hostage to the theme coder’s personal preferences (and possibly errors)
  3. Theme updates – If you do modify the theme extensively, apply updates from the theme author becomes a big diff and merge job
  4. Bloat – This was the main problem for me eventually with the theme we chose, the theme had a huge amount of stuff built in that we didn’t want or need, and served up multiple unnecessary javascript and CSS files which, even after removing as much as we could (dependency whack-a-mole fun!) were still slowing down the site

So having decided I wanted to get away from that, I drew up some goals and requirements for the new site. I won’t go into all of these here but the main principles were :

  1. Responsive design – At this point, unless you have a very clear plan of a way to do it better specific to the site, then all new sites should be built with responsive web design.
  2. Mobile first – Kind of a subset of responsive design, but build the design for mobile devices first and then expand the site for higher resolution devices. This was the first site I’d built in this manner, and I found it to be very efficient both in terms of work-flow and the best option for speed and rendering on all devices.
  3. Content focused – Proven Quality is a site dedicated to quality football writing, so the content has to be the most important thing on the site. I wanted to make a clean, minimal design that gets out of the way to put the focus on the content.
  4. Ease of navigation – With the previously stated goal of being content focused, I wanted the site to be easily navigable on all devices. The site needed to display the content in a beautiful way so that the user can enjoy the content with two secondary goals – firstly that the user will navigate the site to find more content that interests them, and secondly to make it easy to share the content with their friends.
  5. Social – I already covered this in the point above somewhat, but content based sites depend on being shared to grow their readership. The site should have social sharing features to encourage the reader to share the post on the main social networks without compromising the minimalism of the design or slowing page loads (standard sharing buttons are ugly and slow to load, so they’re right out).
  6. Chronological – I like the blog format, and displaying all posts from newest to oldest. It’s a pattern which users are familiar with and I think it works well. The old theme has a number of different sections, sliders e.t.c. on the homepage which I don’t think work well for usability. Articles in multiple categories (we use categories for teams and tags for players and managers) can be displayed in multiple places and there was no way to chronologically browse back through all posts. I wanted to simplify this, and get back to a chronological blog format.
  7. Fast – The site should be fast, really fast! Slimline the code, make better use of caching to make pages load fast so as not to discourage the user from browsing the site due to unnecessarily long loading times.

With all that in mind, I decided that the best way to move forward with the site was to take the time to build a completely new theme, from scratch. Well, not exactly from scratch, as I did use some libraries in the process. I started off with the bones blank wordpress theme as a base. I searched around a few different skeleton themes and bones seemed to the best job of setting up a few sensible defaults for a HTML5 site without getting in the way of development.

Starting with the mobile version, I decided to make a sort of native app-like view of the content, so I added a fixed header at the top with a navigation menu at the left of the header and a sharing menu to the right. I used mmenu jQuery plugin to make these push menus slide out from their respective sides of the screen and hammer.js as an addon to allow the user to open the menus from anywhere on the page by swiping from the left or right edges of the screen. I think this makes for a pretty cool and accessible mobile experience.

For the desktop version of the site I didn’t want the site to look cramped into the middle on large screens either, so I made the site expand to pretty wide on large screens, up to a sensible maximum line-length for the content. The home page and list pages use a 3 column layout, 2 posts side by side with a sidebar. I used some nice web fonts and tried to create a sense of space around the content by paying close attention to both horizontal and vertical whitespace. The mobile slide-out menu becomes a standard horizontal drop-down menu and as we don’t have the mobile sharing slide-out either, a simple share icon is displayed under the byline, which, when clicked slides down a simple sharing menu for the most common sharing methods. There are a couple of enhancements on the desktop site which are not on the mobile site. A simple back to top button shows up a little ways into the article (it’s pretty easy to scroll to top on a mobile device and otherwise the button would overlay the content), and towards the bottom of the article, a small box fades in, inviting the user to view the next article. If you wanted to, on the desktop version of the site you can start at the most recent post and go back through all articles on the site just using this box.

As I mentioned, I wanted to keep the functionality of having share counts for the social networks without impacting page load times, on desktops they can be slow and even if loaded asynchronously, on mobile networks this all adds up to extra requests and latency. The approach was pretty simple, to handle it server side and store it in a wordpress transient (which are thereafter served up by memcached). This is refreshed once an hour for the site as a whole (twitter followers, facebook fans e.t.c.) and on demand for each once an hour for each page (with cache priming, this represents little impact to the user). This handles it nicely, and we can then use those counts in a pleasing way on the site. I made the aforementioned dropdown in the post byline, and some consistently themed shared buttons for the bottom of posts. I also used the total counts to make a widget displaying the Proven Quality social accounts, with fan count blended into the background div.

For icons, I used fontello to create a custom icon font containing only the icons needed for the site. This reduces requests (only one request for all the icons on the site) and means we don’t need to load a whole load of unused icons from, say font awesome. Using an icon font means that all of our icons look lovely on high DPI devices too. Good stuff!

All of these little optimisations add up to a big difference and means that for a typical page, we serve up :

  1. The HTML page (gzipped, of course)
  2. One CSS external stylesheet.
  3. Our web fonts (from Google’s API)
  4. Our icon font
  5. Modernizr
  6. jQuery
  7. One site javascript file
  8. Analytics code
  9. And the logo (base64 encoded and embedded into the stylesheet on mobile, loaded by URL on desktop).
  10. Plus whatever images are on the page

Get most of that served from CDN and the site really pops!

For the last point, site images I looked into various adaptive image solutions. The idea being to serve up only the size of image required for that device. There are a few different solutions out there, but they’re all ‘hacks’ in a sense and, having got the page load time reduced enormously seem like overkill. There is no doubt that there applications for adaptive images, but at this point they are less than perfect and, in my case not necessarily worth the effort.

It’s probably better to visit the site to see how it looks now for yourself, but here’s some screenshots of how the site looks at time of writing :

That’s all, what do you think? Speaking or re-designs, it’s about time I did something with mabujo.com!