核心：转换率（conversion rate）

通过跟踪有百分之多少的用户被你“转化”到了下一个步骤，就能衡量你的网站在达到“商业目的”方面的效率有多高。

任何在用户体验上所做的努力，目的都是为了提高效率。这基本上是以两种主要形式体现出来的：“帮助人们工作得更快”和“减少他们犯错的几率”。

5 Plans

图片源于作者博客，根据《用户体验要素:以用户为中心的产品设计(原书第2版)》添加说明。

The Elements of User Experience

课程：《人机交互与用户体验》

发表于 2024-10-21 更新于 2025-07-01 分类于 HCI

根据课程《人机交互与用户体验设计》确定，每个部分后面数字表示在教材《人机交互：软件工程视角》豆瓣链接中对应的章节。

1. 初始人机交互和用户体验

1.1 从 HCI 到 UX（1.2）

什么是 HCI

“HCI is a discipline concerned with the design, evaluation and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them.” — ACM SIGCHI
什么是用户体验
“User experience encompasses all aspects of the end-user’s interaction with the company, its services, and its products.”—— Donald Norman
```
💡不能够设计用户体验，只能为用户体验而设计
```
用户体验设计
- 借鉴了人机交互、交互设计、视觉设计、信息架构、用户研究等相关学科
- 主要方法是以用户为中心的设计（User-Centered Design，简称UCD）
- 没有一种用户体验设计方法是完美

用户体验 UX vs. 人机交互 HCI

User Experience	HCI
* 广泛的用户基础 * 受业界青睐 * 常见于产品设计、工业设计领域	* 较为学术化 * 常见于计算机专业研究员 * 如今也包含体验的诸多方面

交互设计 IxD
包括：
- 用户界面设计
- 软件设计
- 产品设计
- 网页设计
- 体验设计

1.2 为什么要学习 HCI（1.2）

人机交互的研究内容
- 人
  - 对人的感知特性有所了解
  - 如何处理信息？
  - 可能会犯哪些错误？
- 机器
  - 有哪些特性可供使用？
- 交互
  - 提供了哪些便利？
  - 受到哪些限制？
  - 怎样在具体设计的时候进行选择？

人机交互的重要性
人机交互是一门交叉学科

  💡 孤立地从一个学科出发永远不可能设计出一个具有良好用户体验的交互式系统

1.3 为什么软件会不好用（2.2）

框架
- 提供理解或定义某种事物的一种结构
- 能够帮助人们结构化设计过程
- 认识设计过程中的主要问题
- 定义问题所涉及的领域
执行评估活动周期（Execution-Evaluation Cycle，简称EEC）：交互设计领域最有影响力的框架
- 目标（Goal） & 意向（Intention）
  - 目标：想做什么
  - 意向：达成目标的一系列活动
- 执行（Execution）
  - 要实现目标必须进行的操作
- 客观因素（World）
  - 执行活动时必须考虑的客观条件
- 评估（Evaluation）
  - 用于衡量活动执行的结果与目标之间的差距
为什么有些用户界面会给用户带来问题：执行隔阂（gulfs of execution）与评估隔阂（gulfs of evaluation）
- 执行隔阂（gulfs of execution）
  - 用户为达成目标而制定的动作与系统允许的动作之间的差别
- 评估隔阂（gulfs of evaluation）
  - 系统状态的实时表现与用户语气之间的差别
ECC 模型的启发
- 设计人员要思考如何才能够使用户简单地确定哪些活动是被允许的
- 确定系统是否处于期望的运行状态等问题

2. 交互设计的原则和目标

2.1 “以用户为中心的系统设计”由来（9.2）

相关技术
- 以用户为中心的系统设计（User-Centered Systems Design, UCSD）
- 人本中心的系统设计（Human-Centered System Design, HCSD)
- 用户体验（User Experience, UX）
- 以用户为中心的设计（User-Centered Design, UCD）
- 交互设计（Interaction Design, IxD）
- 人机交互（Human-Computer Interaction, HCI）
- 旨在改善人与计算机的交互方式，但研究侧重和范围各不相同
用户为中心的设计（用户为中心的系统设计）
- 该领域的从业人员汲取了人类学、社会学和信息科学等领域的基础研究成果
- 近年来与人因工效学（Human Factors）、UX、HCI、计算机支持的协同工作、以计算机为媒介的交流信息，以及普适计算等存在相当交集
  - 人因工效学：
    - 目的是使工作环境和工作操作中的安全和健康达到最优，并确保工具、设备还有其他物品的可用性
    - 人因工效学关注的是人与其工作或休闲环境提供良好的“匹配”
以用户为中心的设计思想：人类应该被看作是信息系统中最重要的元素，应该被引入设计
- 包含对用户需求的关注，对活动、任务以及需求的分析，早期的测试和评估，以及迭代式的设计
- 重点：更加强调用户，而不是关注与征集需求和说明的规范化方法
  - 不是一个死板的设计过程，而是一个更加灵活，迭代式的设计方法
- 以人为中心的设计则更进一步
  - 不光关注用户与系统的交互，并且还考虑除了与界面或者系统自身直接交互外，系统还可以怎样影响人们的能力和特征
用户体验（UX）
- 用户对于使用或者预期使用产品、系统或服务的感知和反应
- 用户体验不仅涉及界面设计，还关注人在使用产品前、使用产品时以及使用产品后的心情、信念、喜好、感知、身体和心理的反应、行为以及成就感
```
💡经常和可用性交替使用，但是两者的关注点有明显的不同
~ 可用性和可用性工程关注的是与任务相关的方面（即完成工作）
~ 用户体验与体验设计则将用户的感觉、心情、价值观等放在首位
```
人机交互（HCI）
- 对人（用户）与计算机之间交互方式的研究
- 涵义较界面设计更加宽泛
- 根源是社会科学
人机交互发展的三股浪潮
- 第一股浪潮
  - 吸收了认知理论和人因学的观点
- 第二股浪潮发生在20世纪80年代后期到21世纪早期
  - 关注使用多种应用程序的用户群体，吸收了“情境行为”“分布式认知”以及“活动理论”等多种理论。
  - 在这个阶段“僵化的指导方针、规范化的方法和系统的测试方式”已经不再是主要的关注点，因为人机交互的研究和从业人员已经转向如“参与式的设计研讨会、系统原型和情境问答等各种主动式方法”
- 第三股浪潮
  - 认识到计算机已经被应用到各种私有和公共领域，从公共场合进入到日常生活，其使用不再具有明确的工作相关性、目的性和合理性。
关键技能：确定哪些是核心、主要，哪些是边缘、次要

2.2 可用性（3.2）

Affordance：“可供性” 或者 “示能”
- 指一个物理对象与人之间的关系。该物理对象可以是动物或者人类，甚至也可以是机器和机器人，二者之间发生的任何交互作用。” ——Donald Norman《设计心理学》
- 示能指所有操作的可能性，而非特定指好的交互操作
Mental Modal：“头脑模型” 或者 “心智模型”
- 确定程序充分反映用户关于特定任务的心智模型
可用性目标
- 易学性 learnability
  - 指使用系统的难易，即系统应当容易学习，从而用户可以在较短时间内应用系统来完成某些任务
  - 最基本的可用性属性
  - “10 分钟法则”
- 高效率 efficiency
  - 效率：当用户学会使用产品之后，用户获得的生产力水平
- 易记性 memorability
  - 用户在学会使用软件后应当容易记忆
  - 对偶尔使用的用户，也能够借助一些简单提示即能够使用系统，而不用一切事情从头学起
  - 影响因素：
    1. 位置：将特定对象放在固定位置
    2. 分组：对事物按照逻辑进行恰当的分组
    3. 惯例：尽可能使用通用的对象或符号
    4. 冗余：使用多个感知通道对信息进行编码
- 低出错率（low error rate）
  - 与计算机不同，人是会犯错误的
    - 有些错误会被用户发现并纠正
    - 有些错误会带来灾难性后果
  - 措施
    - 保证导致灾难性后果错误的发生频率降到最低
    - 保证错误发生后迅速恢复到正常状态
- 主观满意度（satisfaction）
  - 用户对系统的主观喜爱程度
  - 某些情况下，系统的娱乐价值比完成任务的速度更为重要（如家用计算、游戏等非工作环境的系统）
可用性
- 是衡量交互式系统质量的一种重要度量
- 体现了软件质量观念的转变
  - 传统软件质量观
    - 侧重内部效率和可靠性
    - 如程序代码运行时的效率以及灵活性、可维护性
  - 人机交互软件质量观
    - 转向用户视角

2.3 可用性工程（Usability Engineering）(3.3)

关键步骤
- 了解用户
- 竞争性分析
- 设定可用性目标
- 用户参与的设计
- 迭代设计
- 产品发布后的工作
简易可用性工程（DUE: Discount Usability Engineering）
- 步骤
  - 用户和任务观察
    - 了解产品的目标用户
```
  ⚠️ 注意
    - 要直接与潜在用户进行接触，不要满足于间接的接触和道听途说
    - “你”不是用户
    - 不要“闭门造车”
```
  - 场景（scenario）
    - 简便易行的原型工具，可节省时间和成本
    - 作用：
      - 在界面设计过程中可以把场景作为用户最终如何与系统进行交互的描述手段
      - 在用户界面设计的早期评估阶段，可以在没有实际可运行原型的情况下通过场景来获得用户的反馈
  - 边做边说
    - 最有价值的单个可用性工程方法
    - 让真实用户在使用系统执行一组特定任务的时候，讲出他们的所思所想
    - 可了解用户为什么这样做，并确定其可能对系统产生的误解
    - 对用户而言不是那么自然，因而实验人员需要不断地提示用户，或请他们事先观摩测试案例
  - 启发式评估
    - Jakob Nielsen等人开发的非正式可用性检查技术
    - 过程
      - 专家使用一组称为“启发式原则”的可用性规则作为指导，评定用户界面元素（如对话框、菜单、导航结构、在线帮助等）是否符合这些原则
    - 启发式规则不是一成不变的
      - 评估不同的设备，如玩具、WEB应用、可穿戴计算设备等，需要根据设计原则、市场研究和需求文档，相应地修改相关原则
        
        其中：
        
        N 是设计中存在的可用性问题的总数，L 是单个参与者所能够发现的可用性问题的比例（经验取值约为31% ）
        
        5 名专家能够发现约 80% 的可用性问题，被认为是最恰当的可用性测试用户数量
        
        若用户数量较多，建议将测试分阶段进行

2.4 设计的基本原则（3.4）

标准与原则
- 标准
  - 由专家制定的，汲取了研究领域中公认的知识和最好的实践。
- 原则
  - 不仅详细列举了那些可以支持设计决策的一般性理论想法，还能够解释为什么有些产品是成功的，以及可能是什么原因导致了产品的不成功，相较而言更具宽泛性。
  - 理想情况下，原则都是以基于大量数据的采集和测试中得到的理论观点为基础的。
代表原则
- Alan Dix（基本规则）
  - 可学习性：新用户能用它开始有效的交互并能获得最大的性能
  - 灵活性：用户和系统能以多种方式交换信息
  - 健壮性：在决定成就和目标评估方面对用户提供的支持程度
- Ben Shneiderman：黄金规则
  - 尽可能保持一致
  - 符合普遍可用性
  - 提供信息丰富的反馈
  - 设计说明对话框以生成结束信息
  - 预防并处理错误
  - 让操作容易撤销
  - 支持内部控制点
  - 减轻短时记忆负担
- Donald Norman:
  - 应用现实世界和头脑中的知识
  - 简化任务结构
  - 使事情变得明显
  - 获得正确的映射
  - 利用自然和人为的限制力量
  - 容错设计
  - 当所有都不成功时进行标准化
