一起来给iOS 11找bug: 苹果还是乔布斯时代的细节控吗?

众所周知,前几天苹果在位于苹果公园的Steve Jobs剧院召开了一年一度的新品发布会,正式揭幕了全屏的iPhoneX, 随后又把iOS 11推送给了测试员(Beta Tester)(正式版将于几周后发布)。我一收到iOS 11 GM的推送就立刻更新了我的手机。

 

译者注:什么是Apple Beta版软件计划?

Apple Beta 版软件计划可以让用户试用预发布版软件。针对使用者遇到的质量和可用性问题提供反馈,能帮助苹果甄别和修正问题并进一步完善 Apple 软件。

 

Beta software自从六月的WWWDC大会以来,我就作为Beta Tester给iOS 11的增量更新密集地做测试。拿着4.7英尺的iPhone以及iOS 11 GM,感觉Beta软件还有很多需要改进的地方。作为一个设计师,我忍不住想把自己的使用感受写下来。

 

我写这篇文章的目的是帮助人们认识到许多需要在将来进行改进的细节。

 

这些对于iOS 11需要改进的感觉绝大部分来自于UI和动画(animation)。iOS的UI元素很不协调,将大量不同类型的UI元素混在一起,这些元素看起来很相似,但是却为UX带来不流畅的体验。这种元素的不一致性主要来自于iOS 11中新更新的UI元素,比如说大标题和搜索条。我的看法是,这些新加引入的元素造成了iOS 11上面许多不一致的UI体验。

 

 

Mail.app

 

首先我们看一下iOS 11上面的Mail.app。就像其他的原生apps一样,Mail也引进了带着大标题的导航条。然而,相较于设计指南样本,Mail上面的大标题有多余的左边距。在这里,我们将搜索条作为参考对象。在设计指南样例中,大标题和搜索条相对于屏幕边缘的距离是相同的,但是在Mail.app中,与搜索条相比,大标题很明显往右偏移了一些。


 

 

Watch.app

 

在Watch.app中,搜索条没有遵循建议的风格,并且用另一个不太合适的背景来突出搜索条。在采用iOS 11设计风格的原生apps中,搜索条应该与导航条很自然的匹配上,而不是像Watch.app这样。

 

在Apple公布的使用指南Building Apps for iPhone X中,他们提到了一个同样的例子:


 

左边的WWDC.app是一个违反设计风格的反例,右边的Contacts.app是遵守设计的最佳实践。视频中的评论者宣称:

 

这是我发现的第二个问题。。。。如果我召唤出搜索区域,这就看起来不太对了。我们可以跟Contacts app 列表比较一下。有很多东西都都错了。搜索条的背景颜色和大小都不太对

所以,iOS 11被建议让搜索条和导航条的背景颜色做一下匹配。目前为止Watch.app作为原生app还没有遵守上面的建议。还有,一旦被点击,Watch.app中的搜索条几乎都要“亲上”状态条了,这说明苹果的工程师们实在是有太多东西需要改进了。


Files.app

 

Files.app里面的搜索条也有一些问题。看起来Files.app的工程师们使用了一个非标准的搜索条。从下面的照片中可以看出,与Settings.app中的标准搜索条比起来,Files.app的搜索条更小,字体颜色更浅。

 

APP Store.app

 

iOS 11的App Store经历了一次重设计,看起来有些像Apple Music。然而,App Store的Today键与Apple Music的For You一比较,日期的字体还是不一样,App Store的字体更大。然后Apple Music的“Wednesday”后面跟着一个逗号,App Store中逗号消失了。

 

再次比较两个apps。在搜索页面中,在App Store中触碰“Trending”项目不会触发hover效果,然而在Apple Music中同样的动作会触发一个hover事件来改变项目的背景/前景颜色。在我看来,Apple Music做得更好,原生apps应该在hover反馈上面达成一致,不管是保留还是去掉这个效果。

 

 

除此之外,在细节之处还有各种各样的问题。在APP Store中,打开任何有横幅照片的app,拖动这个页面从屏幕左边到右边小滑一下(但不是完全滑过,这样会退出app页面)在页面恢复之后这个横幅section的渲染会变得很奇怪(render):

 

同时这里也有性能问题,在更新选项上面,向下拉刷新项目的时候这里会有一个很明显的框架下垂(若果你的大标题被往下拉的太多的话)。这个bug你自己可以很容易感受到。

 

Health.app

 

在Health.app中,Today页面和Health Data页面,同样的数据和同样的风格,但是却有不同的宽度。这个问题是iOS 10的遗留问题,但是现在任然未被修复。

 

Today Widget

 

