[redial]

For better or worse, I think he is right. Non-uniformity has been the norm in Apple's apps for a while, Garageband, Aperture, every iTunes release, among others. I believe the majority of third party mac developers used to be pre OS X developers, and because of that they had and incredible amount of respect for the HIG, but now, the (problematic) apps in the Mac App Store are coming from iOS developers, who didn't grow up with the guidelines. A different UI has given them an edge in the iOS App Store, and the are gonna try the same on the mac.

[thwarted]

the (problematic) apps in the Mac App Store are coming from iOS developers, who didn't grow up with the guidelines. A different UI has given them an edge in the iOS App Store, and the are gonna try the same on the mac.

So we can retire the meme that any random iOS app has a more consistent user interface than any random Android app?

Sometimes it takes seeing the apps all next to each other to realize it like http://wellplacedpixels.com/ does (which effectively documents the inconsistency in iOS apps, and this inconsistency being praised ("beautiful software")).

[thmzlt]

What about games? They have inconsistent interfaces in their platforms (and across platforms) and still work well.

I think it has something to do with the input methods. When all you do is to click buttons and fill in forms, it makes sense to have a consistent interface. On the other hand, some iPad apps produce a great experience based on their inconsistent interfaces (as in http://www.algoriddim.com/djay-ipad and http://www.korg.com/ielectribe)

[thwarted]

Games obviously need a UI that is directly related to playing the game. I'm not including games. But these ones seem to be different for the sake of being different:

http://29.media.tumblr.com/tumblr_l9iz9hfWvl1qazfelo1_400.jp...

http://29.media.tumblr.com/tumblr_l9iz9hfWvl1qazfelo1_400.jp...

http://24.media.tumblr.com/tumblr_l26vemSib51qazfelo1_400.pn...

http://24.media.tumblr.com/tumblr_l1illmwHTD1qazfelo1_400.jp...

And there's not really anything wrong with that. But one can't say that they prefer the iPhone vs something else because the apps are more consistent UI-wise and ignore the trend away from consistent user interfaces.

Then, there's something to be said for things like Sally Park, which is effectively a limited function app that doesn't have a lot of complex user interaction. A lot of these kinds of apps are commodity, so the way to differentiate is by the "prettiness" of the UI. And that's too bad in some sense, because I think usability suffers -- but maybe usability doesn't matter because, since they are one-trick pony apps, you spend more time looking at the screen than figuring out which button to hit or learning it (because the functionality is limited, not because the UI/UX is "obvious" or "consistent").

When it comes down to it, many iOS apps are do-one-thing (and hopefully do-it-well) independent apps, mainly because they don't integrate with other apps on the phone. You kind of expect standard widgets (or icons or labels for functions) (even if you think they are "ugly") on Android because of the integration. I have an Android app that adds a Flickr option to all "share via" functions on the entire phone. This isn't a standalone app that needs its own UI, and it would be dumb if it had its own UI as an independent app, partitioned off from the rest of the functionality of the device. It needs to integrate (hopefully smoothly) with everything else. When I select "share via flickr", uploading to flickr shouldn't be significantly difference in experience or widget selection than sharing with a contact, otherwise it would be too jarring. It shouldn't look like I'm going to some place else to do this, it should look like I'm sharing it without having to leave the app I found the thing I wanted to share in.

[microtonal]

Maybe. But if the HIG is not that important anymore, I think that should also imply that Apple should allow for other UI toolkits in its stores, such as Qt.

[reid]

This idea disappoints me. The system-wide Control-Command-D dictionary works in Twitter for Mac: That doesn't work in apps written in almost-facsimiles of Cocoa. That's only one example, but these's always something quirky about these replicas which is never desirable.

[Xuzz]

There's a difference between "ugly attempt at matching the standard controls" and "extending nicely into a different style of UI".

[microtonal]

The average user would not be able to tell the difference between a well-adapting Qt application and a Cocoa application. We have a Qt application for searching treebanks, and when showing it to another Mac user, he replied "nice, you wrote it with Cocoa?".

Twitter's (or the App Store's) deviation from the Mac look and feel, on the other hand is very noticeable. And I am not sure it is proven that we are talking about "extending nicely into a different style of UI". The Twitter UI is plainly confusing (where do you drag this window?) and having the backward/forward buttons next to the window controls is questionable at the very least.

[wtallis]

Did you just show it to the Mac user, or did you let him actually sit down and use it? Qt does a great job of mimicking the look of Cocoa apps, but it doesn't always get the behavior right, and if you're going to behave differently, you ought to warn the user by looking different.

[CrazedGeek]

Do the Mac App Store guidelines actually disallow Qt apps?

If I'm reading this correctly ( http://pastie.org/1236378 ), the only major requirements are that apps don't screw around with the HIG too much, and they don't use "deprecated or optionally installed technologies (e.g., Java, Rosetta)". Admittedly, the only Qt app I recall using on OS X is Last.fm, but that seemed to be mostly HIG-compliant (a couple things felt a tad out of place, but nothing major).