Other operating systems have pulled ahead and probably will continue to do so. Office has been nearly feature complete since Office 97 (which is perfectly serviceable for 99% of people), and Open Office will eventually get there, if it hasn't already. Internet Explorer continues to slip.
Microsoft continues to win in business software like Exchange and Outlook, and things that integrate with them. My guess is that they're putting a hell of a lot of money in SharePoint, because what other CMSs integrate that well with things like Exchange and Office and Active Directory? SharePoint will help them maintain their business dominance as they get clobbered in other areas.
I'm not sure what the cloud can do for them, there seems to be a lot of "magic happens here" in it. This could be a way for them to move Exchange and SharePoint up to a service pool in the sky.
Microsoft usually takes a few times to get things right. The next iteration of Xbox ought to be a monster, but I wouldn't rely on their cloud for a few more years.
It's that simple. A core percentage of your users simply refuse to read what is in front of them. They skim, they look for only the things they expect, and absolutely nothing else. They're basically running the visual equivalent of an Expect script, responding to a prompt in a way which may or may not be appropriate.
I'll give an example. I had a password reset program which, of course, required an email address specific to our users. However, there was a possibility that users would use a different email address that wasn't valid. No, I had no access to that list of addresses to match and verify, that was simply out. Instructions were provided on the page as to which kinds of email addresses were allowed, and which were not. Of course users ignore instructions, as we all know. They see "email address" and they begin typing. Instructions could be on the top, on the bottom, or right before that row -- it didn't matter. This happened about 45% of the time. Okay, half of our users read directions, yay.
80%? Such an optimist!
Only thirty percent of my users, presented with a HEY IT LOOKS LIKE YOU ARE USING THE WRONG EMAIL ADDRESS HERE IS WHAT IT SHOULD LOOK LIKE kind of prompt, right in their face, changed their behavior. It was big! It was colored! It covered the form until you made it go away. The rest kept doing it the wrong way. Sometimes several times in a row (I watched the logs). I could see them return a month later to reset their password, which they had forgotten, and make the same mistakes. They will not remember more than a few minutes ago, they will not read instructions, and they will not respond to error messages. They will not remember error messages they see.
Once you accept the existence of this core group and realize that you can do nothing to help them besides providing hopefully appropriate environmental prompts, the rest explains itself. Do not waste time trying to solve the problems with this group. If you carefully watch their behavior on other systems, they experience identical problems wherever they may go. They exist in a perpetual struggle with computers, thrashing like a goldfish thrashing in a corner of an aquarium. Feel sorry for them if you must, design around them if you can, but you cannot change their behavior for them, only provide a padded environment where they cannot hurt themselves too much and can hopefully mouth soft objects with rounded corners.
I sincerely hope that this version is better than the first edition, although anything short of a random re-arrangement of pages would serve as an improvement. The first edition actually delayed my initial use of Python by about a year and a half. I had heard wonderful things about the language so I figured, "Ah, an O'Reilly book!" Big mistake.
Endless bits about immutability, without hints as to why I ought to care. I can appreciate the use of the interactive prompt now, but to start with it seems
I ought to have tried fire.
It's time to replace all of those "Microsoft as the Borg" images with "Google as the Borg."
At this point, given how little I use my cell phone, anyway, I am strongly considering making a little box out of mu-metal. I think (but have not run the numbers) that it would be more effective than simple copper at the given frequencies. Whenever I want to use the phone, I will take it out of the box. Seeing as how I have used no minutes or text messages this month (already a third over), there's an argument to be made for switching to a much cheaper service.
I might get a pager, in case work (or anyone else) needs to get ahold of me.
We should log lollipop purchases, so we can crack down on those guys in big white vans with FREE CANDY on the side.
You're right, I completely ignored the hardware decoding aspects. Every time I look at video/audio encoding/decoding, I end up adding at least one more link in the chain. I don't know if video encoding is all that easy. I don't know personally anyone who does it and I know a fair bunch of programmers in disparate knowledge domains. Maybe I just don't know the right guys.
I'm not completely ignorant of serving video over HTTP, I'm just not a huge fan of it. I know it's what the cool kids are doing right now, but it overloads the protocol in a way it wasn't meant to be. Traffic shaping alone kills the issue for me. I would much rather have my lightweight text delivered to me over HTTP and then someone else's bandwidth hoarking video over another protocol. I know everyone talks about the coming bandwidth utopia, but where I am at, we're having significant issues with certain folks (ahem, students) absolutely slamming the Teh Tubes with torrent traffic and videos, so much so that people are having trouble checking email and reading webpages.
Streaming is not downloading. At all.
Downloading sends the whole file. It might as well be over FTP. Streaming is completely different.
First off, your media player and the streaming server negotiate a good bandwidth.
Next, the streaming server selects either the file or a stream within the file (as with RealMedia's SureStream) which suits the bandwidth of your media player.
This gets handed off by the server to your media player in a packetized fashion, little chunks of video. If you want to skip to a minute before the end, you may do so, even if you have not downloaded the whole file.
If a few packets get dropped along the way, if the buffer on your media player fails to take care of it, there can be a resend.
Or if your pipe gets clogged up, the streaming server can renegotiate the bandwidth. Or switch to a different server on the cluster, without you knowing about it.
Then there's a bonus for the people who are concerned with piracy (or those fearful of being sued for enabling it), which is that a whole copy of the file is not left on your hard drive. (You can get one by using a "stream ripper," but this is due diligence we're talking about here)
There's a lot of other stuff involved, and I'm drastically over-simplifying, but Streaming is not Downloading.
For a commercial takeoff, we need to expand beyond quadruplegic patients and the locked-in. Always loved the idea, but let's be honest -- if typing is faster, typing will still win. And that's just output. For input, I don't think competing with something high-speed like vision is all that important. Just a BCI that would allow for IM rates might as well be freakin' telepathy.
Streaming video needs an Apache. By that, I mean a very standardized server and set of protocols for delivering files encoded in a non-proprietary, free-to-use, free-to-decode, unrestricted-in-every-imaginable-sense manner.
The source of what has held this back, in my opinion, is that taking giant video files (and you should see how big raw video is) and cramming them down into small, chunkable files which can decode at the end into recognizable images is hard. Hard in the sense of "takes people with a great deal of math knowledge and computer science knowledge to pull off." It's not like HTML, where you are pushing around what are basically text files that you can open in Notepad. It takes a great deal of intellectual know-how and deep domain knowledge to pull this off on the encoding end in some reasonable fashion that doesn't take a lot of CPU cycles.
The few people who can do this take a long time to figure out a new scheme, and they have to test the living hell out of it. You can write a primitive webserver without too much fuss, it's just a specialized server which kicks out text and binary files on command, after all. Encoding video and serving it, though, is not easy. That's why so much goes into protecting the intellectual property; it was not trivial to create. Wade around in the fifteen profiles for MPEG-4 Part 10 aka AVC aka H.264 for a while and realize that this is not trivial. Hell, it had to be jointly developed by two groups, ITU's video group and MPEG. Take a look at Theora -- even its codebase is descended from something that once took real money to make.
If streaming media is to have its Apache, an investment of money must be made in finding these highly talented individuals and paying them to make a new, open standard. And code must be made available for an end-to-end implementation on many platforms, everything from encoding to serving (with authentication fun, to boot) to decoding, on Windows, on Unix/Linux, on Macs. With regression tests and tutorials. Plug-ins to be written for the top, say, ten browsers. And a decoder library for Flash. While this is going on, political battles will have to be fought to keep Microsoft, Apple, and other companies out of the loop, or they'll pull the usual and destroy or cripple the product before it reaches market, just as they managed to poison HTML5's video standards.
None of this is technically impossible, but it will be hard, and it will cost money and political tokens and time and real effort. Can it be done?
"Ada is PL/I trying to be Smalltalk. -- Codoso diBlini