State of mobile web development, part 3/3: the mobile industry’s failings

Recently Mike Rowehl, a mobile developer with relatively little knowledge of the web world, confessed to being baffled by the attitude of web developers interested in mobile.

This is the last part of my reply. In parts one and two we talked about what web developers are doing wrong; now we’re going to talk about the errors of the mobile world.

Web developers, web developers, web developers

Mike says:

It was my impression that the next generation of mobile web technologies was supposed to cater to the existing set of web developers and make mobile an attractive option for them. I’m not seeing that happen however.

Everybody wants web technologies; nobody wants web developers.

Company after company declares its eternal and undying allegiance to the web. W3C Widgets, pioneered by Opera and Vodafone, are now more-or-less supported by Samsung, Nokia, and RIM. Palm staked its entire existence as a company on webOS.

Problem is, companies that choose for the web don’t bother to follow up with outreach to web developers. I was fascinated by webOS when it was announced in early 2009, but I was unable to establish a connection to Palm and in the end decided not to bother with it. Similar stories abound.

The first company that succeeds in really communicating with web developers will get its product accepted by an already-existing, large and tightly-knit development ecosystem that hasn’t taken sides yet in the mobile platform wars. As a result, its web-based platform will be filled to overflowing with cool applications.

But mobile companies just don’t seem to be able to do it. (Based on personal observations I’d say Vodafone, Palm, and RIM are willing; but they’re still in the process of getting their act together.)

Absent any change the prize will eventually go to Google or Microsoft (or possibly Opera) because these companies have already established communications with (desktop) web developers. (Apple could do it, too, but it’s not interested since it already has a platform filled to overflowing with cool applications.)

In other words, if the mobile companies don’t adapt to web developers they’ll be usurped by the old “fixed web” companies — at least, as far as web technologies are concerned.

Fiercely independent

I think I have a vague inkling of what the fundamental problem is. The web development ecosystem of blogs and conferences, books and barcamps, was created by web developers themselves by the sweat of their brows. Especially during the early formative years we got little support from large companies.

That changed, when (in no particular order) Adobe, Yahoo!, Microsoft, Google, Opera and some other companies were accepted by the web developers and were listened to seriously.

Why exactly these companies? Because they took the time and trouble to listen to web developers, meet them on their own ground, and make serious efforts toward standards compliance.

Still, web developers have learned to be fiercely independent and to distrust large companies, and especially marketing nonsense. They’re quite willing to listen to serious arguments, but those arguments have to be made in their style, at their conferences and blogs, and have to address issues that web developers deem important.

However, mobile companies are just telling their marketing people to establish contact, and web developers are allergic to marketeers. They want to be in touch with engineers and technicians. As a result there’s no meaningful communication.

Contests

The highest revealed truth about communicating with web developers is a kind of contest, where there’s an inordinate amount of money to be won with writing a widget, an HTML5 game, or whatever technology the organising company wants to push.

This doesn’t work. Sure, some web developers are swayed and participate in order to get some money. But, even if they win, will they ever make a mobile web product again, when there’s no specific incentive to do so?

As far as long-term results go the mobile companies could just as well have flushed their money down the toilet. If they’d spent a fraction of it on actually communicating with web developers on web developers’ terms, they would have some results to show now.

SDKs

Another point that just has to change is SDKs. Right now the revealed truth is that anyone who pushes anything into the mobile web space must release an SDK, too.

But web developers don’t use SDKs.

They’re just not necessary. If you want to make a website, you need a text editor, a graphics program, a web server, and some browsers to test in. That’s it, and many of the best web developers pride themselves on needing nothing more.

Besides, there’s far too many SDKs. If I were to take them seriously, I’d have to install the Android, BlackBerry, Samsung, Vodafone, Microsoft, and Nokia ones, plus probably a few more I can’t remember right now. Not only will that make an unholy mess of my computer, it’s also far too much cruft if I just want to make a website or mobile web app.

The only thing that these SDKs hold that’s actually interesting to web developers is the various signing procedures for widgets; especially for the BlackBerry and Samsung bada platforms. I wonder if web developers are going to download them just for this one feature.

