王梓谊的博客

浅析iOS界面设计方法

作者: Mars.W   分类: 资料典藏   标签: ,    评论: 0

文章来源:迅雷CUED 链接:http://cued.xunlei.com/log-009

 

眼看移动互联网之风吹遍祖国大地,各种移动应用接踵而来,作为互联网设计师,若能掌握一些基本设计原则,将会对新平台带来的的挑战轻松应对!今天就以iPhone为起点,让咱们来分析一下iOS界面的设计方法~

开始前先整理下思路,目前移动互联网的界面设计有2种:即移动webUI 和 移动客户端UI

对于设计而言,移动web满足人们高效快速的信息浏览,注重排版和信息整合; 而客户端可以实现更加丰富的交互体验,注重层级关系和操作引导。 思路捋顺了,接下来就开始一层层把它们展开吧~

 

Web设计

 

iphone拥有紧致的尺寸,目前有480×320 和 640×960两种分辨率。它包含了完整的Safari浏览器,可以完整显示HTML,XML网页。利用多点触摸可以做到跟桌面平台一样的网页浏览体验。

但受“ 屏幕小、触屏操作、网速限制” 的限制,web的设计需要考虑诸如:精简布局、降低图片加载、减少输入等等。具体办法似乎可以这么做:

1、对原有信息进行整合重组,横向排列、避免分栏。

2、动作传感器可以感应用户横握手机时自动转为横屏显示,因此信息排版要做到自适应宽度,横屏480(960),竖屏320(640)

 

3、精简精简精简!!在小小的显示屏上,所有主元素都要尽量的“够大”,因此页面只需展示核心功能,去掉不必要的”设计元素”(使用色块或简单背景图),使页面易操作、浏览顺畅。

 

 

客户端UI设计

iphone中的AppStor提供上万种应用下载,每个应用即有一套独立的UI。包括:应用图标、闪屏、功能界面等

 

1、图标设计

图标通常是传达给用户的第一视觉感受,它可以体现出产品风格 、功能,甚至品质。iphone独特的桌面展示方式,引领了”豆腐块”图标趋势,即在一个圆角方形的区域内创造各种可能。 分析众多优秀应用图标发现,要设计一款精致醒目的图标,大概可以遵循以下几点:

a、图形元素尽可能不超过2个,并且不可平均分布,突出主视觉

b、桌面极少使用浅色,因此配色尽量以明亮浅色为主,以免被背景吸收掉

c、为了让图标更加自然融合其中,符合ios平台的透视标准,尽量使用正面垂直角度,光源自上而下。

输出:iOS会为图标自动生成圆角投影,可直接输PNG:57x57px    114×114    512×512     90度直角(不要使用alpha透明度)

 

2、欢迎界面

欢迎界面(闪屏)像是应用的一道门,在使用前给用户一个预示,它通常包含图标、版本号、加载进度等信息。设计可以根据产品风格随意发挥,与图标呼应,强化产品的印象。

 

3、功能界面
遵守IOS的交互习惯,功能界面的结构通常自上而下,分别是“导航栏、标签栏、工具栏”

 

导航栏主要显示“当前状态、返回、编辑、设置”等基本操作。

 

工具栏作为热点触摸区域,用来展示主菜单。形式可以:文字、图标、图标+文字(不可超过5栏)

 

标签栏是主要展示区,也是设计的重点。根据不同功能的界面、常见有以下几种设计方式:

列表视图——适合目录、导航等多层级的界面。将信息一级级的收起,最大化的展示分类信息。

分层的界面—— 利用iPhone本身独有的特性让其固定,或垂直、水平滚动,节省空间。

拟物化设计——适合实现独立功能的界面设计,界面的细节逼真写实。以现实的元素和操作唤起用户共鸣。

 

 

耶~本次分享完毕!cool

有句话说吃进去的是粮食拉出来的是思想,更确切的说法应该是“吃进去的是积累,拉出来的是经验。”   方法论终究是给自己的小小启发和指引,希望以后通过积累能有更高质量的产出~~争取吃的更营养拉的更精美~
12-25
2011

