1. 概念的关系
1.1. 概念是独立的,彼此间无须相互依赖
-
1.1.1. 一个概念是应该独立地被理解、设计和实现的
-
1.1.2. 独立性是概念的简单性和可重用性的关键
1.2. 软件存在依赖性
-
1.2.1. 不是说一个概念需要依赖另一个概念才能正确运行
-
1.2.2. 只有当一个概念存在时,包含另一个概念才有意义
1.3. 概念依赖关系图简要概括了软件的概念和概念存在的理由
- 1.3.1. 概念依赖关系图有助于规划设计和构造软件的顺序、识别概念分组以及解释概念结构
1.4. 概念组合允许单个概念在相互关系中发挥特定的作用
1.5. 概念组合本身是对称的,因为同步的操作是平等的
- 1.5.1. 概念组合可以引入不对称性,因为一个概念可以增强另一个概念的功能
2. 从概念到软件
2.1. 在大多数情况下,渐进式的开发会更好,因为这样开发人员能在早期就获得对其设计工作的反馈,评估已部署部分的价值,并在发现问题时及时处理
-
2.1.1. 渐进式开发并不是单纯地增加概念
-
2.1.2. 无节制地增加概念可能导致优秀产品的瓦解
2.2. 建立概念清单
-
2.2.1. 通用概念清单
- 2.2.1.1. 使用通用的概念不仅可以重用以前软件中的设计知识,还有助于简化设计
3. 概念依赖关系图
3.1. 由于每个概念都是通用且独立的,所以在传统的软件工程意义上不存在概念间的依赖关系
3.2. 概念之间存在其他依赖性,这与概念本身无关,而与它们在整个软件中的作用有关
3.3. 一个概念的存在可能依赖其他好几个概念
-
3.3.1. 将其中一个依赖关系标记为主要依赖(实线箭头),将其他依赖关系标记为次要依赖(虚线箭头)
-
3.3.2. 次要依赖表示一个概念不太重要的存在理由
-
3.3.3. 没有用户概念意味着无法进行身份验证
-
3.3.4. 没有投票概念意味着用户无法为答案做出贡献
-
3.3.5. 没有录音概念意味着提问中的鸟鸣声必须用文字描述,或者要链接至网络上的其他文件
3.4. 概念的任何子集都可以构成一个完备的软件,只要不存在指向该子集的依赖方
-
3.4.1. 产品线的每个完备子集代表这些特定概念可能构建的软件
-
3.4.2. 子集还可以表示软件开发的不同阶段
-
3.4.3. 在开发的任何时间点,你都希望拥有一个完备的子集,以便将其作为一个完整的单元进行评估
4. 概念的映射
4.1. 从底层概念到物理界面
4.2. 概念需要映射到具体的用户界面,将操作映射为单击按键等手势,并将概念状态映射到各种显示视图
4.3. 应用用户界面设计原则时,概念有助于聚焦映射问题
4.4. 试图使用户界面比底层概念更简单可能会适得其反
4.5. 映射必须考虑典型的使用模式
4.6. 用户界面尽管很具有表现力,但可能无法将一切变得清晰,界面中的工具包可能会限制映射设计
-
4.6.1. 有时甚至需要在用户界面中添加明确的注释
-
4.6.2. 创建用户界面不仅包括视觉的设计,它的本质是设计一种从底层概念到物理界面的映射
4.7. 人机交互研究人员对映射的设计进行了广泛的研究,他们制定出的指南主要适用于设计的物理层次和语言层次,这一指南同样适用于通过概念设计的系统
4.8. 概念提供了机会以完善设计的概念层次与物理层次、语言层次的关系
5. 解决模棱两可的操作
5.1. 使用集合概念的软件Zotero可以将论文的引文组织为集合
5.2. safari提供了书签的集合
5.3. Adobe Lightroom允许用户定义照片或电影的集合
5.4. 集合概念与文件夹概念的显著不同是,在集合概念中,一个项目可以属于多个集合
6. 概念熟悉性
6.1. 好用的概念常常可以重用
6.2. 一个好的设计师不仅知道如何发明新概念,而且知道什么时候无须发明新概念
- 6.2.1. 如果你的目的可以通过一个现有概念来实现,那么你最好再次使用这个概念
6.3. 概念与其他任何发明一样
- 6.3.1. 不同的是,概念提供了一种将软件设计的知识和经验变得简单且连贯的方法,从而提供了更具细粒度的重用机会
6.4. 使设计可用的最简单的方法是使用熟悉的、现有的概念
- 6.4.1. 使用用户充分理解的概念可以降低设计不合理的概率,并使设计对用户来说更加直观
6.5. 看起来瞬间爆发的灵感实际上往往来自经年累月的经验培养出的洞察力
-
6.5.1. 一个伟大的设计师会记住一系列设计,随时准备应对遇到的每一个新的设计问题
-
6.5.2. 只有当标准方案不足以解决问题时,他才会寻求新的解决方案
6.6. 软件与任何其他设计领域没有什么不同
-
6.6.1. 应用以前设计的经验教训,你首先需要能够将设计思想提取为可重复使用的关键点,这就是概念的目的
-
6.6.2. 概念是特定设计问题的特定解决方案,它不是一个大而模糊的问题,而是一个个会在许多情况下反复出现的小而明确的需求
6.7. 创造一个新概念来实现一个现有概念可以完美实现的目的不仅是浪费精力,还容易让已经熟悉现有概念的用户感到困惑
6.8. 当将概念映射到用户界面时,对非常规小部件的需求可能表明其基本概念本身就是繁杂和非常规的
7. 概念的重用
7.1. 概念的重用是非常广泛的,尤其是在Web软件中
7.2. 相同的概念可能以不同的形式出现
-
7.2.1. 聊天室概念变成了WhatsApp或Google Groups或Facebook中的小组概念以及IRC或Slack中的频道概念
-
7.2.2. Twitter提供了一个将其设计与现有概念联系起来的很好的例子:关注概念
7.3. 在你发明一个新概念以前,查看现有的概念,看看是否有一个概念满足你的需求
7.4. 请记住,你需要的概念可能来自一个非常与众不同的领域
8. 避免发明新概念
8.1. 当设计师在重用现有概念与发明新概念之间做选择时,最好选择重用通用概念,除非确定现有概念不能有效实现目的
8.2. Keynote的行为大多简单且可预测
- 8.2.1. 他们没有从头开始设计,这也是苹果的组概念更直观的原因
8.3. 如果现有概念似乎仅部分满足你的目标,相较于修改或扩展它,请探索它是否可以与另一个现有概念组合起来提供你需要的功能
9. 概念实例的一致性
9.1. 当设计中出现的概念是熟悉的通用概念的实例时,它应该严格遵守通用概念的行为方式,除非有很好的理由不这样,并且它与通用概念的偏差非常明显
9.2. 没有所谓的对与错,关键在于对概念的熟悉程度以及随之而来的预期
9.3. 预期是软件设计中必须认真对待的强有力因素
9.4. 当概念的行为不可预测且出现不同种行为的可能性似乎相同时,概念设计很可能是错误的
- 9.4.1. 一个好的设计具有必然性的品质