App设计中的基础规范

不符合设计规范的设计很难被用户接受,也会极大地增加开发难度。界面设计严格按照规范来执行,是对用户体验设计师的基本要求。

该部分学习笔记摘自《规律与逻辑》。

App基础布局规范

进行界面设计的第一步是了解市面上手机尺寸的规范和分辨率。但是市面上手机尺寸繁多,尺寸不尽相同。针对每一种机型都设计一套显示方案显然是不合理的,所以我们需要去了解不同手机屏幕之间的差距,还要找出之间的共性,同时应该学习布局中的理论规范。

显示理论基础

首先引入单位dpi,dpi是dots per inch的缩写。原用于表示打印机每英寸(约2.54cm)能打印的墨点数。这个数值越高,打印出来的东西就越清晰,当dpi高到一定程度时,人眼将无法感受到墨点的存在,看到的图片就会越来越清楚。

然后引入单位ppi,ppi是pixels per inch的缩写。表示每英寸可以容纳多少个像素点。类似打印机打印图像,屏幕显示图像使用的是许许多多的发光点。对于屏幕来说,ppi用于描述发光点的密度,也就是单位面积下发光点的数量。一般我们将屏幕上的一个发光点称作是一个像素。ppi可以认为是一个物理单位,因为一块屏幕在出厂时,其尺寸和像素点的数量就已经是确定的。

以iPhone8为例,其手机屏幕宽度约为5.8cm,高度约为10.4cm,屏幕大小为4.7英寸(可根据勾股定理计算得出),像素尺寸为1334px×750px,也就是说每行可以容纳750个发光点,每列可以容纳1334个发光点。其实,1334px×750px也是iPhone6,iPhone7的屏幕分辨率。根据苹果提供的参数信息,iPhone8的ppi值为326,也就是说,在iPhone8中,每英寸(对角面积)可以容纳326个像素点。

我们应该避免询问“一个像素是多大”这种问题,因为像素点的大小通常是不确定的。虽然像素的显示要基于物理上的屏幕发光点,但是脱离了物理屏幕这个大前提,讨论像素就没有了大小可言。比如iPhone8 Plus,其屏幕像素尺寸为1920px×1080px,而常见的笔记本电脑屏幕像素尺寸也是1920px×1080px,iPhone8 Plus的屏幕再大也不会有笔记本屏幕的尺寸大,所以即使像素尺寸一样,其物理大小也是不一样的。

基于上述讨论,可以知道,如果在设计界面时,只关注屏幕尺寸通常是不合理的。而通过屏幕尺寸和像素尺寸计算出的ppi值才是真正需要关注的数据。ppi的计算公式如下:

其中,x为屏幕的长度像素数,y为屏幕的宽度像素数,z代表屏幕尺寸。以iPhone8为例,x=750px,y=1334px,z=4.7inch,代入公式可以计算出ppi约为325.61,四舍五入后得到ppi值为326,与上方讨论得到的数据一致。

同时根据ppi公式还可以反推出,在同样屏幕尺寸(即z不变)的情况下,一条同为长x像素的线条,在不同ppi值的显示下,显示展现出的长度并不相同。比如在iPhone8中,显示一条326px的线,由于iPhone8的ppi值为326,这条线的显示长度为1inch。假设将iPhone8的ppi值降低一半,到达163ppi,那么326px的线将显示为2inch。这是因为163ppi的屏幕每inch只有163像素,所以在显示326像素的内容时需要多花一倍的长度。

逻辑大小与像素大小

这里暂且定义逻辑大小为人对物体真实大小的认知。人的视觉对于对象尺寸的判断是根据逻辑大小来决定的,以一本书为例,无论这本书离我们有多远,在我们的认知中,书的大小“就是那么大”,不会因为我离着这本书很远而感觉这本书“实际变小了”,这是不符合现实的,我们只会感觉“看起来变小了”。我们所认知的大小,就是书本的实际大小,这个实际大小,就可以作为书本的逻辑大小。在以后的讨论中,凡是牵扯到逻辑大小,均指从人的认知上看起来的大小。

物体真实尺寸不同,逻辑大小就不相同,给人的认知就会不一样,在眼中呈现的视觉大小也就不一样。像素大小相同,逻辑大小不一定相同。根据之前的讨论:

像素点的大小通常是不确定的。虽然像素的显示要基于物理上的屏幕发光点,但是脱离了物理屏幕这个大前提,讨论像素就没有了大小可言。

比如一个300×300的像素点阵,在大屏幕上和小屏幕上所使用的显像单元都是90000个,尽管他们的像素大小是一样的,但是能清楚地感受到两者显示的实际大小不一样,正是因为“1像素”的真实大小不同,造成了这个差距。屏幕像素数量不同,在图形有相同像素大小的情况下,图形的显示大小会不一样。

可以举例,对于一个64×64的icon,在iPhone8 Plus上显示的大小就会比iPhone8要小,因为iPhone8 Plus的ppi要比iPhone8更大。那么如果我们假设这个情况更为极端,某个屏幕的分辨率是另一个屏幕的好几倍,那么显示差距悬殊将会更大。业界通用的解决方法是将高ppi屏幕下的显示放大某倍,就可以将不同ppi屏幕下的逻辑大小控制到基本一致。这就是为什么我们感觉大屏幕的手机比小屏幕的手机看着更清楚,因为一般都会将显示部件进行放大。

