Group items tagged

栅格设计系统（又称网格设计系统、标准尺寸系统、程序版面设计、瑞士平面设计风格、国际主义平面设计风格），是一种平面设计的方法与风格。运用固定的格子设计版面布局，其风格工整简洁，在二战后大受欢迎，已成为今日出版物设计的主流风格之一。

网页栅格系统下的定义为：以规则的网格阵列来指导和规范网页中的版面布局以及信息分布。

几种有趣的用户界面设计，它们是： • 滑块筛选 (Slider-based Filtering) • 鱼眼菜单 (Fisheye Menus) • 树图 (Treemaps) • 拖放(Drag-and-drop)

滑块筛选 Amazon’s Diamond Search （亚马逊的钻石搜索）的用户界面采用了点击-拖拽的滑块，这样用户可以扩大和缩小搜索的筛选标准。用户通过滑动来变更用户选择的标准时，该页面可以自动的更新搜索结果。 这个界面具有直观和信息丰富的特点，用户可以很容易的在大量信息中搜索所需要的结果：

鱼眼菜单 鱼眼菜单（Fisheye menus ）对于帮助用户浏览很长、但有序的列表很有用处。该菜单可以动态的变换菜单条目的尺寸，将鼠标所在区域放大。这样便可以在一个屏幕上显示并操作整个菜单了，而无需传统的按钮、滚动条、或分级浏览结构。

1. 你们的项目组使用源代码管理工具了么？MVM：应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。 2. 你们的项目组使用缺陷管理系统了么？MVM：应该用。ClearQuest太复杂，我的推荐是BugZilla。 3. 你们的测试组还在用Word写测试用例么？MVM：不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。 4. 你们的项目组有没有建立一个门户网站？MVM：要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。 5. 你们的项目组用了你能买到最好的工具么？MVM：应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。 6. 你们的程序员工作在安静的环境里么？MVM：需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。 7. 你们的员工每个人都有一部电话么？MVM：需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。 8. 你们每个人都知道出了问题应该找谁么？MVM：应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。 9. 你遇到过有人说“我以为…”么？MVM：要消灭“我以为”。Never assume anything。 10. 你们的项目组中所有的人都坐在一起么？MVM：需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。 11. 你们的进度表是否反映最新开发进展情况？ MVM：应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。 12. 你们的工作量是先由每个人自己估算的么？MVM：应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。 13. 你们的开发人员从项目一开始就加班么？MVM：不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。 14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？MVM：不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。 15. 值得再多花一些时间，从95%做到100%好MVM：值得，非常值得。尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。 16. 登记新缺陷时，是否写清了重现步骤？MVM：要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。 17. 写新代码前会把已知缺陷解决么？MVM：要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。 18. 你们对缺陷的轻重缓急有事先的约定么？MVM：必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。 19. 你们对意见不一的缺陷有三国会议么？MVM：必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。

20. 所有的缺陷都是由登记的人最后关闭的么？MVM：Bug应该由Opener关闭。Dev不能私自关闭Bug。 21. 你们的程序员厌恶修改老的代码么？MVM：厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。 22. 你们项目组有Team Morale Activity么？MVM：每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。 23. 你们项目组有自己的Logo么？MVM：要有自己的Logo。至少应该有自己的Codename。 24. 你们的员工有印有公司Logo的T-Shirt么？MVM：要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。 25. 总经理至少每月参加次项目组会议MVM：要的。要让team member觉得高层关注这个项目。 26. 你们是给每个Dev开一个分支么？MVM：反对。Branch的管理以及Merge的工作量太大，而且容易出错。 27. 有人长期不Check-In代码么？MVM：不可以。对大部分项目来说，最多两三天就应该Check-In。 28. 在Check-In代码时都填写注释了么？MVM：要写的，至少一两句话，比如“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一部分。 29. 有没有设定每天Check-In的最后期限？MVM：要的，要明确Check-In Deadline。否则会Build Break。 30. 你们能把所有源码一下子编译成安装文件吗？ MVM：要的。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。 31. 你们的项目组做每日编译么？MVM：当然要做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。 32. 你们公司有没有积累一个项目风险列表？MVM：要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。 33. 设计越简单越好MVM：越简单越好。设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。 34. 尽量利用现有的产品、技术、代码MVM： 千万别什么东西都自己Coding。BizTalk和Sharepoint 就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文 本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。 35. 你们会隔一段时间就停下来夯实代码么？MVM：要。最好一个月左右一次。传言去年年初Windows 组在Stevb的命令下停过一个月增强安全。Btw，“夯”这个字念“hang”，第一声。 36. 你们的项目组每个人都写Daily Report么？MVM：要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。 37. 你们的项目经理会发出Weekly Report么？MVM：要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。 38. 你们项目组是否至少每周全体开会一次？MVM：要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。 39. 你们项目组的会议、讨论都有记录么？MVM：会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。