iphone Web App 导航设计探讨

作者: Mars.W   分类: 资料典藏   标签: , ,    评论: 0

文章来源:网易UEDC 链接:http://uedc.163.com/7998.html

最近在做iphone端Web App的项目。由于产品形式新颖,技术环境不成熟,公司给与了较宽松的研发时间。在一个月的交互设计阶段,每个环节都得到多次讨论推敲,我从中感悟颇多。导航系统的设计是一个比较典型的点,拿出来与大家分享讨论一下。
导航系统所遭遇的挑战

iphone Native App较常见的导航如下图所示:

手机屏幕底端:A、B、C、D四个tab组成该Native App的全局导航,这是我们经常见到的tab导航栏。

手机屏幕顶端:主要有四种形式。第①种形式是在该位置中心显示产品的logo;也可以将logo适当调整位置,将常用操作或快捷入口放在该位置的右侧。第②种形式是在该位置有两或三个tab选项。第③种形式是在该位置中间显示当前任务标题,在左右两侧放置导航控件或功能控件。第④种形式是在该位置放置搜索框。

与以上的Native App导航方式相比,Web App导航方式有着巨大的不同,如下图所示:

Safari浏览器的工具栏将一直占据着屏幕的底端位置,全局导航只能被动移动到屏幕的顶端位置。这是影响Web App导航设计的最重要因素。

如果产品的功能比较少,且没有特别要突出的功能的时候,可以设计成上图中第①种导航方式。此时存在的问题是如何表现出产品的品牌,毕竟在Safari浏览器登录某网站比运行一个Native App给人的品牌认同感弱很多。

如果将产品logo表现出来,且产品需要将用户常用功能突出(比如刷新功能或者发布入口),就需要设计成上图中的第②种导航方式。

如果在A功能板块下,还需要设置子类别选项,则导航栏中又多一组tab。此时的导航方式就如同上图中的第③种了。

当然,在执行某一项任务的时候,全局导航可以暂时“归隐”,只保留一行标题栏和左右两侧的导航控件或功能控件。如上图中第④种导航方式所示。

在该产品设计中,为方便用户在各功能板块之间快速省力地切换,设计师希望全局导航栏可以保持长久悬停,不要像一般wap网页似的让导航随网页滚动消失。这样的话,基于浏览器的Web App 导航系统便捷性就和Native App相媲美了。

然而,浏览器工具栏将全局导航逼到了屏幕的顶端,却又造成了导航头部过于沉重的问题。如下图所示:

如果将logo栏中的常用功能(例如刷新或发布入口)和全局导航都设计为悬浮停留的形式,内容区的信息展示空间就比Native App减少了一行的高度,如上图中的①。而且,某些页面需要在全局导航的下方出现二级导航;悬停不动的3行导航大大吞噬了屏幕本来就很宝贵的内容显示空间,如上图中的②。

让用户在如此狭小的空间不得不频繁滑动屏幕浏览信息,这样的体验太糟糕了。这个严重的问题很让设计师困扰,因此需要重新设计一下导航系统。设计过程主要包括:优秀竞品分析、方案遴选。

 

优秀竞品分析

首先,分析对比了三款优秀的Web App:Google+、FT Web App、Twitter的导航方式。浏览环境均为iphone Safari浏览器。

1.Google+

导航系统特点:

全局导航单独形成一个页面,其他页面不出现全局导航;

导航栏沿用了ios系统原生控件的形式:标题+导航或功能控件;

标题栏在页面中悬停不动

优点分析:

保证了每个信息浏览页面的导航栏简洁轻薄,尽量少的占用信息详情的显示空间;保证了其核心功能(此处是微博浏览功能)的良好使用体验。

缺点分析:

全局导航隐藏较深,降低了用户在不同功能板块快速切换的便利性;全局导航隐藏较深,用户看不到其它板块功能,大大降低了用户点击使用其他功能的可能性。