在引入了放大这个操作后,就有了逻辑像素与实际像素这两个不同的概念。

逻辑像素与实际像素

试想一个问题:假如我们在为div绘制边框时,使用了border: 1px solid black;这样的CSS进行设置,那么显示预览时,我们可以看到一个黑色的边框,并且大脑会收到认知,这是一个1px的边框。但是,这个边框真的是1px吗?

实际上很多情况下并不是。在我们大脑中存在的1px是一个逻辑像素,根据上方逻辑大小的讨论,这个1px是我们看到的1px,它是逻辑大小。但是无论在iPhone8中显示,还是在iPhone8 Plus中显示,其占用的显像单元却并不是1px的显像单元,而应该是有好多px的显像单元。如果真的在手机上使用1px的显像单元显示1px,恐怕人眼很难看清楚。

从iPhone4S起,苹果采用了一种叫做Retina的技术。这种技术支持把更多的像素当成一个像素来使用,这样可以提高显示的细腻度。

所谓“Retina”是一种显示标准,是把更多的像素点压缩至一块屏幕里,从而达到更高的分辨率并提高屏幕显示的细腻程度。由摩托罗拉公司研发。最初该技术是用于Moto Aura上。这种分辨率在正常观看距离下足以使人肉眼无法分辨其中的单独像素。也被称为视网膜显示屏。

在使用了Retina的iphone4S中,一个1×1的物理像素点可以容纳2×2个像素,所以在其上一代手机iPhone3GS中的显示方案放在iPhone4S中就会显示的非常小,因为实际大小会缩为原来的二分之一。解决方法其实很简单,将设计稿中的全部元素等比放大为原来的2倍,就可以完美兼容iPhone4S。

现在的手机都是向着分辨率越来越高的方向发展的,所以应该尽量优先保证高分辨率的屏幕显示效果。在设计贴图中常见到文件后缀有@2x,@3x等字样,其中不带此类字样的用于普通屏幕,带@2x的用于Retina屏幕,带@3x的用于iPhone Plus系列机型。

规律:实际像素除以放大倍率,得到的是逻辑像素,若两个屏幕中的逻辑像素相同,其显示的实际大小也是相同的。

在iOS系统中,逻辑像素的单位是pt,普通像素的单位是px,在Android系统中,逻辑像素的单位是dp,普通像素的单位是px。

有了逻辑像素可以用来做什么?在进行UI设计时,只需要按照逻辑像素大小进行设计即可,在生成素材时加入@2x,@3x,即可得到高分辨率机型采用的素材,不用再为某些类机型单独做设计。(当然,iPhone X是一个很例外的机型,后面需要单独处理)

利用理论知识进行机型适配

Android机的尺寸比iPhone多得多,分辨率高低跨度很大,但是我们可以根据各种设备的ppi划分成几个区间,并为不同的区间设定不同的放大倍率,这就可以做到统一了标准。至于一些老掉牙的小屏幕机型,在做设计时如果没有特殊需要一般就不需要考虑了,毕竟这样的设备现在也没多少人在继续使用了。

对于iPhone X的适配,重点关注应该是在其头部刘海和底部标签栏与工具栏。这两部分被苹果官方定义为非安全区域,不可以在非安全区域显示任何有效信息。上方不安全区的高度为44pt,下方不安全区的高度为33pt。在适配顶部导航栏,顶部banner,底部按钮,开屏大图时需要特殊注意,这块内容属于经验之谈,不太好呈现在书面上,这里就不做记录了。

界面布局中的栅格系统

在App界面设计中,栅格系统的应用不仅可以让界面看起来更美观,还可以提升程序开发的效率。给界面留出边距这一设计方式可以被视作最基础的栅格系统。

8px原则

读中感觉不明其意,读完感觉,妙啊!

8px原则有两个不同的版本,一种是印刷行业使用的硬栅格,即将元素都放到8px大小的栅格中,一种是App设计中使用的软栅格,即保证元素之间的距离为8px的整数倍数即可。整合起来说,8px原则就是在设计中所有元素的长宽和间距都可以被8px整除。当然这里的8px是基于@2x情况下讨论的,在@3x情况下就是12px,不放大的话就是4px。当然,这里的px理解为pt或者dp也是完全可以的。

8px的由来不是没有道理的,简而言之,如果采用其他比较小px的原则的话,在一些小分辨率屏幕下会导致分辨率的像素参数出现小数,这就会导致元素出现虚边。但是现在来看的话,8px原则适用的320×480作为1×的时代已经过去了,我们可以把这个原则推广一下:

只要给界面中所有元素定义一个最小单位,一切元素的尺寸都是它的整数倍,就可以解决元素的适配问题。

读完后脑中瞬间想到rem,妙啊!rem就是一个相对大小的单位,1rem默认为16px,在开发中以rem作为标准就可以让写出来的东西变得很整齐。