- Nielsen and Molich: 启发式（Heuristics）规则
  1. 系统状态的可见度
    - 系统应该始终在合理的时间以适当的反馈信息让用户知道系统正在做什么
  2. 系统和现实世界的温和
    - 告诉用户他们可以做什么；阻止受限制的操作
  3. 用户享有控制权和自主权
    - 对于因错误而做出的选择，提供一种“返回方法”［如撤消或重做］，或者重新启动的方法［如网站上的返回主页］
  4. 一致性和标准化
    - 不要在不同的地方为同一个功能使用多个概念或名称
    - 提示符、菜单和用户手册的术语要保持一致
    - 使用没有歧义的图标或图像
    - 在整个应用程序使用一致的颜色、布局、大小写和字体
  5. 避免出错
    - Avoid possibility for users to make errors
  6. 依赖识别而非记忆
  7. 使用的灵活性和高效性
    - 对于新手用户，提供简单（但流程较长）的交互操作
    - 对于高级用户，提供快捷键，宏操作等
    - 充分考虑不同类型用户的使用偏好
  8. 审美感和最小化设计
    - Do not put too much, irrelevant information in Dialog boxes
    - Use standard and commonly accepted controls (sliders, buttons etc.)
    - Select fonts/sizes that are suited for screen display to maximize readability
  9. 帮助用户识别、诊断和恢复错误
    - 错误信息应该用简单的语言表达（没有代码），准确指出问题所在，并建设性地提出解决方案。
  10. 帮助和文档
    - Must provide help/manual/user-guide
    - Language and format of User-guide should use simple, standard terminology

3. 如何定义交互系统的需求和用户

3.1 交互需求的差异（5.2，5.3）

不论初始情形如何、项目的目标是什么，都需要讨论、提炼、澄清用户的需要、需求、以及期望
了解用户及其对产品的使用能力，产品相关的所有目标，产品的使用条件，和产品性能需求等
需求获取是项目设计的第一个阶段
- 关于自标产品的一种陈述，它指定了产品应做什么，或者应如何工作
- 应该是具体、明确和无歧义的
  - “完整下载任何网页的时间应少于5秒”：具体的需求“
  - 女孩们应觉得这个网站吸引人”：不具体的需求
交互需求的差异
- 产品自身决定
- 用户群体决定
产品特性差异
- 功能不同
- 场景因素
- 非功能需求
  - 交互式设备涉及许多类型的非功能需求：如大小、重量、颜色、有效性等
- 环境因素
  - 设备环境（物理环境）：所处的物理环境可能会影响交互范围的选择
  - 社会环境：需要考虑协作和协调等社会因素
  - 组织环境：用户支持的质量、响应速度如何？是否提供培训资源或设施？
  - 技术环境：产品应能运行于何种平台上？应与何种技术兼容？
需求验证：迭代式
- 检查获取的需求是否真的符合用户的要求
- 原型的优点
  - 能够给用户一个更加直观的产品形象
  - 是用户乐于接受并愿意与设计人员合作的一种需求验证方式
  - 特别对交互方面的需求验证，原型可谓最为恰当的验证工具
- 原型的重要性
  - 用户往往不能准确描述自己的需要
  - 用户在看到或尝试某些事物后，就能立即知道自己不需要什么
  - 原型可用于检查需求获取结果是否存在偏差
  - 对设计方案也有很好的验证效果
- 原型分类（5.6.5）
  - 低保真原型：多数项目的首选
    - 定义：与最终产品不太相似的原型；使用与最终产品不同的材料
    - 优点：简单、快速、便宜、易于制作和修改
    - 常见形式：草图、故事板、绿野仙踪法
  - 高保真原型：
    - 定义：与最终产品更为接近，使用相同的材料
    - 缺点：制作时间长，难以修改
    - 风险：用户会认为原型就是系统，开发人员可能认为已找到了一个用户满意的设计

3.2 用户的差异（5.4）

背景
- 任何一款交互式计算系统其所面对的用户都是成干上万，上百万，上千万的。而这数以干万计的用户并不是完全相同的。
- 设计人员应该意识到个体的差异并在设计中尽可能地体现这些差异。
- 长期差异：性别、身体能力、智力
- 短期差异：压力、疲劳
- 年龄：随着时间变化
计算机操作水平的差异
- 新手用户
  - 特点：敏感，且很容易在开始有挫折感
  - 设计要求
    - 不能将新手状态视为目标
    - 让学习过程快速且富有针对性
    - 确保程序充分反映了用户关于任务的心智模型
    - 无论什么样的帮助，都不应该在界面中固定
    - 具有向导功能的对话框在不需要帮助的时候消失
- 中间用户：数目最多、最稳定和最重要的用户群是中间用户（或称主流用户）
  - 特点
    - 高级特性的存在会使其放心
    - 能够区分经常使用和很少使用的功能
    - 高级功能的存在让永久的中间用户放心
  - 设计需求
    - 常用功能放在用户界面的前端和中心位置
    - 工具提示（Tooltip）是适合中间用户最好的习惯用法
    - 提供高级功能特性，即便不需要
- 专家用户
  - 特点
    - 对缺少经验的用户有着异乎寻常的影响：”专家说不好就不好”
    - 欣赏更新的且更强大的功能
    - 不会受到复杂性增加的干扰
  - 设计要求
    - 对经常使用的工具集，要能快速访问（提供快捷方式）
- 存在的问题：程序员只创造适合专家的界面，而市场人员要求只适合新手的交互
- 目标
  - 让新手快速和无痛苦地成为中间用户；
  - 避免为那些想成为专家的用户设置障碍；
  - 让永久的中间用户感到愉快
年龄差异：感知、身体和认知
- 老年用户
  - 误解：老年人缺乏对新技术的热情
  - 事实：老年人有更多空闲时间和可花费的收入——市场巨大
  - 技术应能提供对缺失能力的支持
  - 设计必须清楚、简单并且容许出错
  - 信息访问应该采用多种方式（冗余）
- 儿童用户
  - 他们有自己的目标、喜好和憎恶
  - 在为儿童设计交互式系统时让他们参加很重要
  - 允许多种输入模式（包括触觉或手写）
  - 通过文本、图形和声音呈现信息的冗余显示也将增强他们的体验
文化差异：语言、文化符号、姿势和颜色
- 在不同的文化中符号有不同的意思
  - 勾（√）和叉（X）分别表示肯定和否定
  - 不能假设每个人都以同样的方式解释符号
- 姿势的理解存在差别
  - 点头 vs. 摇头
- 颜色的使用
  - 通过冗余阐明特定颜色的指定意义
  - 切忌在界面上仅以颜色作为信息区分的标志
健康差异
每个国家至少有 10% 的人口有残疾
- 视觉损伤
  - GUI 应用的增加将阻碍视觉损伤用户的使用
  - 辅以声音的应用和触觉的应用（Hearme，seeing AI）
- 听觉损伤
  - 较视觉残疾对与图形界面交互的影响要小
  - 给听觉内容加文字描述
  - 姿势识别可作为信息输出方式
- 身体损伤
  - 身体损伤导致的肢体控制问题，语言表达能力的损伤

3.3 理解用户（2.4）

人类处理机模型 Model Human Processor
- 最著名的信息处理模型，描述了人们从感知信息到付诸行动的认知过程
- 三个交互式组件
  - 感知处理器：信息将被输出到声音存储和视觉存储区域
  - 认知处理器：输入将被输出到工作记忆，能够访问工作记忆和长时记忆中的信息
  - 动作处理器：执行动作
- 用途
  - 人机交互本质上也可以被看作是一个信息处理过程
    - 在进行界面设计时，可将与人的信息处理能力相关的知识和理论作为参考
    - 可评估完成不同任务所需的认知要求
    - 可预测不同界面下任务的完成效果
人脑的记忆结构
- 感觉记忆
  - 又称瞬时记忆在人脑中持续约为1秒钟
  - 作用：把相继出现的一组图片组合成一个连续的图像序列，产生动态的影像信息
- 短时记忆
  - 感觉记忆经编码后进入短时记忆（Short-Term Memory，STM）
  - 又称工作记忆，约保持30秒
  - 储存的是当前正在使用的信息，是信息加工系统的核心，可理解为计算机的内存
  - 容量
    - 实验证明，人的短时记忆的存储容量大约为个信息单元，这一发现被称为理论，有时也被称为“MAGIC NUMBER”
    - 通过将信息组合成一个个有意义的单位可以帮助我们记住复杂的信息
    - 正确理解理论
      - 界面设计时要尽可能减小对用户的记忆需求，同时可考虑通过将信息放置于一定的上下文中，来减少信息单元的数目
      - 对命令行界面设计非常有用
- 长时记忆
  - 短时记忆 -> 长时记忆
    - 短时记忆中的信息经进一步加工后会变为长时记忆；
    - 只有与长时记忆区的信息具有某种联系的新信息才能够进入长时记忆；
  - 长时记忆的信息容量几乎是无限的
  - 启发：注意使用线索来引导用户完成特定任务在追求独特的创新设计时也应注重结合优秀的交互范型
  - 遗忘
    - 短时记忆中的信息经进一步加工后会变为长时记忆不代表长时记忆区的信息丢失了
    - 可能失去了提取信息的途径，或原有联系受到了干扰
视错觉
- 知觉感受的扭曲
  - 前后景互换实际上就是视错觉的一种
- 视错觉是不可避免的
- 启示：对于物体的视觉感知与物体所处的上下文密切相关

3.4 格式塔（Gestalt）心理学（2.4.2）

认知心理学（Cognitive Psychology）
- 有助于理解人与计算机的交互过程，同时也可对用户行为进行预测
- 人对于外界的感知有 80% 来自于视觉获取的信息
格式塔心理学 (Gestalt)
- 研究人是如何感知一个良好组织的模式的，而不是将其视为一系列相互独立的部分一事物的整体区别于部分的组合
- “GESTALT”一德语，“完形（configuration）”或“型式(pattern) “
- 格式塔心理学又称完形心理学
- 表明：用户在感知事物的时候总是尽可能将其视为一个”好”的型式
主要原则
- 相近性原则
  - 空间上比较靠近的物体容易被视为整体
    - 设计界面时，应该照相关性对组件进行分组
- 相似性原则
  - 人们习惯将看上去相似的物体看成一个整体
    - 功能相近的组件应该使用相同或相近的表现形式
- 连续性原则
  - 共线或具有相同方向的物体会被组合在一起
    - 将组件对齐，更有助于增强用户的主观感知效果
- 对称性原则
  - 相互对称且能够组合为有意义单元的物体会被组合在一起
- 完整性和闭合性原则
  - 人们倾向于忽视轮廓的间隙而将其视作一个完整的整体

3.5 如何构建人物角色（5.5）

什么是人物角色
- 交互设计中的问题：似乎每个调研到的用户都略有差异，如何满足所有用户的需要？
- 人物角色（Personas）
  - 不是真实的人
  - 基于观察到的真实人的行为和动机，并且在整个设计过程中代表真实的人
  - 是在人口统计学调查收集到的实际用户的行为数据的基础上形成的综合原型
人物角色的构建
- 理想过程
  - 现实情况
    - 跟用户说什么
    - 提什么问题
    - 应该怎样进行对话
```
⚠️ 注意：过分依赖用户或者怀疑用户都不会带来最好的设计
```
  - 方法
    - 从构思带有少量细节的候选角色着手，将类似或相关角色归到一组，然后再填充细节
```
⚠️ 注意：要特别关注使角色之间彼此相区别的那些特征
```
人物角色包含的内容
- 姓名、年龄、性别和照片。
- 关于他们在“现实生活”中所做事情的描述。
- 他们在产品或服务领域的经验水平。
- 他们将如何与你的产品互动，以及他们使用产品的频率。
- 他们执行相关任务时的目标和关注点：速度、准确性、彻底性或任何其他可能影响他们使用的需求。
- 引用用户的话来总结该人物角色的态度。
人物角色的作用
- 弹性用户
  - 产品团队的每一个人都有对用户及其需要的不同理解，这种不确定性会使产品变成“四不像”
  - 如设计医院产品时，考虑设计能够满足所有护士的产品