2. FT Web App

导航系统特点:

Safari浏览器URL一栏一直悬停存在,并将品牌文字FT Web App显示在顶端;

全局导航被隐藏起来,点击功能键后在页面顶端出现;

二级导航出现在页面顶端;

全局导航和二级导航由于新闻板块数量较多,都采取了单行空间不完全呈现的方式,可滑动选择其中某一项;

所有导航随页面滚动,不在屏幕中保持悬停;

优点分析:

FT Web App导航设计最大的优点就是繁重导航的轻量化处理。全局导航和二级导航中的新闻板块都非常多,若将这些板块都展示出来,恐怕要占用屏幕的一半显示空间。FT Web App于是将全局导航隐藏在一个功能键之后,二级导航也只给了一行的显示空间。

缺点分析:

展示给用户的导航只是其全部新闻板块的冰山一角,无法给予用户全部概况浏览的机会,也就无法很好的激励用户去尝试被隐藏的新闻版块;同时,用户寻找某一个新闻版块或者在页面底端回到页面顶端的操作成本略高。

3.Twitter

导航设计特点:

全局导航只有一行,品牌展示浓缩在主页图标中(Twitter小鸟图标);

全局导航一直保持在屏幕顶端悬停不动,不随页面滚动而滚动;

二级导航在点击全局导航某tab后,以菜单列表形式出现。

优点分析:

在屏幕顶端悬停不动的全局导航,可以方便用户在不同的功能板块之间快捷切换,降低了用户的信息寻找成本;Twitter Web App的导航只有一行,为用户保证了尽量大的正文内容显示空间。

缺点分析:

一些常用的功能键被隐藏在二级导航中(比如新信息发布入口),一方面增大了用户的寻找成本,另一方面降低了这些常用功能对用户的激励使用效用。

 

基于对以上三款Web App产品导航系统的分析,设计师对目标项目的导航系统设计形成了以下框定:

全局导航方便用户快速寻找以及功能板块间的切换;

导航尽量轻薄化处理,尽量保证足够的正文内容区显示空间;

将用户经常使用的功能键呈现在前面。

 

方案遴选阶段

基于项目的实际需要以及对竞品分析的思考总结,设计师尝试了3款导航设计方案,并对每一款方案的优劣之处进行了详细分析。

导航设计方案一

设计说明:

■ ABCD是产品的四个功能板块,组成全局导航。

■ 全局导航在屏幕顶端保持悬停不动。

■ E是新消息发布入口,属于用户常用功能。

■ E采用半透明显示方式。

■ E停留在屏幕的右下角

该方案的优点:

屏幕顶端只有全局导航一栏,导航的轻量化为正文内容区节省了尽量大的显示空间;全局导航悬停不动,可以便于用户快速切换到不同的功能板块。

该方案的缺点:

右下角的新信息发布入口致使浏览页面不够清爽,会对用户造成一定的视觉干扰;新信息发布入口没有必要在任何页面都显示,于是可寻性出现了危机;品牌logo无法显示,品牌感较弱。

 

导航设计方案二

设计说明:

■ E是新消息发布入口,属于用户常用功能。

■ ABCD是产品的四个功能板块,组成全局导航。

■ 屏幕顶端的两行导航栏在用户刚进入页面的时候出现,在用户滑动屏幕浏览信息的时候消失。

■ 屏幕右下角半透明功能键在导航栏消失后出现,点击该键导航栏出现。

该方案的优点:

浏览信息的时候导航栏消失,为用户提供提供了最大的正文内容显示空间;可以显示logo,品牌感较强;新信息发布入口的可寻性较好。

该方案的缺点:

屏幕右下角半透明功能键致使浏览页面不够清爽,会对用户造成一定的视觉干扰。

 

导航设计方案三

设计说明:

■ E是新消息发布入口,属于用户常用功能。

■ ABCD是产品的四个功能板块,组成全局导航。

