Archive for the ‘互联网’ category

豆瓣变脸记

三月 13th, 2010

豆瓣又一如既然在变形着,不过这次变在是未登录豆瓣首页,是portal页面,更是脸面,今天阿北们或许又是在搞豆瓣式昙花一现测试法,在深圳本机上用chrome可以显示出来,ie则不行,显示的是老豆瓣首页。和旧版对比,UI干净、清爽,留白也恰到好处;页面信息分布则头轻脚重,页面高度也有原来的两屏半变为三屏半。
分析如下:
A区:导航依然强调了豆瓣改版的战略改变,读书、电影、音乐、九点等产品独立发展,其中读书、电影、音乐中各嵌入一个搜索小图标,以示豆瓣“发现生活”的目标定位。只不过三个小图标在色调上没有啥差异性

B区:注册登录也做了一些调整,除了展示多彩多姿的豆瓣城市小资生活背景外,更加突出注册功能,显示豆瓣对用户数增长的  痴迷,依然是吸星大法式拉取,想必下一步豆瓣依然在老用户与新用户的取舍上更加偏向新用户口味。

C区:“同城、小组、正在发生”告诉人们豆瓣线下生活的丰富多样,社区概念得到加强,更加强调同城设计生活

D区:“电台、迷你站、线上活动”体现了豆瓣线上生活也有特色。

通过以上分析,豆瓣这次变脸强调各产品独立发展的战略转变,同时试图注重加人的情况下,对用户提供更丰富更有实际意义线上、线下“双线”生活服务。给豆瓣的建议是:

一 B与CD区的那条分横线实在让人看这别扭,加之与A区与B区的分割,分明让人看到两条横线映在眼帘,硬生生的把登录区域夹在中间

二 CD区的信息密度较大,适当做些删减,更能体现豆瓣简洁的特色

豆瓣改版分析

二月 28th, 2010

从上个月新版豆瓣昙花一现,到这次新版豆瓣小规模测试,相对于上一次07年底改版一样招致很多老豆油们一片质疑,这次改版却引起了老豆油们更加强劲反弹。从阿北在《豆瓣变形记》 后面生机勃勃的评论中可以看出,这次他们抱怨的不是新版豆瓣的发布模式,而是整个豆瓣架构的重新调整以及部分功能修改对豆油们的情感伤害,综合起来大致有以下三个原因

             1 读书、音乐、电影独立运营

             2 豆瓣社区,豆瓣也要buzz嘛?

             3 破坏已有豆列生存规则,  将豆列分流

(注:豆列是豆瓣网友将书籍、音乐、电影中有某种共同特征的具体条目打包成一个链接,方便资源的整合与传播,是豆瓣网友们辛勤编织的劳动成果)这其中第3个破坏已有豆列影响最恶劣,于是就有了豆油发起了《反对豆列分拆大签名!》,截止目前有1414人参加 。而这些都说明一方面豆瓣在演化进程中充满争议;另一方面令人羡慕是阿北有着这么一群可爱的豆油拥趸发表意见、指出不足,无论如何对豆瓣的发展是值得庆幸的!

写这篇文章的目地一是为了了解豆瓣这次改版的用户反馈;二次是利用信息架构、信息设计等UE知识分析下这次豆瓣改版的背景和原因,以供同行切磋。下面对豆瓣改版的背景和原因进行分析。

可能大家在争论豆瓣这次藐视书影音艺术“通用性”的同时忽视了以下两个因素:

一是豆瓣网在2009年底拿到近1个亿的二轮投资,规模化商业进程开始逐渐启动,阿北及其团队需要扩充产品线和深化产品服务迎合资本方;

