Category Archives: Ux

交互设计 用户体验

大屏手机时代,如何重塑界面交互

157-980

12.30.2014 约稿于百度MUX新官网上线
mux_new_website_mdong.org

这是一个大屏手机的时代。
强调这件事情的意义在于,这已经成为事实。

Medium上存在一份个人统计。
在过去7年,新上市的手机屏幕尺寸越来越大。

157-001

以4.5英寸为分界点,我们更清晰的看到这一变化。过去的两年,4.5英寸的比例从10%升至80%。

157-002

在国内的过去3个季度,使用FHD HD分辨率的手机从38%的份额增至50%。

157-003

【图】《百度移动分发报告2014H1》

更大尺寸的屏幕可以承载更多的内容展现,更适合游戏、阅读与播放视频,体验得以提升。

157-004

【图】《百度移动趋势报告2014Q2》

然而屏幕尺寸的上升并没有引起用户操作上的过多不适,有51%的用户已经适应双手操作。

157-005

【图】《How Do Users Really Hold Mobile Devices》by Steven Hoober

即使用户单手操作,在操作大屏幕时的相对盲区(深色区域),需要更多的响应时间,也可以被接受。

157-006

【图】《Mobile UI ergonomics: How hard is it really to tap different areas of your phone interface?》By Mikkel Bo

即便如此。3.5英寸~4英寸,依然是平衡单手操作与体验的合理尺寸范围。

157-007

这样就产生一个矛盾:用户拥有更大屏幕的尺寸,但从人机交互的角度,并不完美。

面对这一现状,从APP产品界面设计的角度,需要做出改变。

大屏幕拥有典型的可用性问题:纵向单手操作机身,边角、顶部、左右侧边难以触达,放置在以上盲区的点击入口,将导致体验路径中断。

交互设计角度的最佳实践:

1.设计安全区域,避开操作盲区。

示例,百度搜索结果页,根据视线规律,典型的左上角操作盲区可以用于logo展现。

157-008

2.注意使用场景路径触发的连贯性。

示例,在百度手机助手Android中下载百度浏览器,操作区域集中在安全区域。

157-009

3.更多的使用可拖动的浮动按钮,给用户更自由的操作可能性。

示例,百度浏览器Android中翻页/返回顶部的组合按钮。

157-010

4.更多的使用手势,并提供暗示。

示例,百度浏览器Android的删除窗口操作。

157-011

5.更多的使用语音作为输入方式。

示例:生活手记中使用语音替代键盘输入。

157-012

6. 横屏Pad化的操作设计,以及更多的内容展现。

示例,百度浏览器iPhone的横屏设计,如同网页的Responsive Layout概念。

157-013

在界面交互的层面之外,在不远的时间,硬件存在更多的优化可能性。

1.更窄的边框,更大的显示比例。

157-014

2.柔性材质。

157-015

3.“手机”成为服务的触发者,屏幕投射与隔空操作。

157-016

《The World as a Display》

之所以将讨论的范围扩展到硬件,是希望设计师在针对具体屏幕设计的同时,能够从另外的视角,思考人机交互的变化与可能性,激发创造力。

当前是大屏手机的时代,推动你的手机APP产品跟进吧!

一些有价值的相关基础研究链接

  1. 百度移动分发报告2014H1
  2. 百度移动互联网发展趋势报告2014Q2
  3. The Rise of the Phablet: Designing for Larger Phones
  4. Common Misconceptions About Touch
  5. How to design for thumbs in the era of huge screens
  6. Designing for Large Screen Smartphones
  7. Mobile UI ergonomics: How hard is it really to tap different areas of your phone interface?
  8. Insights on Switching, Centering, and Gestures for Touchscreens
  9. A comprehensive look at smartphone screen size statistics and trends

(译)Windows Phone中环绕icon的圆圈

原文http://ux.artu.tv/?p=176
译文http://www.mdong.org/?p=2214

在Stockholm的Windows Phone Design Day期间的Q&A环节,Stockholm本地的交互设计师Petter Sifver提了一个问题,关于Windows Phone app bar上的icon,想知道为什么icon的周围会有圆圈。Petter友好地在其博客上为分享了他围绕设计阐述的观点

我们看到的是Button,而不是icon。——从字面上。在这些Button内部都有小icon。微软提供的开箱即用(out-of-the-box)的Metro设计语言有一致性接近“button like”(可意会的按钮)控件。不论它是一个Push Button, Toggle Button, Command Button或者媒体播放Buttons或者icon button——button在Windows Phone的Metro语言里有一个边框,来定义边界。所以icon buttons在app bar是朴素地遵循了同样的语言——我理解它们可能造成困惑的原因是,我注意到当我们谈论icon时,我们会经常表述在圆圈里的内容并称它们是icons。当我们谈论icon我们会表述它们像icon(没有圆圈——即便如此,99%的它们被当icon buttons来使用)。

Saliency概念是正确的,而在我们的Metro button设计语言中有例外设计。
这样做是在保持一致性。称呼它们button或icon从字面看起来很接近,但是有着非常大的区别。我们使用button用来交互,使用icon传达一个单项的信息。例如,在电话应用在call history list界面中紧挨着calls使用带有电话icon的button——它们是button,不是icon。

另外一个使用icon buttons例子是在文字消息应用——当你希望增加一个新的联系人并发送一条文字消息,你得到一个带有加号icon的小button,同样的,它是一个button——不只是一个icon。你会发现我们不会使用icon作为button。它已经通过加号icon吸引了人去使用——我知道我被建议了。回到开始,正确的接近windows Phone的Metro设计是使用icon button。

现在我们看一下我们如何使用icon。例如在状态栏中,它们是确确实实的通知icon,并且没有使用圆圈(它们不是button)。

我们使用icon做为图形,它们提供给用户单项的信息(它们是不可交互的,因此不是button)。例如在电子邮件应用我们使用小icon(不是button)与用户交流。当有附件在一封邮件里,这时它会成为高优先级邮件(标记)。

所有这些,我希望明确,我们在Windows Phone Design Day所谈轮到——Metro在做两件事情:Metro设计法则与Metro设计语言。Metro法则是设计支撑。Metro设计语言建立在法则之上,是在实体UI元素、动画、排版、构图与其它交互方向中的证明途径。

Metro设计语言由三件事情所定义:Windows Phone的native应用(邮箱应用、文字消息应用、people hub、本地搜索等等);第二,Windows Phone UX Guidelines;第三,控件库与其它Windows Phone SDK & Silverlight Toolkit的可用资源(所有的三项彼此之间会保持一致性)。开发人员与设计人员可以使用Metro设计语言,这会成功地为Windows Phone建立精巧美观、引人注目与一致性的体验。

