Mobile web developers: Your users hate it when you do this

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.

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.

(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)

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.

Incidentally, while trying to get around it, I discovered that 'mobsalon.com' is available.

The proper solution is to offer the choice (Facebook does this) and then REMEMBER it for my login. (Facebook doesn't do that.)

If I'm on a mobile device, I'd like to avoid having to run js.

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.

  X-Preferred-Format: ('Desktop' | 'Mobile')

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.