State of mobile web development, part 2/3: progressive enhancement

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 part two of my reply, and we’re going to talk about progressive enhancement now. (See also part one)

Like me, Mike was impressed by Bryan Rieger’s excellent presentation in which progressive enhancement plays a crucial role. However, it’s important to realise that Bryan’s presentation is the start of the dicsussion, and not the end. Lots of work remains to be done.

Progressive enhancement

Progressive enhancement has been a standard web dev philosophy for a few years now. Everybody agrees that it’s a good idea to build a website in layers, the bottommost of which is the structural HTML layer that can be interpreted by any browser.

On top of that, additional layers are added. Traditionally they are the CSS presentation layer and the JavaScript behaviour layer, but increasingly these two layers are further subdivided. Basic CSS and JavaScript layers are enhanced by, say, hardware-accelerated CSS animations and transitions and advanced Ajax functionality.

The trick is that every browser uses exactly those layers it can handle and ignores the rest. The website is enhanced as much as the browser allows — for any value of “browser.”

Sounds cool, right? Sounds like exactly the technique for mobile, right?

Problem is: progressive enhancement isn’t actually practiced.

Talking point

Sure, it makes for a great talking point at blogs and conferences, and whenever it’s brought up everybody nods wisely and agrees it’s a really cool idea that’s really important.

Then they go home and make sure their latest project displays perfectly on their client’s browser, IE6. If they feel very daring they’ll use border-radius for rounded corners. IE6 doesn’t support that, so they’ve enhanced their website progressively and satisfied their inner web philosopher. (If the client complains, though, they’ll hurriedly add divs in divs in divs.)

OK, I’m exaggerating here. But not much.

Because IE is so very preponderant on desktop, and is the worst browser, the natural inclination of web developers is to make sure that their entire site works perfectly on IE. Out goes progressive enhancement, in come hacks and bitching about IE. And other browsers’ exciting new features aren’t used, because, hey, IE users can’t experience it.

So the problem is that if web developers say “Let’s use progressive enhancement on mobile” they either mean the desktop version, where there are microscopic differences between the browsers but the entire site is made for the least capable target browser, or they mean the true mobile version that nobody has any experience with yet.

Progressive enhancement is a great idea, but we still have to figure out exactly how it works on mobile. Which features are we going to leave out for which browsers? How are we going to distinguish between the browsers? Those are vital questions that we don’t yet have an answer to.

How will progressive enhancement work?

Fortunately, even in the regular web world steps are being taken to truly kick-start progressive enhancement. I’m especially thinking of Andy Clarke’s Hardboiled Web Design project, where he preaches (and practices) genuine progressive enhancement on the CSS side.

I feel that Andy is completely right, and that the ideas and techniques he promotes will be used on mobile first. The desktop web suffers from a surfeit of IE that will continue to hold web developers captive.

In many respects the iPhone takes a position on the mobile side that’s similar to IE’s on the desktop side. But at least it’s a bloody good browser, and it won’t hold web developers back. On the contrary: it’s so good that web developers don’t want to even pay attention to its less capable competitors.

So any mobile progressive enhancement will leave the iPhone at the top of the browser foodchain as the browser that can handle anything and gets the most enhanced experience. That’s totally fine; it’s how progressive enhancement is supposed to work.

In fact, I wouldn’t be surprised if early attempts at progressive enhancement start with an iPhone site and then decide which features are going to be left out for which browsers. If you’re very strict that’s not how it’s supposed to work: you’re supposed to start with the least capable browser and work your way upward; but frankly I don’t care. As long as anything happens I’m happy.

What progressive enhancement needs

Mike has a few more things to say on this topic:

It seems like the “new new” of progressive enhancement laid out in [Bryan Rieger’s] slides would work best when you’ve got: Folks working on the implementation who are at the deep end of HTML/JS/CSS

A web developer, in other words. Yes, that’s a prerequisite.

An environment where the pages need to be static and server side switching isn’t available.

Or where browser detection is rejected on principle. I’ll get back to this in the final article.

There’s a minimal amount of application logic.. trying to interleave dynamic content updates and event responses with the complexity of adaption seems problematic.

In fact, this is exactly the problem that JavaScript libraries are supposed to solve. The tools for dealing with application logic and page updates are there, they just have to be ported to mobile.

That’s why the jQuery Mobile project is so vitally important. It’s the first time a major library gives us a baseline for mobile browser support; a baseline, moreover, that doesn’t stop at iPhone and Android.

I’m less sure where the other libraries stand, but I don’t doubt they, too, are drawing up plans for mobile support. If you have any details, please leave a comment.

More in general the main problem right now is that the web developers’ toolkit needs to be ported to mobile. JavaScript libraries, CSS frameworks, UI design patterns, they all assume that the site is going to run on a desktop computer. In order to groom them for mobile the restricted screen size and small memory must be factored in. This has already started, in fact, but it’s going to take some more time.

Web standards movement

But all that still lies in the future. I’d like to return to the past to give a bit of context. In 1998 the average web developer had no clue what he was doing, either.

Back in those bad old days that only a few veterans such as myself remember, most web developers used shockingly bad techniques. Most concentrated exclusively on one of the two browsers, and advocating new methods and techniques was a slow and painful process.

Still, some disagreed with that painful state of affairs. They created a theory of web development that started with using web standards instead of proprietary code, and then branched out to include accessibility, creative use of CSS, internationalisation, unobtrusive JavaScript, progressive enhancement, and many more techniques or philosophies that made web development into a mature discipline sporting a thriving ecosystem of blogs and mailing lists, conferences and barcamps.

Of course some web developers disagreed. But the standardistas’ victory was inevitable, really. Once the web standards movement started to coalesce and define a coherent philosophy, it became painfully clear that the nay-sayers didn’t really have anything more to say for themselves than “it’s easier because I’ve always done it like this.”

They set up no competing theories, or even much of an ecosystem, and remained solitary hold-outs slaving away on their junk code. No doubt they still exist, but an increasing number of young web developers entering the market have at least some understanding of the importance of the web standards revolution.

Mobile edition

I expect the same to happen in mobile web development. Here, too, there are plenty of web developers who’re making mistakes; probably because they don’t know how to avoid them. Here, too, some are coding for one browser only. Here, too, the web standards movement will eventually win because there is no competing theory.

It’ll take some time, though — I’d say about three to five years. That’s a lot less than last time around, when it took more like ten years. But a lot has changed since 1998, and mobile web developers have the advantage of a full toolkit that didn’t exist twelve years ago. They don’t have to invent everything from the ground up, as we did the last time around.

Today, those who object against the iPhone-centeredness of mobile web development can call upon a vast array of JavaScript libraries, CSS techniques, browser performance and compatibility research, and their philosophical underpinnings that will make their job of convincing the others much easier.

However, these tools and techniques will have to be ported to mobile first. The library makers are turning their attention to mobile and are finding that their scripts are too large, and that they need new workarounds for exciting new bugs in previously unknown browsers.

Performance and compatibility researchers, too, will have to do a lot of work in a new environment. That’s starting, though. I’m doing mobile compatibility research. Steve Souders has started his mobile performance research. No doubt others will also have some research to share eventually.

To be continued

So yes, mobile web developers are definitely doing things wrong right now. However, in the not-too-distant future they will have the tools to do their job properly.

Besides, the mobile world isn’t free from failings, either. The last installment will talk about that.

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

Comments are closed.