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 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.
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.
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.
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.
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.
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.
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?
This is the blog of Peter-Paul Koch, web developer, consultant, and trainer.
You can also follow
him on Twitter or Mastodon.
Atom
RSS
If you like this blog, why not donate a little bit of money to help me pay my bills?
Categories:
Comments are closed.
1 Posted by Mike Rowehl on 21 September 2010 | Permalink
Thanks PPK for the great follow-ups. One point about the techniques not being great for highly dynamic sites, that was something I heard echoed by Aaron Conran from Sencha yesterday at Mobile 2.0. Basically he segmented what they had to offer - JQTouch is good for content based sites and applies a progressive enhancement model, Sencha Touch is good for sites with lots of logic and provides programmatic generation instead. One of the reasons given for Sencha Touch not following a progressive enhancement model was the difficulty of binding and updating event handlers when you have dynamic content and the runtime performance that goes along with it. What's your take there? Not a valid concern given the state of the art? Or something where there's room for improvement with the tools?
2 Posted by ppk on 21 September 2010 | Permalink
Events are the crux. We have to make sure that a site works with the touch events, the traditional mouse events, and even the key events. I don't think that's extremely difficult, but it requires some research that I've been planning to do for ages but haven't actually done.
I'm not convinced of the long-term utility of jQuery Touch and Sencha because they work on too few platforms: basically iPhone and Android, and one of the two throws in webOS, I believe. But no others.
As to Sencha not being able to bind dynamic event handlers, I'd say (without having actually seen the code) that that's a bug in Sencha. There are some notable problems on the iPhone, but otherwise it shouldn't be too much of a problem to use event delegation (i.e. setting the click or whatever event on the document and figuring out the actual event target when a click happens.) Event delegation always works, regardless of the current structure of the page.
3 Posted by Tom Pryor on 21 September 2010 | Permalink
Just wanted to mention that the dojo library has a mobile initiative underway, too.
You can view some of their recent examples here...
http://archive.dojotoolkit.org/dojo-2010-09-20/dojotoolkit/dojox/mobile/tests/
4 Posted by Mark on 21 September 2010 | Permalink
I don't see the different desktop and mobile browsers as being much different from desktop programs running on different Operating Systems.
Since computers have been around, many companies had a program that was made for a single OS. In many cases it wasn't available on other OS's unless there was great demand. They concentrated on that one OS because it takes considerable resources in people, time, and software to develop for another OS, and to make the program as close as possible to how it was in the original OS.
This is one problem we face - in the real world, we aren't given limitless time, money, and *testing equipment* to create a site that will work on some level on every single browser, desktop and mobile.
My company has 10 people in the Internet department. That breaks down to 3 designers (they draw the pages in Photoshop), 2 writers, 4 back end programmers, and 1 front end programmer (me). Of those 10 people, I am the only one that knows anything about the front end. We have 4 sites to support, and I just don't have enough time to program and test in every browser.
We'd like the sites to work in all browsers but the thought is overwhelming.
5 Posted by ppk on 21 September 2010 | Permalink
Update: Sencha seems to work on more than just iPhone and Android; good for them.
Event delegation works absolutely fine everywhere, except on the iPhone. http://quirksmode.org/m/tests/eventdelegation.html
6 Posted by Roland van Ipenburg on 21 September 2010 | Permalink
Progressive enhancement shouldn't be a technical issue. The issue is that most brands aren't ready for a progressive brand identity. If for example 50% of their audience doesn't experience their brand identity with rounded corners or a certain font, what would be the point of including those rounded corners and that font in the brand identity in the first place? Those things are either important enough to try to make it work in as much browsers as possible, or not important enough to keep them when they scatter the brand identity.
7 Posted by Gona on 21 September 2010 | Permalink
@Roland van Ipenburg:
Word!
8 Posted by Aeron on 21 September 2010 | Permalink
I'm struggling with this at the moment and would love your thoughts. Right now, visitors to our site are 80% iOS, 10% Android and 10% everything else. Conversion between iOS and Android is about the same (everything else negligible) but the $ amount of iOS per order is higher. The reason for this presumably is the experience is much better so they keep shopping. You could argue it's a chicken-egg thing: we haven't created an optimized experience for the baseline mobile device, so with a negative experience of course they aren't going to convert. But you could also argue that graceful degradation is a myth - "it works" is not graceful - and the experience would never be a good one simply because the devices suck. I think m-commerce pre-2007 showed that even with an optimized site, conversion wasn't there because the experience on the device was so bad. (cont'd in part ii)
9 Posted by Aeron on 21 September 2010 | Permalink
part ii: So on one hand you have projects like Sencha and Fuchs' zepto.js targeting the latest and greatest webkit - simply because it offers the best experience (for developer and user) - and on the other hand you have approaches like those offered by Bryan Rieger. The problem with any kind of middle ground, is iOS users are extremely sensitive to anything that is less than a native experience (you see criticisms all the time in the app store for apps wrapped in a clunky webview) and the truth in the execution is there are limitations to what you can do if you want to support a broader range of devices. Now from a brand standpoint we only want our users to have an excellent experience, period - so what options does that leave us? Maybe the upcoming jQuery mobile (and other tools) will be the answer. But right now I think the half-life of mobile devices is a short one and what are today's leading devices will become tomorrows mainstream and should be the target moving forward - however I would love to hear your thoughts.
10 Posted by Tanny O'Haley on 22 September 2010 | Permalink
@mark,
These are the ame reasons companies used for only supporting IE. The company you work for need more than one UI developer.
11 Posted by Mark on 24 September 2010 | Permalink
Tanny, you're right. My company really doesn't give a crap about the Internet, much less mobile browsers.
Aside from that, I guess you have to ask how much ROI are you going to get spending scores of hours making a site work for even the most obscure browsers that have a tiny amount of useage. At a certain point it isn't worth it.