Tag: iOS

简单说说 iOS7 的扁平化UI

万众瞩目之下,iOS7的神秘面纱终于被揭开。坊间关于iOS到底会走向“拟物化”还是“扁平化”的传言,就此也告了一个段落。

自从Jony Ive接管OSX团队来,一只就有传言,说这位工业设计大师将会将极简风格引入新版iOS的UI中,从而取代一直以来都是iOS标志性之一的“拟物化”设计。这个传言并非子虚乌有,从年初Podcast应用中去掉精美的博朗TG 60磁带机的设计元素之后,事情就变得越来越明朗。Dribbble上也开始呈现UI扁平化的设计趋势。

可以毫不夸张的说iOS7的UI是颠覆性的。也正因如此,业界、用户对此褒贬不一。下面具体聊聊我对这套UI的一些看法。

用一句话概括这次UI的设计就是:

扁平而生动的半透明蚀刻片——Jonathan Ive对拟物化设计的诠释

扁平

层叠式的界面

从视觉的直观感受来说,谁都看得出来这次真的是够平的。既然是废话,那我们不妨换一个角度,从视图的操控和切换来看一看。随着移动应用在设计方面越来越多的尝试,人们发现,iOS从早期沿用至今的基本界面导航方式和手势已经无法满足当代应用既要夺人眼球又要操控顺畅的需求了。越来越多的应用采用了在画面上以立体的方式展现层叠效果的UI设计,比如iWeekly的滑动返回。多个视图并不再呈现单调的并排关系,通过对空间关系的隐喻,增强人脑对界面的记忆和认知。

我们看到在iOS7的原生应用和基本操控上大量采用了这种层叠式的界面,而在这个前提下,视觉上呈现扁平的层次能使UI显得更为轻巧,不容易出现厚重感。这一点在不少应用中已经得到验证了。

生动

少了纹理材质,那怎样还原出iOS基因中精美、细致的一面呢?这次Jony Ive给出的答案是生动的特效。天气应用中全屏幕的风云雨雪、Safari中更为立体的Coverflow、Siri中动态显示的声波、手机旋转时UI视角的变化、UI滑出时的反弹震动…… 这些动态特效弥补了不少因纹理缺失带来的粗糙感。事实上,iOS7中还增加了一组名为UI Dynamics的API,使开发人员更为方便、标准地植入视觉特效。

半透明蚀刻片

新的UI中采用了大量模糊滤镜(Blur filter),也就是所谓的“毛玻璃”效果。运用这一特效,既能让UI产生通透的层次感,又能很好地分离前景和背景,清晰地将内容展现出来。

此外,iOS7中,到处都能见到“蚀刻片”的影子,该要素最为集中的地方就是新引入的Control Center,其他很多地方也能见到由细细的线条勾勒出来的各种图标。而Apple对字体也做了调整,并且这中纤细化的设计理念还渗透到了新的HIG里面,相信Apple软件及网站的整体风格也会慢慢朝这个方向演进。

这种纤细的蚀刻线条,其最为直接的观感,就是让UI显得更轻盈。但是我觉得这似乎是Jonathan Ive的个人喜好,因为他是做工业设计的,干这行的一定知道蚀刻片是在制图和建模过程中不可或缺的一种工具。从这一点来说,也许我们并不能说“拟物化”被去除了,只是换了另一种模仿对象而已。

新UI的优点和槽点

优点

  1. 视觉轻盈,色彩丰富,更显时尚气息,深得女性消费者爱戴(别忘了这可是数码设备消费的主力)
  2. Control Center的引入让操控更为简便
  3. 扁平化的设计能在某种程度上减轻跨平台的应用设计压力

槽点

  1. 新的官方应用图标色彩饱和度过高,过于鲜亮,存在感太强,与黑色机身不太搭调(难道说真的要出彩壳了……?)不知是否正式版出来前还会有微调
  2. 对于设计师和开发人员来说,UI动画特效更具挑战,可能会导致大量加班……

总结

尽管褒贬不一,iOS7的新UI仍然展现了UI在设计及开发工程中的推进力。也许正式公布的时候会有个别调整,但整体的基调已定。其实要习惯一个东西往往会比想像来得容易,开发者们先玩起来,等几个,iOS7正式发布的时候,相信应用市场上一定会有不少与新定位相符的产品。

iOS Auto Layout in practice

I’ve made a simple presentation at Tokyo iOS Meetup in Dec. 2012, which covers some basic ideas about utilizing the AutoLayout in iOS application. I found that about 1/3 developers there had already adopted AutoLayout in their projects. As I thought most people would stick to the classic “Spring and Struts” layout system then, the result was surprising to me.

In these slides, the basic idea I want to show is that try to make the layout system work as you want in the very beginning rather than to solve the problems when you see the UI acts oddly.

To achieve this, there is a simple rule called the “Rule of 4”, which means you need just 4 constraints (either created by the IB or yourself) on each view, and you can get the layout system work properly. No matter how powerful the AutoLayout API is, just place constraints as less as possible.

The “Rule of 4” will help you eliminate the ambiguous constraints or unsatisfied layout in most cases.

I’ve shown some common patterns about applying the “Rule of 4”. And I hope these patterns might be useful.

