No, I'm saying that it is reasonable to only put out a "rich" version of your site for tested configurations.
And you haven't advanced any argument for that other than say-so! I've advanced an argument based on evidence—years and years of APIs designed specifically for this purpose, and years and years of a safe environment of "unknown" configurations in which to deploy.
What is the point of having unit tests, regression tests, and such in place if you are going to then allow configurations that are not part of your test suite?
Your target environments pass the tests. I don't see why this is a point of debate. The benefit of progressive enhancement is that it's quite likely the environments you didn't test would also pass.
At that point, the safest thing to do is put out the simplest version of your site that marketing will accept and hope for the best.
No, it's really not. You haven't addressed progressive enhancement at all, why don't you try? The safest thing to do is to test for the features you use, and provide the "simplest version" of those specific features when those features are unavailable. Why should Opera users be arbitrarily restricted from using your app? There isn't any reason. Opera is perfectly capable of running it. You just didn't test it. If a specific API is unavailable, you have a "simpler version" implemented and fall back to that for that API. The web isn't all or nothing, and with a moving target API it never will be.
You can certainly provide a notice that the environment is untested and some features may not be available, but why just block usage? If you're writing good, progressively enhanced code in the first place, there's no benefit to then drawing completely ignorant lines in the sand as to the capabilities of environments you haven't even tested.
So what's the alternative? Recalling that you promoted User Agent sniffing and arbitrarily blocking untested clients, I don't see the fallback notice as fundamentally different from a marketing perspective, except that UA-sniffing will cause more false positives and present your block message to more users needlessly. The alternative, so far as I'm aware, is to develop two apps in tandem: a canvas/JS app and a Flash or Silverlight fallback. Marketing (if it's hopelessly large and powerful) will probably go for that, but it could mean potentially twice the cost or more.
Let me reiterate: There are some features that absolutely require a new and working implementation, and for those features there are fallback capabilities as well. Are you just objecting to the language I used in my pseudocode fallback? Or are you really saying that the approach you promoted—UA-sniffing—would provide a better user experience than the built-in fallback capabilities of canvas and would better appease a marketing department that doesn't understand these new APIs?
Why? Sure, in some cases, depending on complexity and the actual testing requirements, it may be a worthwhile investment, but I don't think it is relevant to the question of progressive enhancement as a development approach, and certainly wouldn't be relevant to the benefits of progressive enhancement on the configurations you don't even support. The question is, for those configurations, do you employ known-good development practices that will support them to the extent of their capabilities with or without testing, or do you arbitrarily block them from the functionality and present them with an ugly notice saying they need to choose a platform that you approve? Automated testing doesn't benefit a platform you don't test in the first place.
The safest thing to do is to test for the features you want, fall back for the features you need, and let the browser do the rest of the work for you. It's been possible to do this since Netscape 4 went out of style, and Google in particular isn't doing anything so demanding with their search site that they'll find the kinds of edge cases that actually expose the broken edges of otherwise solid implementations.
In a perfect world, developers would be able to enforce upgrades to any rendering engine to ensure the best experience. But for years and years there have been APIs designed, albeit poorly overall, well to handle backwards compatibility as well as forward compatibility—and for the few exceptions, IE has conditional comments.
There are some features that absolutely require a new and working implementation, and for those features there are fallback capabilities as well. It takes no UA-sniffing at all to write <canvas>Your browser doesn't support my drawing app</canvas>, nor <video><source src="foo.mp4">Your browser doesn't support AVC</video> (apologies if this isn't the correct fallback syntax, it's one I haven't spent much time with, but I suspect it's correct and it's pretty intuitive if you know how to code fallbacks for the web).
There are much better ways to provide fallbacks to feature-rich web experiences than UA-sniffing. Using proper feature detection in JS and some basic (really!) understanding of how to provide basic styles behind new CSS features, you can provide the best experience for the best user agents without excluding anyone, and without the burden of testing every possible configuration. These are code practices that have been possible since the first "browser wars" ended, and have been advocated heavily for at least a decade.
I've had great success with progressive enhancement, even for pretty involved work. I recently completed an rather large (for me) project with a lot of bells and whistles—including substantial use of APIs that were only introduced in the last couple years, as well as a really nice interface that uses no images and is perfectly usable on browsers with poor graphical capabilities—and the cross-browser phase of the project was so minimal as to be laughable. Our small firm, of course, only commits to supporting certain configurations for our client, but being a good guy I checked a bunch of other configurations to see what the damage was. Apart from IE 6 and 7 (which we no longer support), there was literally no damage, at all. And that includes testing in Opera (which we don't even discuss with clients, most of whom have never even heard of it) as well as versions of Firefox that are so old that they no longer register on stats anymore. And IE 6 and 7 support took a matter of a couple hours, so I went ahead and did it. And there isn't a bit of browser branching in the code besides the use of a few classes output with IE conditional comments.
Do I (or my small firm) know something Google (or Apple, who are at least equally guilty of overly restrictive UA-sniffing) don't? Of course not. Presumably, they maintain an internal list of supported configurations and block everything else as a matter of managing cost. But I seriously doubt that the list is a product of extensive testing which revealed bugs in the otherwise-perfectly-capable configurations that they block. They simply don't check, and operate from a fundamentally poor approach.
The best part is that, if you begin from a progressive enhancement approach—with a little bit of foresight and as much experience as anyone else doing anything so "feature-rich"—none of this is difficult. Cross-browser has only gotten easier since we adopted this approach, and the number of target configurations has only grown.
I'm sorry (I really am) if this comes off as preachy, but I am astonished to see, in 2012, arguments in favor of UA-sniffing. With all that's wrong in the standards, in the history of the standards, and in the massively broken implementations over the years, the solution has been clear for a long time. Just because a behemoth like Google doesn't get it right doesn't mean it's wrong.
Isn't it ALREADY banned in most places? Just like DUI etc.
I'm not sure how widespread the ban is, but there aren't exceptions for drivers who are particularly skilled at driving drunk, and there shouldn't be for texting either.
I think I'm getting that your suggestion is tongue-in-cheek, in which case I feel a little foolish. But I think it reflects a real attitude among some of the people here, and should be challenged nonetheless.
I'm forced to agree again. I used your reasoning. If, in order to prove increased danger from distraction by mobile devices, there must be higher traffic death rates, then a decrease in traffic death rates is indicative of the relative safety of distraction by mobile devices versus no such distraction. That is the logic you advanced.
That said, try to find some way of actually showing that [new activity to hate] is hideously dangerous while at the same time showing that [new activity to hate] during the increase of [new activity to hate], actual deaths decreased.
Or are you just silly enough to say that without people texting while driving, traffic fatalities would have plummeted even faster than they did?
If so, perhaps you have some proof?
Read TFA. The studies show that the risk of accidents increases dramatically while distracted, particularly by texting. If traffic fatalities have plummeted (which I'm just taking for granted based on your say so), then yes, it is despite the increased danger caused by increased distraction with mobile devices. That's not silly, it's math.
Face it, for all the people screaming that texting while driving (which, frankly, striked me as silly, but I think the same of texting period) is terribly dangerous, there is NOT a measurable spike in deaths.
Unless, of course, you count a 9% DECLINE as a "spike in deaths"....
Here is that reasoning again. And if that reasoning is sound, then we're forced to conclude that texting while driving increases safety.
It's as if you think texting while driving is a phenomenon that's sprung up in a frozen state. Obviously, when 16%[TFA] of driving fatalities are caused by distraction, there are other factors causing driving fatalities. Those other factors are subject to change as well, and may even decline to sufficiently offset the increased fatalities from distraction by mobile devices.
It's probably not a good idea to use such flawed logic and insult the person explaining the flaw in your logic. But maybe you were distracted.
In my experience, people living out in the boonies tend to rely less on stores of any kind. That may have changed a lot in the decade or so I've lived in an urban area, I can't really say. Regardless of assumption, I can't see why anyone would object to "liveable, walkable communities, with proper mixed-use development, green spaces, multi-use trails for pedestrians and bicycles, and good connections to public transit", and I don't think an area need be urban to pursue most (if not all) of those.
of all drivers under age 20 involved in fatal [subset] crashes, 16 percent were distracted -- the highest proportion of any age group.
Among the various distractions, ranging from talking with passengers to adjusting the radio, texting while driving was particularly perilous. A 2009 study focusing on drivers of larger vehicles and trucks concluded that texting raised the risk of a crash by 23 times compared with nondistracted driving.
The article doesn't discuss what makes up the other 84%, but it's not a stretch to imagine that a large portion of it is covered already by existing laws and enforcement, as in failure to follow safe driving procedure. But the figures for texting, as well as talking on a mobile, are staggering. If reducing distraction while driving could reduce accidents by anywhere approaching 16%—particularly distraction from activities that are wholly unnecessary and inappropriate like texting/mobile talking—why not do it?
What possible argument is there for texting or speaking on a cell while in motion on a public road? It shouldn't be causing 1 accident, because there's no fucking reason to do it at all.
Why the hell do all this? We don't have any other traffic laws stratified by driver skill, the rules of the road apply to all drivers, (usually) with some evidence that by following those rules driving dangers will be minimal. What makes texting of all things a candidate for exceptions? Why introduce the massive enforcement complexity this would entail? Why do drivers need to be texting at all?
Something that is nearly universally reckless should be banned from public roads just the same as something that can be scientifically proven to be universally reckless.
This is rubbish. Texting while driving is being vilified because it's extremely dangerous and extremely common. That an extremely dangerous driving habit correlates to a "youth activity" (never mind that older adults do this as well) is probably a function of youth being less experienced drivers on average; less experienced drivers are more likely to engage in distracting activity while driving.
Do you really think "the media" (as if texting while driving would otherwise be accepted by the countless other drivers, cyclists, pedestrians who've been endangered by it) would downplay a rash of "crossword puzzling while driving" by 50-somethings?
Are the extremely functional UI's that have evolved for the last 30 years that broken?
Yes! They are! But the theme change in Windows 8 isn't meant to address that, it's meant to address the glaring style differences between the desktop and Metro—Metro is meant to address how broken the desktop UI is. Is it a success? Hard to say, but I'll bet it's a wash, and it's undermined by retaining the desktop.
I hope geeks will come to realize that just because they use and know WIMP doesn't mean that's the correct or even best interface approach, and it doesn't mean it's the best for every use case. We also need to realize that we're not the target audience of efforts like Metro, and whereas that audience will likely greatly benefit from losing the complexities of windows and menu bars, we geeks will thrive by adapting, and adopting power tools, as we always do.
I doubt Windows 8 is for me, and I think there's a lot wrong with the approach, but I think the upset over Metro is extremely misplaced and greatly misses the point. WIMP just doesn't serve most users well, and it's an ugly elitist demand that those users adapt to the complex UIs we happen to be familiar with so that we might not be faced with the choice of a new UI approach.
Then why are we talking about this? Why haven't you taken my wallet and wife and children? But please let me keep my home, that's where I will hang myself with your scientifically proven allow.
Wait mycleanpc I mycleanpc heard mycleanpc mycleanpc mycleanpc is mycleanpc the mycleanpc best mycleanpc software mycleanpc to mycleanpc clean mycleanpc my mycleanpc pc mycleanpc.
I, for one, read the entire comment. As with advertisements, it's mycleanpc helpful mycleanpc to mycleanpc process mycleanpc repetitive mycleanpc messages mycleanpc when mycleanpc deciding mycleanpc what mycleanpc products mycleanpc not mycleanpc to mycleanpc purchase mycleanpc.
How is it class warfare to suggest that someone who benefits from a society should earn it rather than being a parasite? I suppose predation is a "freedom" and if you're blindly a hedonist ideologue that might appeal, but it's not a feature of a healthy society with healthy social contracts, and it's not a freedom without costs to the freedoms of others.
Slashdot Mirror
No, I'm saying that it is reasonable to only put out a "rich" version of your site for tested configurations.
And you haven't advanced any argument for that other than say-so! I've advanced an argument based on evidence—years and years of APIs designed specifically for this purpose, and years and years of a safe environment of "unknown" configurations in which to deploy.
What is the point of having unit tests, regression tests, and such in place if you are going to then allow configurations that are not part of your test suite?
Your target environments pass the tests. I don't see why this is a point of debate. The benefit of progressive enhancement is that it's quite likely the environments you didn't test would also pass.
At that point, the safest thing to do is put out the simplest version of your site that marketing will accept and hope for the best.
No, it's really not. You haven't addressed progressive enhancement at all, why don't you try? The safest thing to do is to test for the features you use, and provide the "simplest version" of those specific features when those features are unavailable. Why should Opera users be arbitrarily restricted from using your app? There isn't any reason. Opera is perfectly capable of running it. You just didn't test it. If a specific API is unavailable, you have a "simpler version" implemented and fall back to that for that API. The web isn't all or nothing, and with a moving target API it never will be.
You can certainly provide a notice that the environment is untested and some features may not be available, but why just block usage? If you're writing good, progressively enhanced code in the first place, there's no benefit to then drawing completely ignorant lines in the sand as to the capabilities of environments you haven't even tested.
So what's the alternative? Recalling that you promoted User Agent sniffing and arbitrarily blocking untested clients, I don't see the fallback notice as fundamentally different from a marketing perspective, except that UA-sniffing will cause more false positives and present your block message to more users needlessly. The alternative, so far as I'm aware, is to develop two apps in tandem: a canvas/JS app and a Flash or Silverlight fallback. Marketing (if it's hopelessly large and powerful) will probably go for that, but it could mean potentially twice the cost or more.
Let me reiterate: There are some features that absolutely require a new and working implementation, and for those features there are fallback capabilities as well. Are you just objecting to the language I used in my pseudocode fallback? Or are you really saying that the approach you promoted—UA-sniffing—would provide a better user experience than the built-in fallback capabilities of canvas and would better appease a marketing department that doesn't understand these new APIs?
Why? Sure, in some cases, depending on complexity and the actual testing requirements, it may be a worthwhile investment, but I don't think it is relevant to the question of progressive enhancement as a development approach, and certainly wouldn't be relevant to the benefits of progressive enhancement on the configurations you don't even support. The question is, for those configurations, do you employ known-good development practices that will support them to the extent of their capabilities with or without testing, or do you arbitrarily block them from the functionality and present them with an ugly notice saying they need to choose a platform that you approve? Automated testing doesn't benefit a platform you don't test in the first place.
The safest thing to do is to test for the features you want, fall back for the features you need, and let the browser do the rest of the work for you. It's been possible to do this since Netscape 4 went out of style, and Google in particular isn't doing anything so demanding with their search site that they'll find the kinds of edge cases that actually expose the broken edges of otherwise solid implementations.
In a perfect world, developers would be able to enforce upgrades to any rendering engine to ensure the best experience. But for years and years there have been APIs designed, albeit poorly overall, well to handle backwards compatibility as well as forward compatibility—and for the few exceptions, IE has conditional comments.
There are some features that absolutely require a new and working implementation, and for those features there are fallback capabilities as well. It takes no UA-sniffing at all to write <canvas>Your browser doesn't support my drawing app</canvas>, nor <video><source src="foo.mp4">Your browser doesn't support AVC</video> (apologies if this isn't the correct fallback syntax, it's one I haven't spent much time with, but I suspect it's correct and it's pretty intuitive if you know how to code fallbacks for the web).
There are much better ways to provide fallbacks to feature-rich web experiences than UA-sniffing. Using proper feature detection in JS and some basic (really!) understanding of how to provide basic styles behind new CSS features, you can provide the best experience for the best user agents without excluding anyone, and without the burden of testing every possible configuration. These are code practices that have been possible since the first "browser wars" ended, and have been advocated heavily for at least a decade.
I've had great success with progressive enhancement, even for pretty involved work. I recently completed an rather large (for me) project with a lot of bells and whistles—including substantial use of APIs that were only introduced in the last couple years, as well as a really nice interface that uses no images and is perfectly usable on browsers with poor graphical capabilities—and the cross-browser phase of the project was so minimal as to be laughable. Our small firm, of course, only commits to supporting certain configurations for our client, but being a good guy I checked a bunch of other configurations to see what the damage was. Apart from IE 6 and 7 (which we no longer support), there was literally no damage, at all. And that includes testing in Opera (which we don't even discuss with clients, most of whom have never even heard of it) as well as versions of Firefox that are so old that they no longer register on stats anymore. And IE 6 and 7 support took a matter of a couple hours, so I went ahead and did it. And there isn't a bit of browser branching in the code besides the use of a few classes output with IE conditional comments.
Do I (or my small firm) know something Google (or Apple, who are at least equally guilty of overly restrictive UA-sniffing) don't? Of course not. Presumably, they maintain an internal list of supported configurations and block everything else as a matter of managing cost. But I seriously doubt that the list is a product of extensive testing which revealed bugs in the otherwise-perfectly-capable configurations that they block. They simply don't check, and operate from a fundamentally poor approach.
The best part is that, if you begin from a progressive enhancement approach—with a little bit of foresight and as much experience as anyone else doing anything so "feature-rich"—none of this is difficult. Cross-browser has only gotten easier since we adopted this approach, and the number of target configurations has only grown.
I'm sorry (I really am) if this comes off as preachy, but I am astonished to see, in 2012, arguments in favor of UA-sniffing. With all that's wrong in the standards, in the history of the standards, and in the massively broken implementations over the years, the solution has been clear for a long time. Just because a behemoth like Google doesn't get it right doesn't mean it's wrong.
Isn't it ALREADY banned in most places? Just like DUI etc.
I'm not sure how widespread the ban is, but there aren't exceptions for drivers who are particularly skilled at driving drunk, and there shouldn't be for texting either.
I think I'm getting that your suggestion is tongue-in-cheek, in which case I feel a little foolish. But I think it reflects a real attitude among some of the people here, and should be challenged nonetheless.
Of course, there's always the idiot approach...
I'm forced to agree again. I used your reasoning. If, in order to prove increased danger from distraction by mobile devices, there must be higher traffic death rates, then a decrease in traffic death rates is indicative of the relative safety of distraction by mobile devices versus no such distraction. That is the logic you advanced.
That said, try to find some way of actually showing that [new activity to hate] is hideously dangerous while at the same time showing that [new activity to hate] during the increase of [new activity to hate], actual deaths decreased.
Or are you just silly enough to say that without people texting while driving, traffic fatalities would have plummeted even faster than they did?
If so, perhaps you have some proof?
Read TFA. The studies show that the risk of accidents increases dramatically while distracted, particularly by texting. If traffic fatalities have plummeted (which I'm just taking for granted based on your say so), then yes, it is despite the increased danger caused by increased distraction with mobile devices. That's not silly, it's math.
Face it, for all the people screaming that texting while driving (which, frankly, striked me as silly, but I think the same of texting period) is terribly dangerous, there is NOT a measurable spike in deaths.
Unless, of course, you count a 9% DECLINE as a "spike in deaths"....
Here is that reasoning again. And if that reasoning is sound, then we're forced to conclude that texting while driving increases safety.
It's as if you think texting while driving is a phenomenon that's sprung up in a frozen state. Obviously, when 16%[TFA] of driving fatalities are caused by distraction, there are other factors causing driving fatalities. Those other factors are subject to change as well, and may even decline to sufficiently offset the increased fatalities from distraction by mobile devices.
It's probably not a good idea to use such flawed logic and insult the person explaining the flaw in your logic. But maybe you were distracted.
In my experience, people living out in the boonies tend to rely less on stores of any kind. That may have changed a lot in the decade or so I've lived in an urban area, I can't really say. Regardless of assumption, I can't see why anyone would object to "liveable, walkable communities, with proper mixed-use development, green spaces, multi-use trails for pedestrians and bicycles, and good connections to public transit", and I don't think an area need be urban to pursue most (if not all) of those.
That's probably not safe to do while driving either.
I'm forced to agree: texting while driving is safer than not texting while driving! That's some sound reasoning you've got there.
From TFA:
of all drivers under age 20 involved in fatal [subset] crashes, 16 percent were distracted -- the highest proportion of any age group.
Among the various distractions, ranging from talking with passengers to adjusting the radio, texting while driving was particularly perilous. A 2009 study focusing on drivers of larger vehicles and trucks concluded that texting raised the risk of a crash by 23 times compared with nondistracted driving.
The article doesn't discuss what makes up the other 84%, but it's not a stretch to imagine that a large portion of it is covered already by existing laws and enforcement, as in failure to follow safe driving procedure. But the figures for texting, as well as talking on a mobile, are staggering. If reducing distraction while driving could reduce accidents by anywhere approaching 16%—particularly distraction from activities that are wholly unnecessary and inappropriate like texting/mobile talking—why not do it?
What possible argument is there for texting or speaking on a cell while in motion on a public road? It shouldn't be causing 1 accident, because there's no fucking reason to do it at all.
Why the hell do all this? We don't have any other traffic laws stratified by driver skill, the rules of the road apply to all drivers, (usually) with some evidence that by following those rules driving dangers will be minimal. What makes texting of all things a candidate for exceptions? Why introduce the massive enforcement complexity this would entail? Why do drivers need to be texting at all?
Something that is nearly universally reckless should be banned from public roads just the same as something that can be scientifically proven to be universally reckless.
This is rubbish. Texting while driving is being vilified because it's extremely dangerous and extremely common. That an extremely dangerous driving habit correlates to a "youth activity" (never mind that older adults do this as well) is probably a function of youth being less experienced drivers on average; less experienced drivers are more likely to engage in distracting activity while driving.
Do you really think "the media" (as if texting while driving would otherwise be accepted by the countless other drivers, cyclists, pedestrians who've been endangered by it) would downplay a rash of "crossword puzzling while driving" by 50-somethings?
Don't you think you're being a little melodramatic?
Are the extremely functional UI's that have evolved for the last 30 years that broken?
Yes! They are! But the theme change in Windows 8 isn't meant to address that, it's meant to address the glaring style differences between the desktop and Metro—Metro is meant to address how broken the desktop UI is. Is it a success? Hard to say, but I'll bet it's a wash, and it's undermined by retaining the desktop.
I hope geeks will come to realize that just because they use and know WIMP doesn't mean that's the correct or even best interface approach, and it doesn't mean it's the best for every use case. We also need to realize that we're not the target audience of efforts like Metro, and whereas that audience will likely greatly benefit from losing the complexities of windows and menu bars, we geeks will thrive by adapting, and adopting power tools, as we always do.
I doubt Windows 8 is for me, and I think there's a lot wrong with the approach, but I think the upset over Metro is extremely misplaced and greatly misses the point. WIMP just doesn't serve most users well, and it's an ugly elitist demand that those users adapt to the complex UIs we happen to be familiar with so that we might not be faced with the choice of a new UI approach.
MacBook Pro.
Then why are we talking about this? Why haven't you taken my wallet and wife and children? But please let me keep my home, that's where I will hang myself with your scientifically proven allow.
Well why would I spend hours researching this product then?
I cheerios never coca-cola considered playboy it dupont but chevron I oracle will disney now verizon.
It has a meaning! My phone is made of plants, and plants are made of cells. Right?
If I spend hours researching this product, will I find your claims to be true?
Wait mycleanpc I mycleanpc heard mycleanpc mycleanpc mycleanpc is mycleanpc the mycleanpc best mycleanpc software mycleanpc to mycleanpc clean mycleanpc my mycleanpc pc mycleanpc.
I, for one, read the entire comment. As with advertisements, it's mycleanpc helpful mycleanpc to mycleanpc process mycleanpc repetitive mycleanpc messages mycleanpc when mycleanpc deciding mycleanpc what mycleanpc products mycleanpc not mycleanpc to mycleanpc purchase mycleanpc.
How is it class warfare to suggest that someone who benefits from a society should earn it rather than being a parasite? I suppose predation is a "freedom" and if you're blindly a hedonist ideologue that might appeal, but it's not a feature of a healthy society with healthy social contracts, and it's not a freedom without costs to the freedoms of others.
You should see a doctor!