background image

Mobile Web Development & Device Detection

daniel.hunt's picture
Posted by daniel.hunt - 23 Sep 2010
Twitter share icon Facebook share icon Google Plus share icon

Peter-Paul Koch, also known as @ppk, has posted a three part blog-post on the State of mobile web development [ one | two | three ], in response to Mike Rowehl's recent (correct & justified) rant about web developers' attitude when it comes to mobile.

(Mike's post was originally in response to the truly fantastic slides about Rethinking the Mobile Web, by Bryan Rieger of Yiibu)

So, with that massive link-fest out of the way, here's my tuppence worth...

Thinking like a desktop web developer is no longer enough.

I should start, first of all, by saying that on the whole, both Mike and PPK are completely right.
Web developers are simply not taking "mobile" seriously, and quite a bit has to change before that will take place.

We, as developers and technology enthusiasts, are working in a very fast moving world, and need to evolve quickly (and regularly) to make sure we stay at the top of our game - mobile is just another of those things that we need to adapt to.

  • Companies are becoming increasingly aware of how important a mobile presence is, and it's clear that they are actively engaging with devs to make sure they get one.
  • Users are learning that a mobile presence actually matters
  • "Smartphones" (regardless of your definition of them) are pushing these activities, but often in wildly different directions.

Only 12 months ago, having an iPhone app was the only thing that mattered to some clients, but this has already started to change. Developers are more aware that an Apple-centric view of the world is no different to the Microsoft-IE6-centric view that they work so hard to steer clear of every, single, day. Just because the Safari/WebKit/Opera browsers are so popular now, focussing on any one in particular is development-suicide.

SDK Overload

While this post is actually about web-app development, we can't ignore native-apps completely.
So, on native apps, a point that needs to be re-iterated, is that developers don't want more SDKs.
If I, as a dev, can create, edit and package apps using 2 or 3 simple tools I will be happy.

If I have to download the Android/iPhone/WebOS/BlackBerry/Symbian SDK, just so I can maintain a presence across all platforms, I'll just give up and walk away. It is absolute madness for vendors (read: Apple/Palm&HP/Microsoft/Google/RIM/Nokia) to presume that developers will use their SDK and their SDK alone for developing on their platforms. Even apart from the nightmare it would be to jump between languages and codebases so frequently, our development machines would be an absolute mess (or at least, more of a mess than they already are)

Mobile companies need to engage with, and not dictate to the development community.

Device Detection

Now, with all of that said, we move on to a small bone of contention - device detection.
Device detection is, in my eyes, the second most important thing about mobile web development. There's no point in sending an image that's 1024px wide, to a device that only has a screen that's 3 inches wide - regardless of the DPI of the screen itself, it's counter productive to send such a large (in dimensions and file-size) to a device with (presumably) low bandwidth, low processing power and low rendering capabilities.
Obviously, there are cases where you may want to send large images to a device, but for normal web browsing it's insanity.

Apart from the (admittedly, very simple) example above, there are many, many more potential restrictions that could impact the end-users' experience of a website on their mobile device:

  • Available memory
  • CPU limitations
  • GPU limitations
  • Comparably low, and expensive bandwidth
  • Device capabilities (does the device/browser even support the type of file you're sending it?)

And all of this, all of it, is ignoring the single most important thing about mobile web development...


A mobile user is not sitting at home in front of a desktop PC with unlimited data capabilities (and, presumably, WiFi).
They are downstairs on the couch. They're upstairs in bed. They're on the bus. They're walking down the street. They're sitting, bored, in meetings. They're on the toilet. They're in a pub, showing videos of cats playing the piano to their friends.
They. Are. Everywhere.
A mobile user doesn't care about progressive enhancement. They don't care about seeing an exact replica of desktop sites, but rearranged slightly to make it look good on their phones.
They want information that is important to them. That is tailored to the fact that they are 'mobile' (even if they're not moving anywhere). That is relevant.

PPK's argument is based mainly around Progressive Enhancement (PE), and is, in theory, precisely what we as web developers want to achieve.
But it's not necessarily what the end user wants, needs or expects.
On a desktop machine, PE makes perfect sense. JavaScript capabilities and limitations are well known, standards based and there are plenty of libraries, like jQuery, around to pick up the slack and make things easier for you as a developer. Starting with a simple HTML/CSS layout, and using PE to selectively tack on some AJAX magic here, some onclicks there and some mouseovers somewhere else is fine for desktop browsers, and fine for desktop users. In fact, it's the ideal.

But on mobile, users don't want/need/care about that cruft. They want to be able to find what they're looking for as quickly as possible with as few interruptions as possible.
Take Google, Facebook, Yahoo and the BBC as an example - they all present an interface to mobile users that gives them exactly what they want, without any of the content you would expect to see on a desktop site:

  • Clean & simple menus
  • Mobile-optimised (read: small images, little/no JS, simple CSS by default)
  • User-focussed design

If these heavy-weight names do it, there's good reason for it.

The Solution

Well, considering I work on DeviceAtlas, I'm standing firmly on the "server-side detection" side of the line in the sand. PPK, however, is on the "client-side detection" side.
Obviously, there are arguments both for and against both sides, but my main beef with the idea of client-side detection is that it relies wholly on JavaScript.
That means that every single device that views your webpage will be sent the same chunk of, for argument's sake, 20 lines of JS code.
*That* means that devices that may or may not share any browers characteristics are being served the same JS. What will your BlackBerry/iPhone/Symbian S60/Symbian S40/webOS/Android/random-low-end-OS make of it? Will it skip over the portions it can't understand or interpret? Will it crash the browser? Will it prevent rendering of the page?

There are just so many unknowns when it comes to the low and mid end of the browser market that it just does not pay to offload this kind of relatively sophisticated functionality onto the client. Particularly when the whole point of the functionality is to make it easier to render your site for low end, or less featureful/powerful devices.

Don't get me wrong - JS capability detection makes perfect sense in some cases, but only if you're confident that the devices that it gets served to won't fall over as a result!
If you know for a fact that your customers all have smartphones, or if you genuinely don't care about the low end devices, then by all means implement the more advanced solutions like JS detection and PE.
But if you want to make your site/app accessible to the widest range of users as possible, you really don't have a choice.

Possibly some combination of the 2 approaches will eventually work best, but for now, server-side detection is the only way forward in mobile web development, as I see it.


Posted by daniel.hunt - 23 Sep 2010

daniel.hunt's picture

dotMobi hotshot & diver

Posted by MRLacey 5 years ago

I think you have to use a combination of the 2 approaches.

You use server side detection to determine what to return. Then you use client side detection/progressive enhancement to determine how to display it.

It's important to separate these 2 areas.

As context is king you only want to return what is relevant to the user based on a mobile/desktop/other(tablet?) context. We don't want to download masses of content to the phone which will never get shown or is irrelevant (and take up time/bandwidth).

Then let the browser decide how to best display what's returned.

I'll put my hand up and admit that's not what I always end up doing. But it's how I'd like to work and hope to do so more in the future. It just doesn't work to well when you need to determine doctypes, image formats & sizes, etc. on the server for "older" mobile devices.

Posted by daniel.hunt 5 years ago

So do you think that progressive enhancement should apply to mobile devices such as the iPhone, Android or webOS phones? (which would include things like in-car nav systems and things that we don't even know about yet)

Or just to "large" mobile devices, like tablets?

I don't believe that PE is the right approach for mobile - at least not yet, and possibly not ever.

Daniel Hunt

Posted by stenposible 5 years ago

i made a mobile site but it cant load on opera mini. what might be the problem