Metro法则是优先的,它凌驾于任何语言,所以设计人员可用自由的探索法则,并且通过非主流的方式被你所证明。我们也乐意看到这些事情发生。Metro原则允许无限的探索与进化。这里我们给一些思路…从Swiss Design Style的课程中读一些文章。这描述了许多Swiss设计背后的理念(Metro的根源在它,也可以称为International Typographic Style)——阅读其中的海报与印刷媒体设计。然而,许多这些海报、设计与Metro设计语言并不相像,但是这不意味着做为一个设计人员不能探索其它的表达法则的途径。

「milk香港版」交互设计漫谈(2)——社会化分享

为什么分享的图形是“心”?不应该是三点网络还是别的什么??

因为,人在用心分享!用心。

晚上忽然些许感触。一年前的晚上舜日对那个分享定义,略显激动地解释。

不想在这儿考究用户体验抑或是通用习惯,感觉苍白。

只是说,我们有一种态度,让产品设计与生活走得更近。

在这篇文章发布的几天里,milk香港版iPhone迭代了一个版本,再次被推送在官方新品推荐以及热门推荐。

几周前,milk香港版Android首次面世,新品热门推荐。

零推广。

1.2版本的迭代开发,主要功能是社会化分享。

分享的意义

社会化分享,是指在社会化媒体中,基于其分享功能,将信息网络化输入输出,加速组织传播。博客、微博客、WIKI、博客、社交网络、内容社区等,是可以常见到的社会化媒体形式。在国内近两年,社会化分享的传播量又以QQ空间、新浪微博、腾讯微博势头最猛。

社会化媒体最大的特点是赋予了每个人创造并传播内容的能力。

Twitter平等的信息网络,使得每一个独立个体变得真实。

虽然国内的类twitter产品有变质,人与人多了一层等级关系,信息传播也不再充分流畅。但人们依旧乐于低成本的表达自己,传播感兴趣的内容。

最后在这个项目里,我们确定将新浪微博、腾讯微博做为第一批分享通道。

定位与设计探索

milk香港版的前后两个功能版本迭代间隔两个月。

保持良好的迭代节奏、并达成对用户有参与感的互动体验提升,是分享功能的两个产品考量因素。

设计定位

1. 迭代版本的分享功能,需要在视觉交互中引起用户注意。

2. 分享功能的显示与操作方式,沿用已有的设计,减少用户认知成本。

3. 操作流程简化、流畅,层级关系易理解。

功能ux流程探索

简述:入口->(过渡)->分享UI->(过渡)->完成

在当前的UI框架中,我们有三个区域,放置功能入口。分别是:

(点击放大)

头部条,Getit弹出区域,底部条。

头部条

——优点:规范标准设计
——缺点:游离在milk设计之外 不具有一致的美感

Getit弹出区域

——优点:易引起关注
——缺点:增加手势误操作的可能性

底部条

——优点:规范标准设计 易引起关注
——缺点:占用过多空间 增加手势误操作的可能性

权衡的设计,选择Getit弹出区域的非标准设计,统一在已有的信息框架。

这符合用户对第一个版本的认知——弹出区域是被推荐的互动内容。

(点击放大)

如上图,这是一个最终设计的mockups截图罗列。

接下来的分享通道,将提供2个入口,以及允许回退操作的取消按钮。

验证登录,将提供一个webview供用户填写登录。登录失败将停留在这个页面,允许继续尝试,或回退。

登录成功将填写分享信息,详细的分享内容由应用自动填写,包括关联的图像(隐藏)、slogan 、关联的资讯内容,用户可修改。并通过右上角的按钮进行发布。

更多的细节:更换账户的功能集成在该页面,允许用户的快速回退操作。超出140个字符的内容,将红色提示,默认灰色标示。

上传的过程将提供应用状态。并允许因为网络或其它问题的用户回退操作,回退的关闭按钮与提交按钮位置一致,易于理解。

分享成功会提示成功并进入分享前的初始资讯UI,失败将重新回到填写分享信息UI。

通常情况下,用户完成一个分享操作会经历三次操作,分享入口->分享渠道->提交。

视觉设计与交付

将视觉设计与交付合并,是因为沿用了前期版本的设计,不需要探索新的视觉风格,整个过程会十分高效。

保持标识元素的可识别与简约,皮质底纹。

(点击放大)

iPhone资源,基于640×960与320×480分辨率,@2x标识了retina适用的图像。
Android资源,按480×800分辨率导出,以_ad为区分。

(点击放大)

同样针对每个UI的redlines,为开发提供参考。

碎片的设计

默认的API错误alert反馈,只是在debug版本里才会出现。弹框消息提示是个恶心的设计,并且在这个场景里对用户没有帮助。
为什么小按钮没有pressed的状态设计?它们太小巧了,以至于手指按下后,眼睛看不到这个按钮……
应用提交iTunes时的Special设计……更新的应用截图,丰富的颜色与物品。

后记

这是第四篇编号为2的系列文章。。。- -。。。太懒鸟。。太不知道说什么鸟。。。多去看书体验生活咯。。

「milk香港版」交互设计漫谈(1)——Splash screen

当产品相对稳定与可控,小神有愿望快速记录这个项目。

内容涉及小神参与产品设计与执行的过程,由交互/视觉设计层面的需求分析、功能设计与设计执行组成。

与其带入一些工作中的设计技巧,小神更愿意分享其中的设计思想与理念憧憬。

设计之所以不同于美化,是因为前者被赋予了驱动的灵魂。

背景

milk香港版,内部命名”milk mobile”。是香港潮流杂志《milk》在移动新领域的合作尝试。目标设备为主流的中高端便携移动设备,iPhone/iPod touch/Android Phone/WP7…目前iOS版本如期发布,您可以从这里获得最新的版本。其它平台蓄势待发…

在发布后两周中,milk香港版荣得Apple app store的”新品推荐”与”热门推荐”,Lifestyle排位第二。

小神在过去的三个月,从零开始着手milk香港版的设计执行。

设计的生命周期

在展开一项工作时,我们都希望对它在整体上有所控制。

一个相对清晰的timeline使得设计在时间与质量之间平衡,并在恰当的里程碑有所产出,跟随整个项目进展。

milk mobile的设计定义

milk mobile的品牌与内容定位,决定这即是一面向城市快速消费的精神食粮。

它具备几个特质——高时效性、眼球经济、缺乏耐心的。

继而在视觉与操作着力营造如此的氛围:

  • 信息传递的高度流畅。
  • 信息呈现的节奏感。
  • 轻松的操作浏览环境。

探索从Splash screen开始

Splash是用户进入App,直到程序完全可用前,显示的第一个视图。

