掌握可用性规则[2]

发表于:2010-05-27来源:作者:点击数: 标签:规则
掌握可用性规则[2] 软件测试 2. 不要急于具体化 开发者一贯倾向成为一个 解决方案 的提供者,喜欢解决问题并希望能尽快看到努力的结果。有时这种快速获得结果的倾向性导致的是一个平庸的解决方案。现今的可视化开发工具更是鼓励了这种倾向,纵容我们简单地通

  掌握可用性规则[2]   软件测试

  2. 不要急于具体化

  开发者一贯倾向成为一个解决方案的提供者,喜欢解决问题并希望能尽快看到努力的结果。有时这种快速获得结果的倾向性导致的是一个平庸的解决方案。现今的可视化开发工具更是鼓励了这种倾向,纵容我们简单地通过在屏幕上拖放预先定义的组件来解决界面设计问题。举例来说,通常很少考虑组合框还是一个下拉列表是最好的选择。在开发早期不要急于具体化,开发者和小组在开发过程中可能创建更可用的设计并提出高超的用户界面设计方案。不要过早定义实现的细节,而应在更好理解所需完成的工作和更好把握用户工作流程中的每一个步骤的意图之后。如果开发小组已经跳跃到实施具体方案的阶段,应注意在设计过程中将那些想法置于一个“反馈—提出”的循环中。

  一些技术如抽象原型,能以一种通用的方式在贴纸上表达必需的用户界面元素,可以帮助开发小组先关注整个用户界面结构。抽象原型技术能够保证软件提供所有必需的组件,也能保证逻辑地安排这些组件,而非早早地进行界面图形设计和界面组件选择。

  3. 避免为创新而创新,不要成为时尚的奴隶

  界面设计中新的东西并总不是好于旧的东西。应用得当的话,新的界面组件和交互设计方法将是一个强大的工具并将占领市场优势。过不多久界面设计领域里真正先进的的方法就会被拷贝流传而成为标准设计词汇的一部分。但是,许多创新的界面设计比传统的界面组件和交互设计可用性更差。

  另外要注意的是避免为艺术而创建艺术品。我所见到的一些可用性最差的软件就是图象艺术家或即将成为图象艺术家的作品,他们迷失在视觉效果里最终导致不可辩识的控件、可读性差的布局、不能工作的导航设计。效率和美学并不总是互斥的,相反,最好的软件是两者的结合。虽然人们的艺术的才能总是有限,但是可以集中注意力创建有效、高可用性的满足用户需求的软件。

  最后,不要假定界面设计应模仿一种特别的微软模式或应用至少一种最近的界面组件。用户界面设计有自已的流行趋势,重要的是保持现状。新的组件和交互术语(idiom,Alan Cooper 的称呼)每天都在产生。就象房子、车子或者衣服,软件的风格在变化和进步,但只要简单地看看用户界面设计就可以跟上当前系统设计。特别地,如果设计的软件的运用与微软的应用紧密结合或关联,在很多情况下,这是一个合理的选择。然而,追随领导不是一个通用的解决方案。有一个例子,是我领导评估一个模仿Microsoft Excel界面设计的货币交易系统的可用性。设计的决策使得用户可视分析信息非常困难,从而导致笨拙的、低效率的导航。货币交易员需要的新交易系统并不是微软电子数据表的界面设计。

  4. 努力建立有效的交互

  没有人喜欢乏味、笨拙的工作。确认你的软件没有增加其他人工作的不愉悦感。计算完成一项普通工作所需的击键次数和点击鼠标的次数。让简单的事情简单处理、常用的交互快捷完成。不要将重要信息或关键处理淹没在多个窗口之下或者隐藏在一个“名不符实”的菜单里。应用建模技术如导航映射来帮助设计高效的工作流和避免过长或导致死结的导航路径。只要在纸上画一个原型,用户界面设计的原则如基本效率、任务一致性和任务可见性就可以用上,并且能指出问题所在区域。

  正如令人难忘的Dilbert 的漫画指出的一样,一些软件开发者为用户设计了额外的无意义的步骤,惩罚用户犯下的任何错误,让用户象跳圈一样完成日常工作。如果小组里某些成员显得憎恶用户,让他去见见临床医生,而不要在“Edit”菜单里加上”Other”。

  5. 为实际工作试用界面

  作为最后一个保证用户界面设计质量的措施是:让每个设计和开发软件的成员最少连续半小时使用它,连续使用一个小时更好。使用实际的数据——用户实际使用的数据。如果由于保密或安全的原因不能使用实际工作的数据,可以让客户或用户建立足够多的“伪数据”(不仅仅是10 到20 条记录),能精确反映实际数据的复杂性、潜在的错误和模糊性(subtleties)。作为一个独立的校验,确信测试了所有数据域的最大长度,正确性和过率检查。经常令人惊讶的是在数据库正确定义的域在用户界面上却是长度不够或定义不当。如果定义的数据域是25 个字母的长度,试着输入25 个字母。你能在屏幕上见到所有的25个字母吗?如果需要的话,邮政号码的输入框能处理国外字母和数字混合的编码吗?

  是的,在许多公司这些问题都会归结于质量保证和数据库设计部门,但是,令人吃惊的是它一直被疏忽。所以,应用用户界面试用的经验来测试系统自身。注意到测试的过程象是汽车装配线的最终检查——客户将要看到和体验到。如果界面包括了数据输入域,输入50 或100 条记录,而不仅仅是1 到2 条记录。如果应用程序工作在不定的光照和噪音情况下,在这种环境条件下试用它。如果必需快速输入或屏幕快速反应,将开发小组所有成员置于同一个时间限制的压力下,然后问自己:每天我都想使用这个软件吗?我希望这些技巧能帮助你或开发小组回答:“是的”。

原文转自:http://www.ltesting.net