出自UXGuide.net

通知

Notifications

目录 1 它用在这里合适吗？ 2 设计理念 2.1 必须维持用户操作流程的顺畅 2.2 通知必须是可以忽略的 2.3 需要时使用逐步提升的方式 3 使用模式 4 设计规范 4.1 常规 4.2 通知的内容 4.3 通知的时机 4.4 通知时长 4.5 通知频率 4.6 通知升级 4.7 交互 4.8 图标 4.9 通知队列 4.10 系统集成 5 文本 5.1 标题文本 5.2 正文文本 6 文档编写

“通知”用于提醒用户那些与用户当前活动无关的事件，它会简单地显示一个指向通知区域图标的气球状提示。通知可能由用户操作或重大系统事件引发，也可能提供来自于 Microsoft® Windows® 或某个应用程序的可能有用的信息。

通知中的信息是有用且相关的，但绝不是关键的。因此，通知并不需要用户立即操作，且用户可以完全将其忽略。

典型的通知

在 Windows Vista® 中，通知显示的时长固定为 9 秒。如果用户处于非活动状态、应用程序正以全屏方式运行、或屏幕保护程序正在运行等等的话，通知不会立即显示。Windows 会在这段时间内自动将通知排入队列，待用户恢复正常活动时再依次显示。因此，你无须对这些特殊情形进行任何处理。

致开发人员：你可以使用 SHQueryUserNotificationState API 来确定用户是否处于活动状态。

注：与通知区域、任务栏和气球状提示相关的设计规范请参考各自相应的章节。

它用在这里合适吗？

考虑下列问题以进行判断：

• 该信息是否立即直接由用户在你应用程序中的操作而引起的？如果是，则应使用对话框、消息框、气球状提示或就地显示（in-place）用户界面直接在你的应用程序中显示该同步信息。通知仅用于显示异步信息。

在这个示例中，Windows 防火墙例外对话框以因用户交互而直接显示的。通知在这里并不合适。

• 该信息是否仅当用户正在使用你的应用程序时才有实际意义？如果是，则应在你应用程序的状态栏或其他状态区域中显示该信息。

在这个示例中，Outlook 将其连接与同步状态显示在状态栏中。

• 该信息是否变化迅速、具有持续性并且实时更新？例如处理进度、股票价格及体育比赛得分等。如果是，则不要使用通知，因为它不适用于快速变化的信息。
• 信息是否有用或具有实际意义？用户是否经常会改变他们的行为或避免因接受该信息所引起的不便？如果没有用，则不要显示该信息，或将其输出至状态窗口或日志文件中。
• 该信息是否非常关键？是否需要立即采取行动？如果是，则使用那些需要注意且无法轻易忽略的界面来显示信息，例如模式对话框或消息框。如果程序不处于活动状态，你可以通过闪烁程序的任务栏按钮三次并使其一直保持高亮直到程序被激活的方式来引起用户对关键信息的注意。
• 主要目标用户是否是 IT 专业人员？如果是，则应使用备用的反馈机制，如日志文件条目或电子邮件信息。IT 专业人员非常愿意将日志文件用于非关键信息。而且，服务器往往是通过远程管理的，通常运行时没有任何用户登录，此时通知会变得无效。

设计理念

能够有效提高用户体验的通知具有下列特点：

• 异步的。该事件并不是因用户当前在 Microsoft® Windows® 或你的应用程序中的操作而立即直接引发的。
• 有用的。用户确有可能在看到通知之后采取行动或改变他们的行为。
• 有实际意义。通知显示的信息是有用的，是用户所关心的且并非早已知晓的。
• 非关键性的。通知不是模态的，不需要用户的操作，因此用户可以完全将其忽略。
• 可操作的。对于那些建议执行某项操作的通知，该操作可通过单击通知来启动。不过，这样的操作总是可以推迟的。
• 恰当呈现。通知的呈现方式（时长、频率、文本、图标、交互方式等）与其周围环境相符。
• 不烦人！温和地提醒用户与骚扰用户只有一线之隔。

可惜，有太多令人厌烦的、不恰当的、没有用的、缺乏实际意义的通知存在。比如下面这些荣登 Windows XP 耻辱榜的通知：

在这些示例中，Windows XP 看起来是希望协助用户完成初始设置，然而，这些通知在用户已经知道该怎么做之后还频频冒出来，只不过是些会主动弹出的功能广告罢了。

必须维持用户操作流程的顺畅

