At UI Farm we’ve recently completed the first phase of our responsive framework for WordPress, releasing it as our approach for clients and our own website. This article we will begin to explain some of the best features that we have already implemented. And sure, with our roadmap we look forward to add new features, improving the existing implementation whilst keeping it the most performant we can.
Scope of Our Custom-built Framework
From the very beginning, we aimed to:
- have a starting point for any responsive web project
- be able to fire up a new WordPress website in minutes
- have a platform that is able to easily adapt to clients’ needs
- have a fluid and fully semantic grid handled with custom SASS/Compass functions
- have web typography
- have feature detecting
- have progressive enhancement
- have the fewest possible WordPress plugins
- have everything under source control
- work with 3 different development environments: local, preview, production
- have every stage constantly documented
- have a straightforward CMS update plan
- address accessibility
- address hi-res monitors
To do such a thing we needed to look at performance as a major feature implemented by default from scratch, and not treated as an afterthought.
Most points respond to our need to achieve the best performance and to serve a good multi-device experience at the same time.
The majority of tasks related to the CMS and the source code are not of any interest here, since they’re related to scalability and maintenance. Let’s start with one of the most frequently debated questions.
Why Didn’t UI Farm Choose an Existing Framework?
There are plenty of ready-to-use and responsive frameworks, like Twitter Bootstrap, or Foundation. While there are many good reasons to use one of them, there are also good reasons to not use them. The context is all and our decision was based out of our specific situation:
- we didn’t want a starting point with a pre-defined look & feel
- we didn’t want to spend valuable time to “reset” that look & feel for each single website
- If we had to spend a lot of time digging a framework to learn everything that’s under its hood, why not spend that time building our own based on our needs?
- if we didn’t spend that time digging the framework, we would end up with websites full of useless non-optimised clutter
This simple analysis lead us to the decision: if we wanted something really optimised, performant and easy to scale and maintain, we couldn’t use any of the existing frameworks.
If you prefer a stronger point of view, read this analysis from Joshua Gross.
Designing the Performance
Have a Starting Point for Any Responsive Web Project
Within our framework we have two themes: a parent and a child. The parent theme is part of the framework itself, along with the CMS and our custom made functions and plugins. It has its own repository, with independent version tags and roadmap. It’s imported — and updated — in each project through an SVN external request.
The parent theme is unstyled, and it contains almost all the functions and SASS mixins to calculate and handle things like the main fluid grid, photo gallery grids, icons library and everything that’s not strictly related to the final skin of the website.
Alas, the child theme is the skin, and it’s got all the styled elements: logos, navigation menus, colours, custom web fonts, sprite image, etc.
Fire Up the CMS!
With this structure we can build a new website in minutes: create the remote code repository, set the SVN externals with the latest version of WordPress, a few plugins we use and the parent theme. We setup the database, run the 30 second setup for the CMS and finally login. We have a fully working local environment literally in minutes. Later we can think about the preview, stage or production environments (which are already set in the
Having the environment up and running, we can copy our child theme, enable it from the Dashboard and start working on the skin.
Only Few Plugins
Why? Again, to provide the best performance. The more plugins we use, the more cluttered code we have — especially since plugins tend to inject code or scripts and they’re not always fully documented. Plus, we don’t want to spend all the time needed to dig plugins, so the solution is to use no more than a couple of those and add more functionalities hacking the powerful
functions.php file in the theme’s root.
Fluid AND Fully Semantic Grid
If you do Responsive Design, you use a fluid grid. But what about all those grids out there, ready to use? Well, roughly 90% of the existing grid systems rely on a heavy use of divs and non-semantic classes.
We used the power of SASS and Compass to build our own fluid grid. Relying on dynamic functions instead of fixed divs and classes, we managed to calculate all the widths and elastic gutters, on the fly, without adding any un-semantic value to the markup and keeping our tag structure clean.
Performance Specific Tasks
A vast majority of the user response time — around 85% — is spent on downloading all the components in the page: stylesheets, scripts, images. Reducing the number of components reduces the number of HTTP requests required to render the page. This is the key to faster pages. Other than simplify the pages, there are other ways to get a low number of HTTP requests.
We addressed all of these tasks specific to performance:
- HTTP requests to a minimum
- CSS at the top
- CSS sprites — We combine all the suitable images in a single CSS sprite using the
background-positionproperty to display the desired image segment
- Inline images — On occasions, we use inline images, using the
data:URLscheme, usually to implement gradients or fallbacks for IE8 due to the lack of support for CSS3
- Use web fonts for icons, instead of images. We subset the fonts, embedding only symbols actually used, to keep the size lighter
- Reduce the number of DOM elements — Another reason to avoid using divs and classes to set up a fluid grid
- Use a CDN
To learn more about this, there is a well done document on Yahoo’s Developer Network.
Detect and Enhance
We use feature detection for progressive enhancement, to serve specific functionalities only when supported by browser/device. Currently we’re not using any server-side device detection, and prefer to rely on finding what the device can actually do, no matter the agent.
We don’t set any custom web font in the parent main theme, so we’re free to decide and set it up later in our child theme. Also, if there’s no need for custom web typography we can use one of the old web-safe fonts. The less HTTP requests, the better, especially if requests are without any real use.
Oi, the Default WordPress Theme is Responsive!
Yes, Twenty Twelve theme is by default responsive, so why didn’t UI Farm use it as a parent theme and build a child theme on top of it for each client? Two reasons:
- Did we mention we don’t want to waste lot of valuable time on learning something pre-built?
- A common website built on top of Twenty Twelve has around 500 DOM elements, while our finished framework (two themes) is settled at 168.
Stay tuned for the next part in the series on our Responsive Framework:
- Design in the browser
- On-demand content
- UI Farm’s Responsive Workflow