Splash Screen概念存在的价值

  • 品牌识别(权重30%)
  • 当用户通过桌面icon进入milk香港版,会再此传达具有品牌象征的手写milk英文字符。与milk其它产品形象统一,用户得以加深认同感与归属感。

  • 必要的数据加载与反馈过程(权重70%)
  • 对于milk香港版而言,splash screen的存在更多承载的是功能层面的需求。
    对网络与cache的不同状态产生的scenarios进行处理,并提供良好的反馈。

在iOS Human Interface Guidelines,对Splash的概念有较为详细的阐述,你可以点击这里查看。但并不赞同对Splash Screen的一个定义——Launch Images。

我们所感知到的信息是流动的,图像与其承载的信息也应该在表现上流动,贴近感知。

流动的图像表现上更贴近于animation,iOS从文字示意上误导设计人员并限制了它的可能性。

Launch/Splash是一个无限延展的屏幕空间,不仅是”图像”。

作为跨平台设计,Android对Splash screen的理解,更注重实用性。

If your application has a time-consuming initial setup phase, consider showing a splash screen or rendering the main view as quickly as possible and filling in the information asynchronously. In either case, you should indicate somehow that progress is being made, lest the user perceive that the application is frozen.

Windows Phone 7注重信息传递的效率。绝对效率是应该被真正推崇的,当你不能提供更好的理由使其存在。

Don’t use splash screens for branding. Avoid using splash screens because they may cause users to associate your program with poor performance. Use them only to give feedback and reduce the perception of time for programs that have unusually long load times.

Don’t use animated splash screens. Users often assume that the animated splash screen is the reason for a long load time. Too often, that assumption is correct.

通常,我们尊重平台的design guidelines,它使得你的app与OS融为一体。

milk香港版Splash screen wireframes

基于以上的定义,沉淀设计。文档的细则,受限于NDA将不被分享。但你可以在测试app的过程中,看到不同scenarios下的表现。

  • 当无网络无cache状态。
  • milk香港版不可用,没有数据的App是丑陋的。用户更需要的是一个友好的帮助界面,提供状态反馈与解决方案,在易识别的区域提供异常网络状态与”重试”入口。

  • 当有网络无cache状态。
  • 客户端从服务器端取得少量的必要数据,继而无缝过渡。

  • 当无/有网络有cache状态。
  • 客户端优先读取cache,弱化用户不需要参与的载入状态信息,并无缝过渡。

受益于尺寸变形动画,milk logo的使用场景由Splash自然转化到app页面。于此同时,渐隐Splash背景与隐藏提示信息。由此结束整个Splash screen。

milk香港版Splash screen的视觉设计与交付

Splash的视觉风格统一于app完整的视觉设计。

黑白为色调,赋予皮革材质,以幽暗的顶部光线渗透全部的元素。致力于简洁但不失细节的表现。(视觉设计将单独成文)

使得用户将视觉重心停留在表现丰富的资讯信息。

针对iPhone的屏幕与app的默认展示方式,需要320×480以及为retina屏幕的640×960两种尺寸的设计(单位px)。

Android有着更广的屏幕设计需求,但从实际的开发实践,我们只保持了480×800的设计资源。这被验证为是体积与质量的最佳妥协方案。

接下来的是其中的一则redlines图像,此类的设计资源为团队的开发人员提供参考,使得整体项目运转顺利。

当时间充裕,执行Flash实现的高仿真模型,更高效的推动沟通,并为开发人员提供参考。

Review设计是一个自我提高的过程,并希望对读到该文的同学有所帮助。

突围与革变

厌倦每天重复为设备充电。
厌倦随时携带几台需求交叠的设备。
厌倦花样功能毫无持久力的软体应用。
厌倦毫无关联干瘪应用为中心的生活。

我开始放弃EVO4G,它笨重并且无尽的消耗电力。
保持Mozart,保持基本通信、工作同步与信息查询。
我有4000毫安的移动电源,它支持Mozart续航。
远离iPod itouch,它切割了时间。
保持Kindle,轻巧并联系着真实的阅读。

移动,快速高效至上,并产出浮躁。
琳琅满目,无从选择与尝试。

其实“生活”,并不需要这么多。

硬件需要平衡,性能、便携与续航力。
软体需要平衡,专注、效率与会心一笑的别致。
联系回归真实的“生活”。

被绑架的数字生活

曾什么时候开始,手上的电子产品慢慢多了起来,在享受科技产品带来的便利与精神享受的同时,心似乎也被模式占据了。
直接接触你的不是泥土的松软也不是枯叶的碎落,耐用的工程塑料如影随形。
想了想究竟是什么让我们开始憎恨它,却仍然不能狠心割舍?
那又为什么又会有人把时间浪费在研究信息载体的设备之上?
除了必要的设备/软体的设计生产者,大部分用户将时间用于研究或关注载体,这是浪费效率的一系事。
是罪,创造者的罪。
在你开始纠结如何将信息变着花样便利用户的时候,罪过就已经开始了。

服务产品如何回归人性?

他们就是工具!(不要说你在提供服务,你是kindle还是where与工具无关)

-好的工具 帮人人们更自然的交流 感觉到face2face
-好的工具 建立信任 online-offline touch closer
-好的工具 平台用户感受不到设计的存在(一切发生的自然)
-好的工具 快速想起 快速使用 快速忘记(更closer的与任务贴近 在更自然的场景转化可能)
-好的工具 focus on task
-好的工具 explore只是添加剂

我们浪费了太多的时间在获取信息的方式上。
将要回归自然生活。

移动界面设计点滴(5)——主功能入口设计 tabbar or grid-based

传统的iPhone Android应用主界面功能入口是基于tabbar的设计,区别无非是tabbar的位置是top or bottom。(我们甚至还看到了针对这个位置的讨论,当然两者都有其设计的意义)
而随着产品功能的不断加入,会出现tabbar的空间不能满足需求的情况,你知道iPhone 默认只预留了5个位置(more并不是一个好的设计),在保证主功能可视与可点击的情况下,Android也摆脱不了tabbar设计受限的情况。
是的,我们需要改变这一个传统的设计。或许你在许多应用上已经有所体验——基于grid的设计。

首先,我们再重新回到前面的讨论,tabbar究竟出现了什么问题?综合来看,主要为以下几点

  • 无法满足一次展示全部功能或者更低操作成本下展示的需求。
  • tab切换存在不同tab执行重叠任务的可能,对于用户专注某一flow任务产生障碍。
  • 对操作本身的消极设计,增加误操作的可能性,也成为在单一任务执行时的视觉噪声。

grid-based的设计是如何解决上述的设计?

  • 在一个页面中允许加入大量的icon入口,并通过页面滑动轻松完成对功能的浏览。
  • 结合清晰丰富的功能入口,专注单一功能的流程设计。
  • 页面上更少视觉与可点击元素的加入,更clean的设计。

