[心缘地方]同学录
首页 | 功能说明 | 站长通知 | 最近更新 | 编码查看转换 | 代码下载 | 常见问题及讨论 | 《深入解析ASP核心技术》 | 王小鸭自动发工资条VBA版
登录系统:用户名: 密码: 如果要讨论问题,请先注册。

[转贴]相册的显示与管理中的交互设计

上一篇:[转贴]JS从类内部设置timer调用类本身的函数
下一篇:[转贴]Javascript的IE和Firefox兼容性汇编

添加日期:2006/7/12 11:26:06 快速返回   返回列表 阅读4613次
http://www.chinaui.com/article/detail/20051209120639.html

  许多网站都提供“个人相册”这种服务。用户只需要申请一个帐号就可以在互联网上拥有一个自己的相册了。提供一个能够达到温饱水平的相册需要有稳定的服务器,健壮的程序和足够的带宽,要想提供一个“奔小康”的相册,那就需要在交互设计上做更多的工作了。
 
  图片的浏览从设计上可以分为两类:列表式和幻灯式。
 
  列表式是指:相册中的各个图片文件以列表排列,点击后在新的页面中显示完整的大图。列表可以是文字列表,也可以是所略图列表,显然所略图的列表更便于使用。这种方式的特点是文件列表和最终的显示在不同的页面中显示。
 
  幻灯式是指:相册中的各个图片文件或横向或纵向在页面中占用一小部分空间排列,页面中的主要区域作为“图片显示区域”,用于显示实际的大图,点击文件列表中的某一项,其实际大小的图片在页面中的图片显示区域显示。文件列表和大图显示在同一页面中。
 
  下面针对这两种显示模式各选一个代表加以分析:列表式的代表是“yahoo!相册”,幻灯式的代表是“MSN Space相册”。
 
  yahoo!相册的浏览界面主要由三个页面组成:
1。相册的首页,用所略图显示全部的相册;
2。XX相册页,显示某一相册内的全部照片的所略图;
3。最终显示页,显示某一张照片,并提供照片的相关信息和功能。

按此在新窗口浏览图片
 
  yahoo!相册的管理界面与浏览界面基本一致。在管理界面中,用户可以看到的内容则可以编辑,并为这些编辑功能设计了相应的操作页面,比如,选择上传文件页面,编辑标题和简介页面。这种可见即可编辑的设计将在本文的后半部分详细分析。
 
  yahoo!相册的设计保证了每一个页面显示的内容量较小且性质相同。在相册首页只显示此用户的所有相册;在XX相册页只显示当前相册的标题、介绍和此相册中的照片所略图;在最终显示页只显示用户选中的照片。这种单一化的显示尽可能的减少了干扰用户的信息,使得用户的任务流清晰、快捷。
 
  列表式的显示模式是图片浏览常用的模式,随便打开一个大型网站,几乎都有“图片”栏目,其中整合了这个网站中所有的图片新闻,以列表显示,点击后打开相应的图片新闻。常用的图像浏览软件ACDSee也使用着类似的方式,由于是客户端软件,可以使用鼠标左键双击来切换列表与最终显示。
 
  但是在web界面中应用列表式的显示模式也存在缺陷:由于所略图列表与最终显示页不在同一页面中,用户需要反复在列表页于显示页切换,而在web界面上,切换操作又没法象ACDSee那样通过双击左键来完成。
 
 
  幻灯式的显示模式相比之下应用并不那么多,但是这种方式确实提供了更好交互功能,典型的代表是MSN Space。

按此在新窗口浏览图片
 
  MSN Space的幻灯式的浏览界面只有一个,在页面顶端有一个下拉选择框,用于选择不同的相册,页面正中最大的区域显示大图,实现了最终显示页的功能,页面下部有一个类似视频播放器的控制台,可以对相册中的照片实现一系列浏览操作,并且提供了此相册中全部照片的所略图,这个控制台可以在适当的时候隐藏,基本上解决了“干扰信息”问题,同时避免了反复切换页面的麻烦。
 
  设计幻灯式的显示模式通常会面对“所略图列表如何排列?”的问题,无论是横向还是纵向都要限定在一定的空间范围内,因为如果页面过宽或者过长,“大图显示区”会移出页面,此时点击所略图,只能将页面跳转至“大图显示区”来显示用户希望看到的照片,而用户刚刚点击过的所略图却跳出了页面外。如果是横向排列,用户的鼠标通常是没有横向滚轮的,想要浏览列表需要拖动“拖动条”;通常鼠标是有纵向滚轮的,似乎列表纵向排列是合理的,但这个幻灯式的整体界面对于不同分辨率的显示器很难保证始终不出现纵向拖动条,那么,在这个页面中很有可能出现两个纵向拖动条,两个纵向拖动条的不便,我想大家在撰写email的时候都有体会了。
 
  MSN Space选择了横向排列,并且结合其控制台上的其他功能将有可能出现的横向拖动条设计成了视频播放器中常见的“进度条”。干脆让用户不要把它理解成拖动条,那么拖动条的不便之处也就“与我无关”了。
 
  除去上面说的这个问题,MSN Space这种显示方式存在的更为深层次的问题:编辑状态与浏览状态不统一。
 
  在Alan Cooper的《ABOUT FACE 2.0》中提到一条重要的“公理”:“在有输出的地方允许输入。”对于web界面来说,显然不能做到随时的输入。对这条“公理”我们可以引深理解为:可以输入的管理界面应当与前台的显示界面一致,也就是说,后台管理与前台浏览的输出效果一致。管理界面可以理解为一个添加了编辑按钮的浏览界面,于是,管理界面这个有输出的地方同时也有允许输入了。
 
  图片的管理,到目前为止,比较理想的方式仍旧是列表式的。当用户需要管理自己的相册时,应当看到相片的所略图列表,对列表中的各个文件进行删除、重命名、移动等操作,对管理操作而言,用户通常对自己要管理的照片比较了解,在加上网络带宽带来的显示延迟,用户往往并不希望一个幻灯式的显示模式下管理自己的照片。MSN Space的管理界面虽然在“照片”的首页也采用了幻灯片式的显示,但是真正的管理操作却都是在列表式的显示界面中完成的。