理想情况下，沉浸于其工作中的用户应当根本看不到你的通知。或者说，他们仅当操作流程已经中断时才会看到你的通知。

在《Flow: The Psychology of Optimal Experience》一书中，Mihaly Csikszentmihalyi 指出，当用户全神贯注入某项活动中，从而忘记了时间并感到极大的满足时，即进入了流畅心理状态（flow state）。

高效的通知会呈现能够很容易被忽略的有用、相关的信息，有助于维持用户操作流程的顺畅。这类通知以低调、并不太显眼的方式呈现，且不需要操作。

不要假设无模式的通知就不会打扰用户。虽然用户并非必须关注通知，但通知显然需要用户的关注。你可能会以下列方式干扰用户的操作流程：

• 显示用户并不关心的通知。
• 过于频繁地显示某通知。
• 当一个通知已经足够时却使用多个通知。
• 在显示通知时播放声音。

通知必须是可以忽略的

通知不需要用户立即采取行动，用户可以将其完全忽略。

开发和设计人员经常想让“他们的”通知以一种用户无法忽略的方式呈现。这种目标完全破坏了通知主要的优点，因为它打断了用户的操作流程。如果用户因你的通知而分心，觉得是被迫阅读的话，你通知的设计就是失败的。

如果你担心用户会忽略你的通知，考虑以下两点：

• 如果你正确地使用了通知，且并不需要用户立即采取行动的话，让用户选择忽略是符合设计的。不必更改。
• 如果该事件需要用户立即采取行动，则应当使用用户无法忽略的其他用户界面。关于其他方案，参见这样的用户界面是否合适？

需要时使用逐步提升的方式

如果某通知用于一开始用户可以安全地予以忽略，但最终必须进行强调的事件的话，就需要在情况变得紧急的时候使用另外的 UI。该技术被称为“逐步提升（progressive escalation）”。

例如，Windows 电源管理系统起初只是简单地通过改变通知区域图标来指示电池电量低。

在这些示例中，Windows 电源管理使用通知区域图标来通知用户电池电量越来越低。

当电池电量继续减时，Windows 使用通知来警告用户电池电量不足。

在这个示例中，Windows 电源管理使用通过来告诉用户其电池电量不足。

此通知出现时，用户仍然还有一些选择。用户可以接上外接电源、更改电源选项、迅速完成工作并关闭计算机、或者忽略通知继续工作。当电池电量即将耗尽之时，通知的文本和图标则显得更加紧急。然而，一旦电池电量低到用户必须立即采取操作时，Windows 电源管理就会用模式消息框来通知用户。

在这个示例中，Windows 电源管理使用一个模式消息框来通知用户电池电量严重不足。

最重要的三点：

1. 仅当你确实需要通知的时候再使用它。当你显示通知时，你便有可能打断用户甚至造成侵扰。确保这种打断是经过权衡的。
2. 通知应当用于非关键事件或者不需要用户立即采取行动的情况。对于关键事件或者需要用户立即采取行动的情况，应当使用其他的 UI（如模式对话框）。
3. 如果你使用通知，应当使其成为好的用户体验。不要试图强迫用户看到你的通知。如果沉浸于工作中的用户没有看到你的通知，你这就是好的设计。

使用模式

通知具有下列使用模式：

