The initial response was for the punters who might not want to buy a Kinect because "O NOES ITS BEEN HACKD!!11!". Because for people like that, it means that evil hax0rs can do things like watching you make an arse out of yourself waving your arms around in front of your TV (naked or otherwise).
The subsequent response is for the tech-savvy (dare I say it) hackers who might want to add value to their product by coming up with cool new uses for it, and who in turn misinterpreted their initial response as "O NOES M$ WANTS TO STOP U MAKIN COOL OPEN SAUCE KINECT HAX!!11!".
There's a disconnect between tech-driven communication and sale-driven communication from Microsoft, certainly, but in this case they're not saying incompatible things at all.
There have been relatively few manuals I've needed in any form for the last 20 years. Of those, probably 80% would be fine as PDFs. The remainder are useful, informative and/or entertaining artefacts that contribute well to playing a game. And of those, they still don't compare to most of the things I got with Infocom games back in the 1980s.
So for all the dead tree purists out there: if you really cared about good paper manuals, you shouldn't have stood for so many of them sucking their way into irrelevance over the last couple of decades.
I'm at a university that had WebCT, which then morphed into Blackboard and has just recently been replaced with Moodle. Having using those systems, both as a student and in teaching roles, I have to say that Moodle is just plain better. It's cheaper (TCO), more versatile and more usable. And much less prone to inducing rage
Of course, that doesn't mean that it's invulnerable to screw-ups. If you lock it down from on high with One True Way of Using The System, then you're probably not going to suit the needs of different academic departments and their different kinds of students (CompSci versus English majors, for example). On the other hand, too little structure can lead to ongoing support problems in security, maintenance and training/helpdesk services. The trick is to find a balance that works across your institution.
Damnit! I always thought cows were tauroidal...
Scott Adams published his first adventure in 1978. Infocom published Zork for microcomputers in 1980. While they may have been relatively contemporary, Adams did most of his games alone or with at most one collaborator, compared to the group working on Infocom's technologies. They're both important pioneers, even if Infocom's efforts have dated better.
Bear in mind also that the original version of Zork and Infocom's interpreter was improved over the years, too. I can distinctly remember it being easier to play later in life - not just because I was older, but because it was a little more forgiving with its vocabulary compared to the original version (I booted up the TRS-80 to check).
So wait, a plane switched to "landing" mode was being used for something other than landing, and then suddenly behaved in an unpredictable fashion by trying to land? I'm shocked!
It's not as simple as blaming "software fault" or "human error": it's in the interaction between the systems and the human, and the assumptions that each maintains about the other's actions in a marginally-stable, high risk environment.
No, not at all. The lesson that if you hide the risks from people, they tend to make more risky decisions.
Rather than simply cushioning people from the risks in their environment, they need to be made aware of them and their consequences.
Anyway, geeks? Football? Going outside to play? That's crazy talk!
Back in 1988, an Airbus A320 crashed at an air show during low-level flight manoeuvres. The brand new fly-by-wire systems made the plane easier to control in situations that a non-wire flight system would have problems. By making it that easy, the system also made it easier for pilots to push closer to the unstable edges of that envelope without the same level of feedback that things could go wrong. Things went wrong. People died.
Twenty years later, we're still learning the same lessons, it seems.
Adding features does not necessarily increase functionality -- it just makes the manuals thicker.