Responsive web design needs to be done really cautiously. Jon Hicks site, while beautiful, is not the best example. It sends large images, no matter what resolution the site is being viewed at. The page he links to is 4.8MB for example! Nobody wants to download that on a phone.
Also, for all practical purposes, everybody on Android does use Webkit. The real takeaway to his point there is that if you're doing UA sniffing, you need to keep your site up to date.
> for all practical purposes, everybody on Android does use Webkit.
That might change when Firefox Mobile comes out. I've been using the beta http://www.mozilla.com/m/beta and it's really nice. Also, Opera 10.1 beta for Android is out, and although I haven't tried it, I'm sure it will be popular as well.
Good point. I toned down the recommendations a bit, and added a link to an article by PPK explaining how to avoid delivering all your high-res images to low-res devices. (A lot has been written about this lately, and I didn't want want to repeat too much of what's already been said.)
> Jon Hicks site, while beautiful, is not the best example.
It would be much improved if he dropped the trendy downloadable fonts. They look like some low-res, pre-antialiasing, random-pixel-esque monsters from the Windows 3 days in every browser here: a very different monster in each case, but all just as nasty. I find it rather telling that for all the hype about the legal font embedding services a few months ago, just about the only people who are actually using them seem to be web designers on their own sites, and most of those sites are obviously worse-looking now than before. Meanwhile, getting back to the topic at hand, I get 1GB of download capacity in my mobile phone plan and then things get expensive, so I do not appreciate sites that trigger large additional downloads without actually making the site any better!
While I largely agree, I think there is a contradiction between
(1) giving mobile users the option to see it as a 'full' (i.e. desktop) version
and
(2) Fitting the design to the screen size.
In the quoted example (http://hicksdesign.co.uk/journal/finally-a-fluid-hicksdesign), while a great implementation of fluid design, on my mobile device I don't have the option of seeing what it looks like on a desktop (it doesn't let me zoom out to a larger screen size)
I take exception with this point:
"When possible, serve the same content to all browsers. You can use stylesheets and scripts to customize your layout for different display sizes, as in this beautiful site by Jon Hicks."
The mobile experience is about more than just the layout of the page.
Our mobile users are in a completely different mindset than the guy browsing for a few minutes over lunch at his desk. I imagine that's the case for many other sites as well.
The entire reason we made a different mobile version of playlookit.com was because we needed a VERY stripped down and lightweight way to display cell phone pics.
There's a huge difference between the processing power of a Blackberry and it's crappy browser than a MacBook Pro running the latest version of Chrome.
In our case, loading 30 thumbnails and a photo that's wider than the average mobile viewport made for a terrible mobile experience.
Every so often I run across a well done mobile site. The vast majority of them are terrible. Just this morning I tried to follow a link from my Twitter client, only to find that salon.com redirected me to a broken page on mobile.salon.com - just a white page, with nothing I could do about it, so I ended up not reading their story or viewing their ads.
Incidentally, while trying to get around it, I discovered that 'mobsalon.com' is available.
I absolutely hate this. Mostly because the mobile versions suck, and my phone can handle the full version with no problems. (I'm looking at you, Facebook!)
The proper solution is to offer the choice (Facebook does this) and then REMEMBER it for my login. (Facebook doesn't do that.)
I hate websites that have everything hidden because js is disabled. Or, they have an overlay covering up everything. These are content sites that do NOT even need the js to display the content properly.
If I'm on a mobile device, I'd like to avoid having to run js.
A few of the responses here and in the blog comments are up in arms about your suggestion to treat mobile and desktop users the same. The comments that intend to contrast the differences between processing power, dimensions, and available network resources of "desktop" versus "mobile" devices are predicated on the notion that users do want you to send gobs of data that consume more resources when they are on desktop machines. In general, however, they don't. Witness the comments in "Your social widgets are losing you visitors right now" (http://news.ycombinator.com/item?id=1771607) and the popularity of Readability. (http://lab.arc90.com/experiments/readability/)
Something I think (self-apologetic and self-described) Web "designers" and "UX experts" in the West don't realize is that bandwidth caps still exist even for home use, and in some places they are the norm.
Given the reactions, it seems when people read the suggestion "serve the same content to all browsers", they see "serve mobile users the same content that you serve on your created-with-the-desktop-in-mind ('full') Web site". Perhaps this should be reworded to explicitly say the inverted form: "serve the same content on your full Web site as you serve on your mobile Web site." Surprise! Mobile users aren't the only ones who like to view content created with ease-of-consumption in mind.
[Cue dissent pointing out that I did use the word "consumption", followed by some bullshit suggestion like "Mobile users are primarily consumers while desktop users usually want to engage with the content." Such a suggestion ignores that a non-trivial part of the mobile-use population does seek to interact similarly while on a mobile device, as well as the non-trivial part of the desktop-use population that is mostly only ever annoyed by the extra cruft that gets sent down because they weren't recognized as being on a mobile device. This is due no small part to the fact that there are no such things as a discrete mobile-use population and a discrete desktop-use population. It's the same population coming to the table with varying modes of access.]
And finally, here's something that I've been trying to hammer on for a while. I have a not-modestly sized screen. I should be able to manage applications and Web pages so that I have multiple things visible on the screen at the same time, such as two pages that I'm cross referencing side-by-side; or a page open with some other application visible at the side; or, say, Songbird—displaying lyrics from the Web or band information from Wikipedia—in a way that doesn't take up most of the screen; or any other application which seeks to similarly integrate content from the Web but doesn't conform to the now-ancient assumption of one big browser window displaying the page contents over most of the screen.
Now with the proliferation of wide screens and increasingly large displays, I should be able to consume things in this way, and it should be an option for you to build these types of applications without annoyances like requiring horizontal scrolling.ⁱ Instead of being able to take advantage of these opportunities, we get questions asking, "Can we require even more screen space for our Web pages now?" (http://news.ycombinator.com/item?id=1736808)
1. Horizontal scrolling essentially defeats the attempt to prevent from toggling between multiple windows, because it's ultimately an attempt to prevent from spending too much time managing the viewport of content, rather than spending it acting on or in response to that content.
This is such a great point. A lot of websites go to two opposite but equally repellent extremes with their desktop and mobile sites. For the desktop site, they will shove five pounds of crap into a two-pound bag. Then for the mobile variant, they will strip away some of the fluff, but also omit a lot of detail that actually does contribute to usability — for example, mobile sites sacrifice any ability to actually find what you're looking for a lot of the time, which is egregious because you need more help with that on the iPhone. (The standard mobile WordPress theme is a big offender on this. I want to throw my phone at the wall every time I come across a site using that theme. Tiny font, excessive padding, no navigation to speak of. Ugh!)
I was just struggling with this yesterday. I was trying to post a photo to a friend's Facebook wall while mobile from my Android device, only to learn that Facebook disables, even when viewing the full site, the ability to attach media to a wall post from a mobile device.
There are many time when browser detection works in my favor, but it's content decisions like these that frustrate me to no end with the mobile web.
You were doing this from a browser and not an app? Some mobile browsers disable the file upload dialog, and there's nothing the site can do to get around it. I know it works like this on iPhone (and it's a huge pain in the ass; you'd think they'd AT LEAST tie in the camera to let you upload photos), but I'm not sure about Android. Are you able to upload files on other sites? Again, I don't have an Android device here, so I'm asking, not telling.
I was specifically using the full site because the Android FB app, on 2.1 anyway, is pretty limited as to what it can do. I'm still eagerly awaiting an update to 2.2 from Samsung for my Captivate that will supposedly happen before the end of this month. I'm not holding my breath.
The absolute worst is when you're linked to a specific page on a site, but you get redirected to the mobile home page so you have no way of viewing the page you want.
Advice item #1 is plain wrong (when possible, serve the same content to all browsers). If you do this, the site will not work on the vast majority of the world's phones unless it is supremely lightweight.
There's a good reason why the best mobile sites out there use UA sniffing (Google, Facebook, Yahoo! etc) — it's the approach that gives the best experience for your visitors.
If all you care about is Android and iPhone user then fair enough.
The Yiibu link at the end of my article shows how you can build sites that work on low-end phones and older browsers, as well as Android and iPhone and modern desktop browsers. They do it by reversing some of the more common development practices. Rather than use CSS and JavaScript to transform a desktop site into a mobile one, you can start with a mobile-friendly site, and then use CSS and JavaScript to progressively enhance it in more advanced browsers.
If you haven't seen it already, their presentation is highly recommended:
I really like ESPN's approach of asking you which version of their website you'd like to use immediately upon navigating to it. I dislike having to scan the headers and footers of a site hoping to find a "Go to Full Site" button, if it even exists.
Responsive web design needs to be done really cautiously. Jon Hicks site, while beautiful, is not the best example. It sends large images, no matter what resolution the site is being viewed at. The page he links to is 4.8MB for example! Nobody wants to download that on a phone.
Also, for all practical purposes, everybody on Android does use Webkit. The real takeaway to his point there is that if you're doing UA sniffing, you need to keep your site up to date.