如何进一步的完善grid-based设计?

  • 我们在windowsPhone找到了答案——live tiles。它承载了更多的信息传达,而不只是icon。
  • 专注单一功能的核心flow,不要妄图在单一任务的操作过程中提供其它功能入口。
  • 随时终止并回到主功能入口的可能。

即便我们在上述的文中将tabbar批判的体无完肤,然而grid-based本身也不是完美主义,面临的挑战在于

  • 页面层次变深,对flow设计提出更高的要求。
  • 如果应用的主要功能不超过5个或者仅是单一功能,你并不需要这样一个扩展性极强的设计。

走完上述的文字,隐约察觉这其实是metro与iPhone/Android的碰撞。我想说,metro是一次设计思维的变革,它使得人们开始归回信息本身,任务被更自然的执行,而不再游离在冗余的页面元素。

在随后的几个月,你也会看到我们参与实现的应用——X。

(译)手持设备的可用性研究

原文 usability for handheld devices versus computers
译文 手持设备的可用性研究

当前有许多用户在不同的特定环境中使用不同的移动设备——包括智能手机、数码相机、MP3播放器、电子书与GPS(全球定位系统)。当用户离开桌面电脑之后,这些用户界面在设备上该如何表现?如何对设备进行设计——包括由硬件驱动的控制、交互模型与功能键布局——这将决定设计与软件应用的可用性。我们如何理解用户在移动中的体验。接下来会回答这些问题,以及更多关于手持移动设备的移动用户体验、交互设计与可用性的问题。

设计中唯一重要的事情是设计本身如何与人相关联。——Victor Papanek

企业逐渐地在电子消费产品中引入更多的高级技术,手持设备每天占用了人们越来越多的时间。用户与手持设备的交互与以桌面电脑为平台的网站有着同样的交互麽?什么类型的挑战是用户日复一日地在使用范围如此之广的手持设备所面对的?什么是可用性专业人员在研究不同平台可用性所考虑的?

单手还是双手?

第一个非常大的问题是,用户需要单手还是双手来操作设备?通常与桌面电脑的网站交互时,在操作一个标准键盘时使用双手,使用鼠标或其它点击设备需要单手。有些时候这个决定是在情景下驱使的。比如,用户在驾驶交通工具操作GPS设备时只有一只空余的手。有些决定是从文化角度驱使的。比如,在日本的智能手机用户习惯于单手操作,因为他们经常在奔驰的列车上用另一只手抓住栏杆。

无论我们打算用单手还是双手使用设备,都会很大程度上影响到我们如何设计它——因此,影响到用户如何理解它的可用性。可用性专业人员需要在计划测试任务与创建测试情景时,将该因素加入考虑。

一个标准的键盘还是不同按键的集合?

当用户与桌面电脑的网站进行交互时,一个标准的QWERTY键盘提供了一个近似的始终如一的交互模型。然而,当与手持设备进行的交互,用户可能需要操作特定的设备或者通过硬控件,如按钮,或直接触摸屏操作控件。手持设备有许多不同的形状,有很多不同类型的控件。比如,Sony阅读器与Amazon Kindle有非常不同的按钮集合。Sony阅读器的特点是有10个数字按钮、一个五维按键集合。Kindle有一个QWERTY键盘、前一页与后一页按钮、一个五维按键集合与一个后退按钮。两个企业设计它们的设备为用户提供更好的阅读体验,它们的设计师在考虑如何使用户与数码阅读设备交互,当然基于不同的想法。五维按键集合可以使它们更容易的上下左右操作。一个QWERTY键盘使得输入更容易。

当与不同类型的手持设备交互时,有时缺乏标准化的体验会增加用户的挫败感。因为缺乏标准化,可用性的专业人员必须为移动设备的可用性做系统化地思考,而不只是专注在一个孤立的按钮。因此问及如用户理解如何使用这个特定的按钮,等类似的问题时,需要有更有意义、更有益的提问——一个特定设备的全部按钮集合如何帮助用户完成任务,用户可以成功地找到操作设备的方式麽?他们在按钮集合中迷路了麽?

什么是设备的应用场景?

用户不会在真空中使用手持设备(宇航员除外^^)。他们在驾驶汽车并使用GPS;或者在列车上与朋友发送短信;或者他们在旅途中使用相机捕捉风景;或者他们在公共汽车上并使用Kindle阅读图书。所有的事情发生在围绕联系用户而创建的设备使用的应用场景——这是设备的用户体验的重要组成部分。用户使用手持设备的情景、环境在评估其设备的可用性时基于非常不同的考虑因素与事件。

例如当用户与数码相机进行的交互,他们经常尝试捕捉好的镜头——可能是一个飞逝的瞬间——有非常短的时间与需要操作相机的注意力。设计师如何优化相机的设计——确保用户可以轻松无误的按下正确的按钮——是相机可用性非常重要的一方面。当用户操作一个GPS时,驾驶通常是一个最高优先级的任务。用户只有有限的注意力可以操作GPS,在驾驶场景中,用户界面的按钮要足够大,以方便使用。这同样是为什么语音命令目前在导航系统用户界面中扮演了一部分的角色。

研究手持设备可用性的方法

上述考虑到的想法是非常清晰地,但在实验室中的可用性测试对于研究手持设备可用性并不理想。当有一个特定的实验室测试环境需要参与者参与,他们会从进入实验室开始即进入一个测试模型。他们开始会思考实验设备,将要在其中发生什么,在测试中什么样的事情他们可能会经历。我听过当进入一个可用性实验室的参与者有像这样的评论“这个是新的…”或者”我在此之前从没做过…”。一旦人们走出实验室,他们会回到原来的自己——开始使用他们自己的手持设备,但与刚刚他们告诉我们他们经常操作的方式完全不同。

虽然参与者在可用性测试中有完全的自由,用户研究者已经创建了一个非常好的测试情景,在实验室的测试还是不能提供丰富的真实生活可以提供的环境。真实生活的文化与环境元素是不存在的。在实验室环境中,不可能重现所有的真实生活的小事件,这些小事件会影响到人们在真实环境中使用手持设备的方式。

理想中,如果一个用户研究者作为一个无形的影子会更好,跟随在参与者的周围而不是强加到他们的现实中。例如,当参与者在驾驶中努力尝试使用一个新的GPS系统,研究者可以坐在他的旁边,观察他的体验中发生的所有问题。有许多的方法可以使得用户研究者、可用性专业人员与参与者走的更近。

对家中或工作的拜访是经常优于在实验室的可用性测试。当研究者与参与者到非常熟悉的地方,参与者在演示典型的日常设备使用会更舒适。参与者与研究者的会话,发生在参与者的日常环境会经常帮助想到使用设备的特定的故事,这经证明是非常有价值的并提供了很好的洞察机会。