操作成功 当由用户触发的异步操作成功完成时通知用户。	正确： 在这个示例中，Windows Update 当用户的计算机成功更新之后通知用户。 错误： 在这个示例中，Microsoft Outlook® 当数据文件检查完成时通知用户。用户现在应该做什么？为什么成功完成之后要警告用户？ 显示时机：当异步任务完成时。仅当用户可能会等待操作完成，或者刚刚失败之后才通知用户操作成功。 显示方式：使用实时选项，以使这类通知在用户运行全屏应用程序或当前并未使用计算机时不会排入队列。 显示频率：一次。 侵扰程度：如果由于之前的失败而用户不确定是否成功，或者成功是发生在严重的或非常偶然的失败之后，用户需要额外的反馈时，侵扰程度较低。反之则高。 其他方案：当操作完成时，通过在通知区域中显示图标（或者更换已有的图标）来提供“按需”反馈。当操作完成时再移除图标（或换回先前的图标）。
操作失败 当由用户触发的异步操作失败后通知用户。	正确： 在这个示例中，Windows 激活程序通知用户激活失败。 错误： 在这个示例中，Microsoft Outlook 通知用户一项他们可能并不关心的失败。 显示时机：当异步任务失败时。 显示频率：一次。 侵扰程度：如果内容实用仅相关的话则低，如果问题能够很快自行解决或者用户根本不关心的话则高。 其他方案：如果用户必须立即注意该失败状况的话，则应使用模式对话框。
非关键系统事件 通知用户发生可以被安全忽略、至少是临时忽略的重要系统事件或状态。	在这个示例中，Windows 警告用户电池电量低，但用户仍然有足够的时间来采取行动。 显示时机：当事件发生且用户处于活动状态时，或出现持续存在的情形时。如果是由某问题引起的话，那么一旦该问题解决，当前显示的通知就应当立即移除。和操作通知一样，仅当用户可能在等待该事件或刚刚经历失败之后才向用户通知那些成功的系统事件。 显示频率：当事件首次发生时显示一次。如果是由用户能够解决的问题引起的话，那么如果用户必须在一小时内解决，则每 10 分钟显示一次；如果用户必须在一天内解决，则每小时显示一次。 侵扰程度：低，只要通知显示得不太频繁。 其他方案：如果用户最后必须解决某问题，则应使用逐步升级的方式，直到必须强制进行时显示一个模式对话框。
可选用户任务 通知用户他们应当完成的异步任务。如何可选的还是必须的，该任务都能够完全地推迟。	在这个示例中，Windows Update 通知用户有新的安全更新。 显示时机：当决定某任务需要完成且用户当前处于活动状态时。 显示频率：对于安全相关的任务来说，每小时一次。其他所有情况，每天一次，一共最多三次。 侵扰程度：低，只要用户觉得任务很重要且通知显示不太频繁的话。 其他方案：如果用户最后必须完成该任务的话，则应使用逐步升级的方式，直到任务不得不完成时显示一个模式对话框。
供参考（FYI） 通知用户一些可能有用、相关的信息。你可以将一些可选的、用户能够选择性参与（opt-in）的不太有关的信息通知给用户。	正确： 在这个示例中，收到新的电子邮件消息时将通知用户。 正确： 在这个示例中，联系人上线且用户选择接受此可选信息时将会通知用户。 错误： 在这个示例中，该信息仅当用户已经装有高速 USB 端口时才有用。否则，即便有了该提示，用户也做不了什么。 显示时机：当触发事件发生时。 显示方式：使用实时选项，以使这类通知在用户运行全屏应用程序或当前并未使用计算机时不会排入队列。 显示频率：一次。 侵扰程度：中等到高，取决于用户觉得其实用和相关的程度。如果用户感兴趣的可能性很低的话，则不推荐使用。 其他方案：不要通知用户。
功能广告 通知用户新安装的、不常用的系统或应用程序功能。仅当关键的、难于发现的功能与用户当前活动相关，且没有其他方法能够让用户注意到该功能时才可使用功能广告。	不要将通知用作功能广告！相反，应当使用其他的方式使该功能易于发现，比如： Design the feature to be easier to discover in contexts where it is needed. Don't do anything special and let users discover the feature on their own. 错误： 不要将通知用作功能广告。

设计规范

常规

• 根据其用途选择通知模式。关于每种使用模式的描述，参见上表。
• Don't use any notifications during the initial Windows experience. To improve its first experience, Windows 7 suppresses all notifications displayed during the first few hours of usage. Design your program assuming users won't see any such notifications.

通知的内容

• 除下列情况外，不要通知成功的操作：
  • 安全性。用户会认为有关安全性的操作是最重要的，因此应当将成功的安全性相关操作通知给用户。
  • 刚刚经历失败。如果用户之前刚刚经历失败的话，他不会认为成功是理所当然的，因此在刚刚经历过操作失败之后应当通知用户操作成功。
  • 预防不便。如果报告操作成功能够避免让用户感到不便的话，则应当这么做。因此，当操作是以非预期的方式成功完成的话，应当通知用户，比如操作非常耗时或者比预期的要提前或推迟完成。
• 其他情况下，要么不提供成功反馈，要么“按需”反馈。假设用户认为操作成功是理所当然的。你可以通过在通知区域中显示图标（或者更换已有的图标）来提供按需反馈，当操作完成时再移除图标（或换回先前的图标）。
• 对于 FYI 模式，如果用户能够继续正常工作，或者不太会因为该通知而做什么特别的事情的话，则不要给出通知。

错误：

在这个示例中，该信息仅当用户已经装有此端口时才有用。否则，即便有了该提示，用户也做不了什么。

• • 例外：你可以通知用户那些相关程度无法确定的信息，如果它是可选的且用户能够选择性参与（opt-in）了的话。