■ 屏幕顶端的两行导航栏在用户刚进入页面的时候出现,在用户滑动屏幕浏览信息的时候第一栏向上消失,第二栏上移至顶部保持悬停不动。

■ 手动下拉全局导航栏,可以下拉出第一栏导航。

该方案的优点:

浏览正文信息的时候,仅显示全局导航一栏,做到了导航的轻薄化;全局导航悬停不动,可以便于用户快速切换到不同的功能板块。

该方案的缺点:

下拉全局导航时,可能会有误操作的危险,虽然可能性很小。

 

综合以上的分析,考虑到正文内容区显示空间的大小、对产品的操作便利性以及产品品牌感三方面因素,最终决定将方案三作为导航设计的基本形式,并继续进行进一步丰富细化。

 

总结:

浏览器的工具栏一直占据着屏幕的底端位置,全局导航只能被动移动到屏幕的顶端位置。如何平衡操作的便捷性与正文信息显示空间最大化的关系,是Web App导航设计的关键所在。

最佳方案总是权衡的结果。每一款设计方案解决某些问题的同时也会产生新的问题。此时设计师需要知道哪些功能是最重要、优先级最高的,保证核心功能的良好用户体验是评判设计方案的重要准绳。

12-25
2011

手机浏览器客户端交互设计适配之—屏幕大小

作者: Mars.W   分类: 资料典藏       评论: 0

文章来源:淘宝UED

随着各个手机操作系统的应用平台的上线,几乎所有的互联网应用都在往手机上迁移。然而手机与PC 不一样,PC经过了多年的发展,在设计上形成了很多不成文的规则,如网页的宽度都在960px左右【当然,由于整体的电脑屏幕往大尺寸及高分辨发展,除了背景宽屏自适应外,不少网页也正朝着更宽的方向上发展】。当前的手机种类繁多,手机屏幕的大小、比例各异,并且手机的屏幕本身就小,因此既要考虑应用在不同屏幕大小上的适配,又要保持其一致性,同时还要提高每个手机屏幕的使用效率,这就存在着很多的矛盾点。

在客户端的设计过程中,针对不同的屏幕大小,应该如何来设计?是否每个大小的屏幕尺寸都需要一个新的界面布局,还是所有的屏幕尺寸都使用相同的界面布局?我们将在下面的内容中来探讨这些内容。

一、当前热门手机的屏幕大小 

下图中,我抽取了国内某个网络电器城某周的10大畅销手机排名:

虽然只是2010年中的某一周的手机销售量排名,由此可以看出,当前使用中的手机屏幕差异很大,各种屏幕大小和分辨率都有。如果为了适配更多的用户群体,则需要考虑的手机屏幕大小和分辨率更多。【不过,根据当前的手机发展趋势,及手机客户端的使用行为可以看出,最主要需要用户关注的手机屏幕是2.4吋以上,240*320以上的手机屏幕,因为这样的手机使用客户端的频率和用户量都会更多。个人建议更多地是考虑320*480及以上的屏幕。】

二、屏幕大小正确理解

说起屏幕大小的时候,会有两种表达方式,1) “我的屏幕2.4吋,你的屏幕3.5吋。” 2)“这个屏幕分辨率 240*320,那个屏幕分辨率为320*480。”但在设计过程中,屏幕的分辨率和屏幕的实际尺寸必须同时考虑。

这里首先有几个概念需要再澄清一下:

  • 屏幕物理尺寸:屏幕对角线长的实际尺寸,如2.4吋,3.5吋等等
  • 屏幕分辨率:屏幕所能显示像素的多少。如,240*320等。
  • 屏幕密度(pixel per inch):以每英寸的像素数。每英寸的分辨率数,如160ppi。

物理尺寸决定了屏幕的实际尺寸,而分辨率可以表示屏幕上可以呈现的像素点数,屏幕密度决定了屏幕的精细程度。相同的屏幕大小,如果分辨率高,则屏幕元素更精细。一个界面元素在屏幕里的实际尺寸却是与屏幕密度相关,屏幕密度较小的屏上,界面元素的实际尺寸就会大些,反之亦然。

