Maybe I am missing something, but I am not sure what you are talking about regarding seaside refreshing. If you had bothered to download, install, use seaside, or even read the documentation, you would know that seaside almost never does a full page refresh.
One of us is, anyway. Maybe it's me, but I don't see any signs of the technologies you're espousing. Perhaps there's AJAX and DHTML in the full kit, but their examples don't show it.
Every time you click on a control, there's a full page refresh to communicate the state back to the server. That's not AJAX. That's ancient state-tracking technology. Early versions of Wings used to do the same thing before they started using AJAX.
Of course, having the server hold on to even the most minute of state changes has some serious issues. One is performance. Local DHTML widgets are always going to be more responsive than page refreshes or even AJAX calls to maintain state. The second is that if the state gets out of sync for any reason (like the aforementioned back/forward buttons) the widgets can begin behaving unexpectedly. In particular, options that the user may THINK were changed will have different states once the page refreshes. AJAX is even worse because an inconsistent state can persist on the client throughout the usage of the widget. This can cause the entire program to submit incorrect information and frustrate the user.
A better approach is to have the client widget act on behalf of the server, then submit back information as required. Information should only be sent back in complete batches, thus ensuring that there's never a consistency problem between the client and server. As a bonus, the client can be more responsive and interactive than with the server-state model.
I'm a coffee addict and it's early; my old brain needs to warm up before it functions properly.
Ah. See, that's a different problem from the issue of spelling out acronyms. 99% of people "got it" as soon as it was posted. So you'll just have to warm up the vacuum tubes and pour some coffee into the primer channels before tackling Slashdot in the morning.
Besides, everyone knows that IDE (aka ATA or ATAPI) has been replaced by SATA. The IDE term is antiquated and only exists as one of those strange connectors on some "legacy" motherboards. Sort of like those odd "ISA" slots occasionally found sitting next to the PCI and PCIe slots.;-)
Coincidentally I just watched TRON two days ago. It's still a good movie, and somehow even after almost thirty years it's still not outdated.
Has it really been that long? God, now I'm really feeling old.
If so, that was a rather unpleasant experience. The entire page refreshes on every interaction with the controls. That sort of technology has been around for nearly a decade now and has never caught on for a lot of good reasons. Not the least of which is that the back/forward buttons royally mess with the expected state of the widgets.
For an example, try playing around with this tab editor for Ocarinas. It looks good on the surface, but after using it for any significant period of time, you'll easily bump into significant flaws in the way it works. Even bumping the wrong key by accident can cause an extra tab to get inserted or work to be lost. Compare this to the more primitive Tab Maker which provides a very smooth experience via DHTML technologies.
Um, have you heard of google? I hear they let you store stuff on hard drives...over the web!
Worst. Argument. Ever.
BTW, for those of you who think I'm just trolling, here's an excerpt from the book "When Computers Went to Sea":
Because of shipboard space constraints, the NTDS computers called for very compact high-capacity memories that would also have to be unusually reliable. Electrostatic and mercury delay line memories were physically large, fragile, and out of the question for shipboard use. Magnetic drum memories were not only large, slow, and of limited capacity but were also incompatible with a ship's rolling and pitching in a seaway. Such motions would put large, unwanted gyroscopic precessional forces on the bearings of the massive spinning drums.
Supposedly if the drums were not properly balanced, the gyroscopic forces were powerful enough to induce significant roll into the ship's standing on the water.
The MCP (or "Master Control Program") was the main operating system of the Burroughs (later Unisys) range of mainframes. CANDE stood for "Command AND Edit program" which was an IDE similar in principle to the BASIC editors that many folks may remember using in the 80's. The primary difference is that the T27 terminals worked in a stateless submit/response mode similar to how HTTP works today. Since a persistent connection was not maintained like with the IBM terminals, code was usually edited one screen at a time before being transmitted back to the mainframe.
I shouldn't even have to explain the switch flipping. That was the ideal method of programming the old Honeywells.;-)
1. You're being ridiculously over critical. Does "Web-based Integrated Drive Electronics" make sense? No? How about "Web-based Insulin degrading enzyme"? Pretty silly, huh? Maybe, just maybe the context tells you what you need to know?
2. FTFS: "their web-based framework for code editing" I think that explains the usage of the acronym pretty well. If you're on Slashdot and you don't know what the three letters "IDE" stand for in that context, then you need to hand in your geek card and GTFO my lawn. Especially if you're an old timer, old timer.
(Bah! Back in my day we called our IDEs "CANDE" and we LIKED IT that way! We also threw glowing discs at the MCP right up until management put a stop to our shenanigans. Much more fun than the arduous task of flipping switches on the front of the mainframe. Not to mention that OUR permanent storage could capsize a naval warship if left unbalanced!)
I do believe you've been had. His comment about Win32 strikes me as the intended 'tell' for his sarcasm. The point being that developing desktop applications in a web-based IDE doesn't make much sense. Which I do agree with. The two environments are not at all integrated.
Of course, the AC conveniently ignores the massive business of web development which *could* benefit from centralized IDE services.
Codepress is just an editor. A potentially important piece of any IDE to be sure, but only a piece. You still need file system integration, project control, build support, deployment options, UI editors, code suggestion dropdowns, and a host of other tools and features that make modern IDEs useful products.
In particular, I'm looking for something that goes like "IE8 implements x, y and z, but it implements y wrong, and still doesn't implement important standards a, b and c.".
I thought you asked for a rant?;-)
Getting a comprehensive list of features support/not supported is hard given the scope of what a browser encompasses. You could use a tool like wttjs to test against the HTML5 WebIDL, but the output might be a bit more than you're looking for. From my perspective I'm worried about the big stuff that makes projects possible/not possible. So from my perspective, it's:
- No DOM2 Events support (Bug closed as "By Design") - No CSS Opacity support (Bug closed as "By Design") and IE filter syntax is changed - No SVG support - HTML5 localStorage implementation is wrong - Cross-Document messaging is wrong (lack of DOM2 Events here) - A new Cross Domain XML Request object that incompatibly ignores the existing HTML5 work - No Canvas support (not required, but pisses me off when they are supposedly adding HTML5 support) - CSS is only slightly less borked. I defer to the earlier link for a description of this issue.
I'd go digging for more, but I'm afraid I don't have the time right now. Hopefully those links will get you started!:-)
By the way, I see you're also using the ACID3 test to make a point. You shouldn't. While ACID2 was very relevant in how it tested standards everyone was asking for, ACID3 is content testing for little very specific rendering bugs in various rendering engines and CSS3 (which isn't even a standard yet!).
That's a fair argument. Mostly lack of ACID3 compliance is just more to be annoyed about. Other browsers have extremely high scores on these tests while IE manages a paltry 20/100. I wouldn't care so much if IE wasn't such a piece of crap in other areas, but it is. So if anyone brings up ACID3, I get to complain that it is also terrible there too.:-P
But does the median user really know which clip their machine is capable of?
They don't need to. It follows that if the movie is too slow, try the smaller one. Alternatively, they can try the HD version and see if it works for them. There's more steps, but it's not a burden by any stretch of the imagination.
But for a two hour movie, does anyone want to wait 10 hours? Smooth Streaming's sweet spot is ffor longer form content where the user wants instant-on, low-delay scrubbing, no "buffering" messages, and at the best quality they can get within those constraints.
I honestly think you're trying to solve a problem that doesn't exist. Balancing the movie quality to reach the highest number of users appears to be the best option here. iTunes users seem more than happy enough with the service. (I've certainly never had any problems with movie quality.) Do those users have a burning need for downloadable movies in 1080p? Hell, no. And you're not going to provide it to them anyway. (See below)
In general, content > accessibility > quality. Most people will watch content they like over content they don't like, and will put up with accessibility barriers before they'll watch stuff they don't like. Most people will put up with quality issues in order to have a much better accessibility to the content, but will chose the accessible version over the non-accessible version if both are available. Assuming the same content is availabe and accessable in a high quality and a low quality form, they'll pick the higher quality version.
It's interesting how you understand this without actually understanding it. By your own admission, a user is more likely to try and find the video they want on Youtube long before they become willing to download a Silverlight plugin. Only after they have exhausted all accessibility options for the content they want will they accept the quality benefits. In other words, you've just argued against your own product.
Also, poor video and audio quality is very dependent on the content and the experience the user is trying to have. Sure, the PS3 has YouTube, but watching it on a HD display at leaning back on a couch at 10' is nearly unbearable, even though the same clip would be fine in a small window on a PC with other stuff going on. With Smooth Streaming, we want to really enable to full consumer HD experience AND the streaming model at the same time.
I like the assumptions you make about how the technology will get used. Assumptions which are neither correct (there are plenty of sites that use the same technology to target a specific device and optimize to the needs of that device) and ultimately pointless because Silverlight doesn't support these devices. Even a sub-standard experience is usually better than no experience at all.
The hardware and broadband is here, it's just unevenly distributed. The goal of the technology is to provide every user with the best experience they can get at that moment, without having to underserve the high end or block out the low end.
Actually, you're going to provide them with a substandard experience. You're automatically going to degrade their experience based on factors that the user doesn't understand. The user can do nothing to change the settings and find for himself why his experience is worse than his neighbor's experience. It just is. He's painfully upgrade all his hardware and STILL have a worse experience, never knowing that his neighbor's bandwidth is better.
With options for different sizes, it works when the user wants it to work. But the user who wants to make it better can test out the other options and understand why it's not working. Oh, it keep saying "buffering". Duh. I need bigger Tubes for my Internets. Maybe some of that high fiber stuff that will help clean the pipes so my video goes faster.
The second link is about how the stuff in the first is authored, and doesn't require Silverlight. Sorry if that wasn't clear.
That part was clear. My issue was that the content of the first link was not clear. I assume from the name it's a site that streams HD videos. Which means... well, nothing. Absolutely nothing to me. There's a variety of sites that already do that. Without more information, I can't understand why your site is superior enough to make me install Silverlight.
The challenge with offering multiple sizes is that in forces the user to know what their system and connection can play
Complete nonsense. The idea of "SD" vs. "HD" has been so ingrained into our culture at this point, that it's quite easy for users to figure it out. Take this movie website as an example:
It streams the trailer in computer resolution by default and gives the options for smaller versions (iPod/iPhone) and larger versions (HD). No one complains that they can't see the trailer. It either just works, or they select a resolution more appropriate to their device. Plus they're made aware that they can watch the super-hires stuff by the "HD" link. Apple's website gives users the option of "Small/Medium/Large/iPod". Again, no one complains that they can't figure out how to get the video to work. They complain far more about having to install Quicktime. (Sort of like I'm complaining about Silverlight.)
Ah, that's the point! Smooth Streamings gets us out of having to wait for everyoen to be able to do HD to use it for mass audience content
You're completely missing the point. Multibitrate does not matter. Consider how many people link off to the Youtube versions of the Star Trek trailers! Those are of terrible quality. Yet the convenience and real-world benefits are more important to them than HD resolutions.
HD will catch on when the hardware gets here. And the reason why it will catch on when the hardware gets here is because that is when the best experience can be offered. It's not about HD vs. non-HD. That's a red herring. It's about providing a better service overall. HD video is a bonus and nothing more.
I understand that you've probably put a lot of heart and soul into making multibitrate work. But what you're working on is the modern equivalent of sending VOC files to the PC Speaker. A nifty technology that never saw wide distribution because it attempted to close a perceived gap that simply wasn't there. In the end, users upgraded to SoundBlaster sound cards rather than supporting the VOC->Speaker technology.
There's a lot of flexibility in how a site can present the install option.
You aren't listening. I don't care about the install option. I don't want to install Silverlight. It's the job of the website to convince me that "Yes you do!" The website does nothing to convince me. It merely gives me an ultimatum: We won't show you what we're about until you install this plugin. So install it or leave.
I leave.
In comparison, Youtube can be navigated without Flash. A user can understand what the site is about, why they might want the service, and ultimately make an informed decision about installing Flash.
For example, NBCOlympics.com offered a fallback to an IE embedded WMP ActiveX component.
Good to know that they made the effort to support my Mac, cell phone, Nintendo Wii, PS3, set-top box, Linux, etc. No, wait...
I agree that more sites could do a nicer job of it
Indeed. They could use multi-platform H.264 codecs and thus support nearly every web player on the market. From HTML5 video to the widely deployed Flash 10.
I also used to think that it would ease users into alternative browsers. But what I realized was happening is that users weren't feeling any pressure to move. With IE's market share dropping like a rock, it's more effective to NOT support it. What happens is that anyone who complains about a lack of IE support is immediately ostracized by their peers for running IE.
As an example, a public comment on the game in my sig was a fellow who thought it was funny that IE wasn't supported. He wasn't offended at all. Yet he received replies challenging him to explain why he was even running IE in the first place! (And no, this was not here on Slashdot or any other site which would be biased by the focus of the site.) That right there tells me that it's more effective NOT to support IE. Peer pressure can be a wonderful thing.;-)
At this point it looks like "corporate standards" are doing quite a bit to prop up IE's numbers. The good news is that those who finally move away from IE6 aren't all moving to IE7. Many of those users are switching to an alternative browser. Which means that Microsoft's lock-in is slipping fast.
Do what exactly? Linking off to a site that requires Silverlight with no explanation doesn't seem like a very good argument when you're posting to a forum that doesn't want to install your plugin. (Or more to the point, many of them can't install Silverlight 2.0.)
Your second link talks about multi-bitrate encoding. Which strikes me as (like the entire Silverlight platform) a solution looking for a problem. Despite the fact that Microsoft has had the technology deployed for years as part of WiMP, the market hasn't bought into it. It's just as easy (and probably less confusing) to simply provide different sizes. 95%+ of current streaming videos don't even have to worry about that. The closest thing we have to an issue is Youtube using low quality as the default. And even that has more to do with backwards compatibility and paced rollouts than it does a strict technology problem.
Perhaps Silverlight will be better positioned when HD streaming becomes the norm. More likely however, is that HD will be the norm when the majority of hardware on the market is both capable of HD streaming and integrated into the standard home in a way that would make HD streaming a superior enough experience for consumers to want to use it. At which point the advantage of technologies like multi-bitrate streaming simply vaporize. Microsoft would do better to spend those resources on implementing the web standards they've been blatantly ignoring for the past decade.
As an aside, why is it that every Silverlight website stops you cold? There's not even a description of what it is you're missing and/or why you should install the plugin. It's simply "install this or go away". So I go away. No skin off my nose.
You know, I actually did that for the Canvas tag. Except I used Java as the rendering engine. (Occasionally I even link to the demo here.) I had an entire plan for getting IE up to speed. Then Microsoft intentionally shafted the industry with their IE8 development. And then I stopped caring. I just... couldn't bring myself to feel anything positive toward Microsoft. I just wanted IE to die.
So I no longer support these efforts. Instead, I just watch IE's market share numbers drop. 67% and falling.
And I don't see anything in Silverlight that isn't similarly addressed by HTML5. Ergo, HTML5 is superior for its standardization, true cross-platform support, and competing implementations that can meet the needs of many different ideals.
For the record, I don't have anything against people such as yourself who work at Microsoft. Many people who work there are great people. But from the inside looking out, you can't see the forest through the trees. You especially can't see the massive amount of harm and disrespect your company is paying the industry. And that harm is why I can't stand Microsoft anymore. Mr. Wilson can complain about negativity all he wants, but he refuses to recognize the trail of broken promises he and your company have given to the industry.
Sorry if I'm a little edgy. I do mean that IE8 is a sore spot for me. Slowness to implement standards I can understand. Microsoft has an uphill battle with the Trident engine. But blatant disregard? Flaunting their non-implementation of standards? Closing bugs for standards support as "By Design"? That I cannot stomach.
Death to Microsoft. May the phoenix be a stronger company and a better citizen.
I don't see why. I love web standards. They open up platforms and make the Internet a better and more powerful place for all users. Microsoft's attempts to subvert those standards don't make me happy. Nor does Miguel's backwards attempts at bringing Microsoft technology to Linux.
Microsoft technology was once at the top of its field. While Microsoft lied, stole, and crushed to get there, at least it really was superior to the alternatives. Now they're instead planting their either ancient or useless alternative technology in the way of progress in an attempt to bar the industry from moving forward. I cannot agree with that. I cannot allow that. I will not support Microsoft until their ACTIONS match what their high words about standards support.
Which post would that be? The one where Microsoft failed to implement DOM2 events, then implemented HTML5 features based on DOM2 events and therefore incompatible with the standards, therefore not HTML5?
Don't get me started. IE8 is a sore point for me. You WON'T appreciate what you hear. (Or maybe you will. But it won't be the most pleasant conversation.)
Really? I seem to remember a game written back in '96 called "Subspace". The players of the game were the ones driving its design and development based on their feedback. The bad news is that the game effectively tanked in the market. The good news is that it's still around thanks to all the players who poured their efforts into the game not wanting to see it die.
Slashdot Mirror
One of us is, anyway. Maybe it's me, but I don't see any signs of the technologies you're espousing. Perhaps there's AJAX and DHTML in the full kit, but their examples don't show it.
Go view the examples here:
http://www.seaside.st/about/examples
Every time you click on a control, there's a full page refresh to communicate the state back to the server. That's not AJAX. That's ancient state-tracking technology. Early versions of Wings used to do the same thing before they started using AJAX.
Of course, having the server hold on to even the most minute of state changes has some serious issues. One is performance. Local DHTML widgets are always going to be more responsive than page refreshes or even AJAX calls to maintain state. The second is that if the state gets out of sync for any reason (like the aforementioned back/forward buttons) the widgets can begin behaving unexpectedly. In particular, options that the user may THINK were changed will have different states once the page refreshes. AJAX is even worse because an inconsistent state can persist on the client throughout the usage of the widget. This can cause the entire program to submit incorrect information and frustrate the user.
A better approach is to have the client widget act on behalf of the server, then submit back information as required. Information should only be sent back in complete batches, thus ensuring that there's never a consistency problem between the client and server. As a bonus, the client can be more responsive and interactive than with the server-state model.
You keep using that mod. I do not think it means what you think it means.
Ah. See, that's a different problem from the issue of spelling out acronyms. 99% of people "got it" as soon as it was posted. So you'll just have to warm up the vacuum tubes and pour some coffee into the primer channels before tackling Slashdot in the morning.
Besides, everyone knows that IDE (aka ATA or ATAPI) has been replaced by SATA. The IDE term is antiquated and only exists as one of those strange connectors on some "legacy" motherboards. Sort of like those odd "ISA" slots occasionally found sitting next to the PCI and PCIe slots. ;-)
Has it really been that long? God, now I'm really feeling old.
Is this the SeaSide you're referring to?
http://www.seaside.st/
If so, that was a rather unpleasant experience. The entire page refreshes on every interaction with the controls. That sort of technology has been around for nearly a decade now and has never caught on for a lot of good reasons. Not the least of which is that the back/forward buttons royally mess with the expected state of the widgets.
For an example, try playing around with this tab editor for Ocarinas. It looks good on the surface, but after using it for any significant period of time, you'll easily bump into significant flaws in the way it works. Even bumping the wrong key by accident can cause an extra tab to get inserted or work to be lost. Compare this to the more primitive Tab Maker which provides a very smooth experience via DHTML technologies.
Worst. Argument. Ever.
BTW, for those of you who think I'm just trolling, here's an excerpt from the book "When Computers Went to Sea":
Supposedly if the drums were not properly balanced, the gyroscopic forces were powerful enough to induce significant roll into the ship's standing on the water.
The MCP (or "Master Control Program") was the main operating system of the Burroughs (later Unisys) range of mainframes. CANDE stood for "Command AND Edit program" which was an IDE similar in principle to the BASIC editors that many folks may remember using in the 80's. The primary difference is that the T27 terminals worked in a stateless submit/response mode similar to how HTTP works today. Since a persistent connection was not maintained like with the IBM terminals, code was usually edited one screen at a time before being transmitted back to the mainframe.
I shouldn't even have to explain the switch flipping. That was the ideal method of programming the old Honeywells. ;-)
You *had* to ask, didn't you?
http://robrohan.com/projects/9ne/
And just to keep the vi vs. emacs rivalry well fueled:
http://gpl.internetconnection.net/vi/
1. You're being ridiculously over critical. Does "Web-based Integrated Drive Electronics" make sense? No? How about "Web-based Insulin degrading enzyme"? Pretty silly, huh? Maybe, just maybe the context tells you what you need to know?
2. FTFS: "their web-based framework for code editing" I think that explains the usage of the acronym pretty well. If you're on Slashdot and you don't know what the three letters "IDE" stand for in that context, then you need to hand in your geek card and GTFO my lawn. Especially if you're an old timer, old timer.
(Bah! Back in my day we called our IDEs "CANDE" and we LIKED IT that way! We also threw glowing discs at the MCP right up until management put a stop to our shenanigans. Much more fun than the arduous task of flipping switches on the front of the mainframe. Not to mention that OUR permanent storage could capsize a naval warship if left unbalanced!)
I do believe you've been had. His comment about Win32 strikes me as the intended 'tell' for his sarcasm. The point being that developing desktop applications in a web-based IDE doesn't make much sense. Which I do agree with. The two environments are not at all integrated.
Of course, the AC conveniently ignores the massive business of web development which *could* benefit from centralized IDE services.
Codepress is just an editor. A potentially important piece of any IDE to be sure, but only a piece. You still need file system integration, project control, build support, deployment options, UI editors, code suggestion dropdowns, and a host of other tools and features that make modern IDEs useful products.
So what you're saying is that efs2 and ffs/ufs can't touch this.
HAMMER TIME!
I thought you asked for a rant? ;-)
Getting a comprehensive list of features support/not supported is hard given the scope of what a browser encompasses. You could use a tool like wttjs to test against the HTML5 WebIDL, but the output might be a bit more than you're looking for. From my perspective I'm worried about the big stuff that makes projects possible/not possible. So from my perspective, it's:
- No DOM2 Events support (Bug closed as "By Design")
- No CSS Opacity support (Bug closed as "By Design") and IE filter syntax is changed
- No SVG support
- HTML5 localStorage implementation is wrong
- Cross-Document messaging is wrong (lack of DOM2 Events here)
- A new Cross Domain XML Request object that incompatibly ignores the existing HTML5 work
- No Canvas support (not required, but pisses me off when they are supposedly adding HTML5 support)
- CSS is only slightly less borked. I defer to the earlier link for a description of this issue.
Here's a few articles covering these items and more:
http://annevankesteren.nl/2008/03/ie8-bad
http://annevankesteren.nl/2008/10/ie8-bad-update
http://annevankesteren.nl/2009/01/gettters-setters
http://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=333958
http://webbugtrack.blogspot.com/
As an aside, make sure you read this:
http://annevankesteren.nl/2008/03/office-sucks
I'd go digging for more, but I'm afraid I don't have the time right now. Hopefully those links will get you started! :-)
That's a fair argument. Mostly lack of ACID3 compliance is just more to be annoyed about. Other browsers have extremely high scores on these tests while IE manages a paltry 20/100. I wouldn't care so much if IE wasn't such a piece of crap in other areas, but it is. So if anyone brings up ACID3, I get to complain that it is also terrible there too. :-P
They don't need to. It follows that if the movie is too slow, try the smaller one. Alternatively, they can try the HD version and see if it works for them. There's more steps, but it's not a burden by any stretch of the imagination.
I honestly think you're trying to solve a problem that doesn't exist. Balancing the movie quality to reach the highest number of users appears to be the best option here. iTunes users seem more than happy enough with the service. (I've certainly never had any problems with movie quality.) Do those users have a burning need for downloadable movies in 1080p? Hell, no. And you're not going to provide it to them anyway. (See below)
It's interesting how you understand this without actually understanding it. By your own admission, a user is more likely to try and find the video they want on Youtube long before they become willing to download a Silverlight plugin. Only after they have exhausted all accessibility options for the content they want will they accept the quality benefits. In other words, you've just argued against your own product.
I like the assumptions you make about how the technology will get used. Assumptions which are neither correct (there are plenty of sites that use the same technology to target a specific device and optimize to the needs of that device) and ultimately pointless because Silverlight doesn't support these devices. Even a sub-standard experience is usually better than no experience at all.
Actually, you're going to provide them with a substandard experience. You're automatically going to degrade their experience based on factors that the user doesn't understand. The user can do nothing to change the settings and find for himself why his experience is worse than his neighbor's experience. It just is. He's painfully upgrade all his hardware and STILL have a worse experience, never knowing that his neighbor's bandwidth is better.
With options for different sizes, it works when the user wants it to work. But the user who wants to make it better can test out the other options and understand why it's not working. Oh, it keep saying "buffering". Duh. I need bigger Tubes for my Internets. Maybe some of that high fiber stuff that will help clean the pipes so my video goes faster.
That part was clear. My issue was that the content of the first link was not clear. I assume from the name it's a site that streams HD videos. Which means... well, nothing. Absolutely nothing to me. There's a variety of sites that already do that. Without more information, I can't understand why your site is superior enough to make me install Silverlight.
Complete nonsense. The idea of "SD" vs. "HD" has been so ingrained into our culture at this point, that it's quite easy for users to figure it out. Take this movie website as an example:
http://www.startrekmovie.com/
It streams the trailer in computer resolution by default and gives the options for smaller versions (iPod/iPhone) and larger versions (HD). No one complains that they can't see the trailer. It either just works, or they select a resolution more appropriate to their device. Plus they're made aware that they can watch the super-hires stuff by the "HD" link. Apple's website gives users the option of "Small/Medium/Large/iPod". Again, no one complains that they can't figure out how to get the video to work. They complain far more about having to install Quicktime. (Sort of like I'm complaining about Silverlight.)
You're completely missing the point. Multibitrate does not matter. Consider how many people link off to the Youtube versions of the Star Trek trailers! Those are of terrible quality. Yet the convenience and real-world benefits are more important to them than HD resolutions.
HD will catch on when the hardware gets here. And the reason why it will catch on when the hardware gets here is because that is when the best experience can be offered. It's not about HD vs. non-HD. That's a red herring. It's about providing a better service overall. HD video is a bonus and nothing more.
I understand that you've probably put a lot of heart and soul into making multibitrate work. But what you're working on is the modern equivalent of sending VOC files to the PC Speaker. A nifty technology that never saw wide distribution because it attempted to close a perceived gap that simply wasn't there. In the end, users upgraded to SoundBlaster sound cards rather than supporting the VOC->Speaker technology.
You aren't listening. I don't care about the install option. I don't want to install Silverlight. It's the job of the website to convince me that "Yes you do!" The website does nothing to convince me. It merely gives me an ultimatum: We won't show you what we're about until you install this plugin. So install it or leave.
I leave.
In comparison, Youtube can be navigated without Flash. A user can understand what the site is about, why they might want the service, and ultimately make an informed decision about installing Flash.
Good to know that they made the effort to support my Mac, cell phone, Nintendo Wii, PS3, set-top box, Linux, etc. No, wait...
Indeed. They could use multi-platform H.264 codecs and thus support nearly every web player on the market. From HTML5 video to the widely deployed Flash 10.
Whoops. That wasn't what you mean
Here's a very comprehensive rant I gave a while back, along with links to other well-documented rants:
http://tech.slashdot.org/comments.pl?sid=1105033&cid=26614099
I particularly recommend this link:
http://www.howtocreate.co.uk/wrongWithIE/
Going through that site with IE and any other browser is a seriously eye-opening experience. ;-)
I also used to think that it would ease users into alternative browsers. But what I realized was happening is that users weren't feeling any pressure to move. With IE's market share dropping like a rock, it's more effective to NOT support it. What happens is that anyone who complains about a lack of IE support is immediately ostracized by their peers for running IE.
As an example, a public comment on the game in my sig was a fellow who thought it was funny that IE wasn't supported. He wasn't offended at all. Yet he received replies challenging him to explain why he was even running IE in the first place! (And no, this was not here on Slashdot or any other site which would be biased by the focus of the site.) That right there tells me that it's more effective NOT to support IE. Peer pressure can be a wonderful thing. ;-)
68.15% and accelerating.
At this point it looks like "corporate standards" are doing quite a bit to prop up IE's numbers. The good news is that those who finally move away from IE6 aren't all moving to IE7. Many of those users are switching to an alternative browser. Which means that Microsoft's lock-in is slipping fast.
Do what exactly? Linking off to a site that requires Silverlight with no explanation doesn't seem like a very good argument when you're posting to a forum that doesn't want to install your plugin. (Or more to the point, many of them can't install Silverlight 2.0.)
Your second link talks about multi-bitrate encoding. Which strikes me as (like the entire Silverlight platform) a solution looking for a problem. Despite the fact that Microsoft has had the technology deployed for years as part of WiMP, the market hasn't bought into it. It's just as easy (and probably less confusing) to simply provide different sizes. 95%+ of current streaming videos don't even have to worry about that. The closest thing we have to an issue is Youtube using low quality as the default. And even that has more to do with backwards compatibility and paced rollouts than it does a strict technology problem.
Perhaps Silverlight will be better positioned when HD streaming becomes the norm. More likely however, is that HD will be the norm when the majority of hardware on the market is both capable of HD streaming and integrated into the standard home in a way that would make HD streaming a superior enough experience for consumers to want to use it. At which point the advantage of technologies like multi-bitrate streaming simply vaporize. Microsoft would do better to spend those resources on implementing the web standards they've been blatantly ignoring for the past decade.
As an aside, why is it that every Silverlight website stops you cold? There's not even a description of what it is you're missing and/or why you should install the plugin. It's simply "install this or go away". So I go away. No skin off my nose.
You know, I actually did that for the Canvas tag. Except I used Java as the rendering engine. (Occasionally I even link to the demo here.) I had an entire plan for getting IE up to speed. Then Microsoft intentionally shafted the industry with their IE8 development. And then I stopped caring. I just... couldn't bring myself to feel anything positive toward Microsoft. I just wanted IE to die.
So I no longer support these efforts. Instead, I just watch IE's market share numbers drop. 67% and falling.
And I don't see anything in Silverlight that isn't similarly addressed by HTML5. Ergo, HTML5 is superior for its standardization, true cross-platform support, and competing implementations that can meet the needs of many different ideals.
For the record, I don't have anything against people such as yourself who work at Microsoft. Many people who work there are great people. But from the inside looking out, you can't see the forest through the trees. You especially can't see the massive amount of harm and disrespect your company is paying the industry. And that harm is why I can't stand Microsoft anymore. Mr. Wilson can complain about negativity all he wants, but he refuses to recognize the trail of broken promises he and your company have given to the industry.
Sorry if I'm a little edgy. I do mean that IE8 is a sore spot for me. Slowness to implement standards I can understand. Microsoft has an uphill battle with the Trident engine. But blatant disregard? Flaunting their non-implementation of standards? Closing bugs for standards support as "By Design"? That I cannot stomach.
Death to Microsoft. May the phoenix be a stronger company and a better citizen.
I don't see why. I love web standards. They open up platforms and make the Internet a better and more powerful place for all users. Microsoft's attempts to subvert those standards don't make me happy. Nor does Miguel's backwards attempts at bringing Microsoft technology to Linux.
Microsoft technology was once at the top of its field. While Microsoft lied, stole, and crushed to get there, at least it really was superior to the alternatives. Now they're instead planting their either ancient or useless alternative technology in the way of progress in an attempt to bar the industry from moving forward. I cannot agree with that. I cannot allow that. I will not support Microsoft until their ACTIONS match what their high words about standards support.
Which post would that be? The one where Microsoft failed to implement DOM2 events, then implemented HTML5 features based on DOM2 events and therefore incompatible with the standards, therefore not HTML5?
Don't get me started. IE8 is a sore point for me. You WON'T appreciate what you hear. (Or maybe you will. But it won't be the most pleasant conversation.)
Something like this perhaps?
SVG + Video > Silverlight
And that's only the tip of the technological iceberg. Behold the power of HTML5. Coming to every web browser except Internet Explorer.
No
Really? I seem to remember a game written back in '96 called "Subspace". The players of the game were the ones driving its design and development based on their feedback. The bad news is that the game effectively tanked in the market. The good news is that it's still around thanks to all the players who poured their efforts into the game not wanting to see it die.