Show HN: FlatUIKit - Flat UI components for iOS
github.com
github.com
--
Some customizations here and there are fine and all successful apps notable for their UI do it to a degree. This is what gives an app its personality and character, but note that it's done through meticulous visual polish and attention to details. On the other hand, if you are running on a device that uses inherently skeuomorphic styling and a specific font, then going all flat, green and Proxima Nova is like walking into a cocktail party in flip-flops and a pirate hat. Sure, it will give some people a chuckle and make everyone notice, but it will also make you look like an eccentric dork. And sure as hell it will make hosts think twice about ever inviting you again.
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.
Yes, there's a slight difference, but I think you're making a mountain out of a molehill here.
It's not quite that simple. If you want to use Netflix, you have to use their terrible webkit-based app. So we all do.
That doesn't mean that everyone would have a better user experience with apps sticking to common platform conventions.
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.
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.
Oh, the horror.
The first Apple HIG was published in 1977 for the original Apple II. It was written by Bruce Tognazzini: http://en.wikipedia.org/wiki/Bruce_Tognazzini#Background
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.
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:
http://daringfireball.net/2011/01/uniformity_vs_individualit...
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.
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:
https://www.joingrouper.com/assets/new_landing/OnboardingScr...
> 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.
> 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.
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?
Just like you waved off similar HN feedback on your Exec app? Right on.
And a handsome one, at that.
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".
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.
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.
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>.
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.
Yes, from the comments here, I can see that you must easily get confused by many things. Door handles, the pavement, etc.
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).
I couldn't find an email address in your profile or website. So, on a separate note... I've run into a couple bugs on y'alls app.
<List of things apparently fixed in latest update>
Oops!
I'm using CoreGraphics for a lot of stuff here, just not actually in the controls' drawRect methods. Rather, I use CoreGraphics to produce UIImages of various sizes/shapes/colors and then use the appearance methods provided by each UIControl (e.g. setBackgroundImage) to style existing UIKit controls with said image. So there aren't any external images included in the project. I prefer this approach, as it minimally interferes with each control's existing/desired behavior (not to feed the trolls, but one of the weaknesses in the "Apple wouldn't approve of this" argument presented elsewhere in the comments is that I'm almost entirely just using existing classes/appearance customization APIs provided by UIKit).
Some classes (UIAlertView and UISwitch, most particularly) aren't very flexible in terms of appearance customization, so I had to reimplement them to achieve desired effects. Using them is more difficult: to use an FUISwitch (my UISwitch clone) you have to replace any UISwitches in your app with FUISwitches (also, if you were using categories/subclasses of UISwitch to do some custom stuff, they would break).
Moving logic to a base class isn't really possible, as most of those classes already inherit from UIControl (and I'm not crazy/motivated enough to reimplement them all from scratch - UIKit is awesome, and I want to lean on it as much as possible).
The single header totally makes sense, I'll be sure to add that.
TL;DR: UIKit is great, I don't want to reinvent the wheel, categories are really easy to integrate into existing projects.
I personally had to fork the DCRoundSwitch project to make it more FlatUI like. I am glad there are other efforts out there to help grow this component set.
This is definitely a step above using drawRect: to draw custom views, when images are more efficient in this case thanks to UIControl.