- 自参考设计
  - 设计者或者程序员将其自己的目标、动机、技巧及心智模型投射到产品的设计中
  - 非程序员用户通常难以理解产品的工作方式
- 边缘情况设计
  - 边缘情况指的是一定会发生，但通常不会发生在人物角色上的情况
  - 必须考虑边缘情况，但它们又不应该成为设计的关注点

3.6 基于人物角色和场景交互需求定义（5.6.3）

人物角色 + 场景剧本 → 需求
需求定义的 5 个步骤（迭代）
1. 创建问题和前景综述
  - 问题综述：定义了设计的目标
    - 应该简明反映需要改变的情况，来服务人物角色和提供产品给人物角色的商业组织
  - 前景综述高层次的设计视图是问题综述的倒置
    - 从用户需要开始，转向如何用设计视图来满足商业目标
```
⚠️ 注意
  - 问题和前景综述直接从研究和用户模型中获得
  - 用户目标和需求应该从焦点和次要人物角色中推导出
  - 商业目标应该从利益相关人的访谈中获得
```
2. 头脑风暴
  - 在创建情境场景剧本时，需要摒弃头脑中先入为主的偏见和成见
  - 开展头脑风暴的原因
    - 将头脑置于“解决问题模式”
    - 不受约束且不加以评判
    - 将所有想法表达出来，并整理记录下来
  - 头脑风暴的时间
    - 不要花费太多时间
    - 当想法开始重复或出现得越来越慢时停止
3. 确定人物角色的期望
  - 心智模型 Mental Model
    - 一个人思考或者解释事务的方法，是其对外部现实的内部表达
    - 一个人的心智模型通常是根深蒂固的
    - 人们对产品的期望和对产品工作方式的想象大部分来自于他们的心智模型
  - 界面表现模型与用户心理模型尽量匹配是非常重要的
  - 理清如下问题
    - 理解人物角色目标、经历、渴望，以及其他社会、文化、环境和认知因素
    - 人物角色在使用产品体验方面可能有的一般期待和愿望
    - 人物角色对产品行为的期待和愿望
    - 人物角色关于该领域下基本数据单元或者元素的认知
4. 构建情境场景剧本
  - 情境场景剧本
    - 关注人物角色的活动，及其心理模型和动机
    - 将注意力集中在设计的产品中怎样能够最好地帮助你的人物角色达到目标
    - 专注于高层次的从用户角度描述的行动，做到广而浅
      - 不应描述产品或交互的细节
      - 专注于高层次的从用户角度描述的行为
    - 与人物角色不是一对一的关系
      - 大多数时候可能不止需要一个情景场景剧本，尤其是当有多个首要人物角色时，但有时单个首要人物角色也可能有两个或者多个不同的使用场景。
5. 确定需求
  - 直接提取需求
  - 分别提取数据和功能需求
    - 数据需求：必须在系统中被描述的对象和信息
    - 功能需求：系统对象必须进行的操作
    - 其他需求：开发时间表、产品价格、重量等

4 如何开展交互设计

4.1 交互设计的活动和步骤（6.2）

过早地把重点放在小细节、小部件和精细的交互上会妨碍产品的设计
- 先站在一个高层次上关注用户界面和相关行为的整体结构（设计框架）
Allan Cooper 定义的交互框架
1. 定义外形因素和输入方法
  - 外形因素：设计什么样的产品
  - 产品输入方法
2. 定义功能和数据元素
  - 在需求定义阶段确定的，需要按照用户界面的表现语言来描述
  - 数据元素
    - 交互产品中的基本主体，是能够被用户访问和操作的基本个体
    - 如相片、电子邮件、订单
    - 数据元素应符合人物角色的心理模型
    - 考虑数据元素之间的关系也很有用
  - 功能元素
    - 对数据元素的操作及其在界面上的表达
    - 对数据元素操作的工具，以及输入或者放置数据元素的位置
3. 决定功能组合层次
  - 目的：更好地在任务中和任务间来帮助促进任务角色的操作流程
  - 需考虑的问题
    - 哪些元素需要大片的视频区域
    - 容器如何组织才能优化工作流
    - 哪些元素是被一起使用的
      - 一个过程的多个步骤
    - 产品平台、屏幕大小、外形尺寸和输入方法的影响
4. 勾画大致的设计框架
  - 对界面布局进行粗略的描述最初阶段：界面的视觉化工作应该非常简单
  - 方块图
    - 用粗略的方块图来表达并区分每个视图
    - 方块图对应窗格、控制部件为每个方块图添加上标签和注解
    - 为每个方块添加上标签和注解
  - 注意：不要被界面上某个特殊区域的细枝末节分散了精力
5. 构建关键情境场景剧本
  - 描述了人物角色最频繁使用界面的主要路径
    - 重点在任务层
    - 举例：电子邮件应用中关键线路的活动主要包括读和写邮件，而不是配置邮件服务器
  - 注意事项
    - 必须在细节上严谨地描述每个主要交互的精确行为，并提供每个主要线路的走查
    - 可使用低保真草图序列的故事板进行描述
6. 通过验证性的场景剧本来检查设计
  - 验证性的场景剧本不用具备很多细节
    - 但包含一系列“如果怎样，将怎样”的问题
    - 目标是对设计方案指点，并根据需要进行调整
  - 三种验证性的场景剧本
    - 关键线路的变种场景剧本
      - 关键途径的替换
    - 必须使用的场景剧本
      - 必须要执行但又不是经常发生的情况
    - 边缘情形使用场景剧本
      - 非典型情形下产品必须具备，但不太常用的功能
- 视觉设计框架
  - 确定界面使用的颜色、风格、小组件（widget）
  - 整体的外形尺寸等
- 工业设计框架
  - 原型产品的构建
  - 输入方法方面的研究工作

4.2 如何简化交互设计（6.3）

简化设计的四个策略
1. 删除：（最明显的简化设计方法）删除不必要的
  删除什么？：
  - 功能相关：
    - 按照优先级对功能进行排序：关系到用户日常使用体验的功能最有价值
    - 开发团队有限，要尽力保证这部分功能的正常交付
    - 以用户为中心并不意味着要满足所有用户的需求，并获取用户的欢心。而是能给大部分用户一个良好的体验：通过人物角色（Personas）确定
    - 删除可能出现错误的情况
  - 删除视觉混乱
    - 通过删除多余文字，能加速用户的阅读速度，还能让重要的内容变得“水落石出”。
    - 通过删减界面上可能引起视觉混乱的情况，也可以有效减少用户必须处理的信息，从而集中主意力在真正重要的内容上，使得“数据墨水率〞越来越高。
    - 方法：
      - 使用空白或轻微的背景色对界面内容进行分割，少使用线条和各种强调效果；
      - 合理控制信息的显示层次，减少界面元素的大小和形状变化等。
```
  ⚠️ 注意
    - 问题和前景综述直接从研究和用户模型中获得
    - 用户目标和需求应该从焦点和次要人物角色中推导出
    - 商业目标应该从利益相关人的访谈中获得
```
2. 组织：组织要提供的
  
  按照有意义的标准对界面组件进行分组：最快捷的简化设计方式
  - 分块
    - 通过分块可以把繁琐的功能组织成清晰的层次结构
    - 格式塔心理学：法则
    - 名词：可以按字母表、时间或空间顺序排列的清单
  - 清晰的信息分类标准
    - 切忌从开发人员的视角进行思考
      - 以免设计出不符合用户视角的难以使用的产品
  - 利用不可见的网格进行组织
    - 布局对于设计能否让用户感觉简单十分重要
  - 搜索与页面组织
    - 错误观点
      - 既然有搜索，那么设计者不需要花费过多时间对界面内容进行组织
    - 实际情况
      - 用户只有在缺乏有效导航的情况下才会使用搜索
      - 实现高效搜索功能比组织页面内容困难得多
    - 结论
      - 先对内容进行有效组织
      - 然后再考虑如何设计搜索
```
  ⚠️ 注意：千万不要被自己规划图中清晰的线条和整洁的布局所迷惑
```
3. 转移：各司其职
  - 目的：
    - 将功能以最恰当的方式实现
    - 可以是不同设备或平台之间的转移
    - 也可能是设备和用户之间的转移
  - 设备之间的转移
    - 开发不同终端产品时，没有必要完全复制另一端的所有功能
  - 向用户转移
    - 要求用户以计算机易于处理的方式去制定一个精确计划，则很容易使得项目失败
      - 搞清楚工作适合交给计算机，什么工作适合留给用户

4.3 设计体贴的软件（6.5）

如何做一个体贴的产品：
- 效仿一个关心他人的人是如何和别人打交道的
体贴的软件是自信的
- 当用户提出请求时，体贴的软件不仅不应该怀疑用户的请求，同时应该为可能发生的错误做好准备
  - 比如恢复已经删除的文件等
软件使用与人的记忆|
- 为了能够使用软件完成任务，必须记住的两类信息或知识
  - 和软件如何操作相关的内容
    - 比如应当选择哪个命令或操作、文件存在哪个目录、如何去执行某个操作、其对应的快捷键是什么等
  - 和该任务所需的领域知识相关
    - 比如特定编程语言的语法规则、可供使用的标准库函数，这些函数的参数和返回值是什么；普通用户必须记住的网站名称或地址等。
体贴的软件会怎么做
- 赋予产品了解用户行为的能力，记忆并灵活地根据用户之前的行为显示信息和功能
- 一个简单的原则
  - 如果信息值得用户输入，那么就值得程序记住它们，并在下一次使用时作为默认值
  - 如果这不是用户所希望的，可以让用户纠正
减少用户的等待感
- 今天的用户大多是缺少耐心的消费者，作为软件设计人员应当设法减轻用户的等待感
  - 可以以某种形式的反馈让用户了解操作进行的进度和状态
  - 或者以一种渐进的方式来把当前已完成的处理结果提供给用户
  - 或者给用户分配一些任务，从而分散他的注意力
出错信息的设计
- 用户希望避免错误造成的结果，而不是错误信息
- 好的出错信息应当遵循以下四个简单原则
  1. 使用清晰的表达语言，而非难懂的代码
  2. 语言应当精炼准确，而非空泛而模糊
  3. 对用户解决问题提供建设性的帮助
  4. 出错信息应当有好，不要威胁或责备用户
错误回复机制
- 允许用户撤销错误命令产生的结果
- 允许编辑并重新提交以前的命令，而不用从头输入等
设计提示
- 设计的时候更多站在用户的视角思考
- 通过参与式设计获取用户对特定任务的表征
- 多次迭代的用户测试

4.4 有用的交互设计模式（6.6）

交互设计模式：

不仅仅涉及结构和元素组织，还关注响应用户活动的动态行为与变化

  💡 交互设计模式“是从过去已证明成功的实例中学习的”，是“获得以及重新应用已有知识的一种方案”。 ——Alan Dix

模式的讨论
- 设计模式能够帮助提供有价值、有用的设计思路
模式不是即拿即用的商品
- 每一个设计仍然需要创造性和直觉

5. 如何对交互性能进行评估

5.1 为什么要进行评估（10.2）

邀请用户进行评估的目的不是设法理解用户，而是特定用户在特定环境背景下如何使用系统来执行特定任务。
有一些设计人员错误地认为他们自己能够准确地了解用户工作的方式，然而在实际观察用户操作时就会发现，用户可能会很有创意，并且使用设计人员从未考虑过的方式来使用系统。
评估有助于达成的目标
- 评估系统功能的范围和可达性
  - 不仅包括具有合适的功能，也包括使用户能清晰地意识到需要执行任务的一系列行为，还包括将系统的应用与用户对任务的期望相匹配
