手机客户端交互设计硬件、OS与设计规范.docx
《手机客户端交互设计硬件、OS与设计规范.docx》由会员分享,可在线阅读,更多相关《手机客户端交互设计硬件、OS与设计规范.docx(13页珍藏版)》请在冰点文库上搜索。
![手机客户端交互设计硬件、OS与设计规范.docx](https://file1.bingdoc.com/fileroot1/2023-5/11/3c9c37ec-5006-48e3-bdbe-3ce95132c61c/3c9c37ec-5006-48e3-bdbe-3ce95132c61c1.gif)
手机客户端交互设计:
硬件、OS与设计规范
Iphone和Android系统手机风靡全球的同时,移动互联网的发展也掀起了一股热潮。
最近发现身边一些朋友纷纷在做手机上的第3方应用,或多或少碰到了些困惑,也许对于做惯了基于浏览器的产品的设计师来说,有一些比较典型的要点容易被忽略,这就容易引发出:
找不到手机软件的感觉、布局经常改变、设计和优化时找不到明确的立足点等等一系列令人困惑的问题。
本人有过一段手机交互设计的时光,将在这里罗列一些总结或感想,带一些建议,供看官们斟酌和评判。
抛开定位、使用环境这样的用户研究体系的大头,专注于说明手机交互设计的特点,其难点在于如何有效的结合硬件、软件平台和设计规范。
以硬件区分手机类型:
仅以物理硬键控制操作的机型(后文简称按键机)主要以触摸方式操作的机型(通常包含主页、挂机等物理键)物理硬键齐全,但支持触摸操作的机型(外形和按键机型一样)
主流的可安装第3方应用的软件平台:
塞班s60(第3和第5版) Windows Mobile for PPC Android Iphone OS Java(目前有非常巨大的智能和非智能机型群是包含java平台的) 其他还有很多,诸如plam os、UIQ等
交互设计规范:
一个有经验的设计开发团队,在项目初期会率先着手建立或检查相应平台的设计规范。
和web控件规范一样,手机交互设计规范定义了一些常用控件、组件等的布局和响应方式,提炼设计中的公共部分,减少设计和开发的重复思考,并确保整个设计体系的一致性。
不同的是,手机交互设计规范不仅有着限定作用,它同时还是一个信息架构的体现、一个创新的过程、并且它还对后续的交互设计起到一定指导作用。
我们了解到的iphone的无菜单的风格、各种操作手势、弹出框、标题栏和返回按钮,都是在这个阶段就需要定义好的,而不是具体到某个功能中才任由设计师发挥(所以说创新应该作为一个系统工程,而不是在某几个细节上灵光闪现)。
从设计第三方应用的角度看,大致可以浓缩成以下几个版本的设计规范:
S60第3版—有一套比较经典和严谨的规范 。
另外S60第5版虽然是触摸屏机型,但是对于交互设计师的工作来说两者区别并不巨大,只是把OK键替换换成了点击,以及零碎的一些变化。
Java版—事实上由于左右物理控制键和方向键、OK键是按键机型的普遍配置,S60第3版规范的适用 范围是非常广泛的,稍微修改一点就可以适用于Java平台。
区别在于手机的“删除”和“返回”两个物理硬键的配置不太一致,所以需要统一将右下角的命令默认为“返回”,在编辑文本时,临时变为“删除”。
这样牺牲了某些机型的某些操作的效率,保证了这个整体的机型都可使用。
Iphone OS—Iphone的出现一举打破了之前若干平台固有的设计定势,硬键和操作模式都精简了许多。
不过其缺少固定的menu模式,这对第三方软件的设计来说是个巨大的挑战,要么需要很大程度上脱离iphone自身的设计规范体系,要么就极端精简功能。
Android—跟从了一些iphone中的经典手势,操作和页面布局风格上相对保守一点,保留了menu和back两个硬键,虽然不够独树一帜,但是在功能和设计之间做的了一个不错的平衡,对于第三方应用来说,这是一个可以有宽广发挥空间的平台。
根据上文所述,接下来我就主要以S60第3版、Android、Iphone OS为代表,通过抽取手机交互设计规范中的部分,来说明他们的特性和区别,顺带展开一些个人经验的叙述。
大家请看以下截图:
上面几幅图并没有刻意选择同一类型的界面来对比,我们不妨先仅关注硬键/全局功能键,会发现他们之间的显著不同,实际上反映到设计过程中,这样的区别对界面设计造成的影响要来的更大。
下面以摘取手机交互设计规范的形式来陈述:
1.硬键和手势控制
S60第3版
Android
Iphone:
以上硬键和手势对于操作的控制,需要我们在设计前有个十分清晰的认识,并且整个团队达成一致,如有精力则需要专门写到设计规范文档中。
硬键控制是没有什么改动余地的,两款触摸机型可以对手势适当进行取舍,毕竟有些应用用不到所有的手势,能精简操作最好。
(从下面开始,会有一些功能界面,请允许我偷懒一下,用线框代替实际界面截图)
2.菜单
S60第3版的菜单是由左软键或OK键调出,需要定义以下几点:
(注:
聚焦到某一条目上时,通常按OK键是打开,但有一些内容包含几种看起来级别相当的操作,此时会弹出菜单选择)
如何收回背景是否雾化每屏最多显示多少条 有无二级菜单,如果有,怎样调出和收回,和一级菜单的位置关系,焦点条的区别 菜单项文字靠左 数字标号,如果整个软件能保证菜单项目均在10位以内,建议加上,这样可以与数字键盘对应对聚焦项或当前页面不适用的菜单项,是不显示还是文字变灰处理。
OK键菜单只包含针对聚焦内容的操作项,需控制在一屏之内,避免二级项菜单项的排序规则:
针对聚焦项的在上,其他的在下,这两部分中分别按照使用频率从上至下排列
Android
Android传统的菜单是由menu硬键调出,比较多的是2-3行,每行2-3项,看起来像是一些按钮,所以里面的图标和文字都居中。
作为第3方应用,如果菜单项稍多,做成一纵列的文字项从操作上来看也未尝不可,毕竟用户刻意记住其默认的菜单形式也没有什么好处。
只是仍然需要注意控制一下数量,如果需要二级,可以考虑做成弹出的,比如在一级项中选择“排序”,之后弹出选择框来选择
Android还有一种长按菜单,按住某个项目达到一定时间后,会弹出在触点附近的位置
Iphone
Iphone并没有一个明确和固定的菜单模式,较保守一点可以说是没有。
一些类似菜单的操作通常是通过弹出选择,或者是拆分成几层,一次次点击进入更深层的页面去寻找按钮的形式来达成。
所以要做Iphone平台的第3方应用的同学应当提前做好准备,从产品策划开始就着手考虑这个问题。
最有效的办法是首先尽可能的缩减功能,其次尽可能的缩减操作方式。
否则会发现为了一些细枝末节的操作,还需要设定好几层页面。
当然,也可以加入一条操作栏来作为辅助,只是整体风格和操作就不Iphone了。
说到这里,不得不结合前两点延伸一下,对导航系统进行说明:
众所周知,导航系统主要担负着几个任务:
展示内容架构、表明当前位置/状态、表明可以去哪里。
在网页上的典型形式为全局导航条。
在手机上,导航系统同样重要,但是受限于屏幕尺寸,一般没有足够的空间放置这样的组件,但手机有着自己的体系:
我们可以看到各平台对导航系统的规划:
标题–显示当前位置,可以是文字、图标+文字、也可以是一系列tab菜单–显示可以做些什么,通常包含两种类型的选项:
a只针对选中项/只针对当前页,b全局功能如设置和帮助,也就是说菜单大多数作用是发起针对当前页的操作,或者转到和当前页面没直接关系的页面返回–这个比较复杂一些,也是最需要设计师注意的。
鉴于第2条对于菜单形式的描述,如果再加入关联页面的选项,项目数量和类型会使菜单不堪重负。
并且页面标题通常无法准确表达出相应页面的内容,即使放入菜单,也需要用户花时间去理解和回忆。
所以“返回”很重要:
一个固定的位置,简单机械的一个动作,一按—一看—一按—一看,不需要刻意寻找和思考。
在一个没有全局导航的环境里,一步步后退到自己浏览过的页面,从而了解当前的页面体系,或者重新发起一系列操作,是个能保证用户找到位置的简单高效的模式。
在做第3方应用时,需要尽可能严格保持以上几点的规范化
3.焦点
焦点更大的意义是在按键机型上,用一个带底色的条框衬托出当前选中的项。
对焦点的设定和控制应当尽可能的简单,需要定义默认聚焦的位置、是否允许上下左右循环
在按键机型上,4个方向键控制焦点向4个方向移动。
通常一个方向只限一种移动方式,如上左图:
上下键控制列表区的焦点在列表项间移动,左右键控制标题栏的tab左右切换。
如果列表区也分左右的话,处理起来就复杂了,应极力避免。
如上右图:
需要先向上移动焦点到标题栏,然后才能按左右键切换tab?
但如果当前焦点所在的项处于第2屏,第3屏,或者更靠下呢?
是否需要一直按住“上”,直到上边的内容滚好几屏后才聚焦到tab上?
在一些情况下,焦点容易被遗忘,其中某些对触摸屏机型同样适用:
如上图,页面中包含了一些可操作的元素:
人名、图片、网址,这里也会隐藏着一些典型操作,例如对网址可能有“打开”“复制”“保存为书签”等操作,此时聚焦并按OK键或者点击则需要出现弹出菜单。
另外还需要注意上文提到的横向和纵向切换焦点的问题,正文中同一行如果有两个名字可以聚焦,但是左右方向键已经被标题栏占用,那么切换人名的优先级应降低,改用别的形式,即使是按上下方向键来左右切换人名也是可以的。
4.弹出框
除了菜单功能的以外,弹出框一般出现在屏幕底端,同时其他屏幕其他部分背景雾化,这有利于用户的视线从密密麻麻的小屏幕中快速找到关键:
弹出框有很多种类型,除了“确定”“取消”等元件的基本布局以外,几个平台区别不是很大,大致可以分成几个类型和对应的处理方式,以下是我归纳和建议的一些处理方式,只列最适用于S60第3版的:
5.列表
列表项的呈现可以集中定义几种模式:
常态、编辑/被调用:
常态:
编辑/被调用:
6.还有一些方面可以事先定义:
搜索逻辑事件处理:
无信号、低电量提示的形式和时机、来电、来短信、闹钟时间到、缓存已满、发现新版本等文本输入:
光标的移动、删除和复制粘贴、选中地址/人名等复杂逻辑的返回路径:
有时候会出现操作路径中断并跳转的情况。
比如正在写短信时,弹出提示收到新短信,用户此时通过弹出框直接转到了查看短信的界面,此时“返回”是返回到查看短信的上一层,还是回到编辑短信的界面,这些情况想要集中处理,是比较令人头疼的问题。
不久前我大概归纳过一套返回逻辑,大意是:
a路径默认是从操作步骤向前一步一步返回,或者逐层向上返回;b如果遇到路径跨页面体系转移,先按照a的方式返回,到达跨页面跳转的界面时,允许跨一次跳转,之后按a的方式返回。
以上罗列了一些我的归纳和心得,开始新项目的时候基本可以按此思路先把这些方面统一规范,提及都是习惯用法,追求稳妥的项目可以直接套用,追求创新的项目也可作为一个评判依据。
最后,用一个简单的例子提及一下:
设计与系统规范尽量保持一致的重要性。
假如我们把mac系统的软件风格直接搬到windows中,那么在切换不同软件的时候,最小化、关闭等按钮的忽左忽右,会使我们经常默认就把鼠标移动到了相反的方向。
每1个第3方应用在手机中都不可能一个程序在战斗,手机中会自带很多系统应用,例如电话本、短消息、设置、浏览器等,他们都遵循着一样的规范,用户每天也会在这些程序中切换若干次。
如果一个第3方应用和他们的基本操作方式不同,每次都会使用户经历仔细观察、出错等过程,想象一下每切换一次软件就要转换一套思维的痛苦吧。
当然,规范是可以打破的,如果我们找到了简单高效并且操作方式和习惯用法没有冲突的方式,可以尝试一下。
例如以前触摸屏的列表项点击一次是聚焦,再次点击为打开,后来普遍改为点击一次就打开
————————————————————————————————————————————
附:
小屏幕移动设备网页设计注意事项
在过去,小屏幕移动设备网页通常也被称之为WAP页,或WAP站。
原因是这类网页起源于一个叫WAP的无线协议。
WAP能够运行于各种无线网络之上,如GSM、GPRS、CDMA等。
WML是无线注标语言(WirelessMakeuplanguage)的英文缩写。
支持WAP技术的手机能浏览由WML描述的Internet内容。
而如今的小屏幕移动设备,比如手机,都已经具备访问WWW的能力。
其内置的浏览器,或是第三方浏览器大多是WebKit引擎。
也因此没人再用WML组织WAP站点了,一般都是用HTML+CSS的方式。
在设计小屏幕移动设备网页时,你可能先得了解这么一些前提:
手机屏幕分辨率乱得一塌糊涂,什么分辨率都有!
我们的手机上网费用贼贵贼贵!
UC浏览器拥有了贼大的市场占有率!
关于UC浏览器:
没错,不得不提它。
谁叫它的市场占有率高呢。
对于UC浏览器而言,显然是非常适合我国国情的,它给用户最大限度地节约手机上网流量。
(UC浏览器打的口号貌似也就是省流量这一招了)。
基于移动应用,以及文本的可读性,UC浏览器也体现了大字体、大行距等特性。
UC浏览器相对于其他手机浏览器而言,对HTML标签和CSS属性存在有特殊的、自定义的处理方式。
而所做的这些特殊处理,按目前来看,应该将会继续保留较长一段时间,直到手机上网费用得到较大幅度的下降,令消费者更大胆地移动上网之时。
在实际开发中,我们发现了UC浏览器对CSS存在一些“特殊照顾”:
不支持font-family属性,也就是说,在UC浏览器你只能看到一种字体;不支持font-szie属性,也就是说,在UC浏览器你只能看到一样大小的字体;不支持width、height、padding、margin、line-height属性,也就是说,在UC浏览器只能通过p、br等HTML标签来换行以达到字符上下间隔;不支持固定像素的宽度,100%显示页面,也就是说,在UC浏览器始终将看到的是“满屏的”;不支持浮动、层叠布局,float和position属性无效,也就是说,在UC浏览器你只能看到“左对齐”。
支持background-color,但不支持background-image,也就是说不支持CSS背景图显示,在UC浏览器你只能看到背景色。
不过,个人仍然认为,如今建设小屏幕移动设备网页,完全可依据WebKit引擎的浏览器作为标准进行界面开发。
换句话说,我们设计支持UC浏览器的网页,而不是设计以UC浏览器为标准的网页。
这样做还有个好处,可以在大部分的手机浏览器上保证相对一致的样式。
而针对UC这种连float等标准CSS属性也不支持的浏览器,别过于纠结它!
但为了保证界面中各元素在UC浏览器仍具有良好的阅读顺序,严重建议HTML编码人员留意各个HTML标签的先后顺序。
因为只有在支持float、position属性的浏览器下,页面各个容器才可以任意浮动或层叠的。
否则,浏览器将按HTML标签的先后顺序显示。
另外一些小屏幕移动设备网页设计的相关补充:
网站头(header)
考虑到小屏幕移动设备的一些特性,设计网页时,有些可以去掉网站头(包括LOGO、全局导航什么的)。
比如flick的查看大图页面就去掉了网站头。
在过去,小屏幕移动设备网页通常也被称之为WAP页,或WAP站。
原因是这类网页起源于一个叫WAP的无线协议。
WAP能够运行于各种无线网络之上,如GSM、GPRS、CDMA等。
WML是无线注标语言(WirelessMakeuplanguage)的英文缩写。
支持WAP技术的手机能浏览由WML描述的Internet内容。
而如今的小屏幕移动设备,比如手机,都已经具备访问WWW的能力。
其内置的浏览器,或是第三方浏览器大多是WebKit引擎。
也因此没人再用WML组织WAP站点了,一般都是用HTML+CSS的方式。
在设计小屏幕移动设备网页时,你可能先得了解这么一些前提:
手机屏幕分辨率乱得一塌糊涂,什么分辨率都有!
我们的手机上网费用贼贵贼贵!
UC浏览器拥有了贼大的市场占有率!
因为只有在支持float、position属性的浏览器下,页面各个容器才可以任意浮动或层叠的。
否则,浏览器将按HTML标签的先后顺序显示。