猪窝

编程是枯燥的~尤其在学习阶段

而ruby on rails…. 让你真的体验不一样的感觉，电子书看了半天，依然决定买两本书，当140多块换来两本厚厚的沉甸甸的书，我感觉到了知识的重量~~~~

在第六章按照书中的方法无法进行，会提示undefined method `scaffold’的错误，找了半天，最终找到解决办法：

Rails2.0.2把scaffold 剥离为插件，也就是说Rails2.0.2里面不能直接使用scaffold了，而书中的版本与最新版还是对不上，所以需要重新安装，而且需要安装两个plugin

1. 执行 以下语句 安装scaffolding

ruby script/plugin install scaffolding

2. 分页插件的解决方法

状况如下：

undefined method `paginate’

解决办法：安装老的classic_pagination

ruby script/plugin install http://tools.assembla.com/svn/breakout/breakout/vendor/plugins/classic_pagination/

参考资料：解决scaffold未定义问题
关于rails2.0.2中使用scaffold报错的问题

1. 过去我也曾经跟着大家一起说，因为确实，腾讯没有创新，跟百度，google比起来，确实不行~

2. 上面的现象（跟着大家一起），余世维称之为“群体偏移”：人聚在一起容易发生群体智商低下及方向偏移的现象

3. 最近在读关于博弈论的书《策略思维》，里面描述了很多方法和问题

4. 有一种现象叫做跟随策略：假设两个帆船在比赛，第一名领先第二名20米，因为是帆船，所以决定船速的因素只有“风”。第一如何能够保证自己赢过第二？跟随第二的策略，那么他永远不可能输，记住是永远（刨除任何抬杠的因素）

5. 这种跟随策略能够确保第一名的领先优势及最终的地位，所以对于第一来说，这种策略是最正确的

6. 对于第二，唯一也是最应该能做的就是：创新，创出会有效果，会有作用的新，同时也是第一不能全力跟随，甚至不敢跟随的新~ 看看IBM和DELL？ 大部分书都说DELL挖掘了需求，但是从博弈论的角度讲，如果IBM全力跟随DELL（虽然有品牌啊，定位啊等周边因素的影响），格局则不见得是这样~

7. leopoard 里面太多的东西是vista跟随不了的~

8. 我的视觉设计，页面结构设计能力太差，自己来考虑如何帮助自己成长，试试吧~

需求应包括对象和动作以及上下文。

————出自《about face2.0》

一个从脚本提纲及用户角色中提炼出来的需求（针对系统）应该包括哪些内容？

1. 首先，需求不等于任务：任务必须是通过用户手工完成，而需求则只是暗示特定对象需要存在，及特定的动作及特定的场景。

2. 数据需要： 任务角色的数据需要是必须在系统里被描绘的对象和信息，如文档类型，状态标记等。

3. 功能需要：功能需求是针对系统对象必须进行的操作，最终会转换为界面控件

4. 上下文需要和要求： 即场景需求，需要描述对象集合内对象之间的关系，以及对象和控件之间的可能的关系（应该也是其他需求文档规范中提到的：系统反馈/运行结果）

5. 其他需求：商业需求/技术需求/顾客和伙伴要求

跟传统的需求文档相比，这里主要强调的是上下文，即功能的环境（上文）及系统的反馈（下文）

有人需要一起网或者百度HI的邀请可以留言，留下邮箱

一起网：谢文的理论实践性产品

百度HI：百度的IM软件…

用例是什么？不了解的看这个：了解用例-编写有效用例

用例的作用？

不同的环节，用例起到不同的作用。其实外国人很会挖掘及利用工具，这点比国内的人专业好多。好像千鸟说的日本人的excel都用到很深入，同样，国外对用例的使用方法也是很多样化的。这可能也跟中国的互联网环境有关：一切都是免费的，我不用太珍惜及挖掘。

从工作的经验来看，在现在的流程中，用例主要可以用来描写业务流程，让技术及设计人员对产品的业务流程达成共识，从而认识到产品应该如何与这些业务流程更好的结合，并通过用例的讨论来挖掘需求。同时使用范围来确定产品应包含的功能，来保证开发工作的高效，没有多余的工作。确立范围的方法可以看这个：通过用例确定系统的功能范围

而用例的格式又可以保证在具体功能需求中进行功能，逻辑，现象的穷举，以保证需求的完整性及可实现化。

而产品设计中也有同样的工具：脚本提纲。虽然在国外用例也可以用来描述相似的内容，但主要都是在业务描述及功能描述上。而脚本提纲主要描述的内容是从具体用户的角度定义产品的行为，不仅包括功能（概述），也包括功能的优先级，以及用户看到的，与系统交互的方式等内容。同样也可以迭代：从最初的目标描述，到任务分解后的任务描述，同时包含进去具体使用产品的场景描述，心态描述，用户行为描述，从而用来进行设计及检验产品的功能结构，具体功能交互，用户使用方式等。

这个工具过去没有了解过，感觉确实是一个必要的环节，应该加以重视和实践。

最近有空常翻翻这本书，中文名叫软件观念革命，确实是一本很实用很精彩的书，里面同时提到了很多过去没有想过的方向和观点。

1. 软件的设计与开发是完全两个独立的过程，同时分离这两个部分的工作会提高软件的质量

2. 决定一个软件的成功与否不是一个软件有多少功能，而是功能是否有用及好用（注：有用排在前面）

3. 设计软件，重要的是设计用户的行为：界面不是静止的，是活得行为。即用户如何使用软件是完全依照你的设计来决定的。