- 评估交互中用户的体验
  - 特别对休闲和娱乐系统而言，这一目标就更为重要
- 确定系统的某些特定问题
  - 如用户是否能准确定位到特定菜单项，页面文字显示是否具有良好的可读性等
原则：
- 最具权威性的评估不应该依赖于专业技术人员，而应该依赖于产品的用户：对软件交互性能的评估，主要应有用户来完成
- 评估与设计应结合进行
  - 交互评估是一个过程，这个过程早在产品的初始阶段就开始了。因此一个软件在设计时反复征求用户意见的过程应与交互评估的过程结合起来进行。在设计阶段反复征求意见的过程是评估的基础，不能取代真正的评估。
  - 仅靠用户最后对产品的一两次评估，是不能全面反映出软件的可用性的。
- 交互性能评估应该在用户的实际工作环境下进行
  - 交互评估不能靠发几张调查表，让用户填写完后，经过简单的统计分析就下结论
  - 必须在用户实际操作以后，根据其完成任务的结果，进行客观的分析和总结
  - 如果能够在用户的实际工作环境中开展测试可能会得到更为实用的结果
- 要选择有广泛代表性的用户
  - 参加测试的人必须具有代表性
```
    ⚠️ 注意：
        - 尽早测试、经常测试
        - 快速但存在瑕疵的测试好过什么都没有做的测试
```

5.2 评估实验的规划（10.5）

DECIDE 评估框架
1. 确定（Determine）：评估需要完成的总体目标
  - 检查设计人员是否理解了用户需要；
  - 确保最终界面满足一致性要求；
  - 调查新技术的引入对用户工作的影响；
  - 决定如何修改已有产品的界面，以提高可用性。
2. 发掘（Explorer）：需要回答的具体问题
3. 选择（Choose）：用于回答具体问题的评估范型和技术
  - 定性数据（陈述性数据）
  - 必须权衡实际问题和道德问题
    - 最适合的技术可能成本过高，或所需时间过长，或不具备必要设备和技能
  - 可结合使用多种技术
    - 不同技术有助于了解设计的不同方面不同类型数据可从不同角度看待问题组合有助于全面了解设计的情况
4. 标识（Identify）：必须解决的实际问题，如测试用户的选择
  - 明确实际问题
    - 用户：先做小规模测试确定用户技能所属的用户群
      - 类型：
        
        （如新手和专家）具备不同技能的用户
        
        年龄
        
        性别
        
        文化
        
        教育程度
        
        个性
      - “如何让用户参与“
        
        稍事休息和走动
        
        努力消除用户的焦虑
        
        支付报酬，有礼貌
        
        在任务执行前，安排用户熟悉系统
    - 设施及设备
      - 所有实验设备运转正常、电量充足、项目期限以及经费预算
    - 期限及预算
    - 评估人员的专门技能
5. 决定（Decide）：如何处理有关道德的问题
  - 应保护个人隐私
    - 除非获得批准，书面报告不得提及隐私（姓名、健康、雇佣情况、教育、财务、居所）
    - 评估前签署协议书（IRB）
  - 指导原则
    - 向参与者明确说明研究的目的以及参与者需要做的工作。
    - 向用户说明他们提供的地址、财务、健康或其他敏感资料属于机密。
    - 向用户说明测试的目的是对软件进行评价而不是对用户个人进行测试。
    - 向用户说明关于实验的任何特殊要求。
    - 实验人员应该告知用户自身与待测系统没有关系。
    - 尽量不摄录用户的面部，以减轻他们对录像的忧虑
    - 欢迎用户提问
    - 在可能情况下，应支付用户费用以建立正式的合作关系，并明确双方的义务和责任。
    - 说明参与测试是自愿行为。
    - 避免在引用和描述时无意中透露用户身份。
    - 征得用户同意以后才能引用用户的话语，且引用过程只能以匿名方式进行。在正式报告发布之前，应为用户提供报告副本
    - 牢记“己所不欲，勿施于人”的一般原则。
6. 评估（Evaluate）：解释并表示数据
  - 可靠性
  - 有效性
  - 偏见
  - 适用范围
  - 环境影响
    - 霍桑效应（Hawthorne Effect）
      它描述了在进行观察或实验时，研究对象会表现出与他们平常行为不同的行为。具体来说，霍桑效应通常表现为当人们知道自己正在被观察或参与实验时，他们可能会改变他们的行为，通常是表现得更加积极或更加注意，以满足观察者的期望或要求。
小规模试验：可能会有多次试验
- 测试评估计划
- 避免问题：
  - 含糊不清的指令
  - 错误的时间估计
  - 模糊的任务完成标准
  - 问卷中带有误导性的问题
  - 设备使用中的一些问题
  - 练习访谈技巧

5.3 评估范型及选用（10.3）

评估范型（Evaluation Paradigm）

在使用具体的评估方法前通常需要先考虑最适宜的评估范型，同时需要注意到每种范型都有自身的长处和短处，且并不一定适用于所有类型的系统。

分类

快速评估（Fast Evaluation）：可在短时间完成
- 设计人员非正式地从用户或顾问获得反馈信息，以验证设计构思是否符合用户需要，以及是否能够令用户满意。
- 适用于所有阶段
  - 设计初期：与用户进行非正式接触了解用户对新产品的意见
  - 设计末期：了解用户对图标设计的看法
- 得到的信息通常是非正式、叙述性的
  - 口语
  - 书面笔记
  - 草图
  - 场景
可用性测试（Usability Testing）
- 基于特定任务场景记录用户的出错次数、完成任务的时间等
- 根据这些观察数据计算执行任务的时间、出错次数，甚至分析用户的行为及其原因
- 基本特征
  - 实验是在评估人员的密切控制之下实行的
  - 用户不会受到干扰
- 主要任务：获得用户执行情况的量化数据
现场研究（实地研究，Filed Study）
- 基本特征
  - 在自然工作环境中进行
- 目的
  - 理解用户实际工作情形以及技术对他们的影响
- 优势：
  - 告诉人们是如何真正工作的
- 缺点
  - 难以根据实际情况来控制实验过程
  - 难以侧重于任务变量之间的关系
- 适用范围：
  - 往往用于非安全攸关的系统
预测性评估（Prediction Evaluation）
- 预测性评估中，一方面评估专家们可以根据自己对典型用户的了解来预测产品中可能存在的可用性问题；另一方面也可以基于已有理论模型得出评估结论。
- 基本特征
  - 用户可以不在场
  - 整个过程快速、成本较低
- 缺点
  - 专家可能存在个人偏见
各种评估范型的特征

评估范型	快速评估	可用性测试	现场研究	预测性评估
用户角色	自然行为	执行测试任务集	自然行为	通常不参与
控制权	评估人员实施最低限度控制	评估人员密切控制	评估人员与用户合作	评估人员为专家
评估地点	自然工作环境或实验室	实验室	自然工作环境	类似实验室的环境，通常在客户处进行
适用情形	快速了解设计反馈。可使用其他交互范型的技术，如启发式评估	测试原型或产品	常用于设计初期，以检查设计是否满足用户需要，发现问题，发掘应用契机。	使用启发式评估的原型测试，可在任何阶段进行；模型可用于评估潜在设计的特定方面
数据类型	通常是定性的非正式描述	定量数据，有时是统计数据。可采用问卷调查或访谈搜集用户意见	应用草图、场景、例证等的定性描述	专家们列出问题清单，由模型导出量化数据（如两种设计的任务执行时间）
反馈到设计	通过草图、例证、报告	通过性能评估、错误统汁报告等为未来版本提供设计标准	通过描述性的例证、草图、场景和工作日志	专家列出一组问题，通常附带解决方案建议。为设计人员提供根据模型计算出的时间值
基本思想	以用户为中心，非常实用	基于试验的实用方法，即可用性工程	可以是客观观察或现场研究	专家检查以实用的启发式原则和实践经验为基础，采用基于理论的分析模型

评估技术
- 观察用户
  - 用途
    - 有助于确定新产品的需求
    - 也可用于评估原型
  - 输出：笔记、录音、录像和交互日志
  - 挑战：
    - 不干扰用户的前提下观察用户
    - 分析大量数据
- 询问用户意见
  - 访谈和调查问卷
- 询问专家意见
  - “角色扮演〞的方法，模拟典型用户执行任务的情况，并从中找出潜在问题。
  - 优势：
    - 成本较低
    - 快速完成
- 用户测试
  - 通过测量用户执行任务的情况，比较不同的设计方案通常在受控环境中进行
- 基于模型的分析和评估
  - 用于在设计初期（即制作复杂原型之前）预测设计的有效性，找出潜在的设计问题。
  - 常用技术
    - GOMS 模型
    - 按键模型
常用组合
- 启发式评估+边做边说
- 排除显而易见的可用性问题重新设计后，经用户测试，反复检查设计的效果
- 选择理由
  - 经验性评估不需要用户参与就可以发现并消除系统或产品中存在的许多可用性问题。
  - 这两大类可用性评估方法所发现的可用性问题有明显的不同，这意味着两种方法可以互补而不会重复。
- 访谈和问卷调查
  - 通过对一小部分用户进行开放式访谈，来明确定义封闭式问卷中的具体问题

5.4 评估的对象（5.6.5）

在开发过程中进行评估时会先使用某种原型然后在系统到一定程度后再对整个系统进行评估
纸质原型法非常经济适用于设计的初期阶段
- 收集到的数据一般是定性而非定量的，其结果只是指导设计
基于计算机的原型
- 目前有很多工具可以在多各层次来构建原型，包括从草图原型到交互式的工作原型。
原型分类
- 渐进式
  - 最初的原型在每次开发迭代后，都会向着最终可交付版本不断靠近。
- 变革式
  - 当前原型在每次迭代开发周期结束时都会被丢弃，并开发出新的原型。
低保真原型
- 定义：与最终产品不太相似的原型；使用与最终产品不同的材料
- 优点：简单、快速、便宜、易于制作和修改
- 常见形式：草图、故事板、绿野仙踪法（Wizard-of-Oz）
高保真原型
- 定义：与最终产品更为接近，使用相同的材料
- 缺点：制作时间长，难以修改
- 风险：用户会认为原型就是系统，开发人员可能认为已找到了一个用户满意的设计
构建原型的成本因其复杂程度以及评估的周期而不同，如同在实验室内开展的用户测试和在现场开展的测试成本就有很大不同。但可以肯定的是，无论采取哪种评估方法，原型技术都有利于得到一个好的结果，并且适用于设计过程的很多阶段。

5.5 通过“看”来评估（11.2）

观察的作用
- 观察用户怎样工作：获得数据
- 重要性：用户并不是总是能够客观和完整的对自己使用产品的实际情况进行描述
- 基于观察数据，可以分析用户在做什么并统计用户花在任务各个部分的时间，以及情绪反应
观察的优点
- 适用于产品开发的任何阶段
  - 初期：理解用户的需要
  - 开发过程：检查原型
  - 后期：对最终产品进行评价
- 现场观察是发现同使用环境有关问题的最佳手段
观察涉及看和听两个方面

5.6 通过“问”来评估（12.2，12.3， 12.4）

尤其适用于客观上较难度量的与用户主观满意度和可能的忧虑心情相关的问题。
问卷与访谈
- 快速评估
- 可用性测试
- 现场研究
问卷调查搜集大量用户的意见从中找出普遍性的意见

访谈方便、快捷，若用户没有时间完成问卷，就可以考虑使用访谈方法
在设计问卷的过程应考虑
- 需要什么信息？
- 如何分析问卷？
为了减轻回答问题人员的负担鼓励用户提高回答率，应尽可能应用有限的问题
注意问题的先后顺序
- 先提出一般化容易回答的问题再提出较难回答的具体问题
对征求用户意见的问题
- 应提供一个“无看法”的答案选项
- 避免使用专业术语等
访谈
- 策略
  - 先进行小规模试验
  - 目标是消除问卷设计中的任何问题
  - 问题是否可以理解、结果是否是所期望的、以及问卷是否是期望的信息获取方式
  - 在最后版本发出以前，可以改变表述（并重新测试）
