iPhone 6 / 6 Plus 出现后,如何改进工作流以实现一份设计稿支持多个尺寸?

移动app开发中多种设备尺寸适配问题,过去只属于 Android阵营的头疼事儿,只是很多设计师选择性地忽视android适配问题,只出一套iOS平台设计稿。随着苹果发布两种新尺寸的大屏 iPhone 6,iOS平台尺寸适配问题终于还是来了,移动设计全面进入“杂屏”时代。看看下面三款iPhone尺寸和分辨率数据就知道屏幕有多杂了。
e3e2ae47eb391693752d6d73f60b8eb0_r.jpg

加上Android生态中纷繁复杂的各种奇葩尺寸,现在APP设计开发必须考虑适配大、中、小三种屏幕。所以如何做到交付一套设计稿解决适配大中小三屏的问题?设计和开发之间采用什么协作模式?一个基本思路是:

1、选择一种尺寸作为设计和开发基准;

2、定义一套适配规则,自动适配剩下两种尺寸;

3、特殊适配效果给出设计效果。
手机淘宝的iPhone 6/iPhone 6 Plus适配版本即将提交App store审核。先晒一下我们采用的协作模式,再慢慢说明原委。
62dd57dee9f859151b8ea6a939968a53_r.jpg
第一步,视觉设计阶段,设计师按宽度750px(iPhone 6)做设计稿,除图片外所有设计元素用矢量路径来做。设计定稿后在750px的设计稿上做标注,输出标注图。同时等比放大1.5倍生成宽度1125px的设计稿,在1125px的稿子里切图。
第二步,输出两个交付物给开发工程师:一个是程序用到的@3x切图资源,另一个是宽度750px的设计标注图。
第三步,开发工程师拿到750px标注图和@3x切图资源,完成iPhone 6(375pt)的界面开发。此阶段不能用固定宽度的方式开发界面,得用自动布局(auto layout),方便后续适配到其它尺寸。
第四步,适配调试阶段,基于iPhone 6的界面效果,分别向上向下调试iPhone 6 plus(414pt)和iPhone 5S及以下(320pt)的界面效果。由此完成大中小三屏适配。
为什么选择iPhone 6作为基准尺寸?

当面对大中小三种屏幕需要适配的时候,很容易想到先做好一种屏幕,再去适配剩下两种屏幕。第一个决定是到底以哪种屏幕作为设计和开发的基准尺寸。我们选择中间尺寸的iPhone 6(750px/375pt)作为基准,基于几个原因:
1、从中间尺寸向上和向下适配的时候界面调整的幅度最小。375pt下的设计效果适配到414pt和320pt偏差不会太大。假设以414pt为基准做出很优雅的设计,到320pt可能元素之间比例就不是那么回事了,比如图片和文字之间视觉比例可能失调。
2、 iPhone 6 plus有两种显示模式,标准模式分辨率为1242x2208,放大模式分辨率为1125x2001(即iPhone 6的1.5倍)。可见官方系统里iPhone 6和iPhone 6 plus分辨率之间就存在1.5倍的倍率关系。很多情况下这两种尺寸可以用1.5倍直接等比适配。
3、1242x2208这个奇葩的数值是苹果官方都不愿意公开宣传的一个分辨率,不便于记忆和计算栅格。640x1136虽然是广泛应用的一个分辨率,但是大屏时代依然以小尺寸为设计基准显然不合时宜,设计师会停留在小屏的视角做设计
所以,iPhone6的750x1334是最适合基准尺寸。
只交付一套设计稿,默认用什么规则来适配?

前文提到适配策略是先选择iPhone 6作为基准设计尺寸,然后通过一套适配规则自动适配到另外两种尺寸。这套适配规则总结起来就一句话:文字流式,控件弹性,图片等比缩放。

feffdcc6023e2f17e9000d2e70a34d91_r.jpg

控件弹性指的是,navigation、cell、bar等适配过程中垂直方向上高度不变;水平方向宽度变化时,通过调整元素间距或元素右对齐的方式实现自适应。这样屏幕越大,在垂直方向上可以显示更多内容,发挥大屏幕的优势。
2d10708e03046b24477778c03ea2a853_r.jpg
006b79515d661fd8e5ed9a9fbaec9dff_r.jpg
按 照上述默认适配规则,大中小三种屏幕显示效果均相同。有时候想在大屏幕显示更多内容,需要设计出特殊适配效果。比如App store首页焦点图,从iPhone 6适配到iPhone 6 plus时焦点图尺寸和排版做了特殊处理。底下应用列表也从一排3+个变成一排4+个,真正实现了大屏幕显示更多内容的理念。这些就需要设计师给出相应设 计稿。
896c935642bdac91555d3075ee61e3b8_r.jpg

文章来自《知乎》

原创文章,作者:ioued,如若转载,请注明出处:https://www.iamue.com/1031/

(0)
iouedioued
上一篇 2014-10-27
下一篇 2014-10-28

