ui-context-and-scope

界面上下文与范围

用户需要始终了解三件事：

1. 我在哪里？ — 在产品层级中的当前位置
2. 我处于什么上下文中？ — 当前所在的版块、记录或工作区
3. 我的操作会影响什么？ — 在提交更改前了解其影响范围

这些信息不清楚时，用户容易犯错、感到迷失，并失去对产品的信任。

通过视觉结构传达层级

分隔线与边框

水平线和边框用于标示版块之间的边界。用它们分隔属于不同上下文的内容区域，而不只是为了装饰。

• 标题与内容之间的线表示“下方内容属于此标题”
• 侧边栏边框表示“这是用途不同的另一个区域”
• 避免过度使用分隔线——布局间距和留白应发挥主要作用；只有单靠留白不足以区分时，才用分隔线加以强调

颜色区域与背景填充

背景色是传达“你现在进入了不同区域”的最有力信号之一。

• 为侧边栏、面板或上下文抽屉使用有区别的背景色调
• 为活动或选中区域添加微妙的填充，确认“这是当前上下文”
• 当用户的更改仅适用于特定版块时，应通过边框、填充或两者兼用，在视觉上框定该版块，以便用户在提交前清楚了解影响范围

版块标签与上下文标题

每个主要区域都应能回答“这是什么？”，而无需用户阅读周围的内容。

• 使用用户熟悉的词汇命名版块，而非系统内部术语
• 显示当前活动对象：“正在编辑：发票 #2041”或“工作区的设置”，而不只是“设置”
• 在会影响特定记录的表单中，应在表单标题中醒目显示记录名称

浏览层级

面包屑

当产品有三级或更多层级，或者用户可以通过多条路径到达某个页面时，请使用面包屑。

Home > Projects > Website Redesign > Tasks > #142 Fix header

• 每个面包屑项都应是可点击的链接，用于返回相应层级
• 当前页面是最后一项——仅显示文本，不设为链接
• 在移动设备上，折叠面包屑，仅显示直接上级：← Website Redesign
• 面包屑不能取代主要导航，而是与之互补

将搜索和筛选用作导航

在内容树庞大或动态变化的产品中，搜索可以降低浏览层级所需的认知成本。

• 使用全局搜索查找产品中的任意对象
• 使用上下文筛选器缩小当前范围内的搜索结果
• 搜索结果应展示足够的上下文，以区分相似项目（例如，在任务名称旁显示项目名称）

操作前传达影响范围

当更改、设置或操作会影响特定范围时，必须在用户提交前说明该范围，而不是事后才让用户发现。

• 标签：“此设置仅适用于此工作区”／“所有用户都会看到此更改”
• **视觉框定：**在用户即将编辑受影响区域时，将其突出显示或勾勒出来
• **确认文案：**对于破坏性操作或影响范围较广的操作，应在确认对话框中说明影响范围（“删除此项目及其中的全部 47 项任务？”）

隐藏的范围需要可见指示器

当某个设置决定整个应用显示哪些数据（租户、站点、环境）时，控制项可以放在设置对话框中，但当前状态不应隐藏。应在应用界面的固定区域中放置持久显示的只读指示器。控制项很少更改，并不意味着状态也可以不显示。没有这个指示器，每个屏幕在错误的数据集中看起来仍可能是正确的。

切换范围会丢弃所有基于先前范围生成的内容：搜索、暂存行和选中项。

代表他人操作

每当用户以其他用户、客户或账户的身份查看或更改数据时——无论是模拟他人、管理员“切换视图”，还是代表客户提供支持——界面都必须始终清楚无误地显示这一点，而不只是在进入该模式时提示。

• **持续且醒目的指示：**使用彩色横幅或栏，在整个会话期间始终显示（“你正在代表 Acme Corp 操作——更改会影响其账户”），不要使用会消失的提示消息。
• **明确显示当前视图的归属：**标明正在代为操作的账户或客户，并在视觉上与操作人员自己的常规上下文区分开，确保两者绝不会混淆。
• **提供明显的退出方式：**设置清晰的“返回你的账户／停止代表他人操作”控件，并始终保持可见。

要防范的风险是：操作人员误以为自己处于个人上下文，实际上却在客户的上下文中操作——这种范围混淆会造成实质损害。

身份验证是一种信任上下文

登录／注册页面是用户交出密码的地方——这是一个天然令人不安的时刻，也是用户最需要确信自己身处正确、安全之处的时候。应将其设计为建立信任的界面，而不是事后补上的功能：

