2013 and what to look for in 2014

With new years day now a distant memory for some I thought it was time to look back at what happened in 2013 and what we should expect to see in 2014.

NOTE: In a recent review of the article content I came across this article. It was written on the 1st January 2014 and I never got around to finishing or publishing the article. It’s a little late to finish my predictions now that we’re getting towards the end of 2014, but it’s nice to look back on last year. I’ll put another set in for next year and stick by it.

2013, a year in review

Twenty Thirteen saw a continued push towards a responsive web.

There were hundreds of articles published (add a link to pinboard.in for newslettered articles between Jan and December last year)
many more high profile websites went responsive (link to a series of these)
Page weight increased another 2x (link to web trends)
Performance began to get a foothold
Preprocessors (for CSS at least) made a push
Responsive web applications (although the argument over what the difference between a website and an app continues[link to Jeremy Keiths article]) became more of a focus.
Applications to help designers produce responsive design code came into their own (moovweb, webflow, froont, Adobe Reflow)
Responsive testing applications matured (Adobe Edge, GhostLab)
Responsive Image battle raged on.
Content became a more focal point
Mobile first became a mantra
We’ve began to see responsive design trends

Responsive Design Articles

Over 2013 I’ve personally covered 966 articles in the responsive design weekly newsletter. That doesn’t take into consideration the number of articles that curate out of the newsletter each week (probably add another 50-100% on top of that figure).

These are all large branded sites that have been working on responsive redesigns. By the time the end of 2013 arrived I couldn’t walk into a client meeting without someone asking if the site was going to be made responsive? “Will it be responsive? It has to be responsive. Your CMS supports responsive right?”

Page weight increase

It’s doubled. AGAIN!

With my fingers crossed this doesn’t continue, 2013 saw another sharp increase in the size of web pages.

With the arrival of more smart phones with bigger screens and more pixels per inch a lot of websites have gone with a very heavy image focus. Big bold beautiful images with minimal text that turn what would normally be a small page weight into a few second delay.

Single page parallax scrolling sites didn’t help this too much either, and anyone that didn’t do some kind of lazy loading forced people into expensive data charges on mobile networks.

Hopefully things change in 2014.

Performance improvements

Name and shame (oakley, Nixon etc_
Speedcurve provides feedback on performance
Webpage test included mobile

Although there were some embarrassingly large sites (Oakley, Nixon…. we’re looking at you) there was a big push throughout the year and more towards the end for performant websites.

There was a cry to include performance as part of your website budget, which is a great idea when moving forward with any redesign.

Fortunately there are more and more tools that provide us insights into how our pages are performing — and even allow us to benchmark against our competition.

SpeedCurve

SpeedCurve takes a snap shot of your site for particular pages on a day to day basis so that you can see how you improve over time. It also includes a benchmarking feature to see how you compare to others within your industry.

Webpage Test

WebPage test provides a similar review to SpeedCurve, expect it won’t track you over time and is a less “pretty” experience. It is free however, and if you just want the raw numbers then this will do just fine.

Preprocessors

Sass continued on the rise
Systems like Mixture.io are taking off

Sass

Sass has gone from leaps to bounds in 2013 and it looks like taking out the winners trophy in the race for CSS Preprocessors. Twitter Bootstrap, probably the most popular responsive framework out there, is built upon Less so don’t count it out of the race just yet. At the end of the day though, Sass provides the same features as Less in an interface that’s just as easy… but Sass also provides so much more.

Mixture.io

Mixture is a preprocessor of sorts, but it’s even more then that. It runs Sass and Less itself, but also offers things like Moustache and Handlebars within it’s application. It’s probably best described as slightly more functional Static Site Generator and would pip things like

Responsive Web applications

WordPress admin interface
Mailchimp
Polar

Responsive Images

3 possibilities: srcset, src-n,
Polyfills: picture fill, srcset fill, wikipedia throwing their weight behind x, national geographic throwing their weight behind y.
SAAS RWD Image solutions: Adaptive Images, ress.io, [other image solutions]

Content Priority

A list apart (find other examples)
Medium

Mobile First

Zurb Foundation and Twitter Bootstrap both refactored their approach to their front end responsive frameworks taking a mobile first approach.

Consistent approaches, design trends… what’s the name I’m looking for here?

Hamburger icon is for navigation
Offscreen works best for secondary content

What are the responsive web trends for 2014

Further reduction of m. sites

Further steps will be taken to realise that this is really a one web world. The requirement for a m. site should be questioned as we try to achieve content parity and a single URL for all devices.

There could be an outside chance that we see a resurgence in a few m. sites with big brans, however I feel that companies that already have large and complex sites will already have an m. variety.

So why the resurgence? Well if you have a large and complex site it could be easier to move to a responsive alternative by starting with a mobile first m. site. This has a few advantages

Management probably won’t bat an eyelid at an m. site development in the same way they would if you said you were going to get into a full blown responsive project.
It forces you to think mobile first so anyone that is throwing weight behind the desktop version won’t bother you in the first instance.
It’s much easier to get all of your content components on the page in a mobile view and expand upon them as the viewport increases.

The idea is that once it’s finished and tested you can start working on the increasing viewports until you’ve got a fully responsive site, then you switch the m. for www.

Overall page weight will increase, but initial load will hold steady.

With the push for faster websites and the focus on performance I can see that the initial page render will plateau at 1.4mb. To me this isn’t small enough at the moment, but based on all the evidence at hand it seems that everyone has accepted this to be a suitable size.

Rather than increase I suspect that we’re going to continue to build our sites smarter and offer additional content that requires a more sizeable slice of bandwidth or possible page load time (images, embeds, videos) will be loaded in as needed.

There are already some great tools that provide this for social icons that allow you to show the image of Twitter, Google Plus, Facebook and the like but not load in their JS and frames until the the user shows intent to utilise them.

Also with the promise of Client Hints on the horizon it could mean that we have more information at the server end to make a better informed decision about what size image/quality video to serve and subsequently reduce the overall page weight.