- 避免
  - 设计问题时注意不要暗示答案
  - 访问人的肢体语言对受访人也有较大的影响
数据处理
- 数据的走向和模式
- 数量较大时，应进行数据的标准化，并计算百分比，以便比较不同组别的调查结果
焦点小组是集体访谈的一种形式
- 非正式的评估方法
- 6-9 个典型用户组成
  - 例子：大学网站评估——行政人员 + 教师 + 学生三个分别的焦点小组
- 主持人工作
  - 列清单 + 保证不离题积极讨论 + 结果分析
- 存在风险
  - 用户真正想要的东西并不一定等于他表达出来的东西
  - 避免风险：可以让用户接触在焦点小组中所可能讨论技术的具体实例。
理想情况下
- 评估应该贯穿于整个设计过程中
实际过程中
- 规律性地进行用户测试的费用是很高的
- 寻找用户并不容易，并且很难从不完全的设计和原型获得交互经历的精确评估。
询问专家
- 角色互换
- 压力测试
- 穷尽测试

问卷调查	搜集大量用户的意见从中找出普遍性的意见
访谈	方便、快捷，若用户没有时间完成问卷，就可以考虑使用访谈方法

5.7 启发式评估（12.5）

启发式评估是分析界面可用性的一种相对非正式的方法
具体方法
- 每位专家以他们的方式独立地使用用户界面，记录符合启发式评估标准的设计。

步骤

阶段	步骤
准备（项目指导）	a）确定可用性准则。
	b）确定由3~5个可用性专家组成的评估组。
	c）计划地点、日期和每个可用性专家评估的时间。
	d）准备或收集材料，让评估者熟悉系统的目标和用户。将用户分析、系统规格说明、用户任务和用例情景等材料分发给评估者。
	e）设定评估和记录的策略。是基于个人还是小组来评估系统？指派一个共同的记录员还是每个人自己记录？
评估（评估者活动）	a）尝试并建立对系统概况的感知。
	b）温习提供的材料以熟悉系统设计。按评估者认为完成用户任务时所需的操作进行实际操作。
	c）发现并列出系统中违背可用性原则之处。列出评估注意到的所有问题，包括可能重复之处。确保已清楚地描述发现了什么？在何处发现？
结果分析（组内活动）	a）回顾每个评估者记录的每个问题。确保每个问题能让所有评估者理解。
	b）建立一个亲和图（又称KI法“或A型图解法），把相似的问题分组。
	c）根据定义的准则评估并判定每个问题。
	d）基于对用户的影响，判断每组问题的严重程度。
	e）确定解决问题的建议，确保每个建议基于评估准则和设计原则。
报告汇总	a）汇总评估组会议的结果。每个问题有一个严重性等级，可用性观点的解释和修改建议。
	b）用一个容易阅读和理解的报告格式，列出所有出处、目标、技术、过程和发现。评估者可根据评估原则来组织发现的问题。一定要记录系统或界面的正面特性。
	c）确保报告包括了向项目组指导反馈的机制，以了解开发团队是如何使用这些信息的。
	d）让项目组的另一个成员审查报告，并由项目领导审定。

关于评估专家的人数
- 通常情况下，只需要3~5名专家来做启发式评估，给出有用的结果。
- 非硬性规定：很多人也就认为这是对所有评估类型的硬性规定，这种理解其实是完全错误的。
- 评估所需要的用户数量在很大程度上取决于最终用户群体的多样性。
启发式评估的优点
- 不涉及用户，所以面临的实际限制和道德问题较少，成本相对较低，不需要特殊设备，而且较为快捷。又被称为“经济评估法”
启发式评估的缺点
- “专家每找到一个真实的可用性问题，将发出约一个假警报，忽略大约半个问题”
- 专家找到的问题，可能并不是普通用户面对的问题

5.8 通过“用”来评估（13.2）

用户测试
明确用户
- 用户的组织
- “between-subjects”（被试间设计）
  1. 每个用户只进行一种自变量的实验
  2. 要求有足够多的测试用户，实验结果可能会受到个别参与者的影响
- “within-subjects”（被试内设计）
  1. 每位用户都参与了所有的自变量实验
  2. 需避免“顺序效应”：参与者在执行前一组任务时获得的经验不会影响后面的测试结果
明确测试任务
- 通常在设计实验时我们都会选取对于大多数用户通常都会执行的任务，即所谓的典型任务
度量数据
- 定量数据
  - 完成任务的时间
  - 停止使用产品一段时间后，完成任务的时间
  - 执行每项任务时的出错次数和错误类型
  - 单位时间内的出错次数
  - 求组在线帮助或手册的次数
  - 用户犯某个特定错误的次数
  - 成功完成任务的用户数
- 定性数据
  - 例如：用户为什么使用菜单会产生问题
    - 通过访谈或问卷调查获得

6 交互设计模式与理论

6.1 如何对用户任务进行分解（5.6.4）

任务分析
- 一种用来描述用户的任务以及子任务、这些任务的结构和层次，以及执行任务时用户已经具有的或是需要具有的知识的方法。
“层次化任务分析（HTA）”是人类工效学领域中最广泛使用的方法。
- 目标/任务 — > 子目标/子任务
- 采用层次图结构或表格文本格式表示
- 每个目标以及子目标都有一个描述如何实现该目标的计划
  - 子目标序列
  - 并发需求
  - 行为对任务绩效的指导等方面的信息
- 细分的终止规则
  - 对于不能再进一步细分的子目标，在方框下面画一条横线，表示已经不能再细分。
- 不能细分的任务
  - 包含复杂机械响应的子任务
    - 如”移动鼠标”
  - 涉及内部决策的子任务
    - 如“选择感兴趣的商品”
- 用途
  - 手册和教学
  - 需求获取和系统设计
    - 用来指导新系统的设计
    - 任务分析本身不是需求获取
    - 有助于需求的完整表达
  - 详细的接口设计
    - 如果知道某个任务频繁执行，就会让用户能够很容易地按照合适的顺序执行子任务
    - 如果频繁改变状态，在不同的菜单之间移动将是不可接受的
```
    ⚠️ 注意：
        - 层次化任务分析非常耗时，且不完善
        - 会给出一个有用的、有代表性的描述
        - 但没有说明如何去收集那些我们希望表达的任务信息
```
- 优点
  - 有经验的分析师能够使用HTA相对快捷地提供有用的设计信息，可在早期使用
- 缺点
  - 分析结果的展现方式不容易和软件工程师所用的表示方式联系起来

6.2 如何预测任务的完成时间（8.2）

GOMS 模型
- 主流的支柱之一
  - 基于人类处理机模型
  - 关于人类如何执行认知一动作型任务以及如何与系统交互的模型
  - 采用“分而治之”的思想，将一个任务进行多层次的细化
- 四元素：用于描述用户行为
  - 目标（goal）
    - 用户执行任务最终想要得到的结果
    - 高层次目标如“编辑文章”
    - 低层次目标如“删除字符”
    - 高层次目标可以分解为若干个低层次目标
  - 操作（operator）
    - 任务分析到最底层时的行为，是用户为了完成任务必须执行的基本动作（如双击鼠标左键、按回车键等）
    - 操作不能再被分解
      - 在GOMS模型中它们是原子动作
    - 假设用户执行每个操作的时间是上下文无关的
      - 操作花费的时间与用户正在完成什么样的任务或当前的操作环境没有关系
  - 方法（method）
    - 描述如何完成目标的过程，用于确定子目标序列及完成目标所需要的操作
  - 选择规则（selection rule）
    - 确定当有多种方法时选择和方法
    - GOMS认为方法的选择不是随机的
- 分析
  - 侧重于描述无错误的、专家级的行为
  - 可以用于评价采取多种策略来执行相似任务的情形
  - 常用于电话和全球定位系统的交互预测
    - 用户的相关知识和用户界面需要尽可能统一
    - 但专家级水平的操作人员执行任务的方式可能不同，此时适用
      GOMS模型进行分析
  - 对于多任务或并行任务的分析存在困难
击键层次模型（KLM：Keystroke-Level Model）
- GOMS模型的一个简化版本，也是一种认知任务分析方法
  - 可以快速而近似地计算出用户需要多长时间执行一个任务单元
- 分析
  - 同GOMS模型一样，KLM假定了一个简单的环境
    - 在一个时间专注于一个维务
    - 一个完全定制的界面
    - 无交叉的目标、无干扰、无差错、专家级的熟练行为等
    - 无需担心任务之间的选择关系

6.3 如何预测指定任务的执行效率（8.2.3）

组件与交互
- 交互式系统界面中常常含有各种各样的交互组件
  - 用户在与系统交互的时候需要频繁地在屏幕范围内移动鼠标以激活屏幕组件
  - 用户访问组件的时间对系统的使用效率是至关重要的
Fitts 定律
- 基于对人类的运动特征、运动范围和运动准确性等因素的分析
- 能够预测某种定位设备指向某个目标所需时间
- 可指导设计人员设计按钮的位置、大小和密集程度
- 对图形用户界面设计具有显著指导意义
- “最健壮并被广泛采用的人类运动模型之一”
- 定律认为
  - 如果一个任务的困难程度可等价于“信息”，那么用户完成任务的速率即可等价于人类信息处理系统的“信息量”
  - 换言之，如果我们知道一个动作的难度和执行该动作的速率，通过计算难度除以速率的商，就可以得到表示人类执行能力的值
  - 即：性能指数IP、任务难易ID和运动时间MT之间存在如下关系
    IP (Index of Performance) = ID (Index of Difficulty) / MT (Movement Time)
  - MacKenzie改写为：
    
    A 是振幅（与目标的距离），W 为目标宽度
  - 更好地符合观察数据
  - 精确模拟支撑 Fitts 定律的香农信息论
    
    常数a和b来自对实验数据的线性回归
- 移向屏幕的某个目标所用的时间与两个因素有关
  - 设备当前位置和目标位置的距离（A）。距离越长，所用时间越长；
  - 目标的大小（W）。目标越大，所用时间越短
- 性能指数IP
  - 也被称作吞吐量TP（Throughput）：TP = ID / MT
- 建议：
  - 大目标、小距离具有优势
    - 对选择任务而言，其移动时间随到目标距离的增加而增加，随目标的大小减小而增加
  - 缩短到达目标的时间有两种措施
    - 缩短当前位置到目标区域的距离
    - 增大目标大小以缩短定位时间
- 适用范围
  - 可用于指导桌面应用开发中的屏幕布局
  - 对基于移动设备的交互系统开发同样具有指导作用

HCI Resource（持续更新）

发表于 2024-05-28 更新于 2025-01-05 分类于推荐， HCI

ABCs

~ CS2023
全球范围内最权威、最系统的计算机科学本科教育指南，也是企业招聘和人才标准的“背后模型”。参考此文件的“Human-Computer Interaction (HCI)”进行查缺补漏。

~ Recommended Reading List for First-year HCI Ph.D. students
香港城市大学（CityU）教授写给博士生的入门清单，不仅有 HCI 相关书籍、文章还有更基础的如何阅读、写作论文的建议。

~ 想加入老师的课题组，有没有相关的阅读清单推荐？
北大教授写给对 HCI 方向感兴趣的学生的阅读列表，包括书籍、文章、研究方法等。

~ What books are required reading for HCI students and practitioners?

101

~ 人机交互与用户体验设计
MOOC 上由南京大学软件学院出品的基础课程。教材笔记

~ Interaction Design
coursera 一门经典课程

📚书籍

HCI

~ 《人机交互:软件工程视角》豆瓣链接

UX

~ 总体

