# 正面冲撞习惯 \ 每隔一段时间 Apple 总能“发明”一个让人要捂脸的词语，通过发布会或介绍视频，比如 iPhone 5c 发布时的“Unapologetically”，去年的 iPhone 7 发布会上在解释为什么去掉 3.5mm 耳机孔时，使用了“Courage”这个词。Phil Schiller 在发布会上说 Apple 去掉传统耳机孔的理由可以归结到“勇气”这一个词，迈向未来和做一些让我们所有人都会受益的事情的勇气。“勇气”这个词一出，就像是一个炸弹扔到了正在看直播的人群中，人们纷纷在 Twitter 上[晒出](https://www.theverge.com/2016/9/7/12838024/apple-iphone-7-plus-headphone-jack-removal-courage) Apple 那些具有“勇气”的设计来回应，需要翻身才能充电的 Magic Mouse 2，插在 iPad Pro 上充电的 Apple Pencil，各种转接头，等等。做出这些设计可能是需要一些勇气，因为设计师能预计到大众对这些设计的反应，工业设计也同 Logo 设计一样，设计评论成了一种群体性的观赏体育运动（[Spectator Sport](http://designobserver.com/feature/graphic-design-criticism-as-a-spectator-sport/37607/)），每一个人都有他自己的意见。 ![Apple Health Icon](http://www.hi-id.com/atcl/2017/Apple-Health-Icon-0620.png) 这些观众在看到设计后就立刻表达自己的评论意见，如果错过这个时间点评论将失去意义了，作出评论的速度之快就像是，在这些观众眼里，设计师完成这个设计也是刹那之间的事。如果设计是刹那之间完成的事，没有反复辩论和验证，任意草率地作出决定，那就只是鲁莽而不是勇气了。 勇气是指挑战习俗和规矩的决心，习俗和规矩的一部分就蕴含在那些观众的即时评论之中，除了极少数是为了挑战而挑战之外，对习俗和规矩作出了挑战说明已经对其进行了批判性的思考。有些挑战的作出是显而易见的，比如 3.5mm 的耳机接口将会消失，甚至是耳机物理接口的消失，似乎没有人会反对未来是这样的，那么勇气就在于当前的时间段是否合适；有些挑战的缘由是能理解的，比如新一代的 MacBook Pro 的 Touch Bar 设计的一个主要缘由是原先占据此位置的功能键有着极少的使用率，那么勇气就在于新的设计是否维持原先的一体性，并且能否说服用户这不是替代而是一种升级并且能够预示未来；而有点挑战则是超出用户当前认知范围但又认定是未来的正确方向，甚至与其习惯背道而驰的，而且用户需要一定的接受和适应的时间，因此，甚至会激怒一定的用户群体。因科技带来的更新而作出的改变是容易被理解和接受的，而因审美范式作出的改变往往需要经受时间的考验，其中有的可能顶不住第一波的反作力的抵制而被收回。 无疑四年前发布的 iOS 7 是最具勇气的一个设计，尽管在其发布前人们已经讨论所谓“扁平化”设计很久了，随着当时不停的传言 iOS 将走向扁平化，似乎将潮流的趋势推向了后来 iOS 将去的方向（也可以将这看作是试水民意的一种策略）。当时已经有扁平化的设计了，而且不少设计师也作出了一些概念设计，这些概念设计是当时的熟悉的扁平化风格设计。没有人知道 Apple 会是怎样的设计，而当 iOS 7 发布时，我想几乎所有人，至少第一刻，无论是所谓的果粉还是果黑，还是一般人，像是被利剑刺中了，每个人都需要一些时间来治疗伤口。四年后去回看发展历程，同前 iOS 7 时代比较，同那些所谓“扁平化”设计作比较，以及同当下其他移动设备操作系统的界面设计去比较，无法否认 iOS 7 革新是 Apple 勇气的最佳代表。 如果去细读 iOS 7 的设计，当时给我冲击最大的就是大量的官方应用图标使用了纯白色背景，iOS 11 有更多的图标使用的纯白背景。现在回头去看，这是最让我感到佩服的一个具体设计，我现在很喜欢这些白色背景的应用图标设计。而四年前，第一眼看到这些白色的图标，一种感觉是似乎它触犯了某种天条，另一种感觉是难道 Apple 的设计师这么草率，加上后来[媒体报道](https://www.macrumors.com/2013/06/12/jony-ive-put-apples-marketing-team-in-charge-of-ios-7-icon-design/)说 Jony Ive 启用的市场部门来负责 iOS 的设计（实际上准确说法是 Alan Dye 的平面设计部门），像是摇摇欲坠却又被扶上马的感觉。 这个被触犯的“天条”是什么？就是四年后的今天，在其他移动设备的操作系统上很少能看到纯白色背景的系统应用图标，第三方的应用图标有一些是白色背景是为了同 iOS 版维持一致，为什么这些系统没有跟进呢？天条就是习惯和规则，Apple 的 [Human Interface Guidelines](https://developer.apple.com/ios/human-interface-guidelines/graphics/app-icon/) 也会给出指引规则，但这些规则是基于经过争辩后的理性之上的，而被 iOS 7 应用图标的白色背景所触犯的“天条”是视觉经验形成的审美习惯，它是累积而成的，并没有经过争辩的。白色背景是我们认为 Apple 设计师草率的一个原因，白色在我们看来是空白的背景，空出的未经设计的，尤其是在前 iOS 7 时代的图标设计强调背景具有一定的丰富性，而在我们通常印象中，如果一个图标的背景是黑色还好一点，因为我们有时不会把白色看作是一种颜色。如果将白色看作是同其他颜色具有一样的地位，它在喻示是一种空白之外，先是一种可以拿来填充的颜色，那么这些白色背景的图标就稍稍可以理解一点了。正因为白色具有空白和颜色两种表现力，在 iOS 的系统图标中，白色背景是使用最多的一种颜色，它带来了丰富的“[图–底](https://en.wikipedia.org/wiki/Figure%E2%80%93ground_\(perception\))”视觉体验。 前 iOS 7 时代的图标设计用丰富来表现，图标除了指向作用外，本身也是可品味的，而这种品味像是食用美食一般。一旦追求表现力的丰富，圆角四边形就成了一种限制，面积上的限制，可以看到那一时期的第三方应用的图标设计，就像想方设法同轮廓作物理上的抗争。这些图标有欣赏品味咂嘴的乐趣，但是明显它的实际功用，以及蕴含在实际功用中的审美乐趣就被占用了，Paul Rand 说过好的 Logo 能够提供识别的快乐和意义的承诺（“the pleasure of recognition and the promise of meaning ”），而在那些拟物的图标上，这两项都会被图标的精致刻画给覆盖了。 iOS 7 提供了一个光滑连续的圆角图标，以及图标的网格系统指引，这让白色在图标上的表现力被解放了，可以比较一下那些没有作图标外轮廓统一的 Android 系统，或者作了外轮廓统一但是几何形态设计不考究的 Android 系统，白色在其上就失去了表现力，试想在一个不够饱满没有张力而且识别力差的外轮廓下去使用白色，将会是多一重干扰。如果将 iOS 的图标的外轮廓的圆角变小，比如接近正方形，那么白色部分就会脱离开来，就像是一个现成的彩色图标放在一个白色方块之上；同样如果在目前的白色背景上放一个更加写实的图标，白色背景也将独立而出成为一块底板；如果所有的图标都采用白色背景，那么这些图标也会被看成是一个彩色的图标放在一个统一的白色底板之上。或许使用白色背景的图标设计最忌讳的就是被看成一个彩色图标放在白色底板之上，也就只有双层的叠加关系，而没有同一平面上的“图–底”关系。在这些白色背景的图标中，设计最安全的一种就是具有圆形外轮廓的比如 Safari 和 Photos，另外一种就是像 Music 和 Calendar 这种让白色作为颜色来表现的，而像 Health 的这个图标则通过偏移加强了视觉，并且还可以通过位置带来的寓意，带来的“识别的快乐和意义的承诺”。 规则并不是坏事，就像 iOS 7 的白色背景图标如果失去一些规则的支撑，它将成为仅仅只为冲击习惯和打破规则的混乱产物。Michael Bierut 在[他的一篇文章](http://designobserver.com/article.php?id=24558)中介绍了他进入 Vignelli Associates 工作受到约束的那些规则，诸如“任何项目都不能超过两种字体”，“即使是信笺和名片设计，也要从模数网格开始”等等，并且展开说是如何得益于这些不成文的则的限制，在离开 Vignelli Associates 时他感觉终于可以摆脱这些规则的束缚，经过一段“痛苦”自我放纵时期后又认识到那些规则的价值，直到经过设计师 Tibor Kalman 的点醒，意识到你是无法完全逃脱那些塑造你成长的规矩的影响的，窍门是，每隔一段时间，“fuck them up a little”。 然而，除了这些促进成长的规则之外，还有很多来自各个方向的规则，它们都会影响我们，影响设计，有些规则是可以辨明的，有些规则或许就是莫须有的，不成文的，或许就是[习惯](http://www.hi-id.com/?p=2910)，习惯总是充满陷阱，尤其在思考和批判力涣散或丧失时，它会吞噬一切，所以靠着“fuck them up a little”是隔靴搔痒的，唯有直接正面冲撞。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://blog.jasonzhang.cc/read/apple/zheng-mian-chong-zhuang-xi-guan.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.