Responsive Design Myth(blog.scoutzie.com)
blog.scoutzie.com
Responsive Design Myth
http://blog.scoutzie.com/post/28632936392/responsive-design-myth
15 comments
You can have your cake and eat it too if you focus on client-side adaptation. For instance, with MIT-licensed Mobify.js which we recently released (http://mobifyjs.com) you can have any amount of mobile-specific functionality while keeping the URL of your desktop site intact. Works especially well if your site is complex!
I think that if you settle for a layout that is, from the beginning, relatively mobile-friendly, responsive design will work perfectly and have minimal overhead.
The web is going mobile and that's something designers and developers have to learn to live with - don't think of your interface as a two-headed creature, but rather as a cross-device design which can adapt itself to different resolutions and screen sizes.
Responsive design won't make things easier if what you want to do anyway is two completely different sites. It will probably work better for you if you place the focus of your design at a spot that is slightly more mobile that desktop-oriented (in today's standards). Then it will be all about filling up empty space whenever it's available.
The web is going mobile and that's something designers and developers have to learn to live with - don't think of your interface as a two-headed creature, but rather as a cross-device design which can adapt itself to different resolutions and screen sizes.
Responsive design won't make things easier if what you want to do anyway is two completely different sites. It will probably work better for you if you place the focus of your design at a spot that is slightly more mobile that desktop-oriented (in today's standards). Then it will be all about filling up empty space whenever it's available.
The article states, "Take a look at your Google Analytics first, see how many visitors are coming to your site from different devices, look at their screen resolutions and operating system and then decide who you want to please first."
That does align nicely with data driven decision making, but I'd sure be worried that new visitors, upon visiting my site and realizing the competitor's responsive site is a much nicer experience, decides not to return.
I help run a small store online with enough traffic to matter to me and I think I'm at around 12% mobile new visits. That's a lot and I'm currently not responsive. I'm becoming a bit anxious wondering about new user experience on my site and whether I should start the move sooner than later.
That does align nicely with data driven decision making, but I'd sure be worried that new visitors, upon visiting my site and realizing the competitor's responsive site is a much nicer experience, decides not to return.
I help run a small store online with enough traffic to matter to me and I think I'm at around 12% mobile new visits. That's a lot and I'm currently not responsive. I'm becoming a bit anxious wondering about new user experience on my site and whether I should start the move sooner than later.
That definitely makes sense. We aren't saying that you shouldn't consider doing a responsive website for your mobile visitors, you certainly should. But, like you mentioned, you have a small team and there must be other features on the development roadmap that may be of a higher priority. For example, if you run mobile-targetted ads, you should probably have a great experience on mobile to make sure your users convert. However, if your shopping cart requires 16 steps to checkout, then you're better of first upgrading the cart to a 1-3 step checkout process. Do you see what I mean? Thinking about user data just helps to make a decision on when you'd start implementing responsive layout.
Responsive design is nice and is a very good and useful tool. If done right, it makes your site react better for a larger group of users.
However, your QA time and effort explodes when you do responsive layout. Your testing matrix goes from basically 2 operating systems and 4 browsers all at a fairly standard screen resolution target to supporting 4+ operating systems, 6+ browsers, and at the very least 4 significantly different resolutions/form factors as well as the ability for the user to change orientation.
Visual bug testing and layout issues add a ton of work and testing, especially at the beginning of a project.
Also, making a WHOLE site with multiple different areas, layouts, functionality responsive is a lot different than just making a single blog layout responsive.
However, your QA time and effort explodes when you do responsive layout. Your testing matrix goes from basically 2 operating systems and 4 browsers all at a fairly standard screen resolution target to supporting 4+ operating systems, 6+ browsers, and at the very least 4 significantly different resolutions/form factors as well as the ability for the user to change orientation.
Visual bug testing and layout issues add a ton of work and testing, especially at the beginning of a project.
Also, making a WHOLE site with multiple different areas, layouts, functionality responsive is a lot different than just making a single blog layout responsive.
In practice, I just don't think that's the case. The entire point of a responsive layout is that you don't have to test against every possible resolution - most responsive websites have 2, maybe 3 conceptual layouts. You can get sufficient coverage by separating the layout testing from the site logic - test the layout on desktop with varying window sizes and then test site logic on the major mobile platforms. That usually means 4 desktop browsers with varying window sizes and 3 mobile browsers... not too bad.
Wait, so what is the alternative? If you're going to develop several different layouts, you have to still test them each, anyhow.
The only way out of the testing morass is to simply not target or optimize for some set of devices. I don't think that is the answer.
The only way out of the testing morass is to simply not target or optimize for some set of devices. I don't think that is the answer.
I totally forgot to mention the testing in my rant...
This post is only the preface to a novel that could be titled "The Devil's Advocate's Guide to Responsive Web Design". The complicated decisions facing those tasked with developing and maintaining a responsive site are legion.
To start, determine your breakpoints so you can employ the magic of media queries...
...which are neat, but little more than a parlor trick in real world application since serving all the CSS for all possible views is an anti-pattern...
...especially under the currently accepted best practice/mantra of "Mobile First" site development, which dictates initially assuming a visitor is on a smartphone (to achieve the fastest response for the weakest use case, i.e., relatively low power device+high latency/unstable network) then dynamically scale the content/features based on client capabilities...
...requiring a solution for feature testing and/or device detection, which is performance overhead somewhere in the stack and, though evolving quickly, will remain a elusive target for the foreseeable future...
...which THEN means (just as the OP says) you aren't really developing, maintaining, and serving a single responsive site but one of 3 or more variations which, depending on who you ask, should have context appropriate content.
What's that? You have a highly-performing, flex grid-based, sugar-coated wonderland of a site? Tell me how efficient your responsive/adaptive image workflow/solution is...
TL;DR Thank you @beep for the job security. ;)
To start, determine your breakpoints so you can employ the magic of media queries...
...which are neat, but little more than a parlor trick in real world application since serving all the CSS for all possible views is an anti-pattern...
...especially under the currently accepted best practice/mantra of "Mobile First" site development, which dictates initially assuming a visitor is on a smartphone (to achieve the fastest response for the weakest use case, i.e., relatively low power device+high latency/unstable network) then dynamically scale the content/features based on client capabilities...
...requiring a solution for feature testing and/or device detection, which is performance overhead somewhere in the stack and, though evolving quickly, will remain a elusive target for the foreseeable future...
...which THEN means (just as the OP says) you aren't really developing, maintaining, and serving a single responsive site but one of 3 or more variations which, depending on who you ask, should have context appropriate content.
What's that? You have a highly-performing, flex grid-based, sugar-coated wonderland of a site? Tell me how efficient your responsive/adaptive image workflow/solution is...
TL;DR Thank you @beep for the job security. ;)
I agree wholeheartedly with the sentiment of this piece, but I think the distinction between layout and design isn't highlighted.
If you use a framework like Bootstrap to underpin your html and css then having a responsive layout is really very easy. The point of a responsive layout is that your site is legible and clickable to users on non-desktop screens, not that your site looks beautiful for every user.
If you use a framework like Bootstrap to underpin your html and css then having a responsive layout is really very easy. The point of a responsive layout is that your site is legible and clickable to users on non-desktop screens, not that your site looks beautiful for every user.
Fred, you're right. Adding responsiveness to the site, using Bootstrap or similar frameworks isn't too difficult. But, adding responsiveness with a layout designed to be functional specifically for a certain device/screen size, that is the complicated part. Thanks for the comment!
The fact that Apple.com doesn't have a responsive website is enough to make me doubt the benefits over cost of a responsive design. Of course, Apple has been hard-core pushing the app-mentality...but still, they have the budget and design crew to easily make a responsive site.
Ditto for the New York Times site. I haven't yet seen a responsive site that doesn't inadvertently hide critical features in its minimalist mode, because, I'm guessing, the middle-managers don't thoroughly test enough.
Ditto for the New York Times site. I haven't yet seen a responsive site that doesn't inadvertently hide critical features in its minimalist mode, because, I'm guessing, the middle-managers don't thoroughly test enough.
But those aren't features you'd be getting in a non-repsonsive design. The features that often aren't in the mobile-responsive version are the features that you don't get in the mobile site or the mobile app anyway.
Also, I don't know how Apple not doing something is evidence of a trend.
Also, I don't know how Apple not doing something is evidence of a trend.
The numbers suggest that more and more users are going to be hitting the web on mobile devices (numbers vary a bit, but the consensus seems to be close to doubling annually and around 10% at the moment).
It seems to me that it's not a question of responsive design or not; and it's not a question of responsive design vs. separate sites (completely or substantially separate code). Rather, it becomes a question of how much time do my analytics numbers suggest I should spend making my mobile presentation better?
It definitely cuts both ways, and for some using a decent responsive framework will certainly be fastest, for others, a quick mobile-only lander that directs to a native app might be more well-suited. This problem isn't going away anytime soon, and I'm keeping an interested eye on the almost classic 'responsive vs. mobile-specific vs. native' debate (and all of its variations).
It seems to me that it's not a question of responsive design or not; and it's not a question of responsive design vs. separate sites (completely or substantially separate code). Rather, it becomes a question of how much time do my analytics numbers suggest I should spend making my mobile presentation better?
It definitely cuts both ways, and for some using a decent responsive framework will certainly be fastest, for others, a quick mobile-only lander that directs to a native app might be more well-suited. This problem isn't going away anytime soon, and I'm keeping an interested eye on the almost classic 'responsive vs. mobile-specific vs. native' debate (and all of its variations).
I'm interested in how accessibility fits in here.
Does it get built in at the beginning whether people chose a responsive design or separate pages? Or does it get kludged in at the end, if at all?
I had really hoped that the adoption of smart phones would mean that more sites would have either simpler pages, or would have a minimal version of the page. For example; most sites could get away with a read-only, html+css tiny version of the page. But I accept that I'm wrong and that very few people share that vision and most people want everything on a handheld device.
Does it get built in at the beginning whether people chose a responsive design or separate pages? Or does it get kludged in at the end, if at all?
I had really hoped that the adoption of smart phones would mean that more sites would have either simpler pages, or would have a minimal version of the page. For example; most sites could get away with a read-only, html+css tiny version of the page. But I accept that I'm wrong and that very few people share that vision and most people want everything on a handheld device.
Responsive (and real-time) websites are fundamentally more complex and more expensive to build. There’s no getting around that. If you're going to make the leap, it’s a business decision like any other, and you need to decide if it’s worth the significant initial investment and ongoing maintenance cost.
The apples to apples comparison would be a responsive site versus two separate sites for mobile vs. non-mobile. In that case, I'm not sure its clear a responsive design is fundamentally more complex and expensive to build. In the latter case, every time there is a new feature you have to essentially implement it twice.
There should also be a distinction for dynamic and static websites. I've built many responsive static websites and it was fairly easy and not very labor intensive.
Then I built two fairly dynamic sites which were responsive and the game completely changed. There are so many elements you take for granted on a static site which need to be accounted for. Yes, it took more time, but it also opened the site up to less hassles from mobile users. It also made us really focus on the UX aspect to ensure the user was getting a great experience.
I'm a huge proponent of responsive design. I think it's made me a better developer and designer.
Then I built two fairly dynamic sites which were responsive and the game completely changed. There are so many elements you take for granted on a static site which need to be accounted for. Yes, it took more time, but it also opened the site up to less hassles from mobile users. It also made us really focus on the UX aspect to ensure the user was getting a great experience.
I'm a huge proponent of responsive design. I think it's made me a better developer and designer.
I agree with the author. Having just built a very large responsive website, every new update / feature is (almost) mulltiplied in complexity by the number of devices we support. Especially when the feature is doing complex interactive stuff. For instance, we just built an interactive newsletter reader with drag-click-slide whirling html5 shaz that i ended up having to do 3 version for in css & js on Tablets, Desktops(plus IE), and phones. What I'm wondering is how to monetize as a devloper in the long term. After a year or so experience now I'm definately seeing that a one time up front bill for a mobile version does not cut it.
Making a website that works on desktop, tablet, and mobile all at the same time is difficult and expensive. Responsive Design's value proposition is that it is somewhat less complex and expensive than having a bifurcated experience on an m. subdomain. It also avoids some issues attendent with bifurcated experience[1], and maybe you can even have a decent tablet-specific design.
The head of webdev for my company says that a responsive design is usually about 20-30% more expensive than a traditional mobile-ignorant design. This is significantly higher than 0%. It is also significantly lower than the ~100% increase it would take to build a separate dedicated m. experience. The resulting mobile experience is significantly more full-featured than the shitty bifurcated experience[1] you could otherwise get with 30% of the main site's budget.
Responsive Design is not a silver bullet, and should not be sold as such. If it is worth your time to make a mobile version of your site, it is an extremely attractive option for doing so, and generally superior to the alternatives. Doesn't mean it's free or perfect, just means it's better than the other ways of doing it.
[1] http://xkcd.com/869/
The head of webdev for my company says that a responsive design is usually about 20-30% more expensive than a traditional mobile-ignorant design. This is significantly higher than 0%. It is also significantly lower than the ~100% increase it would take to build a separate dedicated m. experience. The resulting mobile experience is significantly more full-featured than the shitty bifurcated experience[1] you could otherwise get with 30% of the main site's budget.
Responsive Design is not a silver bullet, and should not be sold as such. If it is worth your time to make a mobile version of your site, it is an extremely attractive option for doing so, and generally superior to the alternatives. Doesn't mean it's free or perfect, just means it's better than the other ways of doing it.
[1] http://xkcd.com/869/
A bit OT, but I don't really get the need for a tablet specific design apart from the desktop site in general (I'd see why gestures for e.g. would be tablet specific, but almost no site with iPad specific versions use them). What would be the hurdles to have the same version for tablets and desktops, and a more reduced version for mobiles? It would force a very discoverable page design, no plugins required, and a lot of side benefits from the design POV in my opinion.
We used gestures and a whole slew of iPad-specific media queries and rendering logic on bostonglobe.com. While I agree that you can usually write a lot of common desktop/tablet code in a responsive design, adding tablet-specific (or iPad-specific) features in a responsive design is a big selling point to your typical executive-type.
(Dislaimer: I used to be an engineer at the Boston Globe)
(Dislaimer: I used to be an engineer at the Boston Globe)
In my experience it's 30-40% more expensive, but I try to make the responsiveness fluid from min to max, instead of targeting certain breakpoints so I might be spending a bit more time than others.
Unless you're really going crazy with your dedicated mobile design, it's not going to cost 100% more than a desktop design. I suspect that it many cases, it's probably the same 20-30%. In my mind, the main benefit of being fully responsive is that (in theory) it's easier to maintain a single code base and (in theory) it's more future proof.
Myth, or unrealistic expectations? Aside from the point that one should make sure a significant number of their website visitors are from tablet / mobile (which based on broad trends, would be surprising to find wasn't the case) before diving into targeting different than desktop screen resolutions, I would have liked to see more detailed analysis on the alternatives and whether they were any better. My sense is that responsive design is a technique that can make managing desktop / tablet/ mobile experiences easier than maintaining completely separate websites. Another point of doing responsive design is that a few tweaks can make one experience (say tablet landscape -> HD) work much better for a range of resolution sizes than doing a fixed pixel design.
Not related to the content of the article, but
they should just invest in responsive now
I always get weirded out when adjectives turn into nouns for the first time. I think, "Did he mean invest in responsiveness"? "Invest in a responsive design"?
I'm sure the weirdness will go away, though. I'm almost comfortable with "mobile" as a noun, and "multiplayer" as a noun seems perfectly natural to me (though "online" as a noun in gaming contexts still has a ways to go).
they should just invest in responsive now
I always get weirded out when adjectives turn into nouns for the first time. I think, "Did he mean invest in responsiveness"? "Invest in a responsive design"?
I'm sure the weirdness will go away, though. I'm almost comfortable with "mobile" as a noun, and "multiplayer" as a noun seems perfectly natural to me (though "online" as a noun in gaming contexts still has a ways to go).
I think responsive Web is really at its most powerful if the site is minimal (like google). For any advanced site, either lots of care needs to be taken or perhaps the dreaded "m" subdomain?