I think the visual explanation here offers credence to the criticism. This certainly isn't "hipster" culture - this is design critique.
The worse thing would be if people blindly said things like "iOS7 is just not intuitive" and went on to drink their PBR and evangelize about Phonebloks - instead, these are real examples of why iOS7 could be better.
At the very least, this thread is instructive for learning designers. I know as a younger programmer and designer, when someone said that "JavaScript has the weirdest quirks", it was useless unless someone showed me the quirks. Along came Douglas Crockford's Good Parts, which, while critical of the bad parts, was very instructive. I think this can function in similar ways.
It's not just "Fail" culture rearing its stupid head - the tone is far from embarrassing to Apple, and instead is generally descriptive of legitimate design failures.
The number of obvious bugs [1] included lends a lot of weight to the impression of it being more about sniping than criticism.
[1] z-index, text overlap, mixed states, etc.
These are not questionable design choices. They're bugs. And lumping them in only detracts from the site and the many legit design gripes (problems of focus, alignment, contrast, usability, etc.)
Are bugs in the UI not themselves part of the UI? If their goal is point out "sloppiness" in the UI, why should obvious or slightly less-obvious bugs be excluded?
Because it's very likely that anything that would be seen as a "bug" will be fixed in updates; whereas things that are the result of intentional (bad) design, like lack of information hierarchy, probably won't be fixed, because they won't be seen as incorrect. (Which is, nominally, what this tumblr would be for pointing out.)
I don't think I agree with your last sentence, which seems to be the issue. The site isn't called "The Terrible Design Decisions of iOS7", it called "Sloppy UI" which I think covers both bugs and UI. Further, sometimes it can be hard to differentiate between a bug and a design decision, so I think it's hard to ask them to just stick to one or the other. May as well point out everything you see that isn't up to standards, be those design or implementation.
To me, the Tumblr is pointing out an overall lack of attention to detail. Some of these obvious bugs should have never made it past QA/testing, but somehow they did - and that's sloppy UI, regardless of whether it was an intentional "do that" directive.
I understand what you're saying, and perhaps the name of the Tumblr should change to "Issues with iOS7", but that sounds pretty boring to me. Instead, we can all agree that sloppy/bad decision-making, sloppy QA practices, etcetera can be learned from, and that there is value in identifying (and avoiding) these mistakes both in the works of others and in our own work.
I'm with 'roc' on this one. Including a bunch of obvious bugs tells me that you either a) can't distinguish between design and implementation or b) are more interested in shitting on other people's work than saying anything useful.
This is fail culture masquerading as design critique, and it isn't even doing that well.
Critique doesn't always explain reproduction. That's more like a bug report I think. Actually saying what's wrong is describing that the UI has a clear problem with z-index. I would understand if someone was trolling the Apple bug submission process, but they aren't; they are pointing out flaws with clear visual examples.
I disagree that critique must inherently describe the problem. Sometimes, the problem is fairly self descriptive, especially with what this blog provides, which is obvious issues that most of the blog's audience will immediately understand as "sloppy" - that is, I shouldn't have to explain why the z-index issue is sloppy to justify my criticism, but if you want a bug report, I can explain how I got there.
The worse thing would be if people blindly said things like "iOS7 is just not intuitive" and went on to drink their PBR and evangelize about Phonebloks - instead, these are real examples of why iOS7 could be better.
At the very least, this thread is instructive for learning designers. I know as a younger programmer and designer, when someone said that "JavaScript has the weirdest quirks", it was useless unless someone showed me the quirks. Along came Douglas Crockford's Good Parts, which, while critical of the bad parts, was very instructive. I think this can function in similar ways.
It's not just "Fail" culture rearing its stupid head - the tone is far from embarrassing to Apple, and instead is generally descriptive of legitimate design failures.