Hi ArenMook,
Sometimes the best way to figure out what could use improvement is to have an ui/ux designer tell you what they want... and suddenly you have to implement it somehow. That's happening to me right now, so I'll share some general details of what was required, plus my conclusions about what seemed to be needed.
Firstly, we're doing mobile, so we need something that looks good on many different screen sizes and resolutions. Of course, the first issue was pixel density. As mentioned by others, the proper way to do ui for mobiles is to have a layout that is pixel-perfect at Density Independent Pixel scale, then changes based on density rather than height. This keeps things like nav bars the same size, no matter what device you're on.
After that, I found figuring out how to use anchor / stretch to layout elements in the desired way was a bit clunky. I am happy to hear you are going to try something new. In respect of this, one task I had was to create a bar that stretched across the screen, containing three buttons laid out in a grid. I naturally thought of UIGrid, but the spec was for a fixed pixel space between the three buttons, with the buttons stretching equally to fill the space. UIGrid cannot do this as of now, so I had to do it manually. Therefore, perhaps a grid upgrade is in order? And what about those super awesome grids you find on the net these days that have various sizes of squares, e.g.
www.ted.com? That would be cool.
Next is a gripe: I implemented a scroll view, without softClip, prior to 3.0.6. It worked fine after I looked at the examples for a bit. However, now suddenly in 3.0.6 it broke because there's an automatic change to softClip in Awake. So I went back in and commented it out. But why force softclip on scroll views? Our scroll-view just goes off the sides of the screen.
Also, because of the layout system, I had to write my own UIAnchor subclass called UIAxisAnchor for our scroll view, which anchors in a single axis only. This required changing some of your private methods and fields to protected, which has been mentioned by others. But also, it suggests that the stretch / anchor system is, as stated above, not really sufficient for all use cases.
Speaking of that, the spec for our scroll view was that the elements needed to be a specific number of pixels less wide than the screen width. Again, I couldn't find a way to do this directly with NGUI, so wrote a script that does it in update. Obviously, not super-efficient. Perhaps I will have it do it once on launch, or do a screen-size change event or something. Perhaps NGUI could provide this? Or maybe it already does... who knows?
A final thing I've been asked to do is rounded corners. Easy enough you say! But wait! How about rounded corners on dynamic images downloaded at runtime? Ahaha! Harder. So perhaps, as mentioned by others, some kind of ability to use non-quad meshes, or some other solution to the problem of "masking with alpha".
Okay, that's all for now. As I continue implementing things, perhaps I will encounter more ideas for improvements. If so, will post.
Many thanks,
Nicholas Bellerophon
EDIT: turns out the spec for the scroll-view actually asks it be an infinite loop, including auto-scrolling on a fixed period, with breadcrumbs indicating current location. Looks like I'll be doing a fair bit of work here to turn a standard NGUI scroll view into this "carousel" thing. Hope this is useful.