Listen to Twitter and you’ll believe that building anything less than mobile first, fully responsive websites in this day and age is very very wrong. It’s not always that simple.
My two current projects at work aren’t fully responsive or device agnostic and when I look at all the things I’ve written about over the last year or two, they’re at odds with a lot of what I’ve supported and tried to champion in my work but to be honest it’s nice to concentrate on some known variables for a while.
Project 1 is a fixed width site with a relatively simple front end design but a great deal of back-end development we’re doing with Umbraco.
Project 2 has 4 specific breakpoints which effectively tie in with you’d probably recognise as “mobile”, “tablet portrait”, “tablet landscape” and “big screens” and my build work is defined by a series of visuals (small screens, tablet portrait, tablet landscape and “big”) pre-approved and provided by a 3rd party agency.
For a long time now, I’ve supported flexible templates, content first design and not specifying breakpoints in terms of devices but no doubt like many fellow designers out there I’m limited in my power to influence these two projects and I thought it might be worth reflecting on why it’s not the end of the world.
This isn’t a post saying responsive is rubbish or that you shouldn’t do it on your projects, simply one that explains the background decisions behind a couple of the projects I’m working on.
A fixed width/semi-responsive site, in 2013?
Yep, fixed. As in it’s 1000px wide. View it on a desktop and it’s 1000px wide. View it on a phone and it’s still 1000px wide but as the Go Cardless designers recently wrote, they ditched responsive for their rebuild and went with a fixed width “desktop” site only. We had a similar set of reasons for making a similar decision.
They found, as we did, that there are typically a couple of sticking points with responsive designs once you hit a level beyond standard blog type layouts and dealing with dozens of different templates and pages.
- A lack of current users accessing their site on small screen devices may not “justify” a longer build time
- The time it takes to create and fully test a responsive site is significantly higher than a fixed size one
- Project budget may be limited and resources should be allocated to generate maximum returns on investment
- External decision making
I wrote a while back about not being at the cutting edge and in some ways it can feel like not working on a responsive site is a real step back and “wrong” but in the case of project 1, we spoke at length with the client, established how their current users operate their very extensive site (they do so on a desktop, less than 2% accessed on any sort of mobile device) and what their expectations were for the type of users they’d be targeting (more of the same).
Not every website has 30 or 50% of its users accessing on mobiles and in all likelihood, never will. Even if they do, there’s often a feeling at the moment that responsive design is a one shot deal and that sites you’re building will have to last several years. They don’t. In many cases sites are now evolving and changing faster and a lifespan of 2 years is probably reasonable so change is possible.
Testing time IS greater
I’d love to say building a complicated design mobile first and entirely fluid is a quick and painless thing but it’s not. Yes, you make savings in the design phase by creating more design swatches and patterns rather than full visuals but when it comes to the crunch, testing a large scale site (with a small team like ours) can take a not insignificant amount of time.
On smaller scale projects I find that time saved in designing visuals is roughly evened out by a slight increase in testing time but you roughly break even on time. On larger projects however, testing and tweaking has taken longer and has become more complex when testing on an expanding range of devices.
Allocation of resources within a budget
We use feature based development to give quotes and part of that is mapping out timescales for blocks of work. In the case of project 1, our client had a great deal of CMS development and workflow tools that we all felt would give the client a greater return on their budget than a responsive site that a statistically insignificant number of users would ever benefit from.
External decision making
Coming onto of project 2, well, that’s just easy – it wasn’t our decision on whether the site would be mobile first, responsive, adaptive or whatever. When you’re working solo or you’re in total charge of the decision making chain then it’s easy to lead from the front but that’s not always the case when you work in a team or with other agencies as part of a larger group.
We’re a development agency working in as a part of a chain of other designers and developers on a large scale site project that will span most of 2013. The decision wasn’t ours.
It’s easy to read many designers pontificating on Twitter about mobile first being the only way or that every site has at least 50% iPhone traffic so I wanted to share a few of the reasons behind our current projects that are still exciting us and will be providing some amazing development challenges for Offroadcode this year.
Call for comments
What you are you working on at the moment? Is one of your current projects non responsive or have you made a decision to build in a particular way based on other reasons?
I’d love to hear about your work in the comments (or comment on Hacker News if that’s where you hang out)