二是之去年中开始和腾讯、百度等合作开放平台嵌入应用而带来的近3kw新用户爆发性增长,海量新用户产生的噪音干扰豆瓣最为宝贵的财富且将自身定位为小众而高端老用户,迫使他们担心豆瓣变质迫使自己离开,这也就是阿北在《豆瓣变形记》提到的担忧——“高度活跃的社区对书影乐服务内容可能的干扰,比如社区内的人际冲突会波及到评论和条目内容”。

 看清了以上两个原因之后就可以明白新版豆瓣的信息架构调整,一方面建立豆瓣社区,统一整合用户空间、线上线下社区功能,强化广播(微博、buzz,没办法大势所趋)属性,照顾腾讯空间过来的新用户行为习惯;另一方面是将读书、音乐、电影以独立二级域名形式独立运营,以便日后对老用户提供更好的服务,当然了,也不排除“将鸡蛋放在3个篮子”说法,降低豆瓣运营风险;然而这次豆瓣效果究竟如何呢,请看下一篇《体验新版豆瓣》,敬请期待!

Axure组件值传递妙用

一月 23rd, 2010

Axure是产品原型设计的一大利器,其所作出每一个原型都有以下组件(widget)构成,如文本块(Text Panel)、矩形框(Rectangle)、按钮(button)、文本输入框(Text Field)、以及让众多Axurers喜爱的动态层面板(Dynamic Panel)等。正是因为这些功能形态各异的组件组成了一个产品的基本框架、原始形态,而每个组件都可以拥有一个名号–标签(label),通过对标签命名、组件赋值就可以作出一些令人惊喜的交互效果。

一、利用组件赋值值传递

淘宝改版了,但淘宝的登录入口还是没变,可见阿里人对淘宝登录入口的自信。

taobao_login

利用AxureRP5.6做的原型(下载RP文件请点击taobao-login-axure,查看效果请点击这里),如下图

taobao_login_axure

步骤分解如下:

1 如上图,建立帐户名和密码两个输入框,分别打上user和password标签(label),便于登录按钮识别判断

2 新建立动态层面板(dynamic panel),将面板命名为error ,右键将其隐藏

3 由于有帐户名和密码两个输入框需要鉴权判断,因此需要至少建立两个动态层显示判断异常错误.右键error动态层面板,新建两 个动态层,分别命名为user_error和password_error

4 编辑两个动态层,如将user_error编辑为“用户不存在”、将password_error编辑为“密码不匹配”,这里只考虑简单的两个判断,登录前端后端鉴权多达几十种判断都可以在error动态层里面显示

关键一步,编辑case条件对输入框赋值并进行判断:点击登录按钮,Axure右上侧会出现”注释&交互”栏,建立两个case条件:一是当帐户名输入框user不等于ashnotes.com时,在error动态层面板触发显示user_error动态层;二是当密码输入框password不等于123456时,在error动态层面板触发显示password_error动态层,具体步骤如下图所示。

taobao_login_axure2

3 由于有帐户名和密码两个输入框需要鉴权判断,因此需要至少建立两个动态层显示判断异常错误.
右键error动态层面板,新建两个动态层,分别命名为user_error和password_error

6 最后是case条件的处理来控制error动态层面板,及其他出错提示。在实际运用过程中由于case判断过多的情 况下,可以在需求书上加以详细描述,便于后台开发人员了解判断逻辑及编码。

二、利用标签命名值传递

京东的订单核对页在处理新老收货人信息,点击修改者切换到输入新地址状态,保存则回到填写好的地址状态,只有切花,交互清晰明了,值得模仿、推荐。

360buy_confirm

利用AxureRP5.6做的原型(下载RP文件请点击360buy-confirm-axure,查看效果请点击这里),如下图
360buy_confirm_axure

1 新建modify和address两个动态层面板,每个面板新建两个层,各自对应命名为1、2号层
2 具体原理是对动态层面板各组件命名,交叉触发显示,即利用modify的1号动态层同时触发显示其本身的2号层及address的2号动态层;modify的2号动态层触发显示其本身的1号层及address的1号动态层。呵呵,说起来拗口,点击“修改”和“关闭”后看看效果就知道了
——————————————————-可爱的分割线————————————————–
备注:丁宇同学曾在《从“产品需求文档”(PRD)到“产品设计文档”(PDD)》 提出将产品原型与PRD融在一个文档中。这是一个很好的倡议,但得基于产品与开发两方的深度认可。毕竟axure的独门利器集中于快速交付html交互产出物 ,在产品设计沟通、体验模拟、展示演说方面才是他的初衷,而PRD更多的是产品研发过程中所需要的详细雕琢的文档。

Related Posts with Thumbnails