
Mobile web developers: Your users hate it when you do this - mbrubeck
http://limpet.net/mbrubeck/2010/11/19/mobile-browser-detection.html
======
carussell
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.

~~~
chc
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!)

------
JoelSutherland
Careful with the recommendations.

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.

~~~
sp332
> 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.

~~~
mbrubeck
And regardless, if you want to send WebKit-specific markup to some browsers,
do it by looking for "WebKit", not for "Android".

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

------
jeffclark
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.

------
russell_h
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.

------
wccrawford
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.)

------
jim_h
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.

~~~
carussell
If I'm on any device, I'd like to avoid having to run JS.

------
yock
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.

~~~
rewind
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.

~~~
yock
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.

------
Batsu
Maybe it's time the browser developers start telling sites what to do and try
to standardize use of a custom HTTP request header like this:

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

~~~
pornel
BTW:

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

[http://tools.ietf.org/html/draft-saintandre-xdash-
considered...](http://tools.ietf.org/html/draft-saintandre-xdash-considered-
harmful-01)

------
ronancremin
Some care is warranted here:

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.

~~~
mbrubeck
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:

[http://yiibu.com/articles/rethinking-the-mobile-
web/page-3.h...](http://yiibu.com/articles/rethinking-the-mobile-
web/page-3.html)

...in particular, the part starting with "the absence of support for @media
queries is in fact the first @media query" (slide 85).

------
ladon86
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.

------
netmau5
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.

