正如在上篇博文的开场白中所言,我希望能暂停一下,回顾我们通过本博客展开的对话交流,进一步探讨大家提出的一些观点和问题,我们在 Engineering Windows 7 博客中也采取过这种做法。我们将延续上一篇博文的话题,探讨反馈的重要性,然后分析围绕功能区、Metro 风格和媒体中心可用性展开的讨论。

功能区

刚开始我们就预计,复制文件功能的重新设计,会引发相当多的关注与意见参与。因此我们发布了关于 Windows 资源管理器的博文。我们甚至有这样的想法:讨论过程将会是“火星四溅”。对于曾参与过富有争议的博客主题讨论的读者,这一定不陌生。我们暂且不必纠结于 Slashdot 的引荐数量(远远多于其他博文)或博客服务器性能(我们为提高效率而调整了网站布局),而是直接进入主题 - 谈谈设计方案的选择吧。

首先,该机制是产品的组成元素之一。与复制冲突对话框一样,当您静下心来仔细思考的时候就会发现,双方往往都会遗漏一些重要的问题,同时过分强调一些相对次要的问题。让我们还拿电影来打个比方,有时候用来宣传的片花可能会在无意中将话题带离电影本身(甚至目标受众)。好消息是我们获得了很多可供讨论的话题。

我们不再重复第一篇博文中的内容,但我想强调一点,我们确实将许多我们必然会面临的批评纳入了考虑。我们选择了功能区机制,而对于那些不看好该机制的用户,我不得不表示无法同意您的观点。我们确定并已证实,本博客的读者对于功能区的反感最为强烈。根据来自 Windows 7 博客中某些主题的经验,我们认为那些不喜欢此功能的人会发表高调的评论。这一假设已经获得了证实。

围绕该机制的用户定位曾有过许多争论,探讨该机制究竟适合高级用户还是初学者。曾有人讽刺菜单只适合于初学者(高级用户应使用键盘),所以利用了工具栏对菜单进行了简化。上下文菜单最初是为高级用户设计的快捷方式,但最终获得了广泛的使用。现在,我们听说(并注意到)菜单和工具栏正受到越来越多高级用户的追捧。当然,我们曾尝试整合这些相互独立的机制,以便提供更简单的体验,根据定义,机制的数量越少 UI 表面区域就越小。虽然有许多选项可供选择,但据我们了解,用户对于使用工作区的产品的满意度远高于其他产品,并且该机制的普及程度和接受程度也相对较高。我们也了解到少数人仍然不是非常满意。在引入功能区机制之前的版本中,虽然原因显然有所不同,但同样存在这个问题。可能无论我们怎么做也无法令所有人皆大欢喜。

对我来说,最有趣的是关于视觉开销的反馈。随着“Metro”的出现,我们开始着手研究如何使用较轻量化的图形处理并减少暴露在外的功能,因为人们希望界面尽可能简约。很显然,我们都喜欢简洁,暴露在外的功能越少表面区域就越小,这意味着我们需要编写、测试和维护的代码就越少。简约不是将功能隐藏起来或让有用的功能变得难以访问。简约是将冗余事项剥离只剩下基本功能。剩下的问题就是如何确实地定义这组功能。我们实施简约原则的做法是避免命令的层叠或功能的隐藏“暗袋”(这些机制本身也会成为概念和代码开销,膨胀不仅来自暴露在外的 UI,也来自 UI 本身),并减少 UI 中的机制数量。通过采取这些措施,我们希望能以一致的方式呈现产品的功能。我们也明白简约并不意味着偷工减料,尤其是读者在反馈中提到希望资源浏览器中增加的功能。

渐进式和层次式呈现的功能是我们曾经采用的方式 — 某些仅可以在键盘上实现、某些仅通过上下文菜单实现、某些通过顶级工具栏实现、某些通过您必须显示/隐藏的工具栏实现、某些通过菜单或子菜单实现等等。除非投入大量时间来适应这些机制,否则任何人都无法很好地掌握它们。当然,如果您已经投入了大量时间来适应这些机制,则很有可能会公然反对机制的变革。这可能也是产生不满的原因之一。我曾经是 Office 2000“自适应菜单”的强力拥护者,结果证明该功能简直令人崩溃,但这些是对降低复杂性和减少表面区域的审慎尝试。俗话说:失败是成功之母,通过这次教训我深刻意识到“隐藏不等于简化”。

我们还在继续优化组织命令的方式和需要组织的命令内容(映射网络驱动器、PowerShell),以及默认设置和图形处理。我们正在积极地考虑有关这些方面的反馈。打造简洁的用户体验是我们共同的目标。我们还希望确保为人们提供得心应手的工具。正确使用数据对实现这一目标而言至关重要,这同时也能帮助我们避免小样本数据或特例干扰我们的选择。