正确：

在这个示例中，联系人上线且用户选择接受此可选信息时将会通知用户。

• 对于非关键系统事件或 FYI 模式，应当为每个事件使用单独、完整的通知。不要多次分开显示。

错误：

这些示例只给出了当用户接上某种 USB 键盘时，Windows XP 会显示的八个通知中的四个，每个通知只增加了一点点信息。

正确：

在这个示例中，接上 USB 键盘只会产生一个单独、完整的通知。

通知的时机

• 根据其设计模式来显示通知：

  模式	通知时机
  操作成功	当异步任务完成时。仅当用户可能会等待操作完成，或者刚刚失败之后才通知用户操作成功。
  操作失败	当异步任务失败时。
  非关键系统事件	当事件发生且用户处于活动状态时，或出现持续存在的情形时。如果是由某问题引起的话，那么一旦该问题解决，当前显示的通知就应当立即移除。
  可选用户任务	当决定某任务需要完成且用户当前处于活动状态时。
  供参考（FYI）	当触发事件发生时。
  功能广告	当用户首次进行与该功能相关的操作时。

• 对于操作错误模式，如果该问题有可能在很短的时间内自行修复的话，则应当将失败通知适当地延迟一段时间显示。如果问题自行修复了，则什么也不用报告。仅当经过了足够的时间之后问题仍然存在才进行通知。如果报告得过早，很有可能用户不会注意到报告的问题，却会注意到多余的通知。
  错误：
  
  紧接着：
  
  在这个示例中，没有无线连接的通知为时过早，因为紧接着就出现了连接状况良好的通知。
• 对于操作成功及 FYI 模式，应当使用实时选项，以使这类通知在用户运行全屏应用程序或当前并未使用计算机时不会排入队列。
• 对于非关键系统事件模式，不要将大量事件都关联到那些众所周知的事件上，如用户登录，以避免造成通知犯滥的可能。相反，应当将其关联到事件发生的一段时间之后。例如，你可以在用户登录五分钟之后提醒用户注册产品。

通知时长

在 Windows Vista 中，通知显示的时间固定为 9 秒。

通知频率

• 通知显示的次数取决于其设计模式：

  模式	通知频率
  操作成功	一次
  操作失败	一次
  非关键系统事件	当事件首次发生时显示一次。如果是由用户能够解决的问题引起的话，那么如果用户必须在一小时内解决，则每 10 分钟显示一次；如果用户必须在一天内解决，则每小时显示一次。
  可选用户任务	对于安全相关的任务来说，每小时一次。其他所有情况，每天一次，一共最多三次。
  供参考（FYI）	一次
  功能广告	当功能有关时每天一次，总共最多三次。一旦用户试用该功能后即停止显示。

• 对于可选用户任务来说，不要试图通过不断地显示通知来纠缠用户。如果对于某个特定的与安全相关的任务来说，每小时一次还不够频繁的话，从根本上来说这个任务就是必须的，应当立即显示模式对话框，不要使用通知。

通知升级

• 不要假设用户会看到你的通知。用户在下列情况下是不会看到通知的：
  • 他们正沉浸在其工作中。
  • 他们没有注意。
  • 他们不在计算机前。
  • 他们正在运行全屏应用程序。
  • 他们的系统管理员关闭了其电脑上的所有通知。
• 如果用户迟早要采取某种行动的话，应当使用逐步升级的方式以显示其他用户无法忽略的 UI。

交互

• 下列情况下应当使通知可以点击：
  • 用户应当执行某操作。单击该通知应当显示一个窗口以使用户能够执行该操作。此方式较适合于操作失败或可选用户任务设计模式。
  • 用户可能希望看到更多信息。单击通知应当显示一个窗口以使用户能够查看附加信息。
• 当用户单击时应始终显示一个窗口以用于执行操作。不要在单击后直接执行操作。
• 单击以显示更多信息应当确实显示更多的信息。不要只是重新表述通知中已有的内容。

图标

• 对于操作失败模式，应使用标准错误图标。
• 对于非关键系统事件模式，应使用标准警告图标。
• 对于其他模式，应当使用图标来显示与主题相关或有象征性的对象，比如用盾牌表示安全性、用电池表示电源。
• 如果你的能够识别出你应用程序或公司的品牌，且没有更好的选择的话，应当基于该品牌来使用图标。不过，这些图标对于功能广告模式来说很适用。
• 对于逐步升级方式来说，考虑随着情况越来越紧急而使用越来越醒目的图标。
• 不要使用标准信息图标。通知显然是信息。
• 下列情况下考虑使用大图标（32x32 像素）：
  • 用户能够比理解文字更加快速地理解图标。
  • 用大图标传达含义比用标准的 16x16 像素图标更加清晰高效。
  • 图标使用 Aero 风格。