短期、纵向研究对于手持设备的可用性研究也非常有益。更长的观察周期是使得参与者能够在一个更松懈的自然的方式体验设备,允许出现更多随机的故障与问题。如果参与者有足够目的明确的保持接触,通过纵向研究在每一天的过程中发生了什么,日记也可以很有成效。然而,回顾日记可能并不是对于所有的参与者都可行。许多人发现在每天晚上保持久坐,并思考一天究竟发生了什么是一件困难的事情。在真实的设备中的日志可能是一个好的替代选择。它会提示参与者去做简单的记录而无须考虑是否需要。

总结

用户从手持设备中,面对着与桌面电脑的网站交互的非常不同的可用性挑战。作为可用性专业人员,我们需要考虑一个设备从单手或双手的使用。同样的我们观察用户与手持设备的交互,这将有益于系统地思考设备的可用性,而不只是局限于独立按钮的使用。

当前情景在手持设备的使用中扮演一个非常重要的角色。家庭或工作拜访、短期、纵向研究、日记比起实验室的传统可用性测试会更合适。

移动界面设计点滴(4)——为了阳光而设计

Lisa是一个sales,一天上午她拿出手机准备定位当前与客户的位置,确定路线。却发现因为过于强烈的光线,看不清列表结果页的地址。
Bill有睡前用手机查看订阅、处理邮件的习惯。却总会因为屏幕刺眼的光线,需要时间逐渐从光晕中适应辨清字体。

类似的场景在日常生活中你或许也有碰到。
部分硬件设备也为其提供了相应的解决方案——屏幕亮度调节,可以手动控制屏幕的亮度,适应不同的环境,以及在更高端的设备上支持的光线感应器。
同时我们也看到应用商所做的努力。更有贴心的是阅读应用的夜晚阅读模式,这为字体与背景提供了弱对比度的配色设计。

但我们在更多的应用软件中发现,对光线环境的设计需求被忽略。
我相信也会有更多的方式与设计,为用户带来良好的针对环境的优化体验。
忘记浮躁的成本效益,专注产品UI设计。

设计原则

  • 布局结构清晰
  • 清晰的布局结构是对一个应用是否可用的基本要求,功能布局层次鲜明,使得新用户通过低成本的学习快速记忆掌握应用的功能布局,能够在短时间内完成既定的任务。

  • 内容清晰
  • 保持图标的简约以及文字的可读尺寸,切忌因为过于追求特效与视觉美感,忽略最基本的可读性。

  • 适合的灰度与色彩对比度
  • 为不同的环境模式提供相应的对比度设计,以减少用户的阅读疲劳,其中仍需保持内容的可读性。

  • 声音事件的反馈
  • 设计不应局限于视觉体验,在enable操作后触发的声音,会让用户确信每一步操作的正确,以及填充某些环境下视觉设计的死角。

  • 适合的环境元素参与
  • 更多具有感情色彩的元素参与,将赋予界面更多的灵性。将weather的元素加入reader不是一件很温馨的事情么?

视觉设计范例

Google Map

清晰的功能引导设计,绿色、红色的Pin可以直观的确认目的地与当前位置,导航列表简洁,可以更可靠的工作在日光之下。

QQ浏览器

提供了白天模式/夜间模式的切换,在夜间周围光线较弱时,一定程度上缓解了视觉疲劳。

商铺点评

为室内/室外环境分别做了配色以及字体设计。在室外的实际应用过程中,更大的字体与对比反差带来了良好的阅读体验。并概念性的加入了天气组件,为出游逛街提供了更多便利。

特例

当然,并不是所有的应用都需要针对性的UI设计,该类设计较适用于内容主导的生活相关应用。在游戏中设计多套色彩模型并不是一个好主意。

Desktop端UI测试概要

最近在做一些测试,为产品的顺利公测做部分支持。

以下为Desktop端的测试。

第一部分: Windows程序UI设计初步

1.背景介绍

UI就是用户界面( user interface ) ,就是人和工具之间的界面。在人和机器的互动过程中,必须经由界面。这个界面实际上是体现在我们生活中的每一个环节的,例如我们开车时候方向盘和仪表盘就是这个界面,看电视的时候遥控器和屏幕就是这个界面,用电脑的时候键盘和显示器就是这个界面,到了使用软件的时候,用户能够通过视觉看到的都是界面。这个界面包括硬件和软件。我们这里讲的UI设计特指Windows操作系统下的软件界面。

用户界面设计有三个基本的原则:a. 置界面于用户的控制之下;b. 减少用户的负担;c. 保持界面的一致性。 从程序设计开发的角度来看,界面设计可以分为结构设计、交互设计、视觉设计三个部分。

结构设计也称概念设计 (Conceptual Design),是界面设计的骨架,通过对用户研究和任务分析,制定出产品的整体架构。基于纸质的的低保真原型(Paper Prototype)可提供用户测试并进行完善。在结构设计中,目录体系的逻辑分类和语词定义是用户易于理解和操作的重要前提。

交互设计是程序的神经,使用户与软件处理部分进行沟通,最终目的是使产品让用户能简单使用。 任何产品功能的实现都是通过人和机器的交互来完成的。因此,人的因素应作为设计的核心被体现出来。

  1)有清楚的错误提示。错误操作后,系统提供有针对性的提示。

  2)让用户控制界面。“下一步”、“完成”,面对不同层次提供多种选择,给不同层次的用户提供多种可能性。

  3)允许兼用鼠标和键盘。同一种功能,同时可以用鼠标和键盘。提供多种可能性。

  4)允许工作中断。例如用手机写新短信的时候,收到短信或电话,完成后回来仍能够找到刚才正写的新短信。

  5)使用用户的语言,而非技术的语言。

  6)提供快速反馈。给用户心理上的暗示,避免用户焦急。

  7)方便退出,如手机的退出,是按一个键完全退出,还是一层一层的退出。提供两种可能性。

  8)导航功能。随时转移功能,很容易从一个功能跳到另外一个功能。

视觉设计是在结构设计的基础上,参照目标群体的心理模型和任务达成的,是程序的脸面,要达到使用户愉悦的目的,包括色彩、字体、页面等。视觉设计的原则如下:

  1)界面清晰明了。允许用户定制界面。

  2)减少短期记忆的负担。让计算机帮助记忆,例:User Name,、Password、IE进入界面地址可以让机器记住。

  3) 依赖认知而非记忆。如打印图标的记忆、下拉菜单列表中的选择。

  4)提供视觉线索。图形符号的视觉的刺激;GUI(图形界面设计):Where, What, Next Step。

  5)提供默认(default)、撤销(undo)、恢复(redo)的功能

  6)提供界面的快捷方式。

  7)尽量使用真实世界的比喻。如:电话、打印机的图标设计,尊重用户以往的使用经验。

  8)完善视觉的清晰度。条理清晰;图片、文字的布局和隐喻不要让用户去猜。

  9)界面的协调一致。如手机界面按钮排放,左键肯定;右键否定;或按内容摆放。

  10)同样功能用同样的图形。

  11)色彩与内容。整体软件不超过5个色系,尽量少用红色、绿色。近似的颜色表示近似的意思。