40. 其他部门知道你们项目组在干什么么？MVM：要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。 41. 通过Email进行所有正式沟通MVM：Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。 42. 为项目组建立多个Mailing GroupMVM： 如果在AD+Exchange里面，就建 Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。 43. 每个人都知道哪里可以找到全部的文档么？MVM：应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。 44. 你做决定、做变化时，告诉大家原因了么？MVM： 要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于 是不是能access information/data，而在于是不是掌握资源。 45. Stay agile and expect changeMVM：要这样。需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。 46. 你们有没有专职的软件测试人员？MVM：要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。 47. 你们的测试有一份总的计划来规定做什么和怎么做么？MVM：这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。 48. 你是先写Test Case然后再测试的么？MVM：应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。 49. 你是否会为各种输入组合创建测试用例？MVM：不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚，你是否有时间去运行那么多test case。

《Communicating Design》里面也有10种~ Personas 角色设计文档 Usability Test Plan 可用性测试计划 Usability Reports 可用性报告 Competitive Analysis 竞争分析 Concept Model 概念模型（概念图） Content Inventory 内容清单 Site Maps 站点地图 Flow Charts 流程图（交互流程图） Wireframes 线框图 Screen Designs 视觉设计、原型设计等

5、6、7可以在小型项目中结合，大型的项目中还是要适当分开。 交互原型可以以交互设计说明书的附件形式存在

1、产品概念文档(项目策划书) 主要是对市场需求进行合理的科学的推导，得出新产品机遇，并对产品定位以及未来的发展方向进行概念性阐述。产品概念文档主要用来对新产品进行宣讲，让项目团队对将要开发的产品有一个概念上的理解，在思想上达成一致。 2、用户调研报告 主要有两类，一类是产品概念形成之初，研究人员进行的需求调研而输出的报告。主要是为产品概念的提出提供科学的依据，为需求的推导寻找佐证。另外一类是项目开发过程中，对设计中不确定以及有分歧的地方进行用户测试，得出结果并输出用户测试报告。 3、产品需求列表 这个列表并不一定是文档，但是他非常重要。它是将新产品拆分成几个大的模块，并将这几个大模块再细拆分成各个功能点后形成的功能列表。它的用途是将整个产品的工作量化，利于设计师、开发人员、测试人员评估自己的工作量，利于开发过程中对各个功能点进行跟踪，不遗漏，利于产品测试时对产品进行全面覆盖。 4、产品说明书 产品说明书是目前很多公司中最常见，他主要包括产品功能的详细描述，产品所需要的开发、运行环境，性能要求等等。准确的讲，这份文档并不应该包含具体的交互内容。这个文档面向的是项目的全体成员。 5、交互设计说明书 交互设计说明书对整个产品的界面结构、交互流程进行详细的描述。它一般包括需求分解、竞争产品分析、流程说明、页面布局说明等内容。交互设计说明书的格式众多，灵活性也相当高，但目的都是将产品的结构和及流程形象化。交互设计说明书主要面向开发人员和测试人员。 很多公司将交互设计说明书和产品说明书结合在一起进行撰写，其实这种做法并不是十分合理。通常情况下，产品和设计结合的文档结构非常庞大，非常不利于查阅，也不利于撰写，而且这种结合文档的很多内容对特定人员是无用的。 6、交互设计规范 交互设计规范主要是用来规范新产品中常规的功能、操作等内容，比如页面的标题规范、界面快捷键操作的规范、提示反馈信息的规范等等。 7、视觉设计规范 视觉设计规范主要是规范新产品中一些视觉元件的样式、页面边距相对边距、通用界面的页面框架等等，开发人员根据规范就可以自行开发一些通用界面。 8、开发文档 开发文档包括一些需求分析、系统架构分析、数据库分析、开发日志等等内容。开发文档主要用来作为开发团队的技术沉淀。 9、测试用例 测试用例指对新产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。 10、产品评估报告 产品开发完成后，应由测试人员撰写一份评估报告，对产品功能的实现情况、性能情况、bug解决率等问题进行综合说明和评估，来确定新产品是否符合发布标准。 上面的这十类文档是非常理想化的项目中才具备的，也并不是适用于所有的项目开发，但是，产品说明书、交互设计说明书、测试用例等几类文档是一个项目中不可能缺少的，他们是一个项目有效运行的核心文档。