在这个示例中，用户看一眼大图标即可快速理解该通知的性质。

通知队列

注：当通知无法立即显示时即会进入队列，比如当正在显示其他通知、用户正在运行全屏应用程序、或者用户当前并没有在使用计算机的时候。实时通知只会在队列中存在 60 秒。

• 对于操作成功及 FYI 模式，应使用实时选项以使该通知不会在队列中等待太久。这类通知仅在立即显示时才有价值。
• 当通知不再相关时应移出队列。

致开发人员：你可以通过在 uFlags 中设置 NIF_INFO 标志并将 szInfo 置为空串来实现。如果通知已经不在队列中，这么做也不会有问题。

系统集成

• 如果你的应用程序运行时并非始终在通知区域显示图标的话，在产生通知的异步任务或事件发生过程中应临时显示一个图标。

文本

标题文本

• 在标题文本中，以清晰、平实、简洁、明确的语言概括你需要传达给用户的最重要的信息。用户应当能够简单快速地理解通知信息的目的。
• 使用不带句末标点的文本片断或完整的句子。
• 使用句子大写样式。
• 使用不超过 48 个英文字符以便于本地化。标题最大长度为 63 个字符，但你必须预留 30% 的扩展空间以便将英语文本翻译成其他文字。

正文文本

• 使用正文文本来进行描述（不要重复标题中的内容），并在需要时提供关于通知的特定细节，并让用户知道可以采取怎样的行动。
• 使用带有句末标点的完整句子。
• 使用句子大写样式。
• 使用不超过 200 个英文字符以便于本地化。标题最大长度为 255 个字符，但你必须预留 30% 的扩展空间以便将英语文本翻译成其他文字。
• 正文文本中应包括基础信息，比如特定对象的名称。（例如：用户名、文件名或 URL。）用户应当不必打开另外的窗口来查找这类信息。
• 在对象名称两侧添加双引号。
  • 例外：下列情况下不要使用双引号：
    • 对象名称始终使用标题大写样式，比如用户名。
    • 对象名称出现在冒号后（例如：打印机名称: 我的打印机）。
    • 对象名称可以轻易地从上下文中推断出来。
• 如果你必须将对象名称截断至固定长度以便于本地化的话，应当使用省略号以指明截断。

在这个示例中，对象名称被截断，并使用了省略号。

• 如果可以针对该通知采取行动的话，应使用下列表述方式：
  • 如果用户能够通过单击通知执行某操作：

<基础信息的简介>

<可选的细节信息>

Click to <do something>.（单击以 <做某事>。）

在这个示例中，用户能够通过单击执行某操作。

• • 如果用户能够通过单击通知查看更多信息：

<基础信息的简介>

<可选的细节信息>

Click to see more information.（单击以查看更多信息。）

在这个示例中，用户能够通过单击查看更多信息。

• 不要在通知中说用户“必须”执行某操作。通知是用于非关键信息的，用户可以完全忽略。如果用户确实必须执行某操作，则不要使用通知。
• 如果用户应当执行某操作，应明确其重要性。
• 对于操作失败和非关键系统事件模式，用平实的语言描述问题。

错误：

在这个示例中，问题是以过分技术化而又不明确的语言进行描述的。

正确：

在这个示例中，问题是以平实的语言进行描述的。

• 以与目标用户相关的方式描述事件。如果用户确实有可能因为该通知而执行某任务或改变他们的行为的话，这个通知就是相关的。按照用户的目标来描述通知往往可以达到这一点，不要从技术问题的角度来进行描述。

文档编写

当提及通知时：

• 原样引用标题文本，包括其大小写。
• 应将该组件称为“notification（通知）”，而非“balloon（气球状提示）”或“alert（警告）”。
• 用“click（单击）”一词描述用户的交互行为。
• 应尽可能为标签文本应用粗体样式。对于英文来说，仅当需要避免歧义时才在其两侧添加引号；对于中文来说，则应总是使用引号。

示例：When the Critical updates are ready to install notification appears, click the notification to start the process.（当出现“现在可以安装关键更新了”通知时，单击通知以继续。）

当提及通知区域时：

• 将通知区域称为“notification area（通知区域）”，而非“system tray（系统托盘）”。