4. 交互设计的定义： 交互设计是对人工制品，环境和系统的行为以及传达这些行为的外形元素的设计与定义。

5. 设计具有三个维度： 形式，内涵，行为，分别突出表现在不同的行业。

6. 交互设计师首先要做的，是理解使用他们设计的人们的目标，动机和期望。

7. 什么是产品设计？  理解用户的期望，需要，动机和上下文（情景）；理解业务，技术和行业的需求及限制；将这些所知道的东西转化为对产品的规划，使得产品的形式，内容和行为变得有用，能用，令人向往。

其中最让我惊异和佩服的理论是：  一个成功的产品诞生于业务领域，技术领域及设计领域三个领域的交集。业务保证生存，技术保证实现，设计保证能用，可用。

在业界的例子是： Novell，专注于技术；微软，更擅长业务；苹果，出众于设计；

先来看几个情景：

1. 上网，登陆邮箱，撰写邮件内容，发送邮件，发现网络故障（用户机器/网络服务器等因素）

2. 上google，输入关键词，获得搜索结果，对结果不满意，调整关键词，重新获得搜索结果

3. 上豆瓣，查找书，看看书评，确认要买，右侧有各个网络书店的购买链接，点进去购买，看见此书是缺货

4.  上迅雷，找电影，下载，等了两个小时，发现是枪版，迅雷标题是DVD高清版

……….

从上面的例子你能看出来什么？

目标和任务是区分的，而真正影响最终目标及体验，无论是商业或是用户的，都是目标大于任务。 而关于这方面的文章也有很多，比如白鸦的保证整体体验,千鸟读书后与angela的讨论，最终的结论都是：保证用户目标的完成才是产品（商业）体验所追求的最终效果。

而在用例分层撰写及产品设计中也有相关的理论指导。这方面的内容国外要比国内的丰富许多。所以时刻铭记用户的最终目标，在保证各个“任务”环节的体验友好型、流畅性的同时，确保最终产品的设计宗旨与用户目标的最大化重合，才能真正做到产品的有效性及可用性。

所以即使任务分解了，辅助用户完成任务了，别忘了最终的目标。

原创： 猪猪经验分享

首发： 猪窝

        PHP学习已经有半个月的时间了，总得来说掌握的知识还只是小基础。如果看成是学英语的话那现在就是26个字母基本掌握，掌握了几种简单的语法，同时记住了一些单词。同时我不是一个真正的产品设计，所以大部分工作及精力是放在需求，业务方面，而学了技术，至少是学到现在（可能我学的还不够深入）对我的帮助远远大于对我的限制，确实没有像其他人说的，技术限制了思路。

工作中能体验到的好处：

需求文档中，逻辑的问题少了：不会把多个数据盲目整合，看着整体结构简单了，实际上功能的使用繁琐了，逻辑复杂了，同时有可能会出现矛盾。

对进度的安排及功能的分配心里有些框架了：知道了大概哪些是大工作量，哪些是比较容易实现的，同时平衡业务用户的需求侧重点，从而更合理的安排项目的工期及功能的分配，同时最大化的满足双方的需要。

问题考虑更全面了：一个简单表格，一般我们需要提出的需求需要包括的点有“字段数量，字段定义，字段顺序，表默认显示数据，数据行的排序依据，是否翻页，翻页条件，是否允许查询，查询条件与逻辑”等等类似的功能说明。

歧义句少了： 明白了参数，属性，字段的含义，不会再乱用会误导技术理解的词汇。

文档力求统一，需求分层： 文档同样是一个“产品”，他的面向用户群就是开发人员或设计人员，所以同样需要有概念统一，词汇统一，功能统一的要求，包括各种细节，尽量不要在功能需求中体现表现层的东西，同理在设计建议文档中也少提到逻辑概念。

类似的好处还有不少，总之感觉到是质的变化，再有体会继续整理。

最近实在是没有大块的时间用来总结和写博客，但是又不忍心不更新，所以直接从反否中摘出来平时思维的点滴。

•  永远不要责备一个人，如果你没有让自己处在他的情境下或者没有仔细思考他的处境。
• 网站可以参考传统行业的另一个模式：外包
• 销售，开发，财务，合作伙伴，设计师，管理层，用户，产品经理需要面对的角色实在是不少，追求平衡点
• 理论知识是用来说服他人的基础
• 方法论都应该再进行细分：技巧与基本方法
• 合理的利用挖掘资源，从需求中提炼出重点，在验收中把握住核心，虽然都是很虚的概念，但是需要用这些概念来指导工作中的执行
• 想过的，说过的，学过的，记过的，不要只是重复在嘴里和心里，养成习惯做到行为里才是有效果的，真正学会的，真正提高了。
• W3C发布amaya，号称所见即所得还真是所见即所得啊。暂时没找到怎么看源代码。有空研究研究。
• 人，物，关系，细分每一个主体，考虑再来考虑SNS，六度理论应该不局限人与人之间的问题，人与物？ 用豆瓣考虑：豆瓣里的每一本书的信息，你能通过少于通过其他六本书中间的关联来获得？ 好像能有点意思
• 以情节和事件为中心的设计是对用户为中心的设计的一种提升与改进，但是同时又依赖与用户为中心，因为事件的主体是人，是用户，用户又带来各种感觉及思想上的限制。这样理解应该能更正确些。这个是辩证法？
• 一个好的产品，首先是用户需要（或市场需求）和企业利益的结合，其次是用户需要节约时间和学习成本获得最好的享受，而企业对利益的追求需要降低开发成本，这两者又反过来刺激了技术的发展。 这句话包含了几个点？