常见的布局和适用场景

  • 标签式布局
    • 也称网格式布局,用于承载重要的功能,各模块之间保持相对独立,一行不要超过五个。设计时注意保持风格和细节上的统一。
    • 优点:各个入口清晰呈现,方便用户快速查找信息
    • 缺点:扩展性较差
    • 例子:支付宝主界面的各种功能选项
  • 列表式布局
    • 适用于较长的文字信息组合界面布局,不适合在信息层级过多且字段内容不确定情况下使用
    • 优点:信息展示直观,节省界面空间,浏览效率高,字段长度不受限制,可以错行显示
    • 缺点:单一的列表页容易让人产生视觉疲劳,需要穿插其他板式让页面看起来富有变化
    • 例子:知乎问题推荐,b站视频页下方的相关视频推荐
  • 卡片式布局
    • 是在栅格系统上更进一步进行规范布局的方式,将整个界面切割为多个区域,方便设计迭代,视觉效果统一
    • 优点:最能支持图文混排,适用于信息组合层级较多的情况
    • 缺点:太费空间,用户可能需要大面积扫视才能获取到想要的信息。在不适合的场合强行使用卡片式布局会降低使用效率
    • 例子:淘宝中“我的淘宝”页面
  • 瀑布流布局
    • 界面内卡片大小不一致,产生错落视觉效果的布局称为瀑布流布局
    • 适用于图片为主信息的情况,一般是两列并行,偶见三列情况
    • 适合电商和小视频等界面,不适合文字过多或强调产品稳重性的场合
    • 优点:极大提升交互效率,制造丰富的视觉体验
    • 缺点:过于依赖图片的质量,如果图片质量不高,产品的格调会受影响
    • 例子:淘宝商品页,闲鱼商品页
  • 多面板布局
    • 适合在内容和分类都较多的情况下使用
    • 侧边栏显示竖排列标签,内容页显示相关内容
    • 优点:展示信息效率较高,操作效率较高,减少跳转,分类直观
    • 缺点:分类很多的情况下,侧边栏较窄,不利于单手操作
    • 例子:京东商城商品页
  • 手风琴布局
    • 常见于两级结构的页面中,用户可以点击展开折叠
    • 优点:可承载较多信息,保持界面的间接性,减少页面跳转,减少点击次数
    • 缺点:同时打开多个的情况下,分类标题不好找,界面布局容易被打乱
    • 例子:QQ分组列表页

App基础组件规范

  • 状态栏

    状态栏是显示手机信号,时间,电量等信息的区域,一般是白色和黑色两种方案,此处一般不特殊设计。在状态栏背景颜色不确定时,缺省设置为背景白色。

  • 导航栏

    位于状态栏的下方,一般显示当前界面的名称。Android系统的导航栏标题基于导航栏左边缘对齐,iOS系统的导航栏标题基于整体居中对齐。两者的相同之处在于左侧一般提供返回按钮,右侧为当前界面的功能按钮,按钮可以是文字可以是图形。iOS的导航栏高度一般为44pt(逻辑像素375×667pt),Android的导航栏高度一般为56dp(逻辑像素360×640dp)。

  • 标签栏

    位于界面的最下方,提供界面的切换,功能入口和界面导航等功能。作用是指示当前界面所处的位置和可以前往的方向。在视觉上着重解决“我在哪里”,所以需要清晰且高亮地标注当前界面所处的位置。标签可以是纯图,可以是纯文,可以是上图下文。iOS的标签栏高度一般为49pt(逻辑像素375×667pt),Android的导航栏高度一般为48dp(逻辑像素360×640dp)。Android系统中的标签栏也可以在上方显示(由于Android系统存在界面虚拟按键,现在全面屏的普及也使得这个规矩弱化了,放上放下都行)

  • 工具栏

    工具栏与标签栏显示位置相同,但同一界面中,工具栏与标签栏只能同时显示一条。一般作用是承载一些对当前界面做一些操作的按钮(区别于标签栏的导航),一行不可超过5个,当超过5个时,最后一个显示为“更多”样式。iOS的工具栏高度一般为44pt(逻辑像素375×667pt),Android的工具栏高度一般为48dp(逻辑像素360×640dp)。

App字体规范

其实一般不怎么需要改字体的。

iOS11中系统默认中文字体为“苹方体”,英文和数字默认字体为“San Francisco”。Android8.0系统默认字体为“思源黑体”,英文和数字默认字体为“Roboto”。

字号规范相比字体来讲比较灵活,可以为每个产品都定一个自己的字号规范。但是一定要规定一个最小字号(小于此字号则会影响识别性),同时字号必须是整数,相同表意字段的字号必须一致。比如一级,二级,三级标题,大规模正文文本信息,非重要提示信息,非必读型信息,图标提示信息,它们之间的字号必须有区别,但是必须要保持整体一致。

打赏
  • 版权声明: 本博客所有文章除特别声明外,均采用 Apache License 2.0 许可协议。转载请注明出处!
  • © 2018-2020 Shawn Zhou
  • Powered by Hexo Theme Ayer
  • PV: UV:

感谢打赏~

支付宝
微信