2. UI设计的一些原则。

对于Windows用户来说,用户认识到的就是所看到的。必须看到的现实就是:界面是面向用户的,用户需要的是开发者开发的应用软件满足其需求,并且易于使用。好的用户界面使得用户不用阅读用户手册或接受培训就能使用应用软件。

2.1 交互设计的一些原则:
2.1.1有清楚的,针对性的操作提示。 使用讯息和标签措辞要适当。屏幕上显示的文本是用户主要的信息源。文本措辞直接影响用户的理解。要使用用户的语言,而非技术的语言。讯息措辞要积极,显示用户处于控制之中,并提示如何正确使用软件。如, “你输入了错误信息”还是“帐号应为8位数”会给用户不同的体验。此外,讯息措辞要一致,在屏幕上显示的位置要一致。
2.1.2让用户控制界面。”下一步”、”完成”,面对不同层次提供多种选择,给不同层次的用户提供多种可能性。让用户知道自己当前的位置,使其做出下一步行动的决定。允许工作中断,方便退出。整个交互过程提供快速反馈。给用户心理上的暗示,避免用户焦急。
2.1.3允许兼用鼠标和键盘等多种输入。同一种功能,提供多种方式。
2.1.4使用非破坏性的缺省按钮。通常每个屏幕定义一个缺省按钮,如果用户按了回车键调用此按钮。问题是有时用户会意外敲击回车键,结果激活了缺省按钮。缺省按钮决不能有潜在的破坏性,如删除或保存(也许用户根本不想保存)。最好的方法是使用组合键来设置按钮,更彻底的方法是去掉默认按钮,这违背了同时支持多种输入的原则,但是在特定的场合是可以考虑的。

2.1.5在操作焦点处打开窗口。当用户双击一个对象显示其编辑/详情屏幕,用户的注意力亦集中于此。因而在此处而不是其它地方打开窗口才有意义。
2.1.6弹出菜单不应是唯一的功能来源,主要功能菜单不应该被隐藏起来。适当使用上下文相关菜单。根据情况提供鼠标右键的这种菜单,缺少过滥都是不科学的。

2.1.7提供标准的常用功能 ,提供界面的快捷方式。如,常用的按钮、菜单应该有和其它同类软件相同的快捷键,一般 打开放在文件菜单下。如果一个菜单项,按下去会弹出一个窗口,那么这个菜单项的文字末尾应该有一个省略号来暗示用户,例如 “打开…”

2.1.8要考虑各种层次的用户的操作水平的不均衡。

2.2视觉设计的一些原则:

2.2.1一致性。保证界面的协调一致。对于列表框来说,如果双击其中的项,使得某些事件发生,那么双击任何其它列表框中的项,都应该有同样的事件发生。所有窗口按钮的位置要一致,标签和讯息的措辞要一致,颜色方案要一致。

2.2.2 界面布局很重要。人们是自左而右,从上而下阅读,基于人们的习惯,屏幕的组织也应当是自左而右,从上而下。界面清晰明了,屏幕不能拥挤,拥挤的屏幕让人难以使用。实验结果(Mayhew,1992年)显示屏幕总体盖度不应超过40%,而分组中屏幕盖度不应超过62%。如果要表达的信息比较多,最好分屏显示。 区域排列。当屏幕有多个编辑区域,要以视觉效果和效率来组织这些区域。区域左对齐是最好的方法。与之相应的标签则应右对齐,置于编辑区域旁。这是屏幕上组织区域的一个整洁有效的方式。 数据对齐要适当。对一列列的数据,通常的作法是整浮点数右对齐,字符串左对齐。 有效组合。逻辑上关联的项目在屏幕上应当加以组合,以显示其关联性。反之,任何相互之间毫不相关的项目应当分隔开。在项目集合间用间隔对其进行分组/或用方框也同样可做到这一点。

2.2.3界面间切换很重要。如果从一个屏幕转换到另一屏幕很困难,用户会很快灰心并放弃。当屏幕流程与用户想完成的工作流程相符,此软件对用户才有意义。由于不同用户工作方式不同,应用软件需要有足够的灵活以支持他们不同的方式。尽可能的提供给用户一个相对容易、自由的操作界面;
2.2.4 提供视觉线索。图形符号的视觉的刺激远远大于文字。尽量使用真实世界的比喻。如:电话、打印机的图标设计,同样功能用同样的图形。加图标的目的是为了使它更醒目,更突出。但是如果不加区分的全加、滥加,反而突出不了重点,都是重点就等于都不是重点。加图标要保持风格一致,不要一个按钮的图标是XP风格的真彩图标,下一个又成了Win95风格的16色图标,到下一个又成了Mac风格的唯美图标,这样一个大杂烩显得极不专业,降低用户的信赖度。
2.2.5色彩与内容。整体软件不超过5个色系,尽量少用红色、绿色。近似的颜色表示近似的意思。颜色使用要适当,得一致,以使整个软件有同样的观感。此外,在不同平台上,色彩的表现不尽人意.在一个系统上看上去很好,在另一个系统上常常看上去很糟,需要考虑软件的运行环境而不是开发环境下闭门造车。颜色的使用要遵循对比原则。确保屏幕的可读性,最好的方法是遵循对比原则:在浅色背景上使用深色文字,在深色背景上使用浅色文字。蓝色文字以白色为背景很容易读,但以红色为背景很难辨认。问题出在蓝色与红色之间没有足够反差,而蓝色与白色之间则反差很大。字体使用要适当。要用那些可读性好的字体,如Times Roman。节俭、有效地使用两、三种字体的屏幕看上去远胜于使用五、六种字体的屏幕。此外,字体的使用要一致,要记住每次改变了字体的大小、风格(粗体、斜体、下划线,……)、样式或颜色,都是在使用不同的字体,就表示了他们的不完全一致。显示一定要考虑用户所使用的输入/输出设备,如触摸设备相对要大些。

2.2.6豪华界面,不适合所有的软件。华而不实的感觉往往来自界面。一般来讲,游戏类、播放器类,需要美丽的界面。

3. 用户的操作

对于用户来说,操作越简单越好,程序的使用思路越清晰越好。下面结合环境简单说明一下常用控件该如何合理使用。

3.1对于较长时间的运算:

建议使用进度条(progress bar)比如要进行数据库操作,需要时间长的情况。使用进度条可以让用户有个等待的时间,否则用户不知道你的程序在干什么,用户对于不明不白花费的时间一般容易恼火。设计的时候,对自己的操作运算时间进行估算,确定是否需要使用。如果只有5秒钟,用户一般是可以忍受的,加入进度条反而会产生画蛇添足的效果。