　　步骤一：数据调查          数据可以带来什么？对于各页面及路径的pv(产品),uv(用户)的总结，可以得到产品使用情况的一个大致概貌。　 　　 缺乏什么？不了解用户，不了解过程。 　　步骤二：用户访谈 　　有什么好处？产品和用户之间的联系，就像一个黑匣子。对用户的访谈，就是一个试图打开黑匣子的过程。 　　打开了黑匣子，我们就可以改造他们之间的路径。从而使两者无缝融合。就像是研究dna，对结构的研究可以重塑基因。反映到产品上，就是我们可以以用户的心理模型去创造产品，或者是用富于创造的产品去影响用户。 　　步骤三：产品分析 　　即使了解用户，是否能提出有效的解决方案呢？此时，对于相关产品的研究就会作出帮助。如果说对用户的需求，可以对产品有纵深的认识。那么对产品的分析，有利于横向去加深去产品的理解。为什么做同一个功能，会产生出两种不同的产品？差异表现在大体，也体现在细节，通过不断的比较，会发现产品各功能间，产品和用户间千丝万缕的联系。 　　步骤四：产品定位 　　定位本应在一个产品做出之前决定，可为什么我会在此阶段提出这个步骤呢？事实上，因前面工作的铺垫。只有了解了用户，了解了相关产品后，定位才会更加明确。最初时，时时需要一个定位，却感觉模糊，在此刻，就清楚许多。能否改变，看造化了~~ 　　步骤五：功能确认 　　基于对用户和产品的分析，此时会提出一些新的功能。从产品长远的发展，对用户使用的引导，以及易用性综合考虑，慎审地推出每一项功能。 　　步骤六：信息架构 　　产品的印象开始在脑海里浮现。此时，将信息注入到产品结构中去。导航，管理等是很重要的几项，需要格外小心。另外，不同的页面有不同的信息，以及页面与页面间的信息跳转，甚至是产品间的跳转，每条信息都需要经过审核。如果对产品没有帮助，或者对用户是负担，都不要向里加。 　　步骤七：页面原型 　　就个人而言，在页面原型阶段，除了用visio来画结构图，还是不自觉得要用ps去协助找感觉，这个过程，对自己而言也是一个迭代的过程。当然，之前那些阶段，使整个产品的结构都在脑海里快成型了，这个只需要把它落实到纸上。 　　原型的确认，需要坚持。如果是你自己做了这个过程，而且每一点都是经过思考的。那么就去说服来自各方的反对。事实上，你要相信，人们相信思考的价值，只要你付出了，就有回报，最怕没有付出天天在那里抱怨。 　　步骤八：视觉设计 　　不必多说了。可能会比较多，icon，字体，区域的划分，模块的统一，css的定义，风格的设定~~~所有的一切，都要体现前面工作所得到的东西。 　　步骤清晰，但其实中间的过程可能更有意思。