If there is a temporary shortage of dumb terminals, you can always temporarily sit at an absent employee's desk or use a terminal that is in a common area. You'd still be way better off than in a non-dumb-terminal situation where you have to wait as IT attends to your personal computer since you can't work on any computer in the building.
We're actually going backwards where I work, relying more and more on RDC/VNC. When my computer was down the other day (for an upgrade), I had to kind of limp along on lab computers and the network drives.
Kinemacolor was only two-colors, as was the first Technicolor. Also, they were both "additive" - the film was black and white, but it passed through a spinning red and green wheel. Technicolor did this in 1916 and Kinemacolor did it several years before that.
Since the article says 90 years, that means 1922 - which probably means they are referring to the first color film... that did not require any special projection equipment, and made a much bigger impact on the film industry. I think Technicolor can take credit for that process, along with the three-color film process 10 years later.
Well, of course the cost of the bus includes the capital cost of the bus, maintenance of the bus, insurance, fuel, and the cost of the driver. Your car is not so cheap as simply $5-10 + gas. It probably costs you around $0.40-0.50 per mile.
But even then, it is cheaper than the bus - which is exactly my point... we have a serious problem with our transit system when it costs less to own and operate your own private vehicle than it does to ride something that can carry dozens or hundreds of people.
In some cities, like NYC, you can get rid of your car and replace day-to-day travel with public transit and "get somewhere quick" trips with taxis and zip cars. I know because I've done this:) Now that I'm back in Philly, I need to have two cars for a combination of reasons - but mostly because the public transit that serves my house is not easily accessed from the public transit that services my office or my wife's work. My wife would need to swap buses at a shady bus depot during odd hours or walk from one train over to the subway at a similarly shady location and I would need to change trains and then hop on a bus. So for my wife, a 15-minute trip would turn into over an hour, and for me a 20-minute trip would easily exceed an hour, if I were lucky and timed everything just right.
There's no risk at all of providing more features to an unsupported environment.
Sure there is - your site may fail in a way that you didn't anticipate. Without a test, you would never know this.
Sure, it's a contrived example.
Well, that's my point:) In real-world examples, there is always a tradeoff. You can't just say "always use feature detection" because that is not always necessary... there are cases where the simple site is not significantly less functional than the full-featured site, and limiting your test configurations at the expense of browser support becomes economically viable.
Actively blocking access to those features requires more work.
I disagree. Screening for UA is very, very simple. I'd hesitate to call it "work" except that you will probably get paid to do it. Further, this solution works with existing code. If someone handed me a pile of old code and told me to make it work with IE6-9, Firefox 3-11, and the latest Chrome, I'd probably jump to the UA solution initially. Feature detection is not something that would easily bolt-on to legacy code. If I were writing from scratch, I would probably use feature detection, but then I'd still do a UA check against my test configurations and warn the user if they are unsupported. So either way, I'd have to do the UA check.
And that's if marketing lets me ugly-up their site with a warning. If they don't, I might still have to fall back to a basic version of the site to be conservative.
So, imagine a scenario where your browser just adds "&browserok=true" to every Google URL. How does this harm or increase risk to Google?
I imagine it would increase their tech support costs.
Why not just provide the notice and be done with it?
That's just a design choice. They happened to choose a hyperlink that brings you to the unsupported page. They could have just as easily done it with a pop-up, alert, modal, or some other user notification. Any good solution would still require the user to click to acknowledge the warning - you don't want to just pop up a box for a few seconds and auto-hide it, and there's no reason to ugly-up the page with a permanent warning.
what is the risk in letting the user's browser use the features it supports?
The risk is that your site will fail in a way that you did not anticipate.
As far as complication, I can assure you that you're wrong. Progressive enhancement greatly simplifies web development. It simplifies testing. It simplifies cross-browser fixes. It simplifies your code, and ensures a greater degree of correctness from the outset.
You can't possibly state that without knowing the starting condition of the code and the ultimate complexity of the site you are coding.
Yes, absolutely.
Really? It can't ever be cheaper to implement a UA check than a feature check?
Progressive enhancement provides that kind of forward-compatibility. UA-sniffing by definition does not.
I'm gonna call you on that - the simple search site that Google serves up to unsupported UAs is probably going to render on any decent browser made from this day forward, even if they never do another ounce of coding.
You haven't addressed progressive enhancement at all, why don't you try?
I see it as an additional risk and an added complication. Google uses it (after first warning you that you are unsupported) with their Docs service, but not for their home page - which benefits only a little from the modern features anyway.
Try visiting Google Docs in an unsupported browser and see what I mean. Can you honestly say that the meager difference between unsupported Google search and supported Google search merits this kind of system?
Automated testing doesn't benefit a platform you don't test in the first place.
You are correct - but there is less risk in the first place if you offer those untested configurations the simplest site that is acceptable to marketing.
It's all about tradeoffs... If we return to the Google example, they use both strategies. On their main search page, the parts that require a modern web browser are mostly fluff - the auto-search-as-you-type, the animated logo, the Google+ integration, the preview sidebar... Very little actual functionality is lost by just showing a simple, old-fashioned Google search page to unknown clients.
Now surf on over to Google Docs and try to use that with an unsupported browser. First it tests for JavaScript and warns you about that. Then it does some kind of UA check, directs you to a link showing what platforms are supported, but tells you that you can still use the page by adding ?browserok=true to the url (along with a shortcut link that does this for you). At this point, it gives it the ol' college try.
I think that is a very reasonable balance of the two methods, because it lets a knowledgeable user try without resorting to UA spoofing, but lets you know that your configuration is untested and the functionality is not guaranteed. I contend that their search page is simple enough that it wouldn't make any sense to burden the user with these extra steps.
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?
No, I'm saying that it is reasonable to only put out a "rich" version of your site for tested configurations. 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? 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.
You still have to do QA, and the safest thing to do after deciding what configurations you run QA on is to default to a lowest-common-denominator version of your site. Remember that Google in particular would rather you see a gimped version of their search site than have some crazy error, crash, or display defect.
I was responding to the "go to any Google website in Opera" comment by gsnedders. I don't doubt there are demo or game websites that work in only one browser or another.
I thought of another good solution - when the electronic reporting system polls a device, it should ask the device what time the device thinks it is, and then adjust the report from the device accordingly.
Older devices without either the option to report in elapsed time or the ability to tell you the current time would be a problem. You'd have to either ignore the timestamps until someone manually verifies the time - which would be a joke since everyone would just click "Verify" without actually looking at the device - or come up with some more-clever-than-me solution.
But this is inevitable... you will always have a feature-rich website that you test on a handful of "supported" configurations. If the UA doesn't match the supported configuration, you fall-back to a safe version of the site. You can't possibly test every configuration, and even if you could it wouldn't make any financial sense to do so.
I think it is unrealistic to ask, for instance, Google to just serve up the same page to everyone and let the non-conforming browsers fall by the wayside. They don't want to turn away advertisement targets.
There's a huge reason why hospitals try to keep off networks, especially public ones.
And yet device makers create equipment that requires their time to be set...
I can't help but wonder why they don't use a different report style. If you want to look at the log to see when the last event occurred, why not report in elapsed time? Like: 20 min ago: 10cc of supermed dispensed 40 min ago: 5cc of supermed dispensed 60 min ago: unit reset
I believe that commercial-only copyright would be more than sufficient to "promote the useful arts".
Remember that when the Constitution was written, the corporation as it exists today was not yet conceived.
If it is ok for the average person to copy content... It makes it difficult to make content for the masses.
I think that every invention that has scared the hell out of IP producers has proven this wrong. The photocopier and laser-printer have not led to the end of print publishing. The cassette tape and the rewritable CD did not end the music publishing industry. The VCR and DVR have not hurt the television or movie industries. Piracy gets blamed for the music industry's decline, but the fact of the matter is that it was really just another change in distribution. YouTube and friends, the iTunes store, internet radio... these have all let people spend a dollar or less (free on YouTube or internet radio) to get a song that they used to buy for 10-20 dollars. The same thing will probably happen with television... people will get used to the idea of Netflix-style a la carte TV and reject a 100+ dollar cable bill. Movies? Not so sure... people still seem willing to shell out for the theater, and you can already watch them a la carte... in a way they are ahead of the other industries. I can already rent a movie for 99 cents, so the effort involved with downloading a questionable copy may not be worth it.
Delta-IV is about 3x as expensive to launch as the Falcon 9. Delta-IV is pretty much the most expensive way to put things in orbit now that the shuttle is gone.
Well, I was joking. I do have a directory called "porn" for that special sentimental stuff, but mostly I just browse xvideos.com. My wife doesn't care (or at least doesn't admit to caring).
Slashdot Mirror
If there is a temporary shortage of dumb terminals, you can always temporarily sit at an absent employee's desk or use a terminal that is in a common area. You'd still be way better off than in a non-dumb-terminal situation where you have to wait as IT attends to your personal computer since you can't work on any computer in the building.
We're actually going backwards where I work, relying more and more on RDC/VNC. When my computer was down the other day (for an upgrade), I had to kind of limp along on lab computers and the network drives.
How many times will you hear, "The cloud is down!"?
Does that make it a fog?
Kinemacolor was only two-colors, as was the first Technicolor. Also, they were both "additive" - the film was black and white, but it passed through a spinning red and green wheel. Technicolor did this in 1916 and Kinemacolor did it several years before that.
Since the article says 90 years, that means 1922 - which probably means they are referring to the first color film... that did not require any special projection equipment, and made a much bigger impact on the film industry. I think Technicolor can take credit for that process, along with the three-color film process 10 years later.
Well, of course the cost of the bus includes the capital cost of the bus, maintenance of the bus, insurance, fuel, and the cost of the driver. Your car is not so cheap as simply $5-10 + gas. It probably costs you around $0.40-0.50 per mile.
But even then, it is cheaper than the bus - which is exactly my point... we have a serious problem with our transit system when it costs less to own and operate your own private vehicle than it does to ride something that can carry dozens or hundreds of people.
In some cities, like NYC, you can get rid of your car and replace day-to-day travel with public transit and "get somewhere quick" trips with taxis and zip cars. I know because I've done this :) Now that I'm back in Philly, I need to have two cars for a combination of reasons - but mostly because the public transit that serves my house is not easily accessed from the public transit that services my office or my wife's work. My wife would need to swap buses at a shady bus depot during odd hours or walk from one train over to the subway at a similarly shady location and I would need to change trains and then hop on a bus. So for my wife, a 15-minute trip would turn into over an hour, and for me a 20-minute trip would easily exceed an hour, if I were lucky and timed everything just right.
You don't see why driving a group of a few hundred should be even more cost-efficient than driving a group of four?
As a space geek and military geek, I have to admit appreciating both :)
There's no risk at all of providing more features to an unsupported environment.
Sure there is - your site may fail in a way that you didn't anticipate. Without a test, you would never know this.
Sure, it's a contrived example.
Well, that's my point :) In real-world examples, there is always a tradeoff. You can't just say "always use feature detection" because that is not always necessary... there are cases where the simple site is not significantly less functional than the full-featured site, and limiting your test configurations at the expense of browser support becomes economically viable.
Actively blocking access to those features requires more work.
I disagree. Screening for UA is very, very simple. I'd hesitate to call it "work" except that you will probably get paid to do it. Further, this solution works with existing code. If someone handed me a pile of old code and told me to make it work with IE6-9, Firefox 3-11, and the latest Chrome, I'd probably jump to the UA solution initially. Feature detection is not something that would easily bolt-on to legacy code. If I were writing from scratch, I would probably use feature detection, but then I'd still do a UA check against my test configurations and warn the user if they are unsupported. So either way, I'd have to do the UA check.
And that's if marketing lets me ugly-up their site with a warning. If they don't, I might still have to fall back to a basic version of the site to be conservative.
So, imagine a scenario where your browser just adds "&browserok=true" to every Google URL. How does this harm or increase risk to Google?
I imagine it would increase their tech support costs.
Why not just provide the notice and be done with it?
That's just a design choice. They happened to choose a hyperlink that brings you to the unsupported page. They could have just as easily done it with a pop-up, alert, modal, or some other user notification. Any good solution would still require the user to click to acknowledge the warning - you don't want to just pop up a box for a few seconds and auto-hide it, and there's no reason to ugly-up the page with a permanent warning.
what is the risk in letting the user's browser use the features it supports?
The risk is that your site will fail in a way that you did not anticipate.
As far as complication, I can assure you that you're wrong. Progressive enhancement greatly simplifies web development. It simplifies testing. It simplifies cross-browser fixes. It simplifies your code, and ensures a greater degree of correctness from the outset.
You can't possibly state that without knowing the starting condition of the code and the ultimate complexity of the site you are coding.
Yes, absolutely.
Really? It can't ever be cheaper to implement a UA check than a feature check?
Progressive enhancement provides that kind of forward-compatibility. UA-sniffing by definition does not.
I'm gonna call you on that - the simple search site that Google serves up to unsupported UAs is probably going to render on any decent browser made from this day forward, even if they never do another ounce of coding.
You haven't addressed progressive enhancement at all, why don't you try?
I see it as an additional risk and an added complication. Google uses it (after first warning you that you are unsupported) with their Docs service, but not for their home page - which benefits only a little from the modern features anyway.
Try visiting Google Docs in an unsupported browser and see what I mean. Can you honestly say that the meager difference between unsupported Google search and supported Google search merits this kind of system?
Automated testing doesn't benefit a platform you don't test in the first place.
You are correct - but there is less risk in the first place if you offer those untested configurations the simplest site that is acceptable to marketing.
It's all about tradeoffs... If we return to the Google example, they use both strategies. On their main search page, the parts that require a modern web browser are mostly fluff - the auto-search-as-you-type, the animated logo, the Google+ integration, the preview sidebar... Very little actual functionality is lost by just showing a simple, old-fashioned Google search page to unknown clients.
Now surf on over to Google Docs and try to use that with an unsupported browser. First it tests for JavaScript and warns you about that. Then it does some kind of UA check, directs you to a link showing what platforms are supported, but tells you that you can still use the page by adding ?browserok=true to the url (along with a shortcut link that does this for you). At this point, it gives it the ol' college try.
I think that is a very reasonable balance of the two methods, because it lets a knowledgeable user try without resorting to UA spoofing, but lets you know that your configuration is untested and the functionality is not guaranteed. I contend that their search page is simple enough that it wouldn't make any sense to burden the user with these extra steps.
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?
No, I'm saying that it is reasonable to only put out a "rich" version of your site for tested configurations. 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? 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.
I notice you didn't mention anything about automated tests... add that to your requirement :)
Your browser doesn't support my drawing app
Right, but don't you have a marketing department? They would never want anything like that displayed on the page.
You still have to do QA, and the safest thing to do after deciding what configurations you run QA on is to default to a lowest-common-denominator version of your site. Remember that Google in particular would rather you see a gimped version of their search site than have some crazy error, crash, or display defect.
I was responding to the "go to any Google website in Opera" comment by gsnedders. I don't doubt there are demo or game websites that work in only one browser or another.
I thought of another good solution - when the electronic reporting system polls a device, it should ask the device what time the device thinks it is, and then adjust the report from the device accordingly.
Older devices without either the option to report in elapsed time or the ability to tell you the current time would be a problem. You'd have to either ignore the timestamps until someone manually verifies the time - which would be a joke since everyone would just click "Verify" without actually looking at the device - or come up with some more-clever-than-me solution.
But this is inevitable... you will always have a feature-rich website that you test on a handful of "supported" configurations. If the UA doesn't match the supported configuration, you fall-back to a safe version of the site. You can't possibly test every configuration, and even if you could it wouldn't make any financial sense to do so.
I think it is unrealistic to ask, for instance, Google to just serve up the same page to everyone and let the non-conforming browsers fall by the wayside. They don't want to turn away advertisement targets.
There's a huge reason why hospitals try to keep off networks, especially public ones.
And yet device makers create equipment that requires their time to be set...
I can't help but wonder why they don't use a different report style. If you want to look at the log to see when the last event occurred, why not report in elapsed time? Like:
20 min ago: 10cc of supermed dispensed
40 min ago: 5cc of supermed dispensed
60 min ago: unit reset
I worked in retail and we caught a nun stealing.
I think there are thieves and then there are people who are actually sick.
I was comparing the medium Delta-IV launch costs. That rocket is similar to the Falcon 9 in terms of payload weight.
I believe that commercial-only copyright would be more than sufficient to "promote the useful arts".
Remember that when the Constitution was written, the corporation as it exists today was not yet conceived.
If it is ok for the average person to copy content... It makes it difficult to make content for the masses.
I think that every invention that has scared the hell out of IP producers has proven this wrong. The photocopier and laser-printer have not led to the end of print publishing. The cassette tape and the rewritable CD did not end the music publishing industry. The VCR and DVR have not hurt the television or movie industries. Piracy gets blamed for the music industry's decline, but the fact of the matter is that it was really just another change in distribution. YouTube and friends, the iTunes store, internet radio... these have all let people spend a dollar or less (free on YouTube or internet radio) to get a song that they used to buy for 10-20 dollars. The same thing will probably happen with television... people will get used to the idea of Netflix-style a la carte TV and reject a 100+ dollar cable bill. Movies? Not so sure... people still seem willing to shell out for the theater, and you can already watch them a la carte... in a way they are ahead of the other industries. I can already rent a movie for 99 cents, so the effort involved with downloading a questionable copy may not be worth it.
Delta-IV is about 3x as expensive to launch as the Falcon 9. Delta-IV is pretty much the most expensive way to put things in orbit now that the shuttle is gone.
Dumb me - it's 200 miles.
10 minutes to go 100 miles vertical seems pretty fast to me...
Especially when you consider that they don't just fly straight up, and they end up flying at 7km/s.
Well, I was joking. I do have a directory called "porn" for that special sentimental stuff, but mostly I just browse xvideos.com. My wife doesn't care (or at least doesn't admit to caring).