在使用进度条的同时,可以配合使用状态栏。StatusBar经常被放置在窗体的下面,建议使用dock。可以在状态栏中提供多个面板(pane)来提供不同的信息。 状态栏中,通常都会有一个面板来提示程序运行的信息,例如显示进度,时间等。需要扩展的话,需要owerndrawn属性支持。可以添加按钮等,如取消。一般,在长时间的后台运算开始时,在状态栏中设置开始的状态信息,在计算结束之后,清除状态信息或将状态信息设置为停止状态,在后台运行期间通过状态栏来显示必要的错误信息,提示用户当前的状态。比如,进行一个计算时,开始显示:正在计算,请耐心等待。当运算结束时显示:可以结束,正确退出。

等待指针的使用,在进行计算的时候,尤其在很难计算出这些操作的进度的情况下,设置前台鼠标指针为wait cursor是对用户一个很好的提示。如果有些操作必须是阻塞的,这时需要使用等待指针(wait cursor)也是对用户很好的交代。同样,光标的形状是非常灵活的,合理的使用能够给用户恰当的提示。

总之,使用上面的控件,能通过可视化的方式通知用户有一些程序正在执行过程中,可能需要等待一定的时间。

在程序中合理使用try…finally语句可以达到很好的效果。保证无论遇到什么情况,是正常也还,是异常也好,反正最后都会执行到finally。

3.2操作开始之后,在适当的时候提供必要的程序开关。

用户应当能够通过界面操作取消或终止较长时间的运算。不管你在做什么,都要给用户一个机会,因为用户是程序的使用着。当然,不能让用户,任何时间都可以插手程序的操作,比方,一个数据保存的界面,保存,关闭,取消三个按钮,当正在保存数据的时候,如果强行关闭的话,会导致数据的异常,在这种情况下就需要适当的启用,禁用控件。对于该界面来说,“保存”点击后,禁用“关闭按钮”。在保存处理完毕后,再启用“保存按钮”。

3.3适时合理禁用一些菜单

通过可视化的方式提示用户在运行某些程序的时候某些功能是被禁用的,程序结束后,重新启用一些被禁止的菜单和控件,并通过适当的方式提示用户操作已完成。同时,适当的启用禁用菜单可以使用户更清晰的理解应用程序的工作流程,理解应用程序执行的逻辑。比如用户,一般先要看你界面上什么功能可以使用,什么需要达到一定的前提才能使用。在执行某功能的时候,通过禁用启用,可以知道这个不能执行。当执行完毕后,用户发现,哦,那个按钮亮了,可以执行了。

3.4验证用户的输入,使用validation control。

避免因为用户的失误,导致程序的失败,意外。使用界面友好的MessageBox,注意要在提示对话框中使用适当的按钮和图标,它的重载比较多,根据具体的情况选择不同的图标和按钮。比方说,如果用户强行退出,可以弹出警告,这个时候就应该告诫用户可能产生的不良后果。

3.6使用适当的控件

使用TreeView控件来显示有层次的数据,使用ListView来显示一组具有多个列的数据,使用DataGrid控件可以让用户改变每一个单元格中的数据,使用TabControl可以将窗体中的控件按照使用逻辑进行分类,根据具体的需要开发复合控件,扩展控件,自定义控件。

3.7 合理使用Splitters Docking与Anchoring属性

当窗体放大时,你的窗体上的各种元素是否能够按照比例放大,并且填充区域呢。

用Splitter控件来分离用户区域,使用Dock属性的Fill选项使控件能够填充屏幕的一部分,设置Anchor可以在窗口大小变化时,保证窗体中的控件与窗体的相对位置不发生变化。通过设置

3.8不同分辨率下显示效果的自动调整。

考虑到用户的使用环境,程序在高分辨率下,字体,图片,显示需要随着分辨率自动调整,以满足用户的视觉效果。

3.9通过使用Common Dialog可以让用户通过熟悉的界面来实行标准的操作

ColorDialog,FontDialog,OpenFileDialog等等

3.10对于较长时间的操作,不要阻塞主线程,也就是UI线程

如果时间长的话,建议使用多线程。可以使用ThreadPool.QueueUserWorkItem()来进行异步调用。在该类中,管理线程,QueueUserWorkItem:将方法变成代理,将代理交给QueueUserWorkItem,如果没有其他线程,则立即计算,否则需要等待,给用户提供 取消/停止 的功能。从其它线程中更新用户界面中的控件,需要使用BeginInvoke和delegate。Hook,当前线程中调用的方法,获得另外线程中的方法,在另外的线程中操作。不是用来创建线程,只是让线程去执行想执行的方法。代理 函数指针的封装,自己作为对象 在程序中传递,实现callback机制。在NF2中,使用辅助线程Backgroundworker

3.11关闭确认原则。关闭需要激活原则,使权限不够的用户不能关闭程序。对实时软件尤其重要。

第二部分:UI测试要点

一. UI测试概念

UI测试指测试用户界面的风格是否满足客户要求,文字是否正确,页面美工是否好看,文字,图片组合是否完美,背景是否美观,操作是否友好等等。

用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI 测试还可确保 UI 中的对象按照预期的方式运行,并符合公司或行业的标准。包括用户友好性,人性化,易操作性测试。UI测试比较主观,与测试人员的喜好有关,比如:页面基调颜色刺眼;用户登入页面比较难于找到,文字中出现错别字,页面图片范围太广等都属于UI测试中的缺陷,但是这些缺陷都不太严重。

二. UI测试要点

1. 按功能将界面划分局域块,完成相同或相近功能的按钮框起来, 并要有功能说明

2. 界面要支持按Tab键的自动切换功能;Tab键切换是否正确; Tab键的顺序与控件排列顺序要一直,目前流行总体从上到下,同时行间从左到右的方式;

3. 默认按钮要支持Enter及选操作,即按Enter后自动执行默认按钮对应操作

4. 菜单点击,窗口初始化

5. 父窗体或主窗体的中心位置应该在对角线焦点附近;子窗体位置应该在主窗体的左上角或正中;多个子窗体弹出时应该依次向右下方偏移,以显示窗体出标题为宜

6. 在各种分辨率下是否显示正常

7. 前景与背景色搭配合理协调,反差不宜太大,最好少用深色,如大红、大绿等。常用色考虑使用Windows界面色调。

8. 如果窗体支持最小化和最大化或放大时,窗体上的控件也要随着窗体而缩放;对于含有按钮的界面一般不应该支持缩放,即右上角只有关闭功能。

9. 窗体能否多次正确关闭,打开

10. 滚动条是否能拖动,并可通过键盘自动拖动

11. 与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示,没法使用该按钮)。