在进行手机界面布局中,除了元素的像素值外,考虑元素的实际尺寸也非常重要,甚至更为重要(人眼是要靠物体成像在视网膜上的视角大小来进行识别感知,视角是与物体实际大小和距离有关)。

           

在不同屏幕中,不同的图标点阵或者不同的字体及大小的汉字,在人的主观感知上,会有一个最优的结果值。在设计的过程中,我们需要根据这个最优值来进行界面的布局及设计。

也可以看出,这个用户感知最优的取值也与使用手机的人群有关(如年龄大的用户需要物理尺寸更大的界面元素)。

在不同屏幕中,不同的图标点阵或者不同的字体及大小的汉字,在人的主观感知上,会有一个最优的结果值。在设计的过程中,我们需要根据这个最优值来进行界面的布局及设计。

也可以看出,这个用户感知最优的取值也与使用手机的人群有关(如年龄大的用户需要物理尺寸更大的界面元素)。

三、设计过程与屏幕适配思路

1.确定目标的屏幕大小

屏幕大小由宽度和高度两个因素决定,但是在布局手机客户端的过程中,最关心的是宽度值。宽度确定后,高度可以由滚动或者翻页来显示所有内容;文字可以在适当的位置折行;标题栏可以伸缩适配屏幕宽度等等。但并不是不考虑高度,图标、文字、特殊的组件不仅需要考虑宽度,也需要考虑整个屏幕的布局是否与之适配。

由于不可能对所有的客户端进行单独的开发,因此,需要对手机屏幕的大小的归类。同时,在设计中也不会真的只考虑屏幕大小一个因素,屏幕大小和操作系统、手机类型等还是存在很大的相关性的。

首先,我们先来定义一下手机的屏幕大小的归类档次:

A. 小屏幕:宽度240 px 以下屏幕或者2.4 以下屏幕

  • 一般以非智能机为主,归在这个分类中的手机屏幕,一般是以java版本的客户端为主。

B. 中等屏幕:宽度240~320 px,或者2.4~3.0吋屏幕

  • 智能手机以Symbian或S60 v1,2,3,Windows mobile为主流;或者是非智能手机的客户端以java版本为主。
  • 同时包括240*320的宽屏手机。

C. 大屏幕:宽度320 px以上屏幕或者 3.0吋以上的屏幕

  •  iPhone 手机只有两个版本的适配,屏幕物理尺寸保持一致;
  • Android 系统手机及衍生平台手机
  • Win phone 7 系统手机
  • Nokia S60 v5,symbian 3等

D. 平板屏幕:7吋及以上的屏幕【可以不包含在手机中,^_^】

  • 由于当前的平板电脑上的应用的开发都是基于手机应用的功能,但是,平板的屏幕物理尺寸大增,使用情景也和手机不一致,在设计上有很多的特殊性,可发挥空间也更大,因此个人建议单独的设计。

其次,根据我们的产品战略,来确定待开发产品的用户群体来确定一款目标手机屏幕。由于对于某个业务的手机客户端都不会只推出其中的某一款(除非是战略上的用户群确定为使用某种手机的特殊业务),而是会对不同的手机平台分别进行适配。因此,确定的目标手机屏幕,应该是在该档次中最主流的手机屏幕大小,在以此为基准向上或向下来适配其他的同档手机。

2.适配原则

1)  客户端的logo,在各个手机上都应该清晰地显示

2)  标题或者底部栏必须100%的与手机宽度适配

3)  文字内容如果显示不下的话,可以自动适配宽度进行折行

4)  图片可以根据宽度进行自动缩放,屏幕宽度超过图片本身时,显示图片本身的大小

5)  适配过程中,界面的元素的宽高最小值应该符合用户的主观舒适范围值。

6)  不能完全使用分辨率的绝对比例来对界面布局进行缩放;

