This total disregard for platform conventions does your users a disservice by making moot the effort they've spent learning how the platform operates and what to expect from UI elements and interactions.
On top of that, you have to reinvent all the native components you otherwise would get for free, and your app looks like an ugly odd duckling on the platform.
Why do this? It demonstrates an insane level of condension towards your users, the platform they've chosen, and the time they've spent learning it.
Disregard this feedback. Do you know how to use a blue pencil instead of the standard yellow? I thought so. These controls maintain the overall look and feel of the native components while just giving them a different skin. Sheesh, even Apple recognized that developers wanted to give their own look to controls by giving them Appearance hooks.
You know what else you get by coding your own UI components that mimic native components? A greater knowledge of the underlying platform. Even if you and everyone else hates the end results, the creator has increased his knowledge, which is more valuable than your troll.
Disregard this fellow's feedback, since he clearly has disregarded the platform users and the shared conventions of the platform community.
These elements don't maintain the look and feel of the components at all. They're roughly in the same place, most of the time, and that's about all you can say for them:
> Sheesh, even Apple recognized that developers wanted to give their own look to controls by giving them Appearance hooks.
Yes, which you can use without breaking users' expectations, because they still look like they belong. They truly are re-penciling, not a rework of the UI to look like Windows Phone.
> They're roughly in the same place, most of the time, and that's about all you can say for them
> a rework of the UI to look like Windows Phone
I am laughing at this comment in particular only because most of the project uses the APIs provided by Apple to change the appearance on existing controls, exceptions being the switch and the alert view.
The project only makes it easy to generate and integrate flat images into these controls. You make it sound like he is rewriting UIKit.
> The project only makes it easy to generate and integrate flat images into these controls. You make it sound like he is rewriting UIKit.
What does 'native UI element' mean if you're swapping out all the bitmaps and completely changing the visual language, and ALL UIKit elements must be significantly modified to fit into your new language?
It definitely doesn't render what users have learned moot. Back buttons will still be in the top left. Actions items on the top right. Title bars will be at the top, with centered text. Tab bars will be at the bottom. Sliders will still function by sliding. Buttons will still function by pressing them.
Yes, there's a slight difference, but I think you're making a mountain out of a molehill here.
If the approach propagates because community norms fail, then a bad UI (and another, and another) may result in the shared investment in common platform conventions being lost.
That's one of the worst analogies that I've ever read. This is a piece of functional, well written code, that you may not like but it in no way is going to be harmful to the developers not the end users. If it's not good less people will use it because users will not like the UI.
>This total disregard for platform conventions does your users a disservice by making moot the effort they've spent learning how the platform operates and what to expect from UI elements and interactions.
I call BS.
Does Letterpress also exhibit a "total disregard for platform conventions"? Does Google Maps iOS app? Does Clear (the TODO app)? Does Paper? Even if so, the users are more than happy with them, and tons of other similar apps besides.
It's not 1993 and this is not Mac Word 6.0. In iOS apps are MEANT to be visually distinct and try new interaction paradigms.
Heck, even Apple has stopped advocating the blind devotion to the User Interface Guidelines document, and experiments itself with different looks (and sometimes feel) from app to app. And this has been going on for at least 5 years.
Besides, this project merely adds new visual look. Underneath it uses the regular widgets (it adds Obj-C categories to change the visual appearance), so it's just a new "theme", not a new "feel".
>On top of that, you have to reinvent all the native components you otherwise would get for free
Errr, that's kind of the whole point.
>and your app looks like an ugly odd duckling on the platform.
Or like a special unique snowflake. Like Clear. Or Paper. Or tons of other apps.
>Why do this? It demonstrates an insane level of condension towards your users, the platform they've chosen, and the time they've spent learning it.
I only discern an insane level of pissing on others people work, that they also provide for free as open source and you can very much choose not to use it or not buy any app that uses it. That, and an insane level of self-righteousness (on this response, not on the project).
Flat UI has become a common theme on a number of popular iOS apps. Spotify, Yelp, Truila, Google Maps etc. have all moved to flat UI recently... are all of those apps "disregarding platform conventions?" Of course not.
If anything, they have made flat UI a convention in itself, just like pull-down-to-refresh, large center tab buttons and slide-right navigation weren't originally/aren't native widgets, but have become commonplace.
The rumor is that iOS 7 is going to change to a flatter appearance anyway, so in a few weeks this all might be moot.
I don't use the others, but I often get confused using Google Maps because I have no idea what all the new/unusual UI elements do.
Once I learn Google Maps' way of doing things, I don't want to have to learn a new way for every other app, too.
More to the point, I'd rather not have to learn how to use Google Maps' nonstandard UI to begin with.
> The rumor is that iOS 7 is going to change to a flatter appearance anyway, so in a few weeks this all might be moot.
That's a good point, because the way Apple rolls out incremental UI tweaks is by changing the standard components in backwards-compatible ways.
If you roll your own components, you have to work harder to keep up.
I would emphasize the word "incremental". If you examine the progression of Mac OS X across the past decade, there are significant changes, but they were done cleanly and incrementally and in a way that was immediate familiar to existing users.
I do not believe that we'll see iOS 7 pick up 'flat design' as defined here.
While this comment was pretty strongly worded, I think the ideas of "use native components whenever you can" and "don't reinvent what you don't have to" are usually good ones to follow. This project certainly has use in some circumstances (like the author's, for example) but I think it's important that any potential users also consider the above.
Flat UI isn't some massive new UI paradigm? I thought that's exactly what it is.
> ... it's effectively a theme!
One of the major components of the success and pleasantness of iOS -- and Mac OS X before it -- has been platform consistency.
Apple has made a study of this, and that's part of what users are buying when they buy Apple's products. Dismantling that consistency (rather than, say, building on it) is detrimental to your user's experience and the cumulative value of both the user's purchase and training, as well as other developer's investment in furthering the platform.
There certainly can be a fine line between building on the platform standards and dismantling them, but rewriting all UI components is very much on the side of "dismantling".
>Flat UI isn't some massive new UI paradigm? I thought that's exactly what it is.
Then you were wrong.
Flat UI is merely a graphic design choice. If affects the look and overall design of the user interface (flat colors, no drop shadows, remove frills, etc).
Everything you otherwise know about the UI and how it works remains the same. Buttons are still buttons, text entry boxes behave as before, radio buttons still let you choose one option, sliders slide, etc etc. You can have a flat UI in Gnome, say, just buy changing the GTK theme to use a flat UI design. Nothing "massive new UI paradigm" about it.
CLI to GUI is a "massive new UI paradigm". GUI to Touch GUI is a "massive new UI paradigm". 3D (if somebody implements it in any way that makes sense) would be a "massive new UI paradigm".
Flat UI is merely a theme change -- plus the adoption of a less ornamental design sensibility. The apps still behave and interact the same. You just don't get corinthian lever, faux-wood bookshelves and old Braun tape machines.
>There certainly can be a fine line between building on the platform standards and dismantling them, but rewriting all UI components is very much on the side of "dismantling".
Like Apple Pro apps vs regular Apple OS X apps, right? Since they do have ALL the UI components changed. Or like iBooks vs standard iOS look. And tons of other cases where Apple did the same.
>Buttons are still buttons, text entry boxes behave as before, radio buttons still let you choose one option, sliders slide, etc etc.
They might be, if I can figure out which flat rectangle out of the dozens presented to me is a button or a dropdown or whatever. Say what you will about minimalism and removing unnecessary ornaments, but it is NOT cool to remove visual cues for interaction.
At least the buttons here have shadows underneath that give some sense of depth. But at this rate, we'll be throwing decades worth of UX design out with the bathwater if designers blindly follow <graphic-design-trend-of-the-year>.
None of the top apps look like this, because this is a new app, and the theme has just been released.
But you didn't rant against THIS specific theme and how it looks. You ranted against theming iOS, period. You said it's a disservice to the users, users don't like it, etc.
So, answer me and the parent this: is that's so, why tons of top selling and downloaded apps, the most popular ones by users and critics, are heavily themed? Letterpress, Clear, Paper, Google Maps, Evernote, iA Writer, Vine, Flipboard, etc etc.
The platform has defined conventions. There's a set of Human Interface Guidelines, and those guidelines prescribe what UI elements to use where.
There is also set of standard user expectations, and a general design culture that ties the platform together for its users.
On top of this is the massive investment that Apple has made in educating users of what to expect from the platform -- an investment that is further strengthened each time a user uses an app that follows the expected conventions.
Further, users buy their phones for this cohesive platform experience. If they wanted flat UI, they could buy a Windows Phone. They haven't.
So yes, forcing a completely non-standard UI on users, and promoting its use on the platform, is condescending and honestly hostile to the health and cohesion and shared value of the platform.
Yeah, he should definitely be burned at the stake for not following the mighty HIG. And releasing the code, what an outrage! Now other developers will fall victim to this ignominous tendency of innovation!
Or, perhaps, the standing community can help enforce community and platform norms, as we're apt to do, by explaining what those norms are, and why.
And then, perhaps, we will preserve one of the things that has made iOS, and Mac OS X before it, such a pleasant platform to use: platform consistency.
He and his partner, John David Eisenberg, wrote Apple Presents...Apple, the disk that taught new Apple II owners how to use the computer. This disk became a self-fulfilling prophesy: At the time of its authoring, there was no standard Apple II interface. Because new owners were all being taught Tog and David's interface, developers soon began writing to it, aided by Tog's Apple Human Interface Guidelines, and reinforced by AppleWorks, a suite of productivity applications for the Apple II into which Tog had also incorporated the same interface.
And thus interface standardization was born, out of the cumulative, compounding benefit of fulfilled user expectation.
As developers, it's our job to be the wizards behind the curtain. The users are the star of the show, not us, or our egos.
I've never wished HN had a "Ban Button" before today. He released something that represents a lot of work on his part and you come in here and shit on it. If you don't like it you move along, you don't wage a holy war of negative comments.
So your suggestion for propagating 35 years of community norms that have made Mac OS, Mac OS X and iOS successful is to not say anything when newcomers ignore those norms?
1) be less rude in your pissing on other people's work they offer for free.
2) Wake up and smell the HIG-is-obsolete coffee, the HIG has been not important for the most successful apps for years, and even Apple has toned down their insistence on it half a decade or so ago, including making tons of apps with different looks and even feel (from the iTunes vertical close buttons, to Dashboard widgets, to the totally different Pro apps Look and Feel ever since 2007 or so, to the App Store UI, to numerous other examples all around).
Gruber (an old fierce supporter of the HIG back in the day) has written about this:
On top of that, you have to reinvent all the native components you otherwise would get for free, and your app looks like an ugly odd duckling on the platform.
Why do this? It demonstrates an insane level of condension towards your users, the platform they've chosen, and the time they've spent learning it.