Sure, if you have a paying client you’ll do it, but I’m thinking of web developers that don’t have particular mobile clients but want to try their hand at these exciting new technologies. Will they download Eclipse plus a series of plugins for three, four, six, eight platforms? I don’t think so.

It would be very useful if signing procedures could be done online. Upload your widget and request a sign-off, and a few days later you’d get it back signed and ready to run. Unfortunately all mobile companies are still in walled-garden mode, so this won’t happen any time soon.

Concluding: mobile companies are fundamentally unable to communicate with web developers.

Browser detects

Mike says:

The technique that I see most folks using is segmenting their traffic and swapping things out on the web server. They design for desktop, high capability mobile, and low capability mobile. They detect what device they’re serving to normally based on the user-agent, and then serve up the correct version directly.

Twelve years ago this was the highest reveled truth about making websites. Nearly everybody did it.

And everybody was wrong. Not “there’s something to say for it but sometimes you don’t need it” wrong, but just plain “you have no clue what you’re doing” wrong.

Do you know why nearly all browsers start their UA string with Mozilla/ ? It’s because of browser detects. Not current browser detects, but those of the early nineties. Back then clueless people used the string Mozilla/ to determine whether a browser was modern (i.e. Netscape) or not.

When IE hit the market it could do most of what Netscape could. However, in order to end up on the right side of the browser detects, Microsoft, too, had to start its identification string with Mozilla/ . All browsers that were released later followed suit.

That’s the kind of nonsense browser detection will lead to.

Just say no

I was one of the first web developers to speak out against this practice, and I will continue to do so now that I’ve moved to mobile. I aim to prove that it’s simply not necessary, besides being wrong on a fundamental level.

Why is browser detection so wrong?

It’s incomplete. There’s just no way we’re going to be able to incorporate all devices in this detect. And even if we miraculously did, the next week a new device would hit the market and we’d be incomplete again. It’s unreliable. You’re always going to miss something or make a mistake in your detection. It’s an arms race. If device detection really catches on, browsers will start to spoof their user agent strings to end up on the right side of the detects. Web developers will retaliate by even more finely-grained (and even less complete and reliable) detects, which will cause the browser vendors to improve their spoofing etc. This has happened on desktop (just ask Opera about it), and we should keep the mobile space free of this nonsense. It’s cheating. If you make any mistake at all (and that’s inevitable, really), you’re either denying advanced functionality to a browser tht can handle it, or sending advanced functionality to browsers that can’t handle it. In either case you cheat your end users. It’s inflexible. Sites that were created for any device will be much more flexible in all kinds of situations because the web developer planned for the unknown. Conversely, if you rigidly sort devices into groups and then code for those groups, this rigidity is going to make your site unable to react to the unforeseen.

As far as I’m concernd people who use it aren’t aware of current thinking in web development (and by “current” I mean anything that happened in the last twelve years).

What I’ve noticed far too often is that people who don’t know too much about the intricacies of web development choose this solution, mostly because it seems an easy way out of a tricky situation.

It was only a few months ago that I talked to someone from the mobile world who advocated device detection “because all Java programmers do it.” That’s the perfect summary of all that’s wrong with this technique.

That said, I must admit that even within the web development community some are arguing for a form of detection. It would not be based on the browser string, but rather on a list of capabilities created by some nifty JavaScript checks, and it would not serve completely different websites, but only those parts of the script that are necessary for the device, leaving out useless code branches meant for other devices.

To me, the crucial question is whether the server-side device detection takes place by browser string or otherwise. If by browser string, it’s just plain wrong. Period.

Conclusion

In this series we’ve seen that mobile web developers are making plenty of mistakes, but that that’s mostly due to an iPhone-centeredness that’s partially (but not entirely) caused by demand, coupled with a crippling lack of tools that are available on desktop but still have to be ported to mobile.

Simultaneously, communication by the big mobile companies that don’t play a role in the desktop web, is shockingly bad.

As far as I’m concerned that explains why there’s such a discrepancy between what mobile web developers should do, what they actually do, and what mobile companies have to offer.

Incidentally, if you’re interested in these matters, why not join the Mobile Web?

Comments are closed.