Mobile Web Development & Device Detection
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.
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.
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.
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.
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.
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.
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.