<feed version="0.3" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns="http://purl.org/atom/ns#" xml:lang="en-US"><title>moneya</title><link rel="alternate" type="text/html" href="http://community.hf-mstc.org/blogs/moneya/default.aspx" /><tagline type="text/html">可用性从理论到实践</tagline><id>http://community.hf-mstc.org/blogs/moneya/default.aspx</id><author><url>http://community.hf-mstc.org/blogs/moneya/default.aspx</url></author><generator url="http://communityserver.org" version="1.0.2.33019">Community Server</generator><modified>2007-02-01T15:20:00Z</modified><entry><title>问题为什么这么多？</title><link rel="alternate" type="text/html" href="http://community.hf-mstc.org/blogs/moneya/archive/2007/10/12/3939.aspx" /><id>3a151c65-44f4-4427-9f6e-28e8de5779ab:3939</id><created>2007-10-12T06:50:00Z</created><content type="text/html" mode="escaped">&lt;P&gt;&lt;FONT style="BACKGROUND-COLOR: #efefef"&gt;今天，又为小事争论了。&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT style="BACKGROUND-COLOR: #efefef"&gt;测试人员认为，首页的信息后面跟的日期应该统一为“年月日”，并把此问题设置为bug提交给研发修改。&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT style="BACKGROUND-COLOR: #efefef"&gt;而当我看到页面时，认为这样做是喧宾夺主。为了强硬的统一，而使得左右栏狭窄的空间只能放标题的前5个字，完全不符合可用性原则。&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT style="BACKGROUND-COLOR: #efefef"&gt;问题虽小，可也让研发组长、当事研发人员、测试人员、设计人员耗费了10分钟。&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT style="BACKGROUND-COLOR: #efefef"&gt;随着设计组对项目和产品的参与度越来越高，与产品组、研发组、测试组的关联也就越来越密切和微秒了。&lt;/FONT&gt;&lt;FONT style="BACKGROUND-COLOR: #efefef"&gt;可用性、css、用户体验分别有赖于这3类人员实现，我们只是协助、建议的角色。我们的工作权责不那么清晰，每个环节到底哪种角色来负责，各环节的交叉太多，那么这种绕弯打架的事情，是否依然会继续出现吧。&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT style="BACKGROUND-COLOR: #efefef"&gt;我们现在应该承担怎么样的工作和责任？以设计组现有实力，是否能承担更大的责任？以后的发展方向是什么？&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT style="BACKGROUND-COLOR: #efefef"&gt;技术可以学习，技能可以提高，问题的关键是各职能组的权责能否清晰的划分？&lt;/FONT&gt;&lt;FONT style="BACKGROUND-COLOR: #efefef"&gt;我们的参合是带来了正面效应，还是把事情变得复杂，越搞越乱？？&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT style="BACKGROUND-COLOR: #efefef"&gt;思考，再思考…… &lt;/FONT&gt;&lt;/P&gt;&lt;img src="http://community.hf-mstc.org/aggbug.aspx?PostID=3939" width="1" height="1"&gt;</content><slash:comments>0</slash:comments><wfw:commentRss>http://community.hf-mstc.org/blogs/moneya/commentrss.aspx?PostID=3939</wfw:commentRss></entry><entry><title>4月4日，参加用户培训所得</title><link rel="alternate" type="text/html" href="http://community.hf-mstc.org/blogs/moneya/archive/2007/04/05/3672.aspx" /><id>3a151c65-44f4-4427-9f6e-28e8de5779ab:3672</id><created>2007-04-05T02:41:00Z</created><content type="text/html" mode="escaped">&lt;P&gt;&lt;FONT size=3&gt;参加人数：5人。&lt;BR&gt;参加人类型：&lt;BR&gt;年轻人：20－28；2人；计算机操作水平，中级；系统熟悉程度，中级；认真程度，不认真；&lt;BR&gt;中年人：32－45；3人；计算机操作水平，初级；系统熟悉程度，初级；认真程度，认真；&lt;BR&gt;主要观测人群：中年人。&lt;/FONT&gt;&lt;FONT size=3&gt;&lt;BR&gt;现象：用户不断提问，这项应该填什么内容？&lt;BR&gt;收获：如果输入项标题不是特别明确，就应该给出此项应该填写的正确内容样例。减少用户的疑惑和思考&lt;/FONT&gt;&lt;FONT size=3&gt;询问的时间。&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT size=3&gt;现象：有用户提问列表前面的状态栏里的那些图标是什么意思？&lt;BR&gt;收获：无论用什么形式，都应该给图标添加注释！对于图标的隐寓各人理解不同，甚至没人愿意费心去理&lt;/FONT&gt;&lt;FONT size=3&gt;解，不要让用户思考。&lt;BR&gt;我能想到的注释方法：集体注释，表头注释，tip注释，单个图标后跟注释。&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT size=3&gt;集体注释&lt;BR&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 优点：节省空间，注释集中&lt;BR&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 缺点：用户总是快速浏览而不是阅读，这部分的信息容易被忽略。&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT size=3&gt;表头注释&lt;BR&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 优点：清晰，空间使用度中。&lt;BR&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 缺点：对于同一类用于不同状态之间转化的图标不容易处理&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT size=3&gt;tip注释：&lt;BR&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 优点：节省空间 &lt;BR&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 缺点：容易被初级或计算机操作水平不高的用户忽略。&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT size=3&gt;每个图标后跟注释：&lt;BR&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 优点：清晰&lt;BR&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 缺点：浪费空间。&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT size=3&gt;现象：初级用户对tab视而不见，也不明白tab的意义和用途。&lt;BR&gt;收获：tab的形式和字体应该更突出。&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT size=3&gt;现象：用户需要完成“新建”的操作，可他把位于区域右边的“添加新文章”的按钮给忽略了，怎么也找&lt;/FONT&gt;&lt;FONT size=3&gt;不到。&lt;BR&gt;收获：1.常用且重要的操应该提到更上层的菜单中；2.也许按钮放在左边更符合用户的浏览顺序；3.重要&lt;/FONT&gt;&lt;FONT size=3&gt;的操作按钮样式应该更突出。&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT size=3&gt;现象：权限少的用户对于没权限得到的信息仍然表示极大兴趣，当得知没权限是，感到沮丧。&lt;BR&gt;收获：继续坚持“眼不见，心不烦”的看法。不能操作不出现。减少干扰，提升用户体验的成就感。&lt;BR&gt;思考：不明白什么是系统稳定要建立在不可变上。&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT size=3&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt;&lt;img src="http://community.hf-mstc.org/aggbug.aspx?PostID=3672" width="1" height="1"&gt;</content><slash:comments>0</slash:comments><wfw:commentRss>http://community.hf-mstc.org/blogs/moneya/commentrss.aspx?PostID=3672</wfw:commentRss></entry><entry><title>忽悠了谁？</title><link rel="alternate" type="text/html" href="http://community.hf-mstc.org/blogs/moneya/archive/2007/02/01/3637.aspx" /><id>3a151c65-44f4-4427-9f6e-28e8de5779ab:3637</id><created>2007-02-01T07:20:00Z</created><content type="text/html" mode="escaped">&lt;P&gt;某日，因界面设计问题走访客户。&lt;/P&gt;
&lt;P&gt;抱怨说，这东西看上去得值90w吗？！汗！&lt;/P&gt;
&lt;P&gt;界面缺乏设计，实现更是粗糙，的确有问题。&lt;/P&gt;
&lt;P&gt;在公司呆久了，我也以为客户智商都不太够数，只要功能实现，界面美观与否，根本没关系。&lt;/P&gt;
&lt;P&gt;原来，非也。看来谁都不傻呀！&lt;/P&gt;
&lt;P&gt;为了赶进度，什么都不管不顾了。我们天真的以为，只要客户关系好，功能大差不差实现了，其他都可以忽悠过去了。实在忽悠不过去了，我们再缺哪补哪。&lt;/P&gt;
&lt;P&gt;虽然我接触的客户不多，可真的深刻的感觉到，谁都不傻！我们有成功忽悠过去的用户嘛？好像没听说。我们能忽悠谁？自己吧！&lt;/P&gt;
&lt;P&gt;前期没有严谨的态度，7拼8凑的勉强应付的东西，代码混乱、功能不稳定、性能不佳……只会降低客户满意度，增加后期修改维护的成本，延长的工期。真不知道我们赚了什么？赔了什么？&lt;/P&gt;
&lt;P&gt;抱着忽悠的心态做事做人，得不偿失呀。&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;img src="http://community.hf-mstc.org/aggbug.aspx?PostID=3637" width="1" height="1"&gt;</content><slash:comments>1</slash:comments><wfw:commentRss>http://community.hf-mstc.org/blogs/moneya/commentrss.aspx?PostID=3637</wfw:commentRss></entry></feed>