Discuss: Test-Driven Progressive Enhancement

by Scott Jehl

11 On Fickle Beasts

@Ryan Cannon: Thanks for commenting. You brought up some good points and I’m glad you mentioned Yahoo’s Graded Support. I think an ideal approach could be a combination of capabilities testing AND following a browser support matrix such as Yahoo’s. Correct me if I’m wrong, but to my understanding, Yahoo’s Graded support acts as more of a list of browsers in which a site has been fully QA’d to support, but anything beyond those may or may not receive a usable website, and they fall into groups C or X. It’s more of a support disclaimer than an attempt to provide a usable experience for all. In other words, without some sort of capabilities testing in place, browsers in groups C or X might actually get a completely unusable website instead of a usable one with less bells and whistles. But even if you are conditionalizing your features with capabilities testing of some sort, you’ll surely still have a set of target browsers to support, and that’s where something like Yahoo could come in. This technique just aims to give users with a C or X grade browser a working experience of some sort.

As for the IE mobile 5 object detection error, that’s good to know, and something I wasn’t aware of. Of course, you can decide which tests to run based on your needs. Perhaps there’s a way to write those particular tests to make sure Mobile IE 5 is included when it should be. We’ll look into this further.

posted at 03:12 am on September 25, 2008 by Scott Jehl

12 Re: iPhone

@Steve: The problem lies in how that “good, standards based code” will function on Grampa’s computer * . You’re in good company saying that sniffing for user agents is generally considered bad form. This approach is different from sniffing in that we’re never asking what browser you’re using, we just care if it works well enough to handle a certain feature.

@Erika: We tested the demos in iPhone and deemed them usable. Try tapping on each slider scale to move the handles. In a real implementation though, you might decide these would be better left as select menus for iPod users. After all, you aren’t really “sliding” them anyway, and they might even be easier to use that way on iPhone. This would just mean conditionalizing the slider enhancements with a stricter test.

*sorry, Grampa :)

posted at 03:33 am on September 25, 2008 by Scott Jehl

13 bolding... woops

…sorry for the bold text. Apparently asterisks don’t render out in this system.

Please place mental asterisks after “Grampa’s computer” and before “sorry, Grampa”… sigh :(

posted at 03:35 am on September 25, 2008 by Scott Jehl

14 Best practice?

I’ve looked into progressively enhancing forms a little bit of late, the only concern I have is how best to provide an opt-out for those who may be reliant upon screen readers etc where AJAX seems to be a hit and miss affair. What is a best practice here? Provide a link that sets a cookie, pages then check if cookie exists and enhance based upon preference?

posted at 03:53 am on September 25, 2008 by Bryan Garnett-Law

15 Merge Techniques?

Progressive enhancement does sound like a good idea to me. Reading through all the comments it seems that there is a mixed response. My thoughts are that anything to ensure the end user/visitor gets a good experience that reflects well on the organisation the site represents is a good thing.

The use of CSS media types is a good idea – we are already doing this for printing (I hope) so why not use it for mobile devices. However, there are limitations with this in that it is an all or nothing approach to the problem. Is there some way of combining the CSS media type solution with the use of this JS? If we had the stylesheets loaded correctly at the start then the technique in this article could be applied over the top – the default, or fall back, stylesheet would then be correct for the media type.

I hope that makes sense – I’ve not been up long and my coffee has run out.

posted at 10:36 am on September 25, 2008 by Nathan Davies

16 Isn't this a step back?

Shouldn’t the Progressive enhancement run something like:
HTML -> CSS -> JavaScript -> (Flash / Ajax / Silverlight / etc)
Doesn’t this method skip to step three to test step two?

I’ve always found that CSS media type solves the mobile devices issue and IE’s non-standard conditional comments fix their own shocking CSS support. The ONLY issue I have is Safari which has the odd bug but is impossible to target without hacks. (As far as I know?)

As long as you test for each object / method you use in you JavaScript before implementing the code, there shouldn’t be any problems there either.

Everything else is bells and whistles and shouldn’t hamper the user experience.

posted at 08:38 pm on September 26, 2008 by Matthew Hawkshaw

17 Untitled

To my understanding, Yahoo’s Graded support acts as more of a list of browsers in which a site has been fully QA’d to support, but anything beyond those may or may not receive a usable website, and they fall into groups C or X. It’s more of a support disclaimer than an attempt to provide a usable experience for all. In other words, without some sort of capabilities testing in place, browsers in groups C or X might actually get a completely unusable website instead of a usable one with less bells and whistles.

This isn’t quite right. YGBS limits browsers to three scenarios:

You’re ok, we’ll give you everything and fix the bugs we find.
You’re terrible. You get no CSS/JS, just a sparse but usable Web site, and we’ll make sure you can use it.

We don’t know you, but there’s no way we can cover all the bases. If you act like the standards and precedences say you should, then everything should be ok.

So there’s much less guesswork than trying to plan for many different types of failure secenarios.

Perhaps there’s a way to write those particular tests to make sure Mobile IE 5 is included when it should be. We’ll look into this further.

I didn’t want to pimp my own blog here, but I did some of that work for you in my article The Mobile Dollar .

posted at 11:18 pm on September 26, 2008 by Ryan Cannon

18 Re: iPhone, ok, yes

@Scott Jehl, Thanks for the navigation hints. :)

First, a disclaimer: iPhone is the first mobile browser I’ve used, and I’ve only had it a week. Though IMO that makes me a perfect tester. ;)

Second, yes! the “sliders” work on iPhone if you click the location you want them to “slide” to. Indeed, they do not actually slide, but on the desktop browser, it all seems relatively intuitive (to me). On the iPhone, it is not intuitive (to me). I guess that certain Javascript events are going to be different on the mouse-less device. In general, I feel more basic, intuitive, or at least, “de facto standard” navigation elements make sense to a mobile device. And should be delivered with a media-type stylesheet…?

Also, this article, and the iPhone, is making me think that the concept of “progressive enhancement” is now something of a misnomer, or at least, only part of the issue.

iPhone Safari (for example) is not a lesser, but a different browser.

While it is !important that a browser understands the DOM (and iPhone Safari offers some really neat functionality around block-level elements) — once that part is out of the way, there are a whole lot of other important things. What are the special needs of the user, and how is the device/software delivering content? And once you know you can do something … should you?

With the renewed focus on Javascript… I think we should also keep our focus on usability as a very important part of the design/development process, especially when dealing with highly interactive elements, like forms.

Just some thoughts, tangentally related…

posted at 05:23 am on September 27, 2008 by Erika Meyer