3. 适配思路分析

根据我们前面的分析,

C类大屏幕大小主要以Android、iPhone、win phone 7 和Nokia V5等手机为主,它们都是触屏手机,在适配上可以划为一个档次。

B类中等屏幕大小智能机主要以Symbian 和Windows mobile为主,因此在适配这两个平台时,主要集中在B类屏幕间的适配。

B类中等屏幕大小还有一块是非智能手机,使用Java客户端,同时,A类小屏幕大小主要使用Java客户端,因此,Java类客户端需要适配的范围更广,至少应包括B类和A类的屏幕大小。

(1)Android 与iPhone手机的适配

iPhone 本身就只有两个分辨率及一个屏幕大小尺寸,可以很好的来适配(最多出两套图片即可,系统会自动读取)。

对于android,由于其开放性,导致了各种屏幕的大小及分辨率都有。但Android系统有一个很好的特性,系统会根据屏幕的分辨率密度来进行自适应。但是,当密度差异较大时,自适应后,图标会由于拉伸变得模糊影响效果。这时,必须要通过重新设计新的图标或者加大间距来保持最佳的视觉效果及更便利于用户操作。

Android 手机屏根据屏幕的分辨率密度和物理尺寸,可以分为以下几类:

注:图中的【】内的值为手机所占的百分比值。Android 开发平台数据,不一定准

Android 提供了如下的机制来对不同大小和密度的屏幕进行适配:

1)  图片资源的缩放

基于当前屏幕的密度,平台自动加载任何未经缩放的限定尺寸和密度的图片。如果图片不匹配,平台会加载默认资源并且在放大或者缩小之后可以满足当前界面的显示要求。如果没有多套资源,平台会认为默认的资源是中密度的屏幕资源(160dpi)。例如,当前为高密度屏幕,平台会加载高密度资源(如图片),如果没有,平台会将中密度资源缩放至高密度。

2)  根据分辨率和坐标自动缩放(密度不同的屏幕适配)

如果程序不支持多种密度屏幕,平台会自动缩放绝对像素坐标值和尺寸值等,这样就能保证屏幕元素能和密度160的屏幕上一样能显示出同样物理尺寸的效果。平台会根据密度的比例来缩放实际尺寸的大小。

3)  兼容更大的屏幕大小(屏幕不同的适配)

当前屏幕超过程序所支持屏幕的上限时,定义supports-screens元素,这样超出显示的基准线时,平台会以屏幕大小的比例来缩放整个屏幕。

由上表格也可知,当前的Android手机主要集中在标准屏的中密度和高密度两个型号上。因此在设计中,主要是设计其中的一种为主,再去适配另一个型号即可。对于在一个档次上的手机,都会根据上述的三个原则,系统自动去适配。个人认为,在进行Android手机设计时,如果只准备一套资源时,应该以高密度的版本为主,这样去适配中密度时,效果更好。

当然,如果屏幕的密度差异较大时,自动适配的效果肯定不会,如果要取得更好的适配效果,必须针对几个不同的屏幕密度进行单独设计屏幕元素,提高视觉满意度。

(2)非Android、iphone的手机适配

对于其他的非Android、iphone手机,则需要更多地考虑其适配规则,这些手机系统不提供自适应的适配。

简单整理规则如下:

1)  向上适配(标准屏向更大【分辨率高,物理尺寸大】的屏幕适配)

在向更大的屏幕适配时,根据设备分辨率的不同,会分为两种状态。

A.如果两者的屏幕分辨率密度(dip)差不多,物理尺寸更大的屏幕。那可以直接在当前尺寸上拉长、拉宽即可,图标、行距都可以保持不变。

B. 如果屏幕密度要大很多,物理尺寸差不多的。则适配点包括:

  • 设计多套图标,需要有更大分辨率的图标
  • 使用不同的字体,需要更大的字体来适配大设备分辨率的屏幕
  • 增加行间距
  • 自适应放大内容中的图片
  • Tab页签 需要根据屏幕的大小来确认每屏最多显示的数目。
  •  考虑一些复杂界面,增大界面中的一些元素的分辨率,会导致许多东西需要重新设计。这种情况需要重新设计该界面。