• **必须让人一眼认出这是品牌页面。**通用或不符合品牌形象的登录页面会令人起疑（“这真的是他们吗，还是钓鱼页面？”）。身份验证页面应完整体现品牌形象，包括徽标、颜色、字体和语气。
• **URL 必须属于客户自己的生态系统。**在客户的域名或清晰的子域名上托管身份验证页面，例如 app.customer.com、customer.com/login，而不是随机的第三方 URL。路径应简短清晰（最多为 domain/path/path，且只包含有意义的查询参数）。用户会通过地址栏判断是否安全；不透明的重定向链看起来就像钓鱼页面。

**退出登录时不加载任何外壳。**在根路径直接渲染登录视图，背后不应有任何内容。用模糊效果遮挡外壳，或使用无法关闭的模态框，都只是掩盖；而掩盖不过是 CSS：在开发者工具中移除一个类，就会向匿名访客暴露导航、客户名称和功能开关。应在测试中断言，退出登录时不存在任何外壳元素。

**离开当前上下文的数据。**当某项功能会将人员或客户数据发送给外部模型时，应在请求发出前将所有可识别字符串替换为稳定的假名，并在客户端将响应映射回来。各行之间应保持假名一致，以保留关联关系。名称一旦离开，再好的供应商承诺也无法让它们回来。

区分内部工具与外部产品

内部／后台软件应采用有意设计的视觉“特征”——例如独特的强调色、环境徽标或醒目的页眉——让人绝不会将其误认为面向客户的应用。这可以防止操作人员把内部管理界面误认为外部产品，或把预发布环境误认为生产环境。提示应始终显示且一目了然，不要藏在设置页面中。

哪个应用、谁的数据、什么权限

当一次登录即可打开多个工具时，“我现在在哪里？”这个问题对用户有两个答案，而且两者都应显示在持久化的外壳中，而不是页面上（[[app-shell]]）。

哪个应用。 工具共用一个外壳和一个品牌后，也会开始变得相似——这是好事，但也带来了新的问题：用户可能在错误的工具中操作。应用本身的名称应始终显示在外壳中，并固定在同一位置。

谁的数据。 在多租户或多客户工具中，应始终标明当前租户，并在任何破坏性操作的确认信息中再次显示。请将其作为标签标明；不要用颜色或主题来表示，否则会破坏品牌一致性，还会导致对比度难以预测。颜色应保留给上方的环境提示，因为把生产环境误认为暂存环境会造成实际损失。

什么权限。 内部用户可以从角色信息中了解自己当前使用的权限——这能解释为什么某项操作不可用，也能让当前会话权限过高的情况对使用者一目了然。应在外壳中显示角色；对于用户角色禁止的操作，应优先显示为禁用状态并说明原因，而不是悄然隐藏（[[nielsen-usability-heuristics]]）。面向客户的产品不应以这种方式显示角色；在这种情况下，不显示才是更简洁的做法。

审核清单

• 用户能否始终识别自己当前正在编辑的分区或记录？
• 是否始终使用颜色区域或边框来区分不同的上下文？
• 导航层级超过 2 层时，是否使用面包屑导航或清晰的返回路径？
• 操作确认对话框是否说明了受影响的范围？
• 代表另一个账户操作时，是否有一个持久且醒目的提示，标明代表谁操作，并始终显示退出入口？
• 内部／后台工具是否带有持久的视觉提示，以区别于面向客户的应用（以及暂存环境与生产环境）？
• 如果范围控制项隐藏在设置中，当前范围是否仍以只读方式显示在界面外壳中？
• 用户登出时，是否只挂载登录视图，而没有在模糊背景或模态框后显示外壳？
• 识别性数据在传递给外部模型或服务之前，是否已进行假名化处理？
• 身份验证界面是否完全符合品牌风格？登录 URL 是否位于客户自己的域名／子域名下，并采用简洁易读的路径？
• 分区标题是否使用用户熟悉的词汇，并在相关情况下标明当前实体？
• 内容结构过于庞大、难以浏览时，是否提供全局搜索？
• 多个工具共用一次登录和同一种外观时，是否持久显示当前应用的名称？
• 当前租户是否以标签标明，而不是用颜色或主题表示？
• 在内部工具中，用户角色是否清晰可见？被禁止的操作是否显示为禁用状态并说明原因，而不是悄然消失？