随着“Metro”的出现,对于某些人来说,Metro 就意味着使用特定颜色和字体的“调色板”,可能还包含一些控件的概念。几张已发布的屏幕截图显示,一些命令集(较为不受青睐)已被去除,但主要的变化是调色板的整体缩减。我们发现相对于某些 Metro 应用程序(如 Zune),竞争产品的使用频率更高,并且任何一种媒体播放器都不需要这些功能(解码器、标签等)。

我们一直都在密切留意此类情况,并尝试整合本论坛中有关 Windows 7 整体风格过于暗淡或“苍白”的反馈。事实上,我们已根据通过本博客收到的反馈,向 Windows 7 的原有设计中添加了亮度和像素。我们会继续关注此领域,但是希望避免对整体风格做出“颠覆性调整”,因为许多第三方制造商都倾向于在不通过内置指标或系统设置来获取调色板的情况下模拟 Windows 体验(因此,改变后的风格会显得格格不入)。这一情况引发了对 Metro 风格的讨论。

Metro 风格

围绕 Metro 展开的争论毫无疑问是由于博文发布顺序引起的。我们不确定一开始应介绍较为抽象的概念还是较为具体的概念。由于已有 600 万人观看过有关 Windows 8 用户体验的视频演示(这是一段相当深入的演示),我们认为读者已对用户体验有了大致了解。现在看来,这个假设可能不大符合实际情况。我们还了解到,即使已经掌握了大量背景信息,在实际接触软件之前,人们还是很难对其获得一个完整的认识。在实际使用产品前,人们往往会对其产生过好或过坏的印象。对于本例来说,我很确定不满的人占了大多数。

在许多评论中,人们将关注重点放在了 Metro 上,而我想要阐述的是用户界面的图形元素,即 Metro 与 Aero 的比较。我们看到了对这两者的明确界定,人们认为 Aero 已经过时,而 Metro 则方兴未艾。因此,人们强烈希望现有 Windows 体验能够改头换面或按照 Metro 风格进行重新设计。这些评论大多将重点放在风格或外观的“老”或“新”上。通常,视觉风格的这些细节会在工程流程的后期确定,但我们错误地认为这一点是众所周知的。如果事先声明这一点,关于此问题的争论将大大减少。

许多相关讨论的结果最终要取决于 Metro 给人们带来的观感。如之前一篇博文所述,在查看 Windows 8 的 Metro 风格时,我们所看到的远超过颜色更为单一的视觉效果和更少的控件(更少的命令)。我们看到的是一个全新的平台,对 Windows 的颠覆性改造。对于 Windows 8,Metro 风格意味着一种新的应用程序类型,这种应用程序会自动适应当前(最流行的)平台,并针对其进行优化。这是我们将在 BUILD 上探讨的一个重要话题。您可以观看视频 #1,以便了解 Metro 风格应用程序的工作方式。在 BUILD 上,我们将讨论这些应用程序的特性,以及开发这些应用程序所需的工具和语言。我们在此谈论的是一个功能强大的平台,它可以为各种类型的应用程序提供全面支持,包括媒体、社交、游戏和办公应用程序。我们认为该平台还有巨大的潜力尚待发掘。

本话题的另一个关注点是桌面。桌面的概念因人而异。对于某些人来说,桌面是存储重要文档的位置(最重要的文件夹)。对于某些人来说,它是用来管理文件的资源管理器窗口(应用程序)。对于一些人来说,它是一种隐喻,甚至是 Windows 本身(工具栏/工作区、菜单、MDI/SDI 等)。对于某些人来说,桌面就是一个“始终运行”的应用程序,他们的 Windows 体验仅限于打开文件或开始菜单项(例如,某些人大部分时间都在使用 Outlook、Word、Photoshop、AutoCAD 或其他业务应用程序)。对于主要进行网络浏览的用户,桌面的概念甚至可有可无。

接口的“开放市场”方法始终是 Windows 的独特要素。我们沿用了人们使用和适应 Windows API 的方式,以便为市场带来独特的体验。在任何环境中,都无法确定唯一的“桌面”体验。当然,过去曾有人批评“Aero”无法实现统一性或一致性,即使在 Windows 中也是如此。

Windows 8 中的桌面类似应用程序,您可以选择是否使用它,或在多大程度上使用它。有些人认为访问桌面感觉“很突兀”。在我看来,如果您接受了针对特定任务或目的的多样性或体验,这就不会比在任何其他应用程序之间切换更突兀。当今的网站(和移动应用程序)不再追求跨不同载体或应用程序的一致性,浏览器的外壳也很少采取措施来防止在选项卡(或应用程序)之间切换时产生的突兀效果。我们的平台可以兼容具有调色板或工具栏、全屏/窗口/MDI、内置控件或自定义控件的应用程序。实现这种多样性的机制是对桌面的部分继承。一些人希望获得更高的统一性或更严格的监管。我曾参与构建早期 Windows 工具,因此知道我们曾在这方面进行过尝试。即使在同一性最好的平台上,开发者们也会力求差异并针对特定目的构建用户体验,而体验也会从通用性中分离出来。通用性是从前用来应对复杂性的一种方案,但现如今,我们身边充斥着各种不同类型的数字体验,而我们也对此习以为常(就好像随着技术的进步,人们逐渐适应各种印刷格式和视频格式)。如今我们需要解决的问题是这些设计是否可以在所针对的环境中发挥作用。