2)  向下适配

在向更小的屏幕适配,这种情况较少,那会集中在如下几点:

  • 考虑一些极限点的改进,需要适配到小屏幕的手机中,如标题的最大字数等。
  • title、bottom栏与小屏幕宽度适配。
  • 考虑到行高(行信息展示)的设计是否适合更小的屏幕高度。
  • 在结构上,需要考虑在小屏幕中,显示是否合适。
  • 根据屏幕密度的比例来设计屏幕元素,需要更小分辨率的屏幕元素
  • 使用小的字体,具体的大小需要根据屏幕的大小来设定。

(3)竖屏横屏适配

横竖屏的适配,在本文中,不过多讨论,这里只是简单的整理一下,我自己的理解。

对于不同功能的应用,都有其特定的页面展现形式,个人并不赞同蛮目对任何应用不加选择的都去适配横屏。

个人观点如下:

1)  不同的应用,在设计的过程中,对于选择不同的屏幕有不同的选择,如普通list多的应用,竖屏更合适;显示图片更多的界面,或者想更好的展示全景的应用,横屏更合适。

2)  不必遵循,对任何的应用都可以自动进行横屏竖屏的切换。如果觉得没有必要横屏或者竖屏的应用,就可以不切换。

3)  由于用户在使用手机的过程中,经常会无意中调整位置,从而导致手机误认为是要进行横竖屏的转化,从而更容易导致操作上的失误,引起用户的反感。

4)  横竖屏的切换时,允许用户对于同一个界面有不同的展示方式。例如不一定在竖屏时时list方式显示,在横屏时也和竖屏保持一致,这时横屏可以有更好的适应横屏的展示方式,使用户更好的操作。

由于手机系统各异,手机的屏幕尺寸五花八门,屏幕的性能也呈现多样性,还有触摸屏和非触屏的区分,这四个变量结合起来,会有无数种不同的情况,如何能使你的应用完美地展现给用户,适配固然很重要。但是,更重要的是你要在适配之前,确定应用的目标群体。如果你的应用主要是针对高端手机用户的,那你何必去考虑低端的手机呢?毕竟为了很少的用户,使你花了很大的力气,可能会有不值得,这一点绝对值得每一个设计师思考。

===========

       题外话

一般来说,我们在设计一个产品时,首先需要确定产品的用户群体,然后基于用户群体来设计针对该用户群特点和使用行为的界面。但是对于手机客户端,感觉这个过程不能完全适用:

原因是因为,我的客户端设计主要是针对不同的手机平台(Android、ios,Win Phone 7,Palm Pre,Symbian…)来开发的,因此,开发出来的客户端适用于所有的持有该手机的用户。但是这些手机持有者是否都有相同的特质,是否都喜爱使用该客户端,是个很大的未知数。另一方面,如果我在建立用户群时,完全根据用户的需求、使用行为又或者人种学特征来分类,那每一群人中持有的手机各不相同,那又该如何定义每个不同平台下的客户端的功能呢?

当然,有人也会说那就先了解不同的手机平台的用户群特征,然后再研究这群人对本客户端应用的需求和使用行为,以此再来设计客户端,目前来说这是更好的研究思路。

总之,这样深入的讨论,会发现客户端会越想越复杂,有人说手机客户端的设计是最复杂的,是很有道理的,值得大家更多地探讨…

12-25
2011

浅析手机Web App的交互设计

作者: Mars.W   分类: 资料典藏       评论: 0

本文作者:晓生 来源:http://daichuanqing.com/index.php/archives/3155

HTML5为提高手机网页的体验提供了诸多的可能性,交互效果越来越接近原生App,故而成为Web App,有望将APP功能引向浏览器,让移动平台的竞争由系统平台转向了浏览器之间。

