Reader Glynn writes in:
I’m wondering if you’d ever seen a responsive web design in which a ‘see full site’ link was included. I know that when developing a responsive design we should stay away from hiding content completely, however some users may actually prefer pinching and zooming and using good old fashioned horizontal menus on their devices.
Have you seen an example of this and how do you think it could be approached?
I think this is a pretty darn interesting question.
There was a time when we jousted any site with a mobile version that didn’t give us a “full site” link. But with responsive design taking hold, we’re seeing a lot less of that. In fact I’m not sure I’ve ever seen it on a site that uses responsive design exclusively to accomodate mobile screen sizes.
Why don’t we see opt-out responsive design? My guess is two-fold:
- It’s a bit technically challenging to implement and there aren’t a lot of precedents.
- It’s admitting you didn’t do a very good job on the responsive design.
The latter likely being the bigger factor. Like: why are we creating this responsive design at all if we aren’t sure it’s a better experience?
A possibly-legit situation is different use cases for different users. Perhaps most users come to the site to read and your responsive design accommodates reading very well. But some users come to do some other task and to them the responsive design is hindering.
Doing it
I haven’t actually done this, but theoretically this is how I would. This will be easier if you’ve gone with a desktop-first approach rather than a mobile-first approach (I would think).
1. Query param to swich
Perhaps:
http://yoursite.com/?resp=no
2. Remove viewport meta and class the body
Then you test for that param. I’ll use PHP here just because but it could be anything. We’ll only remove the viewport meta tag if they don’t want responsive design, as well as put a class on the body.
<head>
<title>My cool site huzzah</title>
<?php
if (!$_GET['resp'] == 'no') { ?>
<meta name="viewport" content="width=device-width">
<?php } ?>
</head>
<body class="<?php if (!$_GET['resp'] == 'no') { echo "resp"; } ?>">
You’ll probably want to get a little more complex here. You’ll want to set a cookie (or perhaps use localStorage) to remember the users preference. Then you don’t just test for the query param but also the value of that cookie before making the decision to exclude the viewport meta or not (and the body class).
3. Qualify your media query styles
One way to do this would be to exclude the loading of a separate stylesheet where you have all your responsive styles. That might work for you but I’m generally a fan of keeping as much CSS together in one file as possible. If you do keep it in one file, you can use that “resp” body class to ensure media query styles don’t take place if they shouldn’t.
.page-wrap { width: 80%; }
@media (max-width: 600px) {
.resp .page-wrap { width: 100%; }
}
This way the responsive style will only take hold if the media query matches and the proper class is on the body indicating it’s OK to use responsive styles.
4. Have good UI to switch between
Whatever you cook up, make sure it’s pretty clear how you get back and forth between the two site styles and that it sets the cookie stuff properly.
I haven’t seen this in the wild but have considered for retro-fitting a site with a RWD before, the principle was that existing users may be confused as the desktop design wasn’t changing, so was better to at least give them an option of viewing the ‘desktop’ version from their mobile.
I wrote a demo of how I would do it: http://neilcarpenter.com/2012/05/creating-a-faux-view-full-site-button-for-responsive-sites/
And then actually found a far better solution elsewhere which sets a fixed with in the meta viewport tag: http://creativeandcode.com/responsive-view-full-site/
Also, in the same vein as this, Boris Smus’ Device.js (http://github.com/borismus/device.js) allows for switching of different views on the fly – firstly based on viewport width but also can be manually selected by the user. Demo here: http://borismus.github.com/device.js/sample/desktop.html
Worked out a solution for this a while back (posted it to the CSS-Tricks forum too!). Uses JS to modify viewport tag, requires no class qualification leading to (potentially) bloated CSS. Also uses localStorage to save the user’s preference.
http://creativeandcode.com/responsive-view-full-site/
Yup, that’s the same thing I was thinking. I even made a small library for it, taking it a little bit further.
http://responsiveviewport.com
“ReView is a dynamic viewport system that provides efficient responsive web design viewing choice”.
Turns out it gets quite hard when you want to be able to switch in both directions especially on page zoom, but it is still workable.
If anyone wants to help push what I have so far I am likely to open source it soon.
Very glad you included the part about saving the user’s preference. It is so annoying when you click “View Full Site” on a mobile device, which takes you to the full site, but then as soon as you click something there you are taken back to the mobile/responsive version instead of staying on the full site.
I was just thinking about this the other day. It would be interesting to implement and then track analytic information on it to see if people actually use it.
Definitely agree on your point that if this requested, then the responsive site must be lacking in some areas.
I’ve wondered this myself actually.
Perhaps setting a cookie would be a simpler option and wouldn’t necessarily require server-side code.
kind of related.
loaded up css-tricks in Chrome for Android and clicked “Request desktop site” to see if that could accomplish the goal of this post. it didn’t work.
but for some odd reason, it made your header font look like a ransom note with an odd mix of bold and normal letters. what’s up with that?
I think the important thing to remember is that you can only know what most people want. Some folk are stubborn and don’t want anything to do with your fancy responsive design.
Assuming that everyone likes your designs is foolish and irresponsible. People will accept it on a website because that’s how your website is, but if you change it for mobile, they now have something to directly compare it to. Some people are going to want it the old way.
“Trust me, it’s better for you” is just a rude way to think. Cater to the majority first, but make sure you don’t alienate the minority. And people are very alienated when they know you have what they want but refuse to give it to them.
I think this type of thinking is important. Users first. Don’t be foolish with a responsive design, being quick to implement it just because we feel that we ‘should’. It’s all context – type of site, type of visitors, etc – based on research and analysis on a case by case basis. I’ve encountered this problem myself, of wishing I could pinch and zoom on the full site – but it was primarily on sites where the responsive aspect of the layout was poorly done and “minor” things were just arbitrarily hidden.
Another *big* barrier is JS. Simple RWD can skate on CSS alone, but JS is inevitably called on for the complex, heavy lifting. It’s not simply a matter of swapping stylesheets then. You may need to port or rewrite client-side functionality for “desktop view scaled on mobile” use case. Not pretty or enticing.
I was actually just thinking about this the other day and you’ve brought up a solution I didn’t. The problem I can see with adding a string to the URL though is that if you copy the link and share it somewhere you’ll be sharing the non responsive version of the site, which is probably not preferable.
I wish I could tell you of something more useful that I thought of, but I can’t. Short of a cookie I’m not really sure what you could even do?
Basically what I landed on was that if you are concerned about whether or not you need a “full site” link, you’re probably not in a place to deliver a responsive site. In my particular case I was asked to create a responsive stylesheet for a long standing cms and all of their clients. For obvious reasons this is incredibly complex and there’s no way I could deliver a single stylesheet that would fit all solutions (mostly because their code is non semantic) so because of time constraints we are being forced to go down the redirect to a mobile site route.
How about the link should be to itself, and JS will set the cookie, so that way the URL never changes…
P.S. Obviously the classname on the body will depend on the cookie…
Just a thought
You could only use example.com/?resp and then your if condidtion look like this: `if (array_key_exists($_GET[‘resp’]))’`.
My idea, when reading this text, was to do it with some little JS: http://codepen.io/WouterJ/pen/HBukj
Typically, I like responsive design up to a certain width, and fixed after that, because I’m not a huge fan of text areas that are too wide for their height, with long paragraphs often only filling two or three lines. It interferes with readability, IMO. If you do fix your width at a certain point, it’s probably better to use two CSS files: one for the base or max width, and a second for anything responsive. That way, if the URL or stored cookie says not to be responsive, you don’t even have to load the second CSS file, potentially saving quite a bit of bandwidth.
It’s an extra HTTP request for those who DO want the responsive design, but especially if you’ve got a fairly complex site, the savings in total data transfer for those who don’t can really add up.
There are some good reasons to do that :
– as others said, user confused because of the changes between desktop and mobile view
– responsive designs that do not support old phones (with my device I can’t see icon font, so I see A, M as a navigation… and the deskop version has full words next to icons )
– the way we deal with images (max-width: 100%) can be a problem. If you zoom in to see details (think an infographic) … you can’t. Of course you think “long touch and see in another window”, yes, that’s what I do, but I’ve seen a tweet recently of someone saying “RWD s*cks… I can’t zoom images”.
Do we have to provide a link with target: _blank on all images and an icon or text to say it’s possible ? Maybe …
– Pages with code examples. I opened *this* page with my (old) phone first… I can’t see the code, lines are broken ( missing word-wrap: break-word for small screens ?) . It’s often the case ( maybe device dependent ? )
With more and more smartphones and RWD sites, I think the “confusing” problem is decreasing.
Non support of font-face will not be a long-term problem
We may think of images and show the user he can see them full-screen…
Code argument is not a problem IMO, when we need to see it, we come again with a bigger screen ; )
We had an extensive discussion about “Should users be forced into a responsive design (without the ability to opt out)?” over on ux.stackexchange. Consensus was a “no, give opt-out”, but without in-the-wild examples of how to do it. This is a nice solution.
http://ux.stackexchange.com/questions/20824/should-users-be-forced-into-a-responsive-design-without-the-ability-to-opt-out
The previous design of your site was much better.
I hope you change it back.
You should write a blog post about it and do a serious professional critique of why the old site was better, that would be helpful for both of us.
I’m going to bury this thread because it has nothing to do with this article.
We do this now in a web app I’m working on (mobile-first design). The page has two stylesheets:
Stylesheet1 contains all mobile and universal styles.
Stylesheet2 contains all desktop-specific styles and is qualified by a media query in the <link> tag. The <link> tag also has an id.
If the user wants to force the full site design when mobile would apply or visa versa, we have a button that can click to “Switch to mobile|desktop”. Clicking that button uses javascript to change the media query on Stylesheet 2.
If forcing desktop, the media query is changed to “all.” If forcing mobile, the media query is changed to “none.”
Then the preference is saved in local storage and every subsequent page load will apply it if the preference is set.
The result is amazing. Switching between layouts is immediate. No page reload, and no waiting for another stylesheet to download. Works perfectly for us.
Of course it requires javascript, but our app already requires it anyway.
Great idea, hopefully you can make sa demo for this. :) Thanks!
The “see full site” link on mobile sites is a relic of the days when companies provided “mobile lite” experiences. If a user wanted to do anything complicated, they’d have to leave the mobile site and visit the desktop site. It was an escape for “mobile lite” and it worked.
I think as designers now aim for content (and functionality) parity in responsive web design, this feature (although in some cases helpful) is no longer a priority.
Hi Pon,
Your point is very valid however it cannot be applied to all use cases. For example our website sells children’s formal wear, therefore the majority of our market are 30 – 40 year old mothers. They may have the latest mobile device but may not be browsing mobile websites regularly or using apps such as Facebook where they will become familiar with mobile specific navigation patterns. Some people in that use case simply prefer to navigate using menus that they are used to and should therefore be given the option. It does not mean that the design is lacking in any way it simply means that as a company we are not ignoring the preferences of our less technically minded customers.
Hi Glynn,
I agree that the specific context of your website and audience needs should drive design decisions.
I would avoid using a querystring as when the user shares the link, the next user will have responsive switched off.
This is really the same complaint I have about mobile sites. You go to the full site, get annoyingly redirected to the mobile site – and when you share the link to the page, everyone gets the mobile site, even when they are on a desktop, because your link points to mobile.blah…
Other than that, I think this is indeed an interesting question. Maybe this is one for the user agent to implement though!
Good question.
My personal opinion is that it smells like defeat to offer a layout not optimised for the screen being used…especially if you’ve spent time making it optimised in the first place!
Sometimes I find the opposite is true, the mobile site is easier to navigate and operate than the super wide screen version. You’re only interested in a small area of the screen but it’s now full of adverts or side articles etc.
Would you have an option to “View simple layout”?
I would definitely like the option for certain sites. Either that or they still allow me to access everything with the responsive design if I need to. Some are way too restrictive!
Definitely agree with those 2 reasons, especially the second. I also think most users won’t know what opting out of a “responsive” version will mean. It’s a nit picky naming thing, but my parents would probably assume that means they’d be requesting a sluggish / slow to load page.
I actually had a very similar idea a couple weeks ago. I think before showing a MOBILE site we should have a ‘staging area’ where you offer up a fast loading page with two buttons and a question. “What version of the site do you want?” Mobile or full site.
I hear CONSTANTLY people screaming at their phones about some lackluster mobile site or getting into endless redirect loops because people are just passing a variable into a site and not doing anything with it to keep it ‘set’ (sessions, cookies, etc) So as soon as the user makes a click (or tap) the variable is gone and BOOM back to the mobile site they go.
Let’s do things better folks!
I don’t know that that’s necessarily the best solution. Seems reminiscent of splash pages.
Also, how do you convey what the difference in content is between the 2 types of site? What I may be looking for when I visit the site could be available in the “mobile version”, or not.
” Some folk are stubborn and don’t want anything to do with your fancy responsive design.”
I ran into this on a large sports-related news site that I run after introducing an Adaptive Design site (not strictly responsive as it uses RESS techniques) a few months back.
Some users complained that they didn’t like being forced to view the “small screens” layout and wanted the option to opt out and pinch/zoom/scroll the “desktop” version, so I implemented a cookie solution to store their preference. Seems to work well.
I would be very, very interested to hear metrics from people who have used versions of these techniques.
I have a feeling that “responsive design” is going to soon replace “table-based layout” in all your favorite “remember-when” web design one-liners. And we will all blush when people track down our old designs where everything smooshed into a skinny, giant’s beanstalk of endless swipe scrolling.
We keep hearing about the exciting evolution of “responsive design.” But to me it’s got nothing on the exciting evolution of mobile browsers. (Which, incidentally, are already really, really good at rendering old desktop era sites. And will soon, presumably, give us native capabilities to manage asset loading relative to bandwidth.)
Can anyone talk about their opt-out metrics?
I made a first stab at doing some responsive stuff for the Friends of the Earth EWNI site, http://www.foe.co.uk. It’s no where near as slick as what Chris’ done here, but I did decide to pop in the “Switch to Full Site” link at the bottom. The main reason I decided to put that in was because the mobile designs I was working from hid a bunch of stuff and I didn’t want to frustrate the user if they were looking for more. I’m not sure if the implementation was great, but it worked:
– I have a regular non-responsive stylesheet and a few responsive CSS files.
– Clicking on the “Switch to …” link at the bottom sets & unsets a cookie
– Then in JS I test if you are IE <9, have JS switched off or have the cookie set, if so then just use the non-responsive CSS. If not, then set the responsive CSS files.
Love to go back and improve this (like properly optimise it – it badly needs it!) but we struggle to find the time…
Anyway, was really surprised to see this post as I thought I was the only one who would think of trying to put a Switch to full site link on a responsive (ish) site!
Afraid I don't have any stats about how many people who click this, but I think I'll try and add some Event tracking on it – agree with other posters, would be great to know.
Sorry, just wanted to correct myself – I don’t use JS to detect IE <9 or whether JS is switched off – that would be insane! I only test for the cookie using JS, the other two are done using conditional IE tags and tags… Time for bed now!
I’d love to see an analysis of this topic similar to your responsive tables roundup; a look at the various methods for providing links to moble or full version of site.
For example, often, on my ipad, I get an ipad version of the site, but I don’t need or want it. I want to see the same site I see on my laptop. With an ipad, I don’t see the need for a special version since it’s very easy to view pages. Of course, there are exceptions, but in general, on a tablet, I’d prefer to see full site or at least have the option.
Great article and comments. It comes at the perfect time when I am struggling with the decision to move into responsive design with the current site I am building. I have be wishing for a button just like you described.
The Safari read button on the address bar in Safari on my iPhone does it perfectly for my website (which is not responsive). It pulls exactly the content from the front page that I would have picked, displayed in an easy to read font size in a reader pane super imposed over my site. Perhaps web browsers will be playing more of a part in optimizing websites for mobile in the future.
That could be a big challenge. However I don’t see the point : if your users want to switch off responsive version then why doing a responsive version ?
I mean if the question occurs your UX is probably bad.
To me even if the idea is interesting it would add unecessary complexity to web project.
Sometimes I just wanna see what the “big” site looks like. Responsive design could be awesome, but what’s the harm in giving the option, especially if it’s easy to do.
Well, if you’re using WordPress, you could simply use the Theme Switcher plugin, and have themes that are identical except that one is responsive and the other isn’t.
I have always been a skeptic about responsive design. I think it IS a great solution and it’s definitely here to stay. I have always been somewhat reserved about how our industry as a whole has just jumped on it and decided “this is the solution”.
Part of my hesitation has been this: Responsive Design “assumes” the user is okay with massive amounts of scrolling up and down. It’s really a bad assumption. Many people like to double tap to zoom into sections, or to zoom with gestures, etc.
Giving the user an option, is definitely something to think about. Good post.
I’d love to see the metrics of people clicking a “See site in full” button, personally I think it’s a bad idea. If you build a responsive site right, then surely it does away with the need to fall back to a desktop site.
I personally 50/50 on this, its a great question. I can’t really see any benefit of viewing a full site on a small screen however maybe that’s the users choice? It’ll be interesting to see how this pans out :)
Keep in mind that mobile browsers are built to make browsing ‘full sites’ as optimal as possible.
When we design (and develop) responsively we make the assumption that our tailored approach is ideal for each size range, but this may not always be so for every user. As you allude, it’s about that choice for the user.
###What about the following 3-steps procedure:
> Close all tablet and mobile Media Queries in a body:not(.normal-view) {…}
> On switchbutton click:
Remove viewport meta tag Add {.normal-view} class in body
> Remember user preference
I think it should work.
Covered this myself in May: http://russellbishop.co.uk/writes/code/responsive-web-design-opt-out/
But better to put a Canonical tag at this solution, else you maybe are in trouble with Duplicated Content….
Love the idea that let the user choose the way he wants to view a website. But i’m just thinking : does that really make sense in a Mobile First RWD website ?
Nice tip, just a comment
it would be better if you use
<?php
if(isset($_GET['resp'])){
// code
}
?>
because not using isset, php assumes that the variable is set and only verifies if is true, and will trigger undefined index error.
Uhhh, honestly what are the use cases for this? Users familiar with desktop version? …
I list one in the article.
I run into this with one client, he absolutely hates the idea of a site not looking the same, I think he’s been to too many bad responsive sites that totally botch the experience… but at the end of the day, he’s paying the bills and his opinion is “I just want to know without a doubt that everything is there and I’m not missing anything”.
Personally I think offering an opt-out link is great idea in these cases. Granted most browsers have a request desktop version… but in my opinion, the user that wants “the full desktop version” is probably also the type of user that doesn’t dig through app menus in the first place… I don’t know, that’s a guess.
It’s so easy to implement though.
Great. I was just thinking to start learning responsive web design and media queries, and get to know few really important things. Thanks for the article.
Regards,
TheIToons.
I think this is a great idea not all mobile sites are great and having an option in my view would be a beneficial thing.
I have mixed feelings about this. Whilst I agree that good RWD should mean that UX is optimised for the key device sizes I feel that there is a case where a desktop version should be made available.
Aside from the valid reasons mentioned in the comments – notably, image zooming and the user feeling that they may not be receiving the ‘full’ experience – the user may specifically have requested the ‘desktop site’ in their browser options. Unless I’m viewing a ‘m.’ prefixed mobile version of a website this setting does nothing on responsive sites. Or rather, it does something (changes the user agent) but has no effect.
As much as I hate myself for suggesting it, could this be a valid reason for user-agent sniffing? If the user-agent excludes ‘mobile’ – yet the viewport size suggests otherwise – can we assume that the user is requesting the desktop version and act accordingly?