标签归档:Tag

商品评论的Tag模式

这是再次扯起商品评论这个话题了,09年12月的UCD书友会话题就是“商品评论的设计”,当时我在引导讨论的时候主要涉及到的是很具体的问题,并没有做太大的发散,现在继续来扯….

在商品评论这个问题上一直存在一个矛盾,就网站而言是希望通过点评收集越多的信息越好,而对用户而言则是希望花费越少的成本越好,当然,不排除很乐意点评的情况,比如一个点评5块钱或者晒单。在这个矛盾下造就目前的电子商务网站点评情况是,产品设计师把表单设计的越来越长,用户需要手动输入的东西越来越多,网站运营起来越发困难,不能不花钱买点评(许多点评网站都是这么起来的)。
我小样本的抽查了京东商城的商品点评(如对E71的2000余点评),至少发现3个问题:①用户对“总结”这个表单项不知所错,不知道该写什么;②用户对优点、缺点、总结的输入超过50字的不足10%;③逐条看优点、缺点,很累也不利于数据挖掘。

我们再回到电子商务网站商品点评的本质,商品点评的主要作用是什么?我认为是引导用户快速的作出购买决策,而用户所发出的点评其实是拿商品本身来与自己理想的商品做对比。
这里,我觉得商品点评(上面说的是电子商务网站的点评)应该分为2个大类:引导用户形成购买欲望、引导用户快速作出购买决策。前一种一般由资讯站点与导购站点完成、后一种由电子商务平台自己完成。
作为让用户形成购买欲望的点评必然是图文并茂最好,而作为引导用户快速作出购买决策的点评,我的看法是,越简单越好,越直观越好!所以,长文本框的输入必然不是好的选择,多表单的常文本输入框更是一厢情愿!

那,引导用户快速作出购买决策的点评表单该是怎样的?我们先来看个我曾在新浪微博上提到的例子

这是美国著名的比较购物网站Shopping.com的点评系统的部分截图,其前身是一个购物搜索网站,后期的时候收购了当时美国火爆的点评网站epinions.com。在收购之后他对epinions的点评系统做了改进,整个表单包括打分(5分制)、撰写标题、以checkbox的形式选择出商品的优缺点与最佳用途(允许自定义)、详细描述、是否推荐给朋友。而在前台展示的时候shopping.com对checkbox中的标签根据用户选择的热度只显示最热的部分。
实际上Shopping.com的点评表单就是一个Tag模式的数据挖掘,这种标签模式极大的提高了用户的点评成本,同时用户在浏览的时候也能更加迅捷的知道该商品的性能属性。

当然,我并不认为shopping.com的这种表单设计符合中国网页的设计,我看到确实有点评网站汉化了shopping的这种点评表单,但是,这确实不是一个好做法!
首先,checkbox的做法会让表单显得很长,依旧没有完全的解决我之前提到的最大程度降低用户成本的做法;其次checkbox不是最低成本的用户交互模式;第三,我觉得作为一个比较购物网站,shopping的这种必须要求填写点评标题和内容的设计也是值得商榷的。
我的改进想法:①、利用Tag点选的模式来取代checkbox组件;②、把打分与点评分开。在打分的时候包括5分制的打分和Tag点选模式的选择,点评内容隐藏起来,加一个checkbox选项“不过瘾,我想再说点什么”;在选择点评的时候则显示完整的表单。

目前,没有看到中国的电子商务网站有使用这种低成本且便于做数据挖掘的点评系统出现。我认为,这种模式(不是指这个样式!)会是一种巨大的变革,会是对电子商务产品设计有非凡的价值,那,谁会是第一个有勇气革命?

UPdate:2010年3月28日 ,接内部读者举报开心网(kainxin001)的转贴点评设计(如下图)跟我改进过的shopping的Tag模式类似,牛逼!
原来淘宝UED在去年的时候在淘心得部分的点评中已经实现了我的这个想法,拜服,拜服!

什么是元数据(MetaData)

在读《Web信息架构》的时候第九章讲到叙词表、受控词表和元数据。当时书中的定义很模糊,所讲的篇幅也少,就没有在意,一直也没有能完全理解。今天在读《锦绣蓝图》的时候第四章中再次提到元数据这个概念。遂多查了些资料认真的理解了一下。

什么是元数据?

元数据(Meta Date),关于数据的数据或者叫做用来描述数据的数据或者叫做信息的信息。
这些定义都很是抽象,我们可以把元数据简单的理解成,最小的数据单位。元数据可以为数据说明其元素或属性(名称、大小、数据类型、等),或其结构(长度、字段、数据列),或其相关数据(位于何处、如何联系、拥有者)。

举几个简单的例子:
使用过数码相机的同学都应该知道,每张数码照片都会存在一个EXIF信息。它就是一种用来描述数码图片的元数据。根据
EXIF标准,这些元数据包括:Image Description(图像描述、来源. 指生成图像的工具 )、Artist(作者)、Make( 生产者)、Model (型号)、….、等等。
生活中我们填写的《个人信息登记表》,包括姓名、性别、民族、政治面貌、一寸照片、学历、职称等等这些就是锁定kent.zhu这个人的元数据。

通常情况下元数据可以分为以下三类:固有性元数据、管理性元数据、描述性元数据
固有性元数据;与事物构成有关的元数据。
管理性元数据;与事物处理方式有关的元数据。
描述性元数据;与事物本质有关的元数据。
当然,并不是说所数据总能清晰的划分在以上3类中。比如:一张由kent拍摄的大小为20K的JPG格式的印着一只小狗的圣诞卡照片。
它的固有性元数据包括:20K、JPG;管理性元数据:kent拍摄、圣诞卡;描述性元数据:狗、小狗、圣诞、照片、圣诞节、…
但是,圣诞卡则可以放在以上任何一个分类中。与事物构成有关(说明这个东东是什么)、与事物处理方式有关(说明这个东东的用途是什么)、与事物本质有关(可以直接用来描述这个东东)。

元数据之于信息架构的意义

元数据是一种很有效的方法,用以确保网站上各种形式的内容确实都能被查找到。比如我们常常为搜索很久之前看到的一张美女图片犯愁,而如果一个图片网站如果信息架构足够好,我们就能凭借我们回忆到的元数据(关于武藤兰的?2000年拍摄的?)清晰的找到。
元数据之于信息架构就像是房子的砖瓦,它可以根据需要摆放成不同的信息检索系统。元数据是所有组织系统的基础,从搜索到电子商务网站上的导航系统都强烈的依赖于元数据。
前面提到,元数据实际上是为产品的可查找性(Findability)服务的。而用户在查找信息的时候不会按照机器思维去找(不会输入该照片的ID),而是直接输入关于信息的描述性信息如:“小狗 圣诞卡”。也就意味着在创建关于描述性元数据的时候要尽量的提取出任官关于这个对象所讲述的故事,这些才是人们能记住的和习惯搜索的细节。

我们会发现,机械生成的元数据常常是不靠谱的,如在UCH系统下发布日志的时候系统会自动根据标题进行机械分析生成的一些元数据。
而充分利用手工元数据(handcrafted metadate)是提高可查找性的一个好方法。最常见的例子就是我们见到的Tag。Tag就是一种用户自创的元数据,其特点是无层次结构、自定义。比如
这张Flickr照片下的手工元数据就为在Flickr上查找提供了更多的方便。