What is responsive web development?
Responsive web design involves creating sites which can adapt to suit a number of devices, making the experience of reading and navigating the site totally easy for the user with minimal resizing, panning, or scrolling.
We all know about the pains of browsing on our smartphones (on a long commute or to idly kill time) and encountering a site that isn’t designed to be read on a smaller screen. But why should sites be responsive, and what are the benefits?
It’s becoming essential today that the online world is accessible to all devices and screen sizes. Analysing web traffic metrics, it’s clear that unresponsive sites can instantly create a bad user experience, since a substantial portion of traffic comes from smaller screen sizes. Visitors to a non-device-friendly site will most certainly spend less time browsing, potentially leading to lower conversion rates and, in turn, fewer sales!
Other benefits of having a responsive site come as a result of how Google and other search engines now work. The old method involved redirecting a user to a duplicate but entirely separate version of the site built especially for devices. This meant double the content for search engines to read, which could negatively impact a site’s results and ranking. Furthermore, this would also increase the amount of content to manage, and the overall level of maintenance that a site required.
With Google’s latest update now rolled out, it is more important than ever to have a responsive site. Google recently detailed that the change will have a significant impact on all mobile searches, ultimately meaning that users will be given higher quality results. The effect this will have is that Google will now favour responsive over unresponsive sites, even causing a detriment to rankings for unresponsive sites that previously ranked well.
How responsive sites work – the basic principle
With the ever-changing technologies available to us front-end developers, it’s often difficult to decide how best to go about making a site responsive.
There are several things that need to be taken into consideration; not only the width and height of a potential device on which a site can be opened, but also how the browser on the device itself renders code. A lot of testing is required when we make our sites responsive, to ensure a seamless user experience across a range of devices, all potentially running different versions of various browsers. Here at Edit, we test on actual devices; we have a large collection of some of the most prevalent devices on the market, ensuring the product we deliver works on pretty much everything (we still hate IE8).
Much of the work is done in the CSS (Cascading Style Sheets). This code controls how the site looks, as well as some of the interactive functionality that sites offer. In CSS, we use media queries to make a site responsive, which tell a browser how things should look via some rules defining the width of the screen. For example, for a small device we can write a media query like this:
@media (max-width: 600px) {
// Some code goes here
}
The code we could include overrides any pre-existing code that governs the site’s appearance (beyond the 600px defined in a media query).
Depending on the platform, we also use Javascript to add functionality or move elements around on a page; this is known as ‘DOM manipulation’. We try to avoid doing this if responsive sites can be made fluid using well-written CSS, but sometimes it is a necessary evil.
How we used to make sites responsive (frameworks)
Due to the open-sourced nature of the web industry (with people sharing ideas and methods with one another), there is a large collection of front-end frameworks we can use to make sites work.
Some of the most popular are Twitter’s Bootstrap framework, and the Foundation Framework from Zurb.
Now, there is nothing wrong with these as a method for making a site responsive. The issue for us is that it pigeonholes our designers into using the set breakpoints defined by the frameworks, and also adds a whole heap of code that you might not even end up using! If you are a novice developer and need a quick start to a project, and don’t mind editing lots of html with prestyled classes to apply the responsive CSS, then either of the above frameworks will work great for you.
For us at Edit, these frameworks have been known to cause more issues than they solved. Having to use the infamous ‘!important’ rule in code to override an existing framework override seemed like a long-winded process to fix some of the issues that continually occur using these methods.
To combat this, we came up with a solution that works for us (each to their own!). We built our own framework and set it up to work on the platforms we use most often, so we now have a “Vanilla” Sitecore, WordPress and Magento build. The framework we use across all of these is catered for each platform specifically, which allows for rapid development at the start of a project and ensures quality across each build.
How our new front-end framework makes responsive sites possible
The technologies used in this new framework are all open-source, too! From a variety of libraries and using pre-processed CSS languages, we can speed up the writing of responsive code. We can use some shortcuts within our code which can make development very rapid, and also limit the amount of time it might take another developer to pick up our work and continue if needed.
Our new way of working on the front end of a project utilises a compass gem: SUSY. Here’s what the people behind SUSY have to say:
“In a world of agile development and super-tablet-multi-magic-laptop-phones, the best layouts can’t be contained in a single framework or technique. CSS Libraries are a bloated mess of opinions about how to do your job. Why let the table-saw tell you where to put the kitchen?”
Using this grid system, along with the breakpoints gem, we can write super-lean CSS (compiling it using compass through a Gulp.js task manager!). This new way of working frees up our designers, too, they can build sites of any arrangement to whichever grid they determine to be best for the job. It gives us much more power over what we write and how we write it.
We can create seamless fluid grids without the need for “snapping” (i.e., forcing the appearance of the site to snap into a different size and layout as the screen increases or decreases), and our ethos when adding responsive breakpoints to a site now is to only add one at a point at which the site breaks. That is, if something doesn’t look right or could be optimised when scaling a site down, we optimise it! A project could end up with quite a few break points in the process to ensure the collapse is as perfect as possible – a move away from the out-of-the-box predefined breakpoints of other frameworks. Again, it all comes down to customisation and giving us the chance to create engaging and unique designs for our clients’ sites.
In conclusion
Sites needs to be responsive now – this is a simple fact for anyone looking to compete in a competitive and highly market-focussed environment. Here at Edit, we can deliver an effective and scalable solution to any web-related needs. We have the experience of using third party frameworks, but we now prefer our new method over other libraries; again, that’s not to say that Bootstrap and others don’t serve a purpose. In the frenzied world of UI development, prebuilt frameworks will always have a place; the only thing to consider is what’s right for your project, and since our internal team has spent time developing a bespoke system for our own needs, we felt it was a good time to move away from third party frameworks. The best thing about these new technologies is that we are currently still finding more and more things we can do with our new framework, utilizing both the SUSY and Breakpoint libraries – the possibilities are limitless!
If you want to have a look at some of the resources mentioned in this post checkout the links below:
