When I first got an iPhone in 2008, mobile websites weren't all that common--and this was perfectly fine because the browser on an iPhone is very capable of working with "regular" websites (save those using Flash, of course). But in the time since, mobile websites have become all the rage. This is a very good thing as mobile-optimized websites are certainly more convenient on mobile devices than are sites that are designed for desktop browsers. But the vast majority of mobile-optimized websites only present a fraction of the content of the full website. So what's a visitor to do if he/she wants to get content that's on the full website but isn't on the mobile-optimized site (or, due simply to personal preference, just wants to use the full website on his/her mobile device)? The obvious answer is "visit the full website" but that's where things get tricky: it has been my experience that more frequently than not, mobile-optimized sites "trap" you and disallow you from getting to the full site.

Trapped on a mobile site--how does this happen? Well, let's talk about how you get there in the first place: you don't go to something like mobile.mysite.com, do you? No, you just go to www.mysite.com just like you would on your computer; either that directly presents mobile content to you or it redirects you somewhere like mobile.mysite.com. How does the redirection happen? The site is developed such that the User-Agent value in the request header is inspected and when it is determined that the value provided corresponds to a mobile browser, the site serves up the mobile content or redirects you to the mobile site. You're probably then starting to see the "how" of getting trapped on a mobile site: because the site always does this header inspection, you always go the mobile site, no matter how hard you try to get to the full site.

Trapped on a mobile site--why does this happen? This is a bit more of a complex question. The simple answer is the "how" answer. But why are sites developed this way to begin with? The intent is good: referencing back to the first paragraph, mobile-optimized websites are certainly more convenient on mobile devices and so site developers and owners want to give you the most convenient content for your device. But what so many of these site developers and owners are missing is the other things I said in the first paragraph: there's (generally) content on their full site users might want to access plus some users might just simply prefer to use the full site, even on a mobile device. Look, it's your site and you can do what you want. But if what you want is to serve your site's visitors in the way they like best, don't trap them in your mobile site. It appears that many mobile-optimized sites don't even consider this: they don't give you a link to get to the full site and, due to the aforementioned User-Agent request header analysis, they trap you in the mobile site no matter how hard you try to get to the full site. But there's another class of mobile-optimized sites that trap you and these are in a sense far more discouraging: the sites that do give you a link to the full site--but don't bother to test that it actually works. This is discouraging because it starts with a greater understanding as compared to the other class of sites that trap you--specifically, the understanding that site visitors might want to get to content on the full site--it's just not followed through effectively and as a result, it's vastly more frustrating because they leave you hitting their "visit full site" button in futility, looking like a fool. And this is by no means rare--I see this all the time. Folks, you have to test this stuff! Some of you probably think you do: but using an emulator/simulator isn't sufficient (clearly!). I understand: it's hard to test mobile sites properly because you have to actually use a mobile device and that's a pain. But whipping out a mobile device and pressing the "visit full site" button on your site, isn't all that difficult, is it?

Testing is always mandatory, of course, but testing something broken is only going to prove to you it's broken--and if your site always inspects the User-Agent request header and serves the mobile content or redirects to the mobile site, your site is broken (in regards to allowing users to get to your full site). So if you're inspecting the User-Agent request header and serving the mobile content or redirecting to the mobile site in all circumstances, you don't need to test: first you need to make some code changes (and then you need to test those). If you don't have a "visit full site" link on your mobile site, this is complicated--how then do you know if the user wants to be on the mobile site or the full site? Serving the mobile site to mobile browsers by default and providing a "visit full site" link is the best approach. And if you're doing that then the code changes you need to make are to implement a system whereby if the user actually clicks that link, it supersedes the action taken to supply the mobile content based on the User-Agent request header. There are lots of approaches you can take for this but make sure whatever you do, it's permanent, at least for the duration of the user's session. That means you can't simply add something like a URL parameter of "fullsite=true" and expect that to be good enough because then when the user actually clicks on a link within the full site, he/she will be right back to mobile site. Using a URL parameter like "fullsite=true" is a good idea but you need to implement a system to allow the user to stay on the full site until he/she indicates he/she wants to get back to the mobile site (and, by the way, just as it is the best approach to give users a "visit full site" link on the mobile site, you need to give mobile users on the full site a "visit mobile site" link so they don't end up trapped in your full site). You can do this however you see fit--dynamically add something like "fullsite=true" to all the full site URLs, use a cookie variable that you inspect on every request, whatever you want--but be sure you do something or you're only going to create an even more frustrating experience than if you prevent the user from visiting the full site to begin with (and yes, I've seen this issue too).

Bear in mind that you're not in the clear here just because you're only providing the content to software that someone else developed: just today I was looking at a Wordpress site and while it provided a "visit full site" link, even when I clicked on it, I still ended up redirected back to the mobile site. In fact, experiencing this issue in such a widely used system as Wordpress was the catalyst for me to write this post. I guess if you've made these same mistakes as a developer you can console yourself with the fact that even such well-known software has this issue (or at least did as of whatever version it was that was used by the site I was on).

I know I sound crotchety here but a) I guess I am, sorry--I'm just truly flabbergasted as to how often this issue occurs b) seriously, I run into this issue all. the. time. c) did I mention that I see this frequently? and d) I really am trying to help (it took a long time to write this--I didn't do it complain, I did it to shed light on the issue so readers will get this right on their sites).

2012-01-23 UPDATE: I was hoping this post would generate more views, comments, and general traction that it apparently has. I guess it's that I don't have a good mechanism for socializing it properly. But please help me out: if you read this post and agree with it, send the URL to offending sites (via the Contact Us page or whatever)!