这种多样性使我们有理由相信,从 Metro 风格访问桌面将非常平顺 — 就像如今在应用程序或网站间切换一样平顺。我们会在顶级进行编排,以确保实现无缝转移,因此您将看到很多原有的机制仍将有效,例如:在应用程序间切换、应用程序快照、甚至使用 ALT+TAB 在应用程序间切换和桌面本身。动画效果将仍然有效。复制/粘贴将仍然有效。甚至在“合法”控制面板应用程序间的桥接也将有效。

如我所说,还有很多关于本主题的内容可供讨论。我希望谈及某些反馈的具体内容,并向您介绍在阅读这些反馈时,发生在我和团队中其他成员身上的一些情况。我认为我们需要在产品演示方面做出更多努力,并且可能错误地过早披露了某些信息,但我们已经吸取了这些教训并正在不断改进自己的工作。BUILD 还有几天就要召开了。

媒体中心

尽管媒体中心并非反馈的主要主题,但我仍收到了大约 50 封关于该主题的邮件。我再次向用户保证,媒体中心一定会成为 Windows 8 的一个组成部分,这一点毫无疑问。我们知道预发行版本的测试者对于媒体中心的强烈支持,但我们仍需继续努力以便确保插件的质量和兼容性,这对于预发行版本同样至关重要(对于任何 Windows 版本,兼容性都是一项重要的工作,例如我们在设计基础视频引擎时,必须充分覆盖推动这些领域的功能)。

在接下来的几个月,许多人都将参与 Windows 8 预发行版本的测试。众所周知,早期的版本始终存在以下两个问题。首先,该软件尚未完成,很多方面都可能发生变化,例如会添加新功能或移除现有功能。其次,不同的版本或 SKU 要直到开发流程的后期(临近面市时)才会推出或发布。

首个预发行版本将不包含媒体中心。其他未在首个预发行版本中包含的功能包括:Windows 7 游戏、DVD Creator、升级设置、Dot Net 3.5(可能还包括其他一些相对不太重要的项目)。做出这一决策既出于工程原因也出于商业原因。

随着面市的临近,不仅限于这些特定的功能,我们保证会解释如何向您提供产品的全部功能。此外,就 Windows 某个 SKU 的偏好展开对话为时尚早。我们会持续关注此类反馈,并会认真考虑来自看重其他方案的业务合作伙伴的反馈,并依此做出权衡。这是一件水到渠成的事,您不必操之过急。有趣的是,根据直接发送给我的反馈,大家的主流意见是“我们愿意支付额外的费用,请把媒体中心包含进来”。如今,媒体中心已成为 Windows “增值”SKU 的一部分,也就是说事实已是如此。

此外,很多人表示“我认识的所有人都在使用它”。如我所说,我们一直致力于在 Windows 8 中提供媒体中心,但我希望分享一些使用数据。这些数据不会影响我们不在首个预发行版本中包含该功能的决定,并且我们对于媒体中心的态度始终不会动摇。

我们选择加入的使用情况遥测显示,在 7 月中,全球有 6% 的 Windows 7 用户启动过 Windows 媒体中心,启动频率和时间最高的国家/地区分别为俄罗斯、墨西哥和巴西。但是,大部分人只是打开看看:这些人中只有四分之一(6% 中的 25%)每次会话的使用时间超过 10 分钟(个人平均值),在 59% 的媒体中心会话中(由这些 6% 的用户发起)我们几乎未观察到任何活动(使用时间少于一或两分钟)。电视是我们观察到的最常见的应用场景,此外,传统媒体(DVD 和 CD)的访问率要低于(并且还在不断降低)流媒体和基于文件的内容,这也在情理之中。通过比较,媒体播放器(7 月份 66% 的 Windows 用户曾启动)和 IE (88%) 是最热门的媒体内容呈现引擎,在这些媒体内容中,“增值”内容和流媒体内容的比例有所增加。这些数据再次提醒了我们 Windows 活动中存在的巨大多样性。

 

以上是我们的首篇博文提及的几个重要主题。与 Engineering Windows 7 一样,我们会进行阶段性回顾,适时修正我们的对话内容并对反馈信息进行深入分析。对于我们来说所有反馈都非常宝贵,我们的工作热情也丝毫不会减退,从事这份备受瞩目的工作,让我们感到受宠若惊。感谢您对我们的博客及产品的密切关注,甚至在您尚未获得使用该软件的机会前就已投入如此大的热情,这让我们倍受鼓舞。我们正致力于为 BUILD 做好准备,并力图确保完美地向您展示我们的工作成果,当然,能够继续与您展开对话将是我们最大的荣幸。我非常期待在 BUILD 上与您进行当面交谈,也欢迎您继续通过本博客与我展开对话。

--Steven