相关推荐

  • 未来全新的用户界面将重塑设计师的工作【UXRen译#156】

    副标题:图形用户界面更进一步的思考 作者:Paul Boag  |  翻译:文松,校审:林有九   我们目前的生活已经离不开图形用户界面,它萌芽于施乐帕克研究中心(PARC),目前已经成为PC很重要的部分。不光这样,随着网页…

    交互专题 2017-08-07
  • iOS App中数据加载的6种方式

    我们看到的APP,往往有着华丽的启动界面,然后就是漫长的数据加载等待,甚至在无网络的时候,整个处于不可用状态。那么我们怎么处理好界面交互中的加载设计,保证体验无缝衔接,保证用户没有漫长的等待感,而可以轻松自在的享受等待,对加载后的内容有明确的预期呢?今天这篇文章,会介绍6种常见的加载模式设计,和3种减少等待感的具体手法,希望对追求极致体验的产品人有帮助。

    2017-06-02
  • 【面试】不吹牛13,我是如何7天拿到百度&网易&创新工厂等6个实习offer的...

      “不卑不吭,保持谦逊”,这是管静总结的与HR和面试官打交道的八字法典。 又是一个40度的夏天,没有喧闹,只有窗外吱吱的蝉鸣。刚过完大三的同学,都开始了寻找实习的路程,有人欢喜有人愁。就读于贵州一所普…

    交互设计 2015-08-17
  • 百度贴吧体验升级背后的故事,用户洞察与交互升级

    作者:百度UXC随着产品的发展和用户群体的演变,用户对产品的认知也在发生变化,当用户认知和产品形象发生偏差时,体验升级就势在必行了。而用户对产品的认知大概体现在视觉感受(品牌形象)和使用感受(交互操作)上。对此我们从用户出发寻找设计上的突破口。洞察用户让设计有的放矢视觉感受对于大多数人是一种难以言说的东西,难以通过简单的方式得到答案。面对这个问题,我们选择迎难而上,通过精巧的实验、可视化的方式来解决,邀请用户与设计师一起,参与到品牌升级...

    2018-01-30
  • 行云流水般的交互体验:当智能头机邂逅百度音乐

    音乐,作为一直延续的人类共有的精神食粮。从爱迪生发明第一部留声机到后来的黑胶唱片、再到磁带、CD、MP3经历了整整140年,储存和传输音乐的介质从磁性变成了光学;储存歌曲的数量越来越多,体积也越来越小。但是笔者有一个长期被困扰的问题:作为运动爱好者和音乐发烧友,在跑步锻炼时常常需要将iPod或者Sony Walkman笨重的机身绑在胳膊上,然后再插上耳机、选歌、调节音量等等至少4、5步操作才能听到想听的歌;还常常因为线头缠绕,越解越乱。...

    2018-01-30
  • 复杂性和用户体验[译]

    每一个交互设计师应该都怀有一颗追求简单的心——轻盈的操作,简易的流程,干净的界面。每每提及复杂性,必然会想到其对立面——简单。所谓简单,就是要去除不必要的干扰,让用户直达目标。优秀的产品关注简约而非复杂…

    交互设计 2015-07-22
  • 浅析设计图表色彩的简单方式

    译者按:对色彩的研究通常要么太过随意缺乏逻辑,要不太过理论化难以理解,这篇文章用非常浅显易懂的方式,讲述了一个专门研究数据可视化的团队探寻图标色彩搭配的历程,给出有力的论证,并得出很棒的结论,非常值得一读。对色盲色弱来不够友好*:原文中问题一的标题是“Low Accessibility”,通常用形容来产品对残障人士的友好度不够,这一点在欧美国家经常作为需要重视的产品硬指标(也是由于他们的色盲色弱发病率比亚洲高很多)。因为在中文里没有简短精准的说法,所以我在写的是“对色盲色弱不够友好”。
    逻辑性较强的人*:原文的写法是“left-brained folks”,直译是左脑型的人。通常左脑型的人被认为逻辑严谨,右脑型的人被认为有艺术天赋。因为这种说法在中文里不是很通用,所以我写的是“逻辑性较强的人”。

    2017-05-01
  • 探讨移动电子商务网站中的图文滚动切换设计

    很多人都会和我说,网站中的滚动切换设计一般都是弊多利少,尽量不要使用。但是,本文会告诉你并非所有情况都是如此。 我写这篇文章就是希望我们能够更多理解网站中的滚动切换设计,不要听信传闻。我将用我们的调查数…

    2015-04-03
  • 交互设计师必备的9种能力(下篇)

    让我们继续来跟着大饼哥来看交互设计师必备的9种能力。

    2017-05-15
  • 译文 | 交互设计的5大支柱

    文中提到的《交互设计最佳实践:卷1》/《用户体验设计文档指南》/《2014年Web UI模式》可在此处下载,建议先保存到网盘~

    2017-05-27