I'm going to say something that many won't like, but I feel very strongly about it.
--
Please stop wasting time on pretentious designer bullshit like this. Skinning is great for in-game HUDs, but making a regular repeated-use app look completely alien against native look and feel is one of the worst things one can do.
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.
Thanks for sharing. Can you talk a bit about your decision to lean on categories so much? I'd personally prefer to see a few more base clases and DRY it up a bit. EDIT: And maybe everything inside a single header to include?
Great question. For classes with sufficiently rich customization options (UISlider, UIStepper, UIBarButtonItem, etc) I don't think it's necessary to provide a full-on subclass, as ultimately I'm not really changing what the class does. I'm really just providing a mixin for a particular set of UI customizations (setting colors, etc), which categories are perfect for.
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.
A feature request, localize the switch. I think if the language is english, you get 'ON'/'OFF', otherwise just just |/O. Unfortunately unicode doesn't have these glyphs, but they are pretty simple to CG draw.
Hey Mason, appreciate the feedback. Actually, all of those bugs are fixed in the 1.1 release which came out on Friday night. So just update and you'll be all set!
One of the interesting pull requests that came out of https://github.com/domesticcatsoftware/DCRoundSwitch was to support accessibilityValue . I for one would like to make a request for it. DCRoundSwitch was my first introduction to the power of the Core Graphics layer. I now believe that you can draw almost anything instead of heavy reliance on design images. Best.
That's a really good observation re: accessibility, and something that had totally slipped my mind. I'll add accessibility support for FUISwitch and FUIAlertView in the next release (everything else, being a subclass/category of existing UIKit stuff, should have it already).
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).
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:
Thanks! It feels good to get this out there - we want (and plan) to open-source more stuff but have been so busy that we haven't had the time. Deliberately writing this to be open-sourced also made me a lot more considerate when developing it and improved the code quality as a result.
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.
Great work! This is a really cool project. I actually did something like this in an app I am working on using the same approach. I knew it could be generalized to all UI components and not just buttons, but I did not take those further steps and implement it.
This is definitely a step above using drawRect: to draw custom views, when images are more efficient in this case thanks to UIControl.
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.