按此在新窗口浏览图片
 
 
  MSN显然也认识到了“编辑与显示不统一”这个问题,为了最大程度上消除这一问题,使用了一个比较巧妙的方法:将用户管理操作的最后一步设定为返回幻灯式的显示界面。
 
  在MSN Space的相册中,用户的管理操作可以分成三类:添加相册和照片、编辑现有相册和删除现有相册。
 
  对于添加相册和编辑现有相册两个任务流,当用户最后一步点击“完成”的时候,系统将保存结果并返回幻灯模式,显示用户刚刚保存的结果显示在自己的space上将是什么样子。虽然在操作过程中用户并不能随时看到自己space的显示效果,但是只要完成一个完整的任务,就能显示一次修改的结果。
 
  对于删除操作,由于交互过程相对简单,所以在幻灯模式下就能够完成,对于当前显示的相册执行删除操作,相册很简单的就被删除了,但是,删除之后却出现了一个小麻烦---页面上该显示些什么呢?MSN的设计人员意识到给用户显示下一个相册是不合理的,用户的操作只是要删除当前相册,并不意味着删除后打算看下一个相册,并且也许下一个相册中有大量的照片,由于要显示所略图,页面将有可能进入一个相当长的载入过程,于是MSN的办法是:什么也不显示。在页面顶端的下拉选择框中显示“选择相册”条目,示意用户当前并没有在任何一个相册中。我曾问过许多朋友:“MSN Space的照片栏目中,下拉选择框中的这个“选择相册”是干什么用的?”始终也没有得到过有说服力的解释,看到这里我想我们都应该明白这个“选择相册”条目的作用了。我们可以将这个设计理解为:幻灯式显示模式的主体是针对一个相册的显示,而用户在操作过程中将有可能出现不在任何一个相册中的情况,那么则显示“选择相册”。这个设计终于可以理解了,但似乎仍旧不可接受。
 
  之所以会出现这样奇怪的显示,归根结底还是幻灯式显示模式在管理操作中的不良反应。如果是列表式显示,用户要删除某一相册,删除按钮会在现有相册的列表页,返回的结果页也是现有相册的列表页,这样的显示显然更容易理解,在现在的相册列表中,刚才选择删除的相册消失了,用户的删除操作得到了良好的反馈。
 
 
  幻灯式的显示来源于windowXP操作系统中的“幻灯片”模式,而列表式的显示则源于window传统的文件所略图浏览模式。使用用户熟悉的方式显然是好的思路,减少了用户学习新界面的过程。
 
  网页似乎是可以无限长的,无论是列表还是图片显示区理论上都可以无限制的排方放在一个页面中,但是用户的接受能力是有限的,当用户专注于某一部分内容时,其他的内容往往是多余的,有干扰的,另外过多的所略图列表会使很多所略图远离图片显示区,用户点击时,页面将大幅度的在一个页面内跳转,经常面对这样的操作,用户会出现胸闷,憋气,头晕、恶心等不良反应,不知道最近报道的“上网时间过长,导致猝死”的事件与糟糕的网页设计是否有直接关系?至少我们应该承认,用户对一个页面中的内容是有一定的承受限度的。
 
  互联网似乎是无限大的,但是用户的接受是有限的,即便是雷锋也只能将有限的接受能力投入到无限的互联网世界里,而我们要做的是将无限的互联网设计成有限的接受能力所能接受的样子。这种将大象装进冰箱里的任务完全不是笑话,我们每天都在面对。如果你还没有为这个问题苦恼过,也许是你还没意识到冰箱有多小,大象有多大。
 

评论 COMMENTS
没有评论 No Comments.

添加评论 Add new comment.
昵称 Name:
评论内容 Comment:
验证码(不区分大小写)
Validation Code:
(not case sensitive)
看不清?点这里换一张!(Change it here!)
 
评论由管理员查看后才能显示。the comment will be showed after it is checked by admin.
CopyRight © 心缘地方 2005-2999. All Rights Reserved