Maybe this analogy is failing. All I was trying to point out is that you're perfectly welcome to use their SDK and write iPhone apps, test them in the free simulator, etc, without paying a dime. The $99 fee lets you test on a real device and/or deploy to the store. I can see being annoyed at not being able to deploy to your own phone (that's one of the things I'd most like for them to change) without paying, but access to the store? That's fair game, as far as I'm concerned. They've gone to the trouble of creating this ecosystem, setting up all the infrastructure necessary for you to deploy your app to potentially hundreds of thousands of users, and handle all the financial transactions. All you have to do is write it, and of course, pay them $100.

Perhaps brick and mortar comparisons are just as useless, but if I make some gadget, I don't see why any store on the block would be obligated to accept it as merchandise and put it on their shelves. Apple charging me for access to their system simply means that all I have to do is invent and build the gadget. They even take care of the packaging. Seems like a pretty fair deal to me.

They charge a fee if you want to send builds to a device, or publish in their store, but the SDK itself, and its associated dev tools, are free as in beer.

Which is exactly why Apple gives away all their development tools for free, and why the built their current flagship software product on top of BSD, drawing significant interest and new users from the Linux crowd.

Apple doesn't hate geeks, it hates the way many geeks think that because they're so smart, they're automatically good at everything. The Unix that is OS X and the iPhone platform provide plenty of room for tinkering -- perhaps less so on the iPhone -- but it's not like everything Mac is a lifeless void. What Apple doesn't like you doing is trying to one-up them at their own game. For instance, if Apple made it easy for you install themes the way you might in any number of Linux window managers, chances are pretty good that you'll just make your computer hideously ugly and then have the audacity to show it to all your friends. This isn't a chance they'd like to take, being that their niche is in good design (how depressing is it that good design is a niche market?).

These beautifully designed packages you passingly deride are what make computers usable. In the case of the iPhone, seriously, the vast majority of apps in the store are awful, even adhering to Apple's design guidelines and making use of their standard UI toolkits. Imagine what we would end up with if programmers had total control over the system. In my eyes, it would result in a sharp decrease of users as the typical iPhone would be less stable, potentially less secure, and certainly more confusing as apps would depart more significantly from the accepted set of standards. Practically every rule in their SDK license has some similar reason behind it, even if a few of them are overkill. Background processes can drain battery life. Interpreted code environments (especially user-generated code, which is the biggest concern IMHO) can make it difficult for Apple to evaluate the spectrum of how an app might perform in real use (or fail to perform), which is a real concern for those who care about all the little details of packaging and interface design.

It used to bother me how much Apple locks things down, but I have to admit that they've been really successful in creating a pleasing, easy to use, and reasonably flexible system that also brings with it a thriving market ecosystem. Essentially none of the other smartphone manufacturers and platforms have come even close to this. It certainly makes you wonder if an open platform is really the solution to the "iPhone Killer" problem.

Exactly right. It's similar to the situation we have with recent automobile designs, where all kinds of sensors are in place to detect potential engine problems. I have nothing against these sensors being there if it helps consumers realize something is wrong before serious damage occurs, but sometimes the sensors fail, and all you have to go by is the "Check Engine" light. A previous car of mine had a faulty sensor that would constantly trigger the engine light, and even though there was nothing else wrong with the car, it wouldn't pass smog as long as the light was on, which was most of the time. After spending way more money than I had ever intended to, both in attempts to get the car smogged and taking it to mechanics who simply plugged in a computer and "diagnosed" the problem the sensor was erroneously reporting, I actually ended up taking it to a mechanic who was nice enough to reset it for free, giving me enough time to take it across the street to get it smogged before the light came back on. It wasn't until later that I learned the sensor itself was the culprit.

Has it occurred to anyone that this paper isn't the "PC Brigades"? I'd be willing to be most of you haven't even bothered to read it.

Nobody is asking anyone to fill a quota. Minorities and women are underrepresented in games for the same reason that they were underrepresented in film and television for so long (and still are in many ways)...because they are socially marginalized. It's more a reflection of the state of our culture than anything else. You're probably not old enough to remember it, but if you look back just 30-40 years, it's hard to even find movies that are shown from a woman's point of view -- one of the biggest critiques of film by early feminists was the way in which female characters were often passive objects, plot devices or romantic interests of the male leads at best. Social researchers are interested in the way our culture reflects the biases we have.