As to which tool do I suggest to use when dealing with layout constraints, I think it quite hard to give an answer. Although I’m a heavy user of IB and IB gives more visible hints, IB is not intelligent enough yet to understand your intention on layout, more over, IB is not literally equal to the API.

Update: Ole has written a blog titled 10 Things You Need To Know About Cocoa Autolayout, which is also a great summary of Cocoa Auto Layout.

A Comment on Remote View Controllers in iOS 6

Ole Begemann has written an blog on Remote View Controllers in iOS 6, which shows Apple has adopted XPC in the sharing service of iOS 6.

As the XPC in iOS is still a private feature, we still have no idea about what will come together with the next major release. At he end of the blog, Ole put some outlooks regarding on XPC in iOS.

Remote view controllers are an exciting new feature for iOS. I sincerely hope that Apple will use this technology in iOS 7 to enhance data sharing and communication between third-party apps without compromising the iOS security model. We need it.

How could this work? Apple could ask developers who want to provide a sharing UI to other apps to include a second executable in their app bundle. This executable would be an XPC service that looks a lot like the MailCompositionService.app we analyzed above. Its main component would be a stand-alone view controller that was able to communicate via XPC and implemented some standard Apple-defined protocols named something like UISharingRemoteHost and UISharingRemoteService.

Apple’s existing UIActivityViewController would then maintain a list of registered sharing services and present these options to the user.

I hope we will see something like this next year.

With the 5-year evolution, iOS has been so powerful than ever before, unfortunately, it still doesn’t support inter-app communication. I think most developer would be very happy to see this being available in iOS.

As my consideration, I agree that the implementation described above is feasible, however, I doubt whether Apple will do this or not.

  1. Technically, XPC is introduced to OS X to help developers break a large App into several building blocks based on their functions. In OS X, the XPC services are privately bundled in their host App. Which means those services are not system-wide (A system-wide service module is something like Microsoft’s COM+), and there is still no way to invoke these services across different Apps.

    Although the XPC services are clearly different to the services on OS X, I believe that Apple will make a few XPC services be able to be invoked by other Apps (probably by wrapping those services into a common framework), but they would not allow any 3rd-party provider to create their own system-wide XPC services. Because it will be very difficult to handle the consistency of the services, especially on a mobile device. What if a service is not upgraded to the latest version? What if there are multiple dependency to different versions of a certain service? It will bring mess as well as benefit.
     
  2. As to the business strategy, Apple is always choosing the partner with great care. Those services which has integrated into the iOS not only benefit the users but also the service provider and of course Apple as well. So, what will make Apple allow any 3rd-party provider to provide system-wide services? I’ve no idea yet.

Anyway, let’s see what we will have in iOS 7.

用Key-Value Observing解耦视图控制器

Implementation with KVO

Follow 在Objective-C中,有一种称为Key-Value Coding(KVC)的机制。简单地讲,就是一组为对象属性命名的规则。符合这个规则的对象,可以使用runtime提供的-valueForKeyPath:和-setValueForKeyPath:方法进行访问。类似Java中的Ja...

Read More.

关于Core Animation工具箱的构想

最近在构思一个用于Mac/iOS开发的工具。感觉比较庞大,脑子里的东西比较混乱,决定先把最初的设想写下来,然后再一步步细化。

问题的由来

这个构思的起因是2011年底前的一个iOS项目。设计MM为了吸引用户,在UI中设计了各种可爱的元素。也差不多在这同时,Path 2登场了。其精致的动画让设计MM意识到动画也是体现UI表现力的重要手段。于是,她就开始设计中增加动画元素。

围绕这这些动画效果,我发现在设计和开发过程中有不少问题:

  • UI设计师如何描述动画
    动画与传统的静态UI不同,单单凭借静态的设计是很难把问题说清楚的。如果采用关键帧的方式去绘制一些分镜头的脚本,会给设计师增加不少工作压力。
  • 开发人员如何实现动画
    在Mac/iOS平台上,实现动画主要靠的是Core Animation框架。然而Core Animation比较底层,因此Apple对其进行了封装,提供了Cocoa Animation以方便开发人员实现动画。但不论在Mac还是iOS上,通过编程方式实现动画效果依然需要大量的代码,而且对于比较复杂的动画,开发人员还是需要直接通过Core Animation操纵CALayer、CAAnimation来实现。在我的项目中,最重的view controller里,居然有80%的代码用于实现动画效果。

于是我意识到,这样的开发是有问题的。理由很简单,设计师所设计的是动画,既然是动画,就不应该是几个分镜,几个关键帧这样的半成品。更不应该等到开发人员将代码写出来,再就具体的效果进行讨论。而开发人员也不应该堆砌大量的代码用于动画,因为同时具有艺术感和代码实现能力的开发人员真的非常少。想要做出高质量的动画,这样的过程没有几个回合是搞不定的。总之一句话:

Does real animator write codes? Definitely NOT!

在设计师和开发人员之间必须有个工具扮演桥梁的角色。类似于Flash上的工作流,设计师能够通过该工具直接做出大部分动画效果,而开发人员则在项目中导入这些预先定义好的动画脚本,并根据需要进行一些优化和微调。

如果存在这样的工具,不仅能有效简化设计师和程序员之间的沟通过程,实现工作职责的更合理分配。更重要的是,它还能使代码变得干净,提升代码和动画的可复用性。 Read More.