《用户体验要素:以用户为中心的产品设计(原书第2版)》（原著：The Elements of User Experience: User-Centered Design for the Web and Beyond，Second Edition）豆瓣链接笔记

🐮大牛

~ Amy J. Ko, Ph.D.

~ Zhu, Haiyi

~ Xiaojuan Ma
这位老师在教学的第一线，有相关课程材料可作参考。

~ Jesse James Garrett
~ jjg.net
“Ajax 之父”博客，后一个为老版本

~ Bruce Tognazzini

~ Edward Tufte
Edward Tufte 数据可视化

学校相关

~ Degree Programs
Reddit 全球关于 HCI 项目，绝大多数为硕士课程。

~ CSRankings: Computer Science Rankings
根据发 paper 对学校进行排名。不仅有 HCI 方向，也包括 CS 其他研究方向。

Deno 1.0

发表于 2020-06-11 分类于 Deno

说明：本文来自 Deno ,作者：Ryan Dahl, Bert Belder, and Bartek Iwańczuk

文章版权属于原网站/原作者。我依旧只是个搬运工+不称职的翻译。本文不翻译鸣谢部分。

Deno 1.0

动态语言是有用的工具。脚本允许用户快速高效的将复杂的系统连接在一起，并且在不需要关心诸如内存管理或者构建系统等细节中表达想法。最近几年，像 Rust 以及 Go 这样的语言，使机器代码更易生成；这些项目使得计算机基础架构获得了极大的发展。然而，我们认为拥有一个强大的脚本环境来处理各种问题依旧重要。

JavaScript 是最广泛使用的动态语言，运行于各种浏览器中。大量程序员精通 JavaScript，并且已经在优化其执行方面投入了大量精力。通过如 ECMA 这样的组织的建立，JavaScript 得到了谨慎并且持续的进步。我们相信 JavaScript 是动态语言工具的必然选择；无论是在浏览器环境还是作为独立进程。

我们是这块实践的先行者，Node.js 被证明是非常成功的平台。Node.js 足以构建 Web 开发工具、创建独立进程以及无数其他案例。在 2009 设计 Node 时，JavaScript 是截然不同的。出于必要，Node 发明了一些概念，这些概念随后由标准组织采用，并以不同的方式添加到语言中。在《Node 的设计问题》（译者注：安利这个演讲，一定要看哦。）演讲中，提供了更多细节。由于 Node 已经有大量的使用，使得这一系统发展变得困难并且缓慢。

随着 JavaScript 的更新，以及 TypeScript 的加入，构建 Node 项目可能会变得很艰难，涉及到管理构建系统和其他繁重的工具，这使动态语言丧失了乐趣。除此之外，通过 NPM 存储库从根本上集中了链接到外部库的机制，与 web 的理念并相冲突。

我们认为 JavaScript 和相关的软件基础架构已经发生了足够的变化，值得进行简化。我们寻求一种有趣且高效的脚本环境，可用于多种任务。

用于命令行脚本的 web 浏览器

Deno 是一种在 web 浏览器之外用于执行 JavaScript 和 TypeScript 的全新运行时（runtime）。

Deno 试图提供一个独立的工具来快速编写复杂功能的脚本。Deno 是（并且永远是）一个单一的可执行文件。正如 web 浏览器，它知道如何获取外部代码。在 Deno 中，单个文件无需任何其他工具即可定义任意复杂的行为。

import { serve } from "https://deno.land/std@0.50.0/http/server.ts";

for await (const req of serve({ port: 8000 })) {
  req.respond({ body: "Hello World\n" });
}

在这里，只需一行代码，一个完整的 HTTP 服务器作为一个模块即添加完成。不需要额外的配置文件，也不要提前安装，只需要：

1	deno run example.js

与浏览器一致，代码默认运行于安全的沙盒中。代码无法访问硬件、打开网络连接或者是在没有许可的情况下进行任何潜在的恶意操作。浏览器提供了访问摄像头和麦克风的 API，但前提是通过用户的认证。Deno 在终端中提供类似的行为。上面的示例在没有标明 –allow-net 下会失败。

Deno 小心的不要偏离标准的浏览器 JavaScript API。当然，并不是每个浏览器 API 都与 Deno 相关，但无论它们在哪里，Deno 都不会偏离标准。

TypeScript 的默认支持

我们希望 Deno 适用于广泛的问题领域：从简单的一行代码，到复杂的服务端商业逻辑。随着程序变得越来越复杂，有一定的类型检测变得越来越重要。TypeScript 是 JavaScript 语言的扩展，允许用户选择性地提供类型信息。

Deno 在不需要任何外部工具下支持 TypeScript，内置 TypeScript 是其设计理念。deno types 命令是 Deno 提供的所有内容提供类型声明。Deno 的所有标准模块由 TypeScript 编写而成。

Promises 贯穿其中

在 javascript 之前 Node 设计时就引入了 Promises 或者是 async / await 的概念。Node 的 Promises 对应的是 EventEmitter，所有重要的 API 都基于这个，比如 sockets 和 HTTP。抛去对编程时使用 async / await 的好处来看，EventEmitter 存在背压（back-pressure）问题。拿 TCP 套接字（socket）来举例，套接字在接收到传入数据包时将发出“ 数据（data） ”事件。这些“ 数据 ”的回调将以不受限制的方式发出，从而使事件（events）充满整个过程。由于 Node 会持续接受数据事件，基础 TCP 套接字没有适当的背压，远程发送端并不知道服务端已经过载而继续发送数据。为了降低此风险，添加了 pause() 方法。解决了这个问题，但需要额外代码。由于只有在进程非常忙碌的时候，这个问题才会出现，导致 Node 程序充满了数据。结果是系统严重的尾延迟（tail latency）。

在 Deno 中，套接字依旧是异步的，但在接受新数据时，需要用户明确使用 read()。正确的构造接收套接字而不需要额外的暂停语义。这不是 TCP 套接字所独有的。系统的最底级别绑定层从根本上与 Promise 相关联，我们称之为“ ops ”。Deno 中所有的绑定是 Promises 的一种实现或提升。

Rust 有自己类似于 Promise 的抽象，称之为 Futures。通过 “ op ” 抽象，Deno 使基于 future 的 Rust API 巧妙的与 JavaScript 的 Promises 绑定在一起。

Rust API

我们提供的主要组件是 Deno 命令行界面（CLI）。今天（5 月 13日）CLI 正式发布了 1.0 版本。 Deno 并不是一个单一的程序，而是设计为 Rust 的集合，允许在不同层级的集成。

deno_core 是 Deno 的基础，它不依赖 TypeScript 和 Tokio。它简单的提供了 Op 和 Resource 模块。deno_core 提供了绑定 Rust futures 和 JavaScript promises 的组织方式。因此 CLI 完全建立在 deno_core 之上。

rusty_v8 为 Rust 和 V8 的 C++ API 提供了高质量的绑定。这个 API 试着还原所有原先 C++ API。这是零成本的绑定，Rust 暴露出的对象正是 C++ 的操作的对象（举个🌰，之前 Rust V8 的绑定尝试强制使用持久句柄（handles））。这个模块提供了建立于 Github Actions CI 之上的二进制代码，同样也允许用户从头编译 V8 并调整它的构建配置。所有 V8 源代码均在此模块进行分发。最后，rusty_v8 试着成为一个安全的接口。现在还没有 100% 完成，但我们在逐步接近于此。能够以一种安全的方式与像 V8 这样复杂的 VM 交互是非常令人惊奇的，这让我们发现 Deno 本身存在许多困难的bug。

稳定性

我们承诺在 Deno 中维护一个稳定的 API。Deno 有大量的接口和模块，所以对我们来说的”稳定”保持透明是很重要的。我们创建用于与操作系统交互的 JavaScript API 都可以在“ Deno ”命名空间中找到（例如 Deno.open()）。这些已经被仔细检查过了，我们定会对它们做向后兼容的更改。

在使用 –unstable 命令行标志之前，所有还没有稳定的方法将会被隐藏。你可以在这查看没有稳定的接口。在接下来的时间中，其中的 API 也会逐渐稳定下来。

在全局命名空间中，你可以发现各种其他对象（例如 setTimeout() 和 fetch()）。我们努力保持这些接口和浏览器中一致，但是如果发现意外的不兼容性，我们将进行更正。浏览器标准定义了自身的接口，而不是我们。任意错误的更正只会是修复问题，而不是更新接口。如果与浏览器的标准 API 不兼容，可能会在大版本发布之前进行修复。

Deno 还有很多 Rust API，比如 deno_core 和 rusty_v8 模块。这些 API 都还没有达到1.0。我们会继续对它们进行迭代。

局限性

需要了解的是 Deno 并不是 Node 的一个翻版，它是一种全新的实现。Deno 只是开发了两年，而开发 Node 已经超过十年。基于到对 Deno 的兴趣，我们希望它能继续发展和成熟。

对于一些应用来说，Deno 是一种好的选择，对于其他的则不是。这取决于需求。我们想说明 Deno 的局限性来帮助人们选择 Deno 。

兼容性

不幸的是，令人沮丧是许多用户会发现与现有 JavaScript 工具缺乏兼容性。Deno 通常与 Node（npm）包不兼容。初步建立在 https://deno.land/std/node/，但还远远没有完善。尽管 Deno 采取了强硬的方法来简化模块系统，最终 Deno 和 Node 是有着相似的目标和相似的系统。随着时间的推移，我们希望 Deno 可以开箱即用的运行比 Node 更多的系统。

HTTP 服务器性能

我们持续追踪 Deno HTTP 服务器的性能。每秒 25000 次使用 Deno HTTP 服务器请求 hello-world 最多延迟 1.3 毫秒。类似的 Node 程序每秒请求 34000 次，而最大的延迟在 2 ~ 300 毫秒之间。

Deno 的 HTTP 服务器是在原生 TCP 套接字之上的 TypeScript 中实现的。Node 的 HTTP 服务器是由 C 语言编写的，并暴露给 JavaScript 的高级绑定。我们阻止了将本地 HTTP 服务器绑定到 Deno 的冲动，因为我们想优化 TCP 套接字层，以及更普遍的 op 接口。

Deno 是适当的异步服务器，能应付每秒 25000 次的请求，可以满足大多数的需求。（如果不满足，JavaScript 可能并不是最好的选择。）不仅如此，我们预计，由于普遍使用了Promise (之前已经讨论过了)，Deno 在尾延迟方面表现得更好。综上所述，我们的确相信该系统还有更多的性能优势，希望在将来的版本中实现这一目标。

TSC 的瓶颈

Deno 在内部使用微软的 TypeScript 编译器来进行类型检测和生成 JavaScript 。与使用 V8 直接编译 JavaScript 相比，这样做非常缓慢。之前，我们想使用“ V8 快照（V8 Snapshots）”来大幅度提升性能。快照当然有帮助，但它仍然很慢。我们认为可以在现有 TypeScript 编译器的基础上进行一些改进，但是很明显，类型检查最终需要在Rust中实现。这是个艰巨的任务，可能在短时间内不会发生；但它可以让开发人员在经历关键路径中提供数量级上的性能改进。TSC 需要移植到 Rust上。如果你对这个问题感兴趣，请联系我们。

插件 / 挂件

我们有一个使用自定义 ops 来对 Deno 运行时进行初步扩展的插件系统。这个接口还在开发中，已经标记为非稳定版。因此，访问 Deno 提供的系统以外的本地系统是很困难。

Deno 是什么，它能代替 NodeJS 吗？

发表于 2020-05-24 分类于 Deno

说明：本文来自Medium ,作者：Fernando Doglio

文章版权属于原网站/原作者。我依旧只是个搬运工+不称职的翻译。

Deno v1.0.0 计划于 5 月 13 号发布。这里有一些有趣的事实，可能对确定 Deno 起作用。

Deno

确定的是，（显然）太早了来讨论这个事情，但这些事实可能可以确定 Deno。