You probably don't care, and that's fine. Nobody in the game industry is going to read this study any more than the slashcrowd, and if they did it's not going to cause them to rethink their plans. They make the games that sell, just like the moviemakers of yesteryear made the hero worshiping, male-centric films that audiences loved. Games, film and other cultural artefacts will continue to mirror the social gestalt, social change will be gradual, and most people won't notice. Social theorists and scientists (you can put scare quotes around it if you like) will continue to pay attention to these things, because they think, quite rightly, that having a pulse on our culture is a good thing.

The rejections weren't nonsensical, you just didn't agree with them. Apple's guidelines are freely available and fairly clear (even if they appear to give a a fair amount wiggle room). The fact that you attempted to re-submit a reworked version of your app, all while knowing that it still failed to comply with Apple's rules, is particularly telling. Don't like the fact that you're not supposed to link to 3rd party libraries? Do you think it's silly that they don't want the app's charity focus announced in the store? Well, too bad. There are plenty of other mobile platforms with far less traction that would love to have your half-assed product. This isn't Open Source, and you don't get to just take other people's hard work, make some little throwaway project, refuse to play by the rules, and then throw a hissy fit when things don't go your way.

For the record, I do iPhone development, and though there are some lovely interface concepts on the device, the overall state of UI design in many iPhone apps is typically lacking. But that said, if a fresh look at UI design is what you're after, you probably won't find it on Linux. There are just far too many ego-inflated power nerds who think they're good at everything, and engineers who couldn't give less of a damn about usability. Or worse, the occasional hotshot engineer with an artistic streak that assumes, obnoxiously, that UI design is the same thing as "skinning".

I mean, if UI quality were judged in the number and variety of themes available, we'd all be running Englightenment! Right guys? The really annoying thing about it is that this information is out there, and despite the fact that UI improvements have taken a back seat in recent years, any software developer could head on down to a decent library and learn at least a little of what makes an interface work (or better yet, learn that UI design is not a computer-specific domain, that sure would be a mindfuck). That is, if he wanted to.

That doesn't mean the rest of us need to give a $@*

http://en.wikipedia.org/wiki/White_phosphorus_use_in_Iraq

White Phosphorus burns to the bone when it comes in contact with skin, and water makes it worse. The use of White Phosphorus as an incendiary weapon in Fallujah (and for that matter Gaza) constitutes deliberate killing of civilians. Any weapon that is used as a blanket over a wide area is, by definition, incapable of distinguishing between combatant and non-combatant.

While this is a good point, your analysis (and in fact, every single Slashdot headline about HCI) assumes that interaction design is limited to designing interfaces that are intended as replacements for generic, everyday data manipulation, such as mice/keyboards/etc. The real assumption we should be confronting is the notion that interface design is like a diagram of human evolution, or that innovations should necessarily replace everything that have come before them.

Siftables, for instance, make little sense as an interface for graphic designers working in Photoshop, but might make a fabulous specialized interface for young children, who primarily learn through direct physical interaction with their environment. Todd Oppenheimer's book "The Flickering Mind" points out some of the issues that can arise from young children spending too much time with traditional computer interfaces â" by bypassing a child's need for direct, physical interaction you can actually end up stunting her intellectual development. In other words, sometimes a "practical" (i.e. efficient, sufficiently abstract) interface isn't what you want.

This is partly symptomatic of Slashdot's demographic, and also a byproduct of the sort of hype associated with digital media departments, and the kind of language they have to construct in order to attract funding. Mega-nerds don't usually think of technology except in the abstract and functional, and tend to regard inefficient or unusual interaction systems as a waste of time and resources (why would I want to stand there flailing my arms in the air when I could just write a shell script?). Academics tend to use overblown language to justify their work â" blanket statements about the way new digital technologies are "forever changing our world" are commonplace. Somewhere in between is the realization that we ought not only to rethink our one-size-fits-all perspective on technology, but that we should also keep in mind the way new technologies affect the meaning of interaction.