Web App比起原生App和wap有着自身的优缺点,先简单了解下其特点,掌握设计趋势,也便于以后在设计中应用。

离线存储

离线存储的意思是第一次访问是下载网页,以后在无网络的情况下也可以使用。一个离线应用程序就是一个URL列表–HTML,CSS,JavaScript,图片,或者其他类型的资源。访问时探测到服务器列表的缓存名单时,会触发下载事件,根据名单下载指定的文件存储到本地。

 

在下载的同时,浏览器将会周期性的触发进度事件,此事件包含了诸如多少文件已被下载,多少文件仍然处于下载队列等信息。当缓存名单中所有列出的资源被成功下载后,浏览器触发下载完成事件。

当再次访问时,浏览器会再次检查网站的缓存名单,通过对比名单和本地的资源,得知是否需要加载新资源。新版本加载完成之后不会立即被使用。后台可以下载新网页,也不会强制用户打断当前操作流程,重新刷新页面。

如果此过程中的任何一点出现可怕的错误,你的浏览器将会触发一个错误事件,并立即终止。类似于安装应用程序,中途不可以出错。

 

Web App可以利用存储的特性将重要和重复的数据保存在本地,避免页面的重复刷新,减少重要信息在传输过程中被泄露,增量传输修改内容。

而离线存储但也不是Web App特有的问题,浏览和阅读类App也有离线的使用需求,用来应对随时可能出现的网络问题。如离线模式是利用网络闲暇时间下载内容,当用户打开App时立即开始阅读。或者是网络不佳情况下保存用户的操作记录和加载相对重要的文字内容,之后再依次上传已更新的数据,如微博的发送队列机制。

交互操作

手机网页的操作发送只有点击,点击链接和控件,交互方式非常单一,而Web App 的操作将越来越接近应用程序。

1.Web App的建立离不开网络速度的提升,加载更多的内容,图形元素更为丰富。同时更多的JS交互,便于用户操作和形成扁平化的信息架构。

 

图标取代文字链接,界面更为美观,便于识别的。点击区域不限于元素的视觉区域,便于用户点击。同时排版不受限制,可以达到原生App的视觉效果。

 

增加标签栏,首页呈现更为的内容,减少界面的层级关系,页面关系更为明确。

 

界面可以部分更新,在需要时再呈现,减少界面的刷新,保存视觉的稳定性。

气泡框可以减少页面跳转,适合消息提醒等微任务的处理。信息架构上越来越接近原生App,有利于扁平化层级关系和减少界面跳转等设计元素将得到更多的应用。

 

2.识别更多的手势操作,如下拉刷新和右滑存档等平移手势。操作不必全部呈现在界面中,和平台操作保证一致。

3.调用系统硬件,如重力感应等传感器,不过在手机端还鲜有应用案例,离大规模应用还有一定的距离。

 

总之,交互上可以按照原生App的设计方式,效果将越来越接近,主要区别在于:

1.设计中要考虑到浏览器地址栏和工具栏的占有空间,和其对App的操作存在一定的影响。

2.暂时不适合调用系统底层接口,更适合web网站适配手机做的分支版本。

3.由于HTML的限制,交互的细节上存在一定的差异。

4.动效还没大规模的应用,但Web App界面操作将更为流畅,界面跳转时的平滑移动已经可以实现,以后还有更多的动效得到应用。

5.现阶段信息架构还混杂着原生App和wap两种架构方式。

参考资料:

W3C HTML5

Mobile Web Application Best Practices

HTML5离线存储

Making It a Mobile Web App

Css iPhone

Developing Mobile Web Applications and Mobile Widgets

Getting Started with iOS Web Apps

Youtube Mobile Web App

[IBM developerworks]HTML5 Web app

12-25
2011

Hello world!

作者: Mars.W   分类: 生活日记       评论: 1

欢迎使用 WordPress。这是您的第一篇日志。您可以编辑它或是删除它,然后开始写您自己的 blog。

08-25
2009
loading...