
- 本栏最新文章
- 信息化软件和图形界面1 05-12
- 脚本代码:实例解析Js+XML的操作方法 05-11
- 控制电脑关机或者重新启动的JS代码 05-11
- 服务器端可控情形JS跨域访问解决方法 05-11
- 用Javascript制作声音按钮 05-11
- asp文件打不开的原因 05-09
- AJAX中文乱码的两类问题 05-09
- 提升JSP页面响应速度的七大秘籍绝招 05-08
- 页面乱码解决4种方案 05-08
- 在JSP环境中如何配置和使用fckeditor 05-08

- 本栏推荐文章
- Photoshop教程:水灵灵的美女调出来 12-30
- AS3与后台交互 12-21
- AS3通俗教程---AS3自身loading制作 12-19
信息化软件和图形界面1
暴长的文章,一根筋的就给翻译了,还是没翻完,有人看得话就找时间翻完,翻译水平很业余,见谅。
原文:Magic Ink - Information Software and the Graphical Interface
作者: Bret Victor
交互性被认为是不利的
Chris Crawford为交互定义了一个三个阶段的进程:获悉指令,判断含义,作出回应。对于操作型软件来说,交互是十分有必要的:用户通过查看所呈现的内容,判断并执行下一步的操作。软件进而执行用户的操作要求,显示更新的内容。能循环反馈并有效执行的交互就像是在同软件"说话",过程顺畅且迅速。它的操作体验无异于使用通常的物理工具。
而信息化软件则恰恰相反,它类似于我们平常生活中的“阅读”,而不是操作。它的目标是“认知”──构建一个意识上的模型。因此,用户需要聆听软件,思考它说了些什么…而手动操作则很少出现。手动操作存在的唯一理由就是它能够明确提供一些情境,使得软件能够在缺乏关联数据的初期积累更多信息。对信息化软件而言,所有的交互基本上都是围绕数据空间进行的。
例如,Amazon的数据空间是由其分类目录组成的。黄页中包含了所有企业名单;电影指南中包含所有上映时间和电影资料;机票预订中包含了所有机场的行线信息。在所有这些情境中,每一次的交互,包括点击鼠标,敲击键盘,搜索关键词和选择菜单,都是为了将用户的视线吸引到数据空间。简单来说,这就是导航。
Alan Cooper把在认知过程中的附加工作比作是使用工具时的额外负担──它无法直接到达目标。举例来说,给机车加油只是让它作为了汽车运行的动力,而并没有让车到达目的地──这才是最终目标。Coopper断言,软件导航只是个完成目标的中介。
关于导航,最重要的是要知道,几乎在所有情况下,他代表着纯粹地附加工作。或者至少很接近附加工作。除了在游戏里,用户目标就是成功的穿越障碍或迷宫来成功导航之外,在软件里,导航不能满足用户的目标‘需要或者期望,不必要的或困难的导航会成为用户沮丧的主要原因,实际上,在作者看来,糟糕的导航是任何应用软件或者系统──桌面的,基于Web的或者其他系统设计中的头号问题。
如果所有的交互都只是导航,那导航就应该算做是头号软件问题,它另交互看起来糟透了。不过,与其他两种情境关联的来源相比,互动性还存在更为严重的问题,而不仅仅只是令人沮丧地浪费时间:
用户必须明确知道她想要什么才能要求获得什么。而那些提供历史数据和环境关联的软件可以主动为用户推导出潜在的相关信息,否则,用户自己不会有明确的概念去要求获得这些信息。纯粹的交互软件迫使用户提出明确需求。
用户不得不清楚如何发问。也就是说,她必须学会操作一台机器。 Donald Norman提出的关于确定用户“心理模型”的观点在软件可用性领域已经得到普遍认可,而且被认为是一个核心的设计挑战。但是,Norman在当初提出这个概念主要针对的是机械设备领域。因此,它只适用于那些包含机械隐喻的软件,它们才需要确定用户的“心理模型”。而一个低交互性,非机械隐喻模式的信息图形能让用户和设计师从“心理模型”的束缚中解脱出来。
导航意味着规则。导航只所以在软件中存在,是因为用户很容易迷失方向。导航越多,说明迷失的可能性越大。操作的规则越多,说明人们越容易操作出错。操作规则是人们害怕使用电脑的主要原因──条条框框越多的东西越容易出错。
此外,互动暴露了身体的劣势。手动比眼动要慢得多。 Licklider这个词形容花费数小时绘制图形而只需花几秒就能看完它们。这同样可以用来形容用户必须手动索取资料的状态──不能合理分配鼠标点击和眼睛查看的时间,她大部分时间都被用于操作航行而不是获取信息。此外,用户可能更愿意在用眼睛获取信息的同时用手干点别的,例如写字,吃东西或抚摸猫咪。每当软件占用用户的双手,都意味着其他本可以并行的事被打断。最后,越来越多的与电脑有关的由于重复性操作导致受伤的案例表明,不加选择的互动行为对身心都会产生伤害。
不幸的是,那些致力于电子产品人因工程的团体都将术语锁定为“交互”。对于信息化软件来说,真正的重点是情境关联,交互只不过是实现它的一个手段。特别是在只能通过鼠标笨拙地点击进行 “输入”时,交互应该只能被当作是最不得已才使用的手段。
可能会有设计者提出抗议,认为交互在实践中是不可避免的,甚至认为我的理想──无交互软件,只是无稽之谈。这只是因为该想法一直未得到重视和发展。我相信,随着发现更新的情境关联图表模式,探索更好的获取和利用信息环境及历史数据的手段,“点击”和“拖拽”这两个当前用于信息检索的典型手段将被认为是可笑的老一套。但是,由于学术界的倡导和商业公司的附和,“交互”仍会在未来持续存在一点时间。
减少交互
当某个软件迫使用户进行交互,它就把自己判定为操作型软件。软件的外部模型通过对导航进行操作形成情境模型。但是,不同于真正的操作型软件,用户不关心这个外部模型──它只是为了最终看到相关信息的一种手段。
设计者的目标是让用户以尽可能少的操作塑造出情境模型。假设将图形设计,历史数据和环境关联等手段被抛在一边,他们就没有什么技术手段可以减少交互带来的负面影响了:
形象化操作能将情境模型应用于适当的信息集合中。
相关性引导能让用户确认模型,而无需建构模型。
紧凑的反馈循环能让用户无需太多操作便能接近结果。
形象化操作。命令行系统被批评为强迫用户来学习电脑的语言。现代的图形界面可能会更容易使用,但它相对前者在这方面没有太大的改进。图形界面语言是由菜单,按钮,以及确认框组成的,每一个控制元素都是非情境化的。用户要通过一个特定的的指令输入需求──它完全不同于任何人类语言,缺乏形象化的含义且很不自然。
打个比方,看这个男孩如何向别人“演示和描述”他的玩具:
话由于这个孩子的描述能力不强,他只能通过演示来传达复杂的概念。同样地,图形界面的发展并不完善,使得文字提示繁琐且晦涩,但软件的动态传递是理想的演示方式。用户可以点击某处的信息图形,说:“就是这儿!”,来获取该处的关联情境。
两个最根本的描述情境的条件便是“时间”与“地点”。几千年来,人们都以这两个条件为基础来绘制专门的信息图表。但仍有许多现代软件放弃了这一传统做法,看这家网上热门的搬家公司:
这些下拉菜单既突兀又没能显示充足的信息。地理位置应该从地图上找,而日期应该从日历上选。这是重新设计后的效果:
这个设计也并非最理想。地点和日期信息应该能从用户既有的地图和日历上提供。但在满足这样需求的平台普及之前,软件至少应该提供类似的临时服务。
作为进一步应用特定情境的一个例子,看一个主流的网上花店设计是如何让用户局限在下拉菜单里的: 对比另一个简单的可视化导向设计:






