设计 Windows 8 文件名冲突体验
非常感谢您的建议，这对于我们改进文件管理基础操作十分有帮助。我们做出的改变击中了公众的兴奋点，大家热情关注的讨论之声如潮水涌来。这是为什么 Windows 8 相关工作充满趣味的原因。尽管评论和建议涉及我们讨论的众多议题， 然而到目前为止，交锋最激烈的讨论来自文件名冲突对话框（仅一个对话框！），因此这个话题的讨论可以说相当深入和充分。通过回顾开发过程中的设计存档，向您展示我们的设计思路和实现这些思路的方式 — 我们认为这很有意义。在这个问题上，我 们还会回来继续讨论我们所做的所有变更，不过我们认为花一些精力来了解我们的设计方向也大有裨益。此博文是由研发该功能的相关人员（包括 Ben Truelove（设计人员）、Matt Duignan（UX 研发人员）、Jon Class 和 Ilana Smith（项目经理））撰写，他们同时也参与了 Windows 8 其他部分的工作。--Steven
我们上一篇关于 Windows 8 中新的复制体验的博文引发了关于新 [Choose Files]（选择文件 ）对话框（用于解决文件名冲突）的大量问题和评论。看到大家如此关注这个问题，我们觉得有必要与大家分享我们的设计迭代和引导设计方向的可用性测试。
在已实施的设计中，对于文件名冲突（或简称“冲突”）有两种控制级别。
- 主要体验是只需单击一次即可批量管理所有冲突，提供 [Replace all]（全部替换）或 [Skip all]（全部跳过）选项。我们将其称为“简单冲突解决”对话框。
- 还有一种选项，就是进入次要体验，提供更多信息和更多精细控制。这是“详细冲突解决”对话框。
Windows 7 及以前版本
解决文件名冲突是一个固有的棘手任务，因为它涉及在两个非常相似的内容之间做出明智选择。
下面是我们在 Windows 3.1 中的处理方式：
到 Windows 7 时，我们确实进行了一些改进：
在 Windows 7 中，有大量的信息可以帮助用户进行选择，同时提供了更多操作选项。对于 Windows 8，我们认为可以更进一步改进这个功能，便于用户高效地做出正确选择，更快速地完成文件传输任务。正如我们之前提到的，针对现有对话 框的反馈和请求支持的电话非常清楚明朗，在一个非常复杂的对话框中做出正确选择需要哪些信息，团队成员非常费劲才有了一些眉目。尽管我们已经做了大量的工作，但有时还是会出现不妥之处，需要花费相当多时间来处理。考虑到有数百万人使用的 是早先发布的 Windows 7 版本，并且在我们的论坛中这并非讨论热点（不是说不会出现相关问题，而是并非被广泛提起）。
针对 Windows 7 体验的改进
首先，我们力图保持应用体验的前后一致性，与此同时通过优化进行决策所必需的关键信息，来不断改进该功能。
这些设计引入了一些非常切题的思路：
- 去除不必要的标签（类似“修改日期”），明显的说明性文本令我们可以快速一览即可提供重要的详细信息。
- 元数据形容词会被重点强调。而不会要求用户比较诸如文件大小（使用类似“较大”这样的字词向用户提供正确的摘要）等值。
- 智能默认值是预先选定的，可以减少用户的工作。
快速而流畅：更好地进行冲突的批量管理
对于 Windows 8 而言，我们希望用户能更快速更高效地完成处理 — 快速而流畅，这是贯穿 Windows 8 所有设计方面的关键词（无论是触摸操作，还是鼠标/键盘操作，均是如此）。下一主要设计迭代，意在紧跟密切的复制进度体验，将排队 的冲突排放在一个单一对话框中，以提供更流畅管理冲突的能力。
引入了优化 [Replace all]（全部替换）或 [Skip all]（全部跳过）选项的想法。大多数时间里，您确切地知道您正在复制的内容以及发生冲突的原因，您可以对要采取的操作有一个简单明了的选择。
对于您需要更多信息或更精细控制的情况，我们决定会以“层”的形式披露更详细的信息。
我们先从两层开始：
然后我们来尝试三层：
在一层结束：
此设计有很多优势。它提供了很多信息。由于单击标题会选择一个列中的所有内容，它提供了管理冲突的更多实际能力。不过，在最初的体验中，这个 UI 表现出相当的复杂性。
我们将这些最佳选项合并，如下：
简单而详细的冲突解决
此设计的目标是在简化性和适合用户模式的能力之间达到一个平衡，这一点非常清楚。
不幸的是，我们在此设计方面遇到了一个真正的挑战：当您选择 [Let me pick]（我来选择）时，结果令人非常困惑，并且非常复杂，因为简单和高级的选项同时都可用。这会导致一个这样的设计，“简单冲突解决”对话框和“详细冲突解决”对话 框是独立的体验。
有了这项决定，我们的基本结构已经就位。
精调
对用户测试进行准备的过程中，我们对设计进行迭代。
- 我们清除了由单一缩略图引起的混淆。
- 我们令源和目标（及其列）更加明显。
- 我们的用户辅助团队（撰写用户在产品、帮助和 Web 中使用的文本的技术专家）帮助我们编写更流畅的文本。
有趣的是，“简单冲突解决”对话框和一些用于处理单一文件冲突的初期设计之间具有相似性。这两个设计与该对话框的最终设计之间也非常相似。
第一轮可用性调研
在我们的可用性测试中，我们的调研人员寻找了一组目标对象，他们不在 Microsoft 环境中工作，技能水平和经验也大相径庭。我们向他们展示了该软件，并让他们完成一组任务。他们描述思路时我们仔细倾听，仔细观察他们查看 UI 的方式 并评定是否成功完成任务，我们可以获取对该设计的有价值的洞见。
理解可用性测试是我们使用的一个工具，这一点至关重要。曾经使用过该工具的人会知道您本人不仅要是这个领域的专家，还要是设计测试方面的专家，因为，观察者的偏见和测试结构会很容易导致您对优化存在固有缺陷的解决方案的安全和努力 有一个错误的认识。为了在这方面辅助我们，我们的测试是由那些理解测试所受限制的客观研究者所设计，同时还确保从这些测试中得出来的结论要与测试意欲评定事项相吻合。最终，设计选项要求使用许多不同的输入（定性和定量以及经验和直观）。
我们知道，我们在第一轮的可用性测试中学习了很多东西，做了很多的更改，所以我们使用了 RITE 方法作为我们的协议。大多数可用性研究对所有用户测试同一 UI，但是有了 RITE，我们会基于我们所了解的内容在参与者之间进行持续更改。（在这个环节，我们是使用 PowerPoint 幻灯片进行测试，所以 进行更改很方便。）
我们不需要对“简单冲突解决”对话框进行很多更改，因为它测试结果良好，但是我们对“详细冲突解决”对话框测试了很多不同的内容：
我们的主要经验总结：
- 复选框是必要的。尽管我们倾向于没有复选框的更为清晰的外观，它在测试中的表现却不是很好。当随 UI 呈现时，用户不知道如何操作。在提供适当的选择线索方面，复选框非常有效。我们保留了一个大的单击目标区域，以便用户可以单击复 选框、缩略图或文本以选择一个文件。
单击目标区域以便进行文件选择
- 将形容词（如“较新”或“较大”）与元数据混合可能会导致混淆。用户将它们解释为两个不同的概念。形容词尤其容易出现问题 — 人们会认为他们是标题，或是在描述文件位置（例如，“较旧”会被理解成在描述目标中的文件，因为“较旧的文件” 就是指当前文件拷贝的前身）。
- 列需要更为明显突出。初看起来，它像 Explorer 中的“平铺”视图，而不是一个表。
更多精调
对于形容词和列问题，没有一个简单的解决方案，这就需要更为复杂的设计思路：
在如何最好地定义层级以及源/目标与冲突行的重要性方面，我们确实很纠结。我们尝试了竖线，这会造成源和目标分隔得太远。我们最终采用了水平线，与文件名组合成为标题，可以明显地显示冲突之间的差异。复选框用于区别源和目标之间的选 项，而不会干扰这些区别。
我们最初的一些想法在这时被放弃了：
- 没有默认选项。随着冲突在页面上向下滚动，默认值会造成太多的数据丢失风险。一行中没有选择会导致复制被跳过的文件，所以不会丢失数据。
- 没有形容词。我们喜欢“较新”和“较大”，但是他们会造成混淆，用户更喜欢具体的数据。
为了帮助用户进行选择，我们选择了更为细微的建议 — 较新和较大的元数据值在 UI 中为粗体。这已经被证实为特别有效，无需引入 新概念或增加混乱。
更多可用性调研
我们下一轮的可用性测试，将与最终设计非常接近，出现在测试中备选项目将很少：
无疑第三个选项是赢家。两列的视图是使用空间的最有效方式，可以将复选框移动到离问题更近一些。日期和时间需要在同一行上，因为一般来说它们是单一值。
“详细冲突解决”对话框还提供了以下功能，以便在需要更多信息进行选择时提供帮助：
- 双击缩略图会打开文件。
- 右键单击缩略图会打开标准上下文菜单。
- 蓝色的源和目标文本是可单击的，可在 Explorer 中打开这些位置。
- 在缩略图或链接上悬停将会显示一个工具提示，带有全文件路径。
继续迭代
我们已经不断进行更多研究，自初次调研后进行了一些细小的变更，但是基本的核心设计还保持不变。看到用户轻松地完成可用性测试，令人非常欣慰。解决文件名冲突是一个很棘手的问题，但用户非常高效且成功完成。
[![图 16 - 最终设计](https://msdntnarchive.z22.web.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/01/29/43/%0Ametablogapi/3566.Figure-16---Final-hero-shot_thumb_0A266392.png "图 16
请查看我们上一篇关于文件管理基础操作的博文中的视频，以查看动态的设计过程。
我们热切需要您的反馈，并愿意充分利用之以期达成最佳设计，因此对所有评论意见，我们都在认真对待。我们还热切期望您能参与到实际设计工作中来。
- Ben Truelove、Matt Duignan、Jon Class 和 Ilana Smith
（如果您没有找到上述几位，那么还有几位团队成员在上篇博文中就引发的问题发表了一些观点，他们是：Alex、Matt、Jordi、Jon）。
Comments
- Anonymous
September 01, 2011
看得出来，Win8的设计和开发人员确实花了很多心思。但其实个人还是比较喜欢那个需要看详细情况的时候在同一个对话框里展开的实现。如果按钮安排得当，不会有杂乱的感觉。 而且可以省去一次我关闭弹出窗口的操作，另外尤其不喜欢那么多层的弹出窗口盖在上面。 - Anonymous
September 01, 2011
虽然有点跑题，但真实希望win8的cmd命令行窗口能加上类似linux上的历史命令过滤的功能，希望开发人员能考虑考虑，这对经常用命令行窗口的人来说是个福音啊，虽然小众了些。稍微具体点的功能要求：现状：当你在cmd窗口中执行了很多的命令，现在的实现时你可以用上下方向键来获取上/下一条历史命令，但是如果你在已经输入前几个字符的情况下，你再用上下方向键的时候， 你的输入丢失，取而代之的是上/下一条历史命令。期望结果： 在输入若干字符之后，用上下方向键索取命令历史的时候，能通过已经输入的字符过滤历史命令，只取得以已输入字符开始，或有部分匹配的历史命令。令，如果cmd窗口如果能支持扩展就好了，类似功能估计就可以第三方开发，而且可以实现更炫或更方便的功能 - Anonymous
September 03, 2011
@rzfish建议你去英文原文那里用英文反馈.........