在iOS 11中。有两个方式打开Today Widget,在Home屏幕或者锁屏从左到右轻扫,页面里面的搜索条用不同的方式召唤出来会有不同的行为。当从Home页面被召唤出来时,向下拉Widget page将不会显示搜索条,点击搜索条的时候会缺失出现的动画以及霜冻效果,以及点击取消之后搜索条变宽的动画(虽然变窄有动画)也缺失了。整体的体验很尴尬。

 

Photos.app

 

iOS 11中充满了不恰当的边距,要不然太多,要不谈就是太少。导致感觉这个系统是一个半成品,太多东西需要改进和完成了。

 

在Photos.app的分享选项上面,边距(下图中箭头指的地方)太窄了并且不一致,与其它原生APP中相似页面相比。

 

Settings.app

 

在Settings.app中-->Apple ID小节中,设备列表完全没有与ID节对齐。在iOS 10中还是正常的,在iOS 11中就不行了。

 

Music.app

 

在Apple Music中的连接上面,图片和文字之间的边距实在是太小了。这不应该是设计的决定,因为在桌面macOS上面的iTunes端边距还是正常的。虽然连接不是一个常用的功能,苹果也不应该犯这种低级的UI设计错误。

又是Apple Music,通过Library进入专辑列表之后,点击首字母列表来快速进入以那个字母开头的专辑,你会看到那个首字母所在的小节遮住了专辑封面的一部分。

 

Weather.app

 

iOS 11中的Weather.app也使用较大的字体和较少的余量进行了更新。不过我注意到,iOS 11中的温度文字并不是中心对齐的,而在iOS 10中是对齐的。

 

 

这可能是iOS 11的设计决策。然而在实际使用中,由于不对齐,对于某些数字,对于用户来说,更接近左边缘的文字是非常明显的,但效果并不比iOS 10好。

 

字体问题

 

在我看来,最后和最严重的问题是字体。上述问题可能不会影响正常使用,但下面的问题实际上会影响我们每个人。

 

这是iOS 11 Safari中的PingFang(iOS的默认中文字体)的粗体字体。当我在iOS 11上调试个人网站时,我发现了这个问题。所有的比较都是在iOS 11和iOS 10之间进行的。

 

如上图所示,PingFang实际上是渲染为粗体。伪粗体基本上不使用字体本身提供的字体重量,而是强制地在某些基本字体上增加字体重量。伪粗体是由算法生成的,通常缺乏质量,引起笔画重量和字母跟踪的问题。在屏幕截图中,你可以看到,iOS 11中的伪粗体PingFang在文本之间有更大的间距。

 

经过一些测试,我发现只有当CSS font-family包含“-apple-system”,即使用系统提供的旧金山字体的font-family时才会发生这种情况。一旦我们删除它,系统将会尊重由字体本身提供的字体重量,并且粗体粗体已经消失了。

 

这个问题不仅在Safari中,而且还会影响使用iOS的webkit引擎的所有应用程序来呈现网页,例如微信的内部浏览器和豆瓣。正如你所看到的,豆瓣已经被伪粗体苹方占领,看起来还算不错。

 

 

随机选择一个电影评论文章,你会注意到标题是粗体。通过比较,你还会注意到,粗体字体中的字体间距是有问题的。其实这不只是伪粗体的问题,还波及常规或任何字体的重量,所以你看到“伪Regular”等等。伪 Regular 或许很难从笔画粗细这一角度发觉问题,但通过下图对比,可以发现 iOS 11 中正文的字距也偏大,足以证明这是「伪 Regular」:

 

再欣赏一下伪粗体在微信推送中的表现:

 

 

Safari的这个伪字体问题已经出现在iOS 11 Beta 1中,我在8月初提交了反馈应用程序的错误报告(案号为#3436665)。然而,这仍然是今天的一个问题,可能适用于iOS 11或更高版本。作为排版爱好者,我对此感到非常失望。

 

 

小结

 

近几年,关于 Apple 软件质量下降的讨论不绝于耳。Apple 在生物识别、机器学习、AR 等重大领域大跨步前进,公司规模愈来愈大的同时,似乎失却了过往那种细心雕琢每一个产品细节的心。13 日的发布会上,听着 The Beatles 的歌,听着 Steve 的话,有那么一瞬间,我感到我们好似还身处过去的 good old days。不过今日的 Apple,确实是不同以往了。我无意唱衰 Apple,作为一名生活中充满 Apple 产品的人,Apple 现在仍是我最喜爱及尊敬的科技公司。我只是希望,Apple 不断前进的同时,不要忘记过去他们所珍视的价值。

 

via hackernoon.com

猜你喜欢

转载自gbin1.iteye.com/blog/2394373