87 lines
5.8 KiB
Markdown
87 lines
5.8 KiB
Markdown
---
|
||
name: win-ui-ux-design
|
||
description: 为 WinUI 3、Windows App SDK、XAML、Fluent Design，以及使用 PySide 或 PyQt 面向 Windows 的 Qt for Python 应用设计、评审和实现专业的 Windows 桌面端 UI/UX。当任务涉及 Windows 桌面应用外壳或界面、PySide6、PyQt6、PySide2、PyQt5、Qt Widgets、QML、导航与窗口化、标题栏、NavigationView 或框架等价控件选择、响应式 XAML 或 Qt 布局、主题资源、QPalette 或 QSS、Mica 或 Acrylic、键盘/鼠标/触控交互、无障碍、设计系统规范、UI 审查，或将设计转换为 WinUI 3、PySide 或 PyQt 代码时使用。
|
||
---
|
||
|
||
# Windows 桌面端 UI/UX 设计
|
||
|
||
将 Windows 视为以键盘和指针为主、可调整窗口大小、信息密度较高，同时可能接收触控和笔输入的桌面环境。优先采用用户熟悉的平台行为，而不是装饰性的新奇效果。
|
||
|
||
## 遵循核心规则
|
||
|
||
- 先优化用户任务流程，再设计单个控件的样式。
|
||
- 优先使用 WinUI 控件、系统资源和内置交互行为，再考虑创建自定义 UI。
|
||
- 将键盘、指针、触控、屏幕阅读器、缩放、主题和高对比度视为同一体验，而不是后期适配项。
|
||
- 定义每个有意义的状态：默认、悬停、按下、焦点、选中、禁用、加载、空、错误、离线或不可用、成功，以及适用时的撤销。
|
||
- 使用语义化 Token 和主题资源。不得只用颜色表达含义，也不得假设浅色模式的配色可直接用于深色模式。
|
||
- 保持适合桌面工作的界面密度。不要放大移动端模式，也不要把常用命令隐藏在仅触控手势中。
|
||
- 根据项目的 Windows App SDK 版本、目标操作系统、打包模型和依赖项，对每个 API、控件和 Toolkit 建议设置版本门槛。
|
||
- 区分 WinUI 3（`Microsoft.UI.Xaml`）与 UWP/WinUI 2（`Windows.UI.Xaml`）。未经验证不得跨框架复制 API。
|
||
|
||
## 执行工作流
|
||
|
||
### 1. 确立约束
|
||
|
||
在提出实现细节前检查项目。确定：
|
||
|
||
- 框架及其准确的软件包版本；
|
||
- 最低 Windows 版本，以及已打包或未打包的部署方式；
|
||
- 主要任务、目标用户、本地化、数据密度和无障碍需求；
|
||
- 预期窗口尺寸、多窗口行为，以及调整大小和贴靠场景；
|
||
- 主要输入方式，以及是否需要针对触控优化；
|
||
- 品牌约束、浅色/深色行为和现有设计 Token。
|
||
|
||
如果信息缺失，明确说明保守假设，并让版本敏感的建议保持条件化。
|
||
|
||
### 2. 建模体验
|
||
|
||
定义主要用户任务、信息层级、窗口图、导航模型和命令界面。保持顶级导航浅而清晰。确定哪些工作应放在主窗口、辅助窗口、内联界面、浮出控件或模态对话框中。
|
||
|
||
先描述顺利路径和恢复路径，再制作原型或 XAML。在导航、调整大小、刷新和错误发生时保留用户上下文。
|
||
|
||
### 3. 定义视觉系统
|
||
|
||
为字体、间距、几何、颜色、层级、材质、图标和动效建立精简的语义系统。除非品牌需要有意偏离，否则使用 Windows 默认规范。阅读 [windows-foundations.md](references/windows-foundations.md)，了解当前 Fluent 原则、响应式断点、主题、材质和动效指南。
|
||
|
||
### 4. 将意图映射到控件和模式
|
||
|
||
根据交互语义选择控件，而不是根据外观或任意的项目数量阈值。跨菜单、工具栏、上下文菜单和快捷键复用命令。选择导航、集合、表单、设置、反馈或数据表格模式前，阅读 [controls-and-patterns.md](references/controls-and-patterns.md)。
|
||
|
||
### 5. 规定交互与无障碍
|
||
|
||
记录焦点顺序、方向键行为、访问键、快捷键、指针提示、上下文菜单、触控目标、拖拽替代方式、无障碍名称、状态播报、对比度和缩放。阅读 [input-accessibility.md](references/input-accessibility.md)，了解必需的交互与无障碍基线。
|
||
|
||
### 6. 工程实现与验证
|
||
|
||
请求实现时，遵循现有架构，并集中管理 Token、命令和状态。保留虚拟化，避免在 UI 线程上执行同步工作。阅读 [engineering-validation.md](references/engineering-validation.md)，了解版本门槛、实现实践、性能检查和测试矩阵。
|
||
|
||
在真实的紧凑、中等和宽窗口宽度下验证结果，而不是只在全屏显示器分辨率下验证。
|
||
|
||
## 产出可用于决策的结果
|
||
|
||
对于新设计，提供：
|
||
|
||
1. 假设和目标场景；
|
||
2. 信息架构与窗口/导航模型；
|
||
3. 带响应式行为说明的标注布局；
|
||
4. 控件和命令映射；
|
||
5. 语义化视觉 Token；
|
||
6. 交互与状态矩阵；
|
||
7. 无障碍要求；
|
||
8. 实现说明和验收检查。
|
||
|
||
对于评审，先按严重程度列出发现。每项发现都要指出受影响的界面或控件、用户影响、违反的 Windows 约定和具体修正方案。将正确性与无障碍缺陷同主观的视觉润色建议分开。
|
||
|
||
对于实现，只修改请求范围，复用项目现有模式，构建或运行相关检查，并报告任何仍未验证的 API 或版本假设。
|
||
|
||
## 拒绝常见失败模式
|
||
|
||
- 不要把过时的 UWP 或已归档 Toolkit API 当作当前 WinUI 3 指南。
|
||
- 不要推荐使用 `ComboBox` 进行多选；它不支持多选。
|
||
- 不要假设当前 WinUI 3 项目中存在已归档的 Windows Community Toolkit `DataGrid`。
|
||
- 不要把 Emoji 用作结构性界面图标；使用平台字形或一致的矢量图标集。
|
||
- 不要强制在所有表面使用 Acrylic。用材质表达层级，并提供可读的纯色回退方案。
|
||
- 当标准控件已经公开准确的无障碍名称时，不要强制设置 `AutomationProperties.Name`；仅在缺少语义时显式添加名称。
|
||
- 不要默认确认每次删除。对频繁且可恢复的操作优先提供撤销；仅对代价高或不可逆的后果使用模态确认。
|
||
- 不要把单一窗口尺寸、主题、DPI、区域设置或输入方式硬编码为设计基线。
|