对于初学者来说，Deno 由创建过 Node.js 的 Ryan Dahl 编写，是不是听起来很熟？这是不是意味着 Deno 是 Node 的替代方案并且可以计划我们对重构进行冲刺了？当然不是！但如果你想了解更多，请继续读下去!

让我们从头开始

在 2018 年，Ryan 讲了他认为做 Node.js 时犯的错误的前十名，并且在演讲的最后，他揭示了 Deno，在那个时候，这只是一个可以称为 Node.js 第二的小项目，提供了更多的安全方案。

点击这里观看视频（请自备梯子）。

两年后，Deno 1.0 官方发布日期确定了：5 月 13 号。为后端开发准备的全新的 JavasSript 运行时，使用 Rust 而不是 C++ 编写而成，基于 Tokio 平台（为 JavaScript 提供必备的异步运行时），依旧运行于 Google V8 引擎之上。

但还有什么新东西呢？

我们讨论的不仅仅是与当前的 Node.js 完全兼容的新的 JavaScript 运行时，取而代之的是，Ryan 为 Deno 添加了在创建 Node.js 时没有考虑到的特性。

安全集成

一般来说，Node.js 允许你具有访问所有内容，意思是你可以在文件系统中进行读写操作，向外发布请求，访问环境变量等等。尽管对于开发者来说，获取这些权限是有益的，但代码可能不小心留下安全隐患。

取而代之的是，Deno 使用命令行参数用于是否开启不同的安全措施。比如你的代码需要访问 /etc 目录，则需要：

1	deno --allow-read=/etc myscript.ts

这允许代码读取该目录，除此之外会报安全错误。这与其他平台的安全措施类似。如果你是安卓用户，许多应用在使用时会向你询问是否能获取系统权限（比如联系人，通行记录，文件夹等），同样的原理也应用于此。通过使用这些选项来执行你的代码，提供了代码所需的权限。

更完整的标准库

自从第一个 Node 版本开始，JavaScript 改进了其标准库，但与其他语言相比，它还有很长的路要走。Deno 试图为开发者提供完善标准库用于完成基础任务，而使用外部库（也就是 NPM）用于更复杂的任务。

实质上，开箱即用的是，Deno 为终端文字增加了颜色，使用外部数据结构（比如 binary, csv, yaml 等），生成 UUIDs 甚至是编写 websockets。还有些其他的，更多可使用的基础模块，比如访问文件系统，日期助手（date helper）方法，http 关联方法以及其他库。

TypeScript 集成

你没看错，如果你是 TypeScript 粉丝，那么 Deno 帮你解决了，而不需要额外工具，默认在内部完成编译为 JavaScript 。

尽管在默认情况下，Deno 会解决许多问题，你可以使用 tsconfig.json 进行设定：

1	deno run -c tsconfig.json [your-script.ts]

默认情况下使用严格模式，因此，任何不良的编码将立即收到警告。

不再有 NPM 或 node_modules 目录

这是一个问题，因为每个包和其父类的都有依赖。这是不是显得太臃肿了？这是分发依赖关系的错误方式吗？这无疑是Node 最具争议的方面之一，而 Deno 确定彻底摆脱这种方式？

所以 Deno 是如何处理依赖的？自此，允许你可从任意地方引用。换句话说，你可以这样做：

1	import * as log from "https://deno.land/std/log/mod.ts";

自身不再需要的集中式存储库，但需要小心进行实践，无法控制第三方导入的模块，导致处于暴露状态。

事实上，我们也没有 package.json，使用包含模块列表以及其依赖的 URL 的 deps.ts 文件用于模块管理。但版本管理呢？我知道你会提问的。你可以在 URL 上标明版本号，这样并不优雅，但的确可行。

deps.ts 文件示例如下：

1 2	export { assert } from "https://deno.land/std@v0.39.0/testing/asserts.ts"; export { green, bold } from "https://deno.land/std@v0.39.0/fmt/colors.ts";

只需要简单的更改 URL ，你就可以重新导出模块并改变其版本。

随便说一下，导入的代码会被缓存，第一次运行代码时，需要增加 –reload 标签进行重新构建。

还有什么呢？

Deno 还包括了另一些模块，比如开箱即用的工具，例如测试运行器（test runner）、调试、文件监听等等。但话又说过来，其中一些只是语言提供的 APIs，你需要编写自己的工具进行使用。

比如文件监听 API，由 Deno.watchFs 提供，你可以使用类似于 nodemon 进行构建。这里仅仅使用 23 行代码就能解决类似的问题：

Deno.watchFs

这段代码是 Caesar2011 发布的其中一段，你可以在这里看到完整代码。

所以，Deno 会很快代替 Node.js 吗？

实话实说，并不会，这里有些标题党了。我们使用 Node.js 可以追溯到 0.10 版本，并且已经用在实际产品中了！告诉你真相可能有些恐怖，但我们这么做是因为当时没有其他可选方案。无论是 PHP、Python 还是 Ruby (更不用说 Java 或 . net )，都无法与后端同时使用 JavaScript 和异步 I/O 模型相提并论。这些年来，Node（和 JavaScript ）已经成为工业的必备。这是不是很完美？当然不是！与生活类似，当涉及到编程语言时，没有是完美的。

Deno 并没有区别，只是因为现在，它是花了两年时间在一个想法上的成果。其还没有在实际产品中进行编码和测试。尚未对 Deno 进行检测，也没有放入怪异和意外的用例中，以了解是如何处理边界情况的。直到这些完成，Deno 只是尝鲜者把玩的玩具。可能过了一年，我们开始听到公司是使用 Deno 的经历，他们是如何解决发现的问题，其背后的社区将对其进行怎样的调整，使其能够发挥作用。Deno 是否能代替 Node 呢？谁知道呢？只有时间才能给出答案。

所以，你是怎样认为的呢？

HTTP/3 是什么？

发表于 2019-10-17 分类于 HTTP

说明：本文来自Medium，作者：Grigor Khachatryan

文章版权属于原网站/原作者。我依旧只是个搬运工+不称职的翻译。

这段时间在研究 HTTP/2 的相关知识，没想到 HTTP/3 也在酝酿中，于是乎找到一篇介绍 HTTP/3 的文章，学习并在此进行记录。

HTTP/3

HTTP-over-QUIC 这个实验性的协议会被命名为 HTTP/3，IETF 的一位成员披露了这条消息。

从 HTTP/1.1（发布于1999年）到 HTTP/2 已经过了许多年，而在 2019 年将大大推动 HTTP/3 的发展。

HTTP/3 由 Google 的 QUIC 协议发展而来。它开始于 Mark Nottingham 的建议。

所以啥是 QUIC ？

QUIC（Quick UDP Internet Connections / 快速 UDP 网络连接）是一种新的传输模式，与 TCP 相比减少了延迟。大体来说，QUIC 类似于 UDP 上实现 TCP + TLS + HTTP/2。由于 TCP 在操作系统内核和中间件之上实现的，导致对于 TCP 进行重大更新几乎是不可能的。然而，QUIC 基于 UDP 之上实现，所以就没有这些限制。

QUIC 于现有 TCP + TLS + HTTP/2 上的主要功能包括:

大大减少建立时间
改善拥塞控制（congestion control）
无队头阻塞（Head-of-line blocking）的多路复用
前向纠错（Forward error correction）
连接迁移（Connection migration）

Google说，从 Chrome 到 Google 服务器的所有请求中，大约有一半是通过 QUIC 提供的，并且他们还在继续增加 QUIC 的占比，最终使其成为Google 客户端——Chrome 以及移动 apps 到 Google 服务器之间的默认传输方式。Google 计划正式向 IETF 提出 QUIC，使其成为一个网络标准，但首先还需要做一些工作，比如更新线路标准并将其实现从 SPDY-over-QUIC 更新为 HTTP2-over-QUIC（当前的 HTTP-over-QUIC 协议草案使用最新发布的 TLS 1.3 协议）。在接下来的几个月内，Google 打算减少握手开销以便用于更好的服务器扩展，提升前向纠错和改善拥塞避免，同时增加对多路径链接（multipath connections）的支持。

HTTPS over TCP + TLS vs HTTPS over QUIC

reddit 的一位用户对 TCP 和 QUIC 的区分有个很好的解释：

开发 TCP 的时候需要通过比现在更大丢包率的网络进行数据包传递，并且当时的计算机系统需要更长的时间来响应 TCP 消息。例如，即便在 5 秒内无法完成 TCP 握手，主机的链接超时仍为 20 秒，即使在你不太可能获得响应的情况下。长时间的延迟是网络应用存在停滞时间过长的原因。我们无法更改这个 70 年代产生的协议，尽管在看到可靠性以及速度有很大提升的情况下。

在最大限度的与当前 TCP 兼容，而不是最终减少不会改变包的默认值的情况下，协议开发者开始使用 UDP 并在此基础上实现自己 TCP。向 IPv6 的转变是修改 TCP 诸多问题的理想时间，例如大部分的超时，窗口尺寸（window size）以及 TCP 的慢启动。有些值可以在你的操作系统中调整，但是最烦人的超时是不能调整的。如果你终止已经有 5 秒超时的一条 TCP 套接字（TCP socket），操作系统依旧需要为此保持打开状态，直到 20 秒以后结束，这会消耗系统资源。

参考资料：

HTTP/3详解
What is QUIC?
HTTP/3 - HTTP over QUIC is the next generation by Daniel Stenberg （墙裂推荐）
上一条视频的幻灯片

介绍 CSSOM

发表于 2019-09-27 分类于 CSS

说明：本文来自Varvy，作者：Patrick Sexton

文章版权属于原网站/原作者。我依旧只是个搬运工+不称职的翻译。

前不久，在微博上看到貘吃馍香在吐槽

貘大的吐槽

于是去搜索和查阅了相关资料，也做了一些复习，加上 W3C Plus 相关文章收费，因此在此做个记录。

CSSOM 是什么？

CSSOM 代表着 CSS Object Model
CSSOM 基本上是页面中 CSS 的“映射”
CSSOM 与 CSS 的关系类似于 DOM 之于 HTML
CSSOM 与 DOM 相结合使浏览器渲染页面

CSSOM

CSSOM 是页面渲染不可缺少的部分。

CSSOM 是关键路径渲染（critical rendering path）的基础和关键，理解 CSSOM 做了什么是对页面优化（页面加载更快）的重要部分。

CSSOM 做了什么？

CSSOM 将样式表中的规则映射到页面上需要样式化的内容。

为此，CSSOM 做了许多复杂的操作，但是 CSSOM 的最终是将样式映射到这些样式需要去的地方。

（更精确的说，CSSOM 定义了令牌（token）并将其隐藏的链接到树结构的节点中。页面中节点及其样式的所有映射就是 CSS Object Mode）。

浏览器使用 CSSOM 渲染页面

为了渲染页面，浏览器必须执行一些操作。此时，我们将其简化一下并讨论四个主要步骤，这些步骤将说明 CSSOM 的重要性。

浏览器执行 HTML 并构建出 DOM（Document Object Model）。
浏览器执行 CSS 并构建出 CSSOM（CSS Object Model）。
浏览器组合 DOM 和 CSSOM 用于创建渲染树。
浏览器展示 web 页面。

如上所示，CSSOM 确实是展示 web 页面的重要部分。

好消息

为了优化 web 页面，其实你不需要了解 CSSOM 到底是如何工作的。

你只需要知道 CSSOM 的几个关键点就可以对页面进行非常实际的优化。

知道CSSOM 阻止任何东西的渲染。
知道当载入新页面时，CSSOM 需要重新构建。
知道渲染页面时，javascript 和 CSS 之间的关系。

让我们快速的了解这几点，然后为了优化页面我们能做什么。

1. CSSOM 阻止任何东西的渲染

所有 CSS 是阻塞式渲染（意味着直到 CSS 处理完成，将不会展示任何东西）。

