When I found out that I was building the new UX London website, I was really excited. My first attendance was when I was at University, and it was my first ever conference experience. I remember discovering a whole world of user experience that I didn't get to see from the classroom. I left with a notebook full of scribbles and I met lots of friendly and inspiring people. It's amazing that a few years on, I am writing about building the new UX London website.

The website needed a conference vibe, but it also had to reflect its fun, inspiring and creative side. So, I saw this as an opportunity to try out some new techniques.

Away from the screen

First of all, I printed the page designs and used paper and scissors to help me better understand the overall design, layouts and components of the site. I cut out the components of each page, drew on some of them and stuck them to the wall behind me for easy reference throughout the project.

UX London patterns UX London website patterns

At first I noticed how fantastic the design looked on landscape orientated screens, but at this point I hadn't seen many designs based on a portrait orientation. While I waited for these designs, I had a stab at re-ordering components myself. Since I had already cut up the components of the site, I could easily move them around on the wall and see how the layouts could change.

Re-ordering UX London patterns

What I loved about this approach was how easy and quick it was for me to manipulate layouts without needing Sketch or Photoshop. I enjoyed being able to think about different layouts for different screen sizes and orientations; something I don't often get the chance to take part in. The beauty of paper prototyping is its low cost of change; I could throw it away and repeat it as many times as I wanted.

I also some spent time drawing complex patterns to help me figure out the best approach to building them. For example, the navigation changes a lot between small and large screens; some of the elements completely switch places. So, I drew the different layouts and highlighted the differences. It was clear from this that Flexbox would be really useful because of its order property.

drawings of patterns

Performance gains

UX London is an image heavy site, so it was important to look out for ways to make performance gains. This also included perceived performance. When you consider how much has to happen before a page begins to appear in the browser, it's not a surprise that users are sometimes left staring at a blank screen for a couple of seconds or more before their content arrives. But we can do something about that. Improving the perceived performance of a site doesn't technically improve things like page weight or requests, but it can make a huge difference to a user's experience. Here are a couple of quick wins for achieving this.

Font loading

Browsers hide text that should be styled with a custom font until that font has finished loading, which isn't ideal, especially as you can't control the network connectivity your site will be viewed with. Here is how the UX London site used to look on a regular 3G connection:

timeline before font loadingThere should be text under the logo, on the buttons and on the navigation (top right), but you can't see it until the font has loaded.

At his Ampersand workshop on responsive web typography, Richard introduced us to Bram Stein's Font Face Observer, so I decided to give it a try. Font Face Observer is a @font-face loader. You can read more about it on Github, but in short, it allows you to detect if and when a font is loaded. You have to create a new observer for each font family, tell it to check() (observe the font loads), and use the then() method to get a callback when it finishes loading. In this case, when all the fonts are loaded, a class called .wf-active (specified in the then() method) is added to the HTML element, enabling the custom fonts to replace the fallback fonts. So, I've styled every element with fallback fonts by default and custom fonts are added to the .wf-active selector like below:

body {

font-family: Helvetica, Arial, sans-serif;

} .wf-active body {

font-family: PFDinTextPro-Regular', Helvetica, Arial, sans-serif;

}

Now the site looks like this:

timeline after font loadingIf you compare it to the previous image, you'll see that the text appears almost straight away using the fallback font . The perceived performance is hugely improved.

Background images

Once we could actually see the text, it was apparent there was lots of white text placed on top of images throughout the site. It is important to remember to add a background colour to background images so that white text can still be read while image are loading. Look at how long it takes for the image to load on a regular 3G connection, below:

timeline of images loadingWithout the dark background colour, the white text would be invisible against the default white background of the website.

Font subsetting

Font subsetting has made huge difference to the page weight of the UX London site. Since we were lucky enough to know the content for the website, we could safely remove some of the characters in each font. One of the fonts had over 1400 different glyphs and we didn't need anywhere near that many. Jeremy used an app call Font Prep to create subsets of our fonts and it really helped reduce the site's page weight. For example: calluna-medium.woff was reduced from 114k to 18k and DinPro-medium.eot was reduced from 130k and it was reduced to 20k—that's huge! Here's a breakdown of the total size of each file type (there are three font files for each type).

Totals before

  • EOT: 332k
  • WOFF: 468k
  • WOFF2: 324k
  • TTF: 1090k

Totals after

  • EOT: 66k
  • WOFF: 44k
  • TTF: 64k

These are just a few of the steps we took to optimise the performance of UX London. I haven't really covered images in this post, which were huge considerations. The easiest steps we took were using media queries to ensure the right size images are loaded for the right screen sizes. Image-set is a really useful CSS value, which allows us to provide multiple image options and let browsers decide which images to use on high density displays.

I took note of so many useful techniques on this project. Reducing a site's page weight is pretty addictive, so I'm sure this won't be the end of the project.

This was originally posted on my own site.

Related thinking