12. 对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会,如删除确认提示,退出前确认是否保存

13. 可写控件的数据类型及长度,尽量在前台进行控制

14. 非法的输入或操作应有足够的提示说明, 让用户明白错误出处,避免形成无限期的等待,提示、警告、或错误说明应该清楚、明了、恰当;提示顺序按Tab顺序

15. 对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符, 特殊字符常有;;’”><,`‘:“[”{、|}]+=)-(_*&&^%$#@!,.。?/还有空格

16. 在读入用户所输入的信息时,根据需要选择是否去掉前后空格。

三. 一般客户端测试逻辑划分

1. 标题栏

a、标题文字描述的正确性

b、标题栏中(最大化、最小化、关闭)按钮,根据窗口的特性,如没有最大化或者最小化状态的窗口,应该不显示最大化和最小化按钮,或者把按钮Disable状态显示。

2. 文字

(1)文字描述的准确性:

a、检查文字的描述和所对应的功能是否一致;

b、检查错别字。

(2)文字用语的一致性:

(菜单、界面按钮或者Label等、ToolTip、窗口标题)比如选项设置,在主界面的有按钮可以进入选项设置对话框,或者菜单中有菜单项可进入选项设置对话框中,那么,按钮、菜单、对话框的标题都应该统一用词,如用“选项”或者“设置”,而不能又用“选项”,又用“设置”,或者还有其他的的用词。

(3)为了全面的检查所有的文字,应该检查程序中的所有文字资源,因为一些对话框可能比较难在黑盒测试的时候能全部都出现过。

3. 控件

(1) 控件对齐:

a、 并排关系的控件间应该左对齐,同行的控件应该横向对齐。

b、 有所属关系的控件应该缩进。

(2)控件状态:

a、不能操作的的控件的状态应该为Disable,这样界面也起到引导用户使用操作的效果。

b、有依赖关系的控件,比如(几个选项供选择(CheckBox或者RadioBox),每个选项下面都有独立的设置(其他的控件:Edit、 ComboBox、CheckBox等),那么当所属的选项没有选中时,下面的控件应该是Disable的,相反为Enable。

(3)控件的TabOrder

控件的TabOrder应该依次从上到下、从左到右的顺序,界面中默认的TabOrder应该落在界面上的第一个Enable状态的控件上面。

(4)控件的右键菜单支持

允许输入的控件都应该支持右键菜单,方便习惯使用右键菜单的用户复制、剪切、粘贴、全选等操作。

(5)控件的操作方式

a、单行文本的Edit输入框中,对回车符的支持:回车默认操作是本窗口中的“确定”按钮的功能。

b、在可操作的列表控件(List、ListView)中,鼠标双击的操作、键盘操作都应该有对应的默认操作。比如下面的图中,双击列表中某一项,默认操作就是Modify按钮的操作;双击列表中的空白处,默认操作应该是Add按钮的操作;选中列表中的项的情况下,按下Delete键,默认操作应该是 Remove按钮的操作。

(6)Edit控件对输入的有效性判断

a、类型判断:整型、浮点型的数据输入框中,不允许输入非表示数据的其他字符串(如:abcd或者其他字符等);

b、大小判断:数据类型的数据如有大小范围限制的,要对输入的大小进行判断(如:表示月份的输入框中,只能允许输入1-12的数字。

c、长度判断:如果是程序处理的字符串有长度限制,但是输入框中没有对输入的数据长度进行限制,将有可能会造成程序错误,或者处理后的结果和输入的不相符合。

d、正确性判断:表示路径的或者文件名全路径的输入框,要对输入的路径是否为有效的路径进行判断,如:输入aaaa或者 C:\//等为不正确的输入。

4. 图片

图片显示的篇幅不要太大。

5. 界面整体的颜色搭配

6. 窗口在任务栏上的系统菜单

每个应用程序,如窗口在系统任务栏上有缩小图标的,都应该有系统右键菜单的支持(还原、最大化、最小化等),要测试右键菜单中各个项的Enable和Disable状态的正确性以及功能的正确性。

7. 提示对话框测试

1、文字描述的正确性

2、图标显示的正确性:

a、程序错误、操作错误、禁止操作等的提示:MB_ICONHAND, MB_ICONSTOP,MB_ICONERROR

b、询问的提示:MB_ICONQUESTION

c、感叹、警告的提示:MB_ICONEXCLAMATION ,MB_ICONWARNING

d、普通信息的提示:MB_ICONASTERISK,MB_ICONINFORMATION

第三部分: UE测试概要

UE(User Experience 用户体验):指的是软件应用和审美价值,是以用户至上的观点作为基石的。主要由以下四种因素构成:
1、印象(感官冲击)
2、功能性
3、使用性
4、内容
这些因素相互关联,不可分割,共同形成正确的用户体验。这些因素也是一个软件成功必不可少的主要因素。其中“印象”也可以归结成这个软件塑造的一个“品牌”效应。

用户体验是一种纯主观的在用户使用一个产品(服务)的过程中建立起来的心理感受。因为它是纯主观的,就带有一定的不确定因素。个体差异也决定了每个用户的真实体验是无法通过其他途径来完全模拟或再现的。但是对于一个界定明确的用户群体来讲,其用户体验的共性是能够经由良好设计的实验来认识到。

用户体验主要是来自用户和人机界面的交互过程。在早期的软件设计过程中,人机界面被看做仅仅是一层包裹于功能核心之外的“包装”而没有得到足够的重视。其结果就是对人机界面的开发是独立于功能核心的开发,而且往往是在整个开发过程的尾声部分才开始的。这种方式极大地限制了对人机交互的设计,其结果带有很大的风险性。因为在最后阶段再修改功能核心的设计代价巨大,牺牲人机交互界面便是唯一的出路。这种带有猜测性和赌博性的开发几乎是难以获得令人满意的用户体验。至于客户服务,从广义上说也是用户体验的一部分,因为它是同产品自身的设计分不开的。客户服务更多的是对人员素质的要求,而已经难以改变已经完成并投入市场的产品了。但是一个好的设计可以减少用户对客户服务的需要,从而减少公司在客户服务方面的投入,也降低由于客户服务质量引发用户流失的机率。

现在流行的设计过程注重以用户为中心。用户体验的概念从开发的最早期就开始进入整个流程,并贯穿始终。其目的就是保证(1)对用户体验有正确的预估(2)认识用户的真实期望和目的(3)在功能核心还能够以低廉成本加以修改的时候对设计进行修正(4)保证功能核心同人机界面之间的协调工作,减少BUG。

在具体的实施上,就包括了早期的focus group(焦点小组),contextual interview,和开发过程中的多次usability study(可用性实验),以及后期的user test(用户测试)。在设计–测试–修改这个反复循环的开发流程中,可用性实验为何时出离该循环提供了可量化的指标。