这样做的原因是，如果在 CSS 执行之前就展现 web 页面，那你看到的 web 页面是没有样式的，然后过了一会，页面有了样式。如果这样做的话，体验是相当糟糕的。

CSS 阻塞式渲染

由于 CSSOM 用来帮助创建渲染树，如果在页面中的 CSS 不能高效的完成，那么将会产生严重的问题。

主要问题是加载 web 页面时的白屏。

2. 当载入新页面时，CSSOM 需要重新构建

对你来说，这个可能不是相当明显，但确实是非常重要的一点。

意思是尽管你的 CSS 被缓存了，并不意味着 CSSOM 是针对每个页面构建的。

用户访问其他页面时，CSSOM 必须重新进行构建（尽管浏览器可能已经缓存了所需要的所有 CSS 文件）。

换句话说，如果你的 CSS 是劣质和庞大并且编写相当糟糕的，那么在渲染页面时会带来副作用。

3. 渲染页面时，javascript 和 CSS 之间的关系

在 web 页面中使用 javascript 可能（或者说经常）会阻塞 CSSOM 的构建。

简而言之—页面展现需要 CSSOM。如果 CSSOM 没有完成，页面将不会展现任何内容。如果阻塞了 CSSOM 的构建，那么 CSSOM 将会花费更长的时间，意思是页面展现将会花费更长的时间。如果 javascript 阻塞了 CSSOM 的构建，那么用户将会花费比原本更多时间停留在空白页面。

CSSOM 的优化方法

这里有些最佳实践用于加快 CSSOM 的构建（因此页面能加载的更快）。

函数式系列(2)：闭包和柯里化

发表于 2019-06-09 分类于 Functional Programming

说明：本文来自scotch，作者：Austin Roy

文章版权属于原网站/原作者。我依旧只是个搬运工+不称职的翻译。

什么是闭包？

如果经常写 JavaScript 代码，大概率你会遇到一个既有用又经常引起困惑的概念—闭包。但什么是闭包?

闭包是函数和声明该函数的词法环境（lexical environment）的组合。

但这到底是什么意思呢？词法环境由函数创建时的所有局部变量组成。通过闭包，可以引用函数下的所有局部变量。这实际上是通过在一个函数中定义另一个函数来实现的，在函数中的这一函数称为闭包。一旦父函数被调用，一个包含所有局部变量的全新拷贝的执行上下文将创建。在全部变量中引用局部变量可以通过与全局变量进行链接，或者是返回父函数中的闭包。

一个简单的示例将采用与此类似的:

function closuredFunc (){
    function closure(){
    // some logic
    }
}

同样也可以通过以下方式让同一闭包返回多个方法：

function closure(){
    function first() { console.log('I was declared first')}
    function second() { console.log('I was declared second')}
    function third() { console.log('I was declared third')}
    return [first, second, third]
}

为了引用这些方法，我们将闭包分配给一个全局变量，然后将其指向一组公开的方法。如下所示，每个方法分配了唯一的变量名称，以将它们带入全局范围。现在，可以调用它们了。

let f = closure()

let one = f[0]
let two = f[1]
let three = f[2]

one() // logs I was declared first
two() // logs I was declared second
three() // logs I was declared third

为什么使用闭包？

你可能想知道为什么要花这么多时间来写闭包。然而，闭包具有许多用途与优点。

先前介绍了 ES6 中的 Class，闭包提供了类似于面向对象编程方法用于创建类似于类的隐私方法，允许我们遍历私有方法。这个也可称为 模块模式（module pattern），其允许我们更容易的维护代码，减少命名空间污染（namespace pollution）的同时增加可重用性。

让我们看一个这样做的栗子。

var makeCounter = function() {
  var privateCounter = 0;
  function changeBy(val) {
    privateCounter += val;
  }
  return {
    increment: function() {
      changeBy(1);
    },
    decrement: function() {
      changeBy(-1);
    },
    value: function() {
      return privateCounter;
    }
  }
};

var counter1 = makeCounter();
var counter2 = makeCounter();

counter1.value(); // returns 0
counter1.increment(); // adds 1
counter1.increment(); // adds 1
counter1.value(); // returns 2
counter1.decrement(); //subtracts 1
counter1.value(); // returns 1
counter2.value(); // returns 0

在上面的例子中，我们定义了一个公共函数同时也可以访问一些私有变量如 privateCounter 和其中的函数的方法 makeCounter。创建 makeCounter 模仿了类的行为，其具有内置的功能和变量。这可以在创建两个不同的计数器 counter1 和counter2 时看到。每个计数器（counter）是独立于其他计数器，指向不同状态下的变量。

闭包还允许我们使用函数来创建其他函数，这些函数会为其参数添加特定的值。在这种情况下，允许这种行为的父函数被称为函数工厂 (function factory)，因为它实际上会创建其他函数。

使用函数工厂，我们实现的这样行为称为柯里化（Currying）。我们将在下个部分详细描述。

柯里化

柯里化是一种函数模式用于立即执行并且返回其他函数。这使得 JavaScript 函数返回其他函数的表达式成为可能。

柯里化函数通过定义并立即返回其内部函数来链接闭包来构造。

这里有柯里化的例子。

let greeting = function (a) {
    return function (b) {
        return a + ' ' + b
    }
}

let hello = greeting('Hello')
let morning = greeting('Good morning')

hello('Austin') // returns Hello Austin
hello('Roy') // returns Hello Roy
morning('Austin') // returns Good morning Austin
morning('Roy') //returns Good Morning Roy

从 greeting 创建了两个函数（hello and morning），每个返回函数处理提供的输入用来生成问候语。它们还接受了一个参数用于要打招呼的人的名字。

在上面的例子中，greeting 也作为函数工厂使用，hello 和 morning 由此生成。

在第一次调用之后，还可以继续调用内部函数，如下所示：

1 2	greeting('Hello There')('General Kenobi') //returns Hello There General Kenobi

柯里化认为是函数式编程的一部分，同时柯里化函数在使用 ES6 的箭头函数语法和新版本的 JavaScript 时，能更容易的书写清晰，优雅的代码。

let greeting = (a) => (b) => a + ' ' + b 

greeting('Hello There')('General Kenobi') 
//returns Hello There General Kenobi

总结

自从在 ES6 有了 Class，闭包可能不会经常使用，在编写清晰的可重用代码，闭包依旧占有一席之地。在本质上与面向对象编程中的私有方法具有相似用途的函数式编程中，闭包和柯里化是其重要的概念。

参考资料

函数式系列(1)：Map, ForEach 及 Filter, Reduce

发表于 2019-05-03 分类于 Functional Programming

Map, ForEach 及 Filter, Reduce

概念

map, foreach, 及 filter, reduce 为典型的函数式编程实践，均为高阶函数（Higher-Order Functions）。

高阶函数指的是一个函数能作为值传递到另一个函数中，或者，一个函数可以作为另一个函数的输出。

区别

map filter 和 reduce 均有返回值，而 forEach 是没有返回值的
forEach 能终止循化，而 map, filter 和 reduce 是无法终止的

map filter 和 reduce 的区别如图所示。
map, filter 和 reduce

map filter 和 reduce

map

map 是将数组的每一项通过同样的操作进行变换，得到一个新的数组，且新数组与原数组的长度是一致的。

var array1 = [1, 4, 9, 16];

const map1 = array1.map(x => x * 2);

console.log(map1); // 输出：[2, 8, 18, 32]

console.log(array1); // 输出： [1, 4, 9, 16]

filter

filter 是保留数组中符合条件的数据，得到一个新的数组，且新数组的长度不大于原数组的长度。

var array1 = [1, 4, 9, 16];

const filter1 = array1.filter(x => x > 0);

console.log(filter1); // 输出：[1, 4, 9, 16]

console.log(array1); // 输出： [1, 4, 9, 16]

reduce

reduce 是合并数组的每一项数据，最终返回一个新的数据。

var array1 = [1, 2, 3, 4];

const reducer = (accumulator, currentValue) => accumulator + currentValue;

console.log(array1.reduce(reducer, 5)); // 输出：10

console.log(array1); // 输出： [1, 2, 3, 4]

注意：三个例子中，原来的数组是没有发生任何改变的。

核心：转换率（conversion rate）

5 Plans

1. 初始人机交互和用户体验

1.1 从 HCI 到 UX（1.2）

1.2 为什么要学习 HCI（1.2）

1.3 为什么软件会不好用（2.2）

2. 交互设计的原则和目标

2.1 “以用户为中心的系统设计”由来（9.2）

2.2 可用性 （3.2）

2.3 可用性工程（Usability Engineering）(3.3)

2.4 设计的基本原则 （3.4）

3. 如何定义交互系统的需求和用户

3.1 交互需求的差异（5.2，5.3）

3.2 用户的差异（5.4）

3.3 理解用户 （2.4）

3.4 格式塔（Gestalt）心理学（2.4.2）

3.5 如何构建人物角色（5.5）

3.6 基于人物角色和场景交互需求定义（5.6.3）

4 如何开展交互设计

4.1 交互设计的活动和步骤（6.2）

4.2 如何简化交互设计（6.3）

4.3 设计体贴的软件（6.5）

4.4 有用的交互设计模式（6.6）

5. 如何对交互性能进行评估

5.1 为什么要进行评估（10.2）

5.2 评估实验的规划（10.5）

5.3 评估范型及选用（10.3）

5.4 评估的对象（5.6.5）

5.5 通过“看”来评估（11.2）

5.6 通过“问”来评估（12.2，12.3， 12.4）

5.7 启发式评估（12.5）

5.8 通过“用”来评估（13.2）

6 交互设计模式与理论

6.1 如何对用户任务进行分解（5.6.4）

6.2 如何预测任务的完成时间（8.2）

6.3 如何预测指定任务的执行效率（8.2.3）

ABCs

101

📚书籍

HCI

UX

🐮大牛

学校相关

大牛

网站 & 博客

说明： 本文来自 Deno ,作者：Ryan Dahl, Bert Belder, and Bartek Iwańczuk

文章版权属于原网站/原作者。我依旧只是个搬运工+不称职的翻译。本文不翻译鸣谢部分。

用于命令行脚本的 web 浏览器

TypeScript 的默认支持

Promises 贯穿其中

Rust API

稳定性

局限性

兼容性

HTTP 服务器性能

TSC 的瓶颈

插件 / 挂件

说明： 本文来自Medium ,作者：Fernando Doglio

文章版权属于原网站/原作者。我依旧只是个搬运工+不称职的翻译。

让我们从头开始

但还有什么新东西呢？

安全集成

更完整的标准库

TypeScript 集成

不再有 NPM 或 node_modules 目录

还有什么呢？

所以，Deno 会很快代替 Node.js 吗？

说明： 本文来自Medium，作者：Grigor Khachatryan

文章版权属于原网站/原作者。我依旧只是个搬运工+不称职的翻译。

说明： 本文来自Varvy，作者：Patrick Sexton

文章版权属于原网站/原作者。我依旧只是个搬运工+不称职的翻译。

CSSOM 是什么？

CSSOM 做了什么？

浏览器使用 CSSOM 渲染页面

好消息

1. CSSOM 阻止任何东西的渲染

2. 当载入新页面时，CSSOM 需要重新构建

3. 渲染页面时，javascript 和 CSS 之间的关系

CSSOM 的优化方法

说明： 本文来自scotch，作者：Austin Roy

2.2 可用性（3.2）

2.4 设计的基本原则（3.4）

3.3 理解用户（2.4）

说明：本文来自 Deno ,作者：Ryan Dahl, Bert Belder, and Bartek Iwańczuk

说明：本文来自Medium ,作者：Fernando Doglio

说明：本文来自Medium，作者：Grigor Khachatryan

说明：本文来自Varvy，作者：Patrick Sexton

说明：本文来自scotch，作者：Austin Roy