第一次对话回顾(第 2 部分)

正如在上篇博文的开场白中所言,我希望能暂停一下,回顾我们通过本博客展开的对话交流,进一步探讨大家提出的一些观点和问题,我们在 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 展开的争论毫无疑问是由于博文发布顺序引起的。我们不确定一开始应介绍较为抽象的概念还是较为具体的概念。由于已有…

1

第一次对话回顾(第 1 部分)

在启动本博客时,我们的出发点就是对话 – 有关构建 Windows 8 的双向对话。为了实现这一目的,我们已经开始讨论如何构建该产品,并有机会通过显然对您很重要的主题的相关评论和帖子获得反馈。就具体数字而言,我本人收到了大约 300 封电子邮件(并回复了相当一部分),我们总共从大约 1,700 名读者那里收到超过 3,000 条英语语言的评论。在 Twitter 跟随者数量方面,我们稳定在 15,000 名左右(这个数字相当于诸如此类博客的“市场”规模)。与 Engineering Windows 7 博客一样,在该过程的早期阶段,我想回头细想一下我们正在进行的对话并专注于几个主题。这是开始一个新博客的正常流程一个组成部分:在前期投入大量精力做好充分准备,让每个人都能找到共鸣点。 我们知道谈论 Windows 8 与谈论 Windows 7 将有所不同。Windows 7 是回归,而 Windows 8 要在保持根本出发点的基础上向前迈进一大步。朝新的方向迈进总是会带来工程方面的挑战,同时在谈论我们所做工作时也会遇到挑战。对于 Windows 8 尤其如此,原因有两点。 首要,我们谈论的是十亿人在使用的产品。无论您如何划分,都会形成各式各样的观点,并需要满足数量庞大的客户的需求。当然,通过一个毫无保留的产品为广泛客户群提供服务将给人们带来巨大价值。在评论中我们可以明显看出这一点。人们通过评论强调自己的观点,经常重申他们的观点,并且针锋相对。以高度负责的态度来看,我们的职责是提供适应各种客户应用场景,并以拥有单个产品的价值为基础构建的产品(对于开发人员、IT 管理员、PC 制造商、硬件供应商等)。 其次,我们要改变 Windows 8 的用户体验模型。从事过用户界面工作的人(特别是使用过界面的人)都知道,对用户界面发表意见并不困难。即使是制作事物外观的静态图像模型也不那么难。对话框和工具栏的模型和提议塞满了我的收件箱。不过之前就已经是这样了,这一流程我们已经沿用了很长时间。通过静态图像谈论用户界面就像是只通过观看一个剧照就来总结或评论一部影片一样困难。在对设计进行评估时,我们自己所做的测试按顺序使用了几十张图像。 对于如何开始撰写博客,我们反复讨论过好多次。显然,读者希望了解更多信息。同时,我们认为当我们尝试开展一些大项目时,人们应该有机会参与到该过程的分步讨论当中。电影不会一开始就让人想到结尾,它会让您慢慢认识背后的人物和动机(在优秀的电影剧本中)。由于环境和我们所做的工作在每个时刻都是独一无二的,因此对于如何处理这一点,我们总是需要学习。 从这个意义上讲,之前我们学到了非常重要的一课,即,许多人都愿意讨论用户界面,但通过静态图像快速实现用户界面时却抓不住重点。这与用显微镜过度放大局部而导致看不见整体情况很像。它还会使那些可操作性最低的反馈浮出水面,从而筛选出“喜欢它”/“讨厌它”类别。即使通过简短视频,我们也未能找到让环境为总体体验服务的正确方法。如果给予足够的关注、启示和放大,任何事情都会变得非常重要,成为热门争论的主题。对此我们当然功不可没。 在这篇帖子和后续帖子中,我想特别谈论四个主题:反馈(我将在今天谈论)、功能区、Metro 和媒体中心。我希望在此另外增加一些“关注、启示和放大”,而不会歪曲整体情况。从评论和对话中,我确实感到每个话题都值得深入讨论。人们希望更进一步讨论的另外一个主题是整体编程模型,在发布内部版本时我们将会介绍这一主题。很明显,现在讨论这一主题还为时尚早,因为我们有太多话要说,有太多内容要演示,需要多篇博文才能完成。 反馈 博客毫无疑问是一个反馈机制。它是众多反馈机制中的一个。我们致力于吸取反馈中的精华。没有其他任何一种产品由那么多人使用,同时又具有这种对话渠道,这么说毫不为过,在它发布之前肯定不存在这种情况。我们如何使用这一渠道无疑是一个值得讨论的话题。 我最近确实收到一些极其热情的邮件,告诉我不要理会“那些怪物和粉丝们”以及“您所说的将会引起共鸣”。面对同等数量的指责我们所做的工作有多糟糕的邮件,读到这一类邮件让我感到很欣慰。我们还收到大量非常具体的问题和建议。 我们能够收到这些建议,Windows 对众多用户的重要性也就不言而喻了。它告诉我们,Windows 对人们的家庭、工作和学校生活的影响有多大。产品中细微的变化都可使事情变得简单得多。巨大变化则有可能使情况得到显著改善,也可能不会。我们每天要做的工作就是判断如何对产品进行更改,使其能够更好地符合您的预期,甚至超出您的预期。 我们很愿意回复每条评论或对每个建议进行评论,但评论数量实在太惊人了,超出了我们的能力范围。而且那还只是有关本博客的讨论。我们的方法是认真聆听。我们认为,对代表某一主题或话题的评论做出响应有助于该对话的顺利进行。团队成员已成为对话的一部分。截至目前,至少有 20 位团队高级成员发表过评论。随着对话的逐步深入,这一数量还会逐渐增加。…

0

团队简介

对于如潮的评论意见和电子邮件反馈,我们深表感谢(同样感谢在 Twitter 上持续关注我们的大量读者)。大家的热情和关注让我们倍受鼓舞,倍感荣幸。最初的评论中已经涌现出一些重要话题,其中一些是基于对 Windows 8 用户体验的展望。我们正着手讨论这些问题、设计细节,并做出权衡。Windows 8 产品的各个方面都增加了大量的新功能。构建 Windows 8 需要大型团队的共同协作,因此我觉得有必要向大家介绍一下团队结构,有时,了解“怎么做”会有助于了解“是什么”和“为什么”。本文将让您获得有关我们在 Windows 8 的哪些方面添加了新功能的概况,并成为您了解本产品的指南。 有些人倾向于将 Windows 的概念想象为一个实体或一个小组,另一些人则将 Windows 想象为一系列具体的个人。有时,您会通过某些人在会议上的讲话或发布的博客形成对该产品的概念。事实上,Windows 从来都是由一个完整的团队及 Microsoft 大部分资源构建的产品。几乎每个开发小组都会以某种方式为构建 Windows 8 做出贡献。而 Windows 也同样会为大部分其他小组提供帮助。 Windows 实际上是由一系列相互关联的小规模项目组成的巨型项目。当开始构建 Windows 8 时,我们对前进的方向已经了然于胸,并根据该方向建立了相应的团队结构。我们在确保许多团队共同合作的同时,尝试将工作细分给许多完全独立的小组。显然,客户希望获得相互关联的功能,但工程师希望能够相对独立地工作。我们需要对此做出良好的权衡。 我们投入了大量精力来构建团队结构,以便顺利完成 Windows 的开发工作。首先需要确定的是我们准备“做什么”,以便确保我们有完成该工作所需的最佳团队及团队结构。同时,我们必须确保全部工程流程(如,日常构建、集成、质量、安全和所有基本功能)从一开始就相互衔接(如若展开讨论这些话题需要极大的篇幅!)。 我们的团队由以下几种工程职能或角色组成。开发人员负责 Windows 的代码编写工作。此代码实施项目管理人员编写的规格附带的功能以及产品设计人员提供的交互设计。测试人员负责确保规格的完备性以及代码实现规格所述的功能。以上就是对职能划分的简单概述,但在日常工作中,各角色的工作人员也常常需要涉足其他角色的某些工作。团队中还有一些同样重要的角色,但我们倾向于将整个发布过程中的工程工作划分为开发、测试和项目管理三个相互衔接的步骤,这些角色的工作人员拥有平等的发言权和决策权。 我们还将 Windows 团队划分为“功能团队”,即负责 Windows 中一组特定结构元素或情境的开发人员小组。Windows 8 的组织结构中总共设置了 35 个功能团队。每个功能团队由 25-40 名相互协作的开发人员,外加测试和项目管理人员构成。我们的团队共同致力于构建一款全球性产品,为此我们的部分团队位于美国以外的其他国家/地区,同时在全球范围内提供该产品。 通常,一个功能团队将负责构建 Windows 的一个特定领域或组件。“功能”是一个很宽泛的词,有些人会将其想象为“用户界面”或网络等大型结构组件,其他人可能会将其想象为“开始菜单”或 IPv6 等更为具体的功能。因此使用功能一词可能有些不太确切。我们在设置不同的功能团队时,会将结构(代码、子系统、组件)与用户接触该结构的情境(用户体验)配对,同时努力压缩团队规模并确保其可管理性。功能的定义难以确切界定,因此我们很久以前就已停止尝试统计新功能。但我们还在统计与构建的工作和规格相对应的工作项(但该列表已经相当庞大)。 当人们通过计算得出我们团队中开发者的数量时,通常会有以下两种反应之一:“天啊,这么多人,怎么可能有效地组织起来呢。”或者“天啊,你们只用了这么点人,怎么可能开发出供数十亿人使用的产品呢”。对我们来说,团队越小越容易管理,但对您来说,团队越大就越有可能开发出您所需要的各种功能。因此,我们在两者之间进行了折中。我们希望在确保团队易于管理的同时,编写出高质量、功能齐全的代码。…

1

关于本博客和您的评论

非常感谢大家的热情响应。看到大家纷纷关注本博客和 Windows 并投入了极大热情,我们感到受宠若惊。我们已虚心采纳了大家在评论中反映的所有问题和建议(许多邮件都是紧紧围绕具体主题发表评论和看法的),我逐一阅读了收件箱中接收到的海量邮件(我无法逐一回复每封邮件,但是我已经竭尽所能进行回复了)!非常感谢大家。大多数问题/评论均与“如何注册测试版”有关。我们在此承诺,一旦有任何预发行的软件程序需要大家参与测试,我们会提前发布通知并广而告之。 在本博客中讨论构建 Windows 8 的相关问题之前,我们有必要先开一个帖子澄清一下两个基本出发点,之后再展开与构建 Windows 8 和产品相关的讨论。我们希望提前介绍一下博客文章的撰写过程,并就发表评论表明我们的观点。 全部博文皆出自“货真价实”的工程师之手,不掺杂任何产品推广或宣传目的。除了一些基本的审稿工作之外,我们不会雇用影子写手撰写博文,不会安排校对人员对博文内容进行修改,也不会借助其他手段过滤您对开发团队的评价。 此举的优势在于,让您从真实的原创帖中亲身体验产品开发人员的热情。但同时也意味着本博客中的文章并非专业写手创作。一些帖子在叙述中可能会事无巨细。而且不同作者的“语气”也可能有所不同。我们希望大家不要在文字方面过于深究,请记住我们坚持的原则 — 坦率直言。我们保证,每位作者都将合理适度地发表个人评论。 对于如何处理有关 Windows 8 构建(简称“B8”)的评论,我们曾有过大量探讨。从过去的经验来看,Engineering Windows 7 博客(简称“E7”)中的评论大部分都是正面的,但也有少数人恶意滥用自己的电子邮件和评论权限。请大家紧紧围绕本社区的建设宗旨来发表评论,避免在评论中讨论不相干的主题。 毫无疑问,本博客的主要宗旨在于建立一个双向对话,而评论是促成这一宗旨不可或缺的一部分。因此,我们决定沿用上千个 MSDN 博客所使用的评论机制,即允许匿名评论,并且不会对发表评论采取任何管制措施。本博客平台采用了一些细微的安全措施和垃圾邮件过滤机制,我们对这些措施是不加控制的。 换句话说,我们始终欢迎您的评论。Windows 团队所有成员都将密切关注大家的评论,并期望与您亲切交流。在参与交流时,我们会尽力确保 Microsoft 的员工,特别是与所讨论的领域相关的 Windows 团队的成员以真实身份参与交流。我们希望评论界人士(撰写文章、发表博文、tweet 内容的专业人士)也能做到这点。 我们期待的评论: 关于 Windows 的许多相关、有价值、新奇的想法,以及关于 B8 的帖子 围绕帖子内容而不是话题表面的东西展开的评论 — 即深入挖掘 礼貌、友善、愉快的沟通 我们保留删除评论或修改评论内容的权利。如评论中包含以下内容,则将考虑予以修改或删除: 根据社区标准判定属于攻击性或侮辱性语言或行为的内容 不实表述(即以他人的名义发表的内容)— 您可以不使用真实姓名,但您个人资料中的姓名不能具有攻击性或侮辱性,也不能使用他人的名字 重复发表同样的评论或讨论主题,或者不顾博文的核心内容而试图在所有帖子中发表某一特定话题 任何类型的垃圾跟帖或链接滥用 我们希望通过这些规定建立更活跃、更具导向性的讨论。 –Steven

4

欢迎加入 Building Windows 8

构建下一版 Microsoft Windows 需要整个行业的齐心协力,Microsoft 怀着强烈的责任感和谦虚谨慎的态度寻求整个行业的帮助。作为面向新一代计算设备的颠覆性 Windows 系统,Windows 8 将成为全球 10 多亿人数亿台新旧 PC 的最理想操作系统。 我们一直埋头于设计和构建 Windows 8,今天我们迫切想与将在未来几个月内试用预发行版本的广大用户进行一场畅所欲言的对话。我们计划在 Windows 8 的整个开发周期内定期发布文章,并重点介绍产品工程方面的信息。欢迎加入“Building Windows 8”(亦称为“B8”)。 对于 Windows 团队来说,博客是 Windows 8 开发工作的一个重要部分,如 Windows 7 博客一样。通过博客,我们可以就设计选择、实际数据和使用以及 Windows 8 带来的新机遇与您进行双向沟通。总之,我们将开启一次将一款重要产品推向市场的独特旅程。能够有机会讨论 Windows 8 的开发历程,并与热情洋溢的最终用户、开发人员和信息专业人士亲切交流,我们发自内心地感到激动。 从核心技术到用户体验,全面颠覆 Windows 传统 Windows 8 是对传统 Windows 的一次重大颠覆。这是一条重大讯息,它将贯穿博客的始末。此外,我们的另外一项重要承诺是,我们百分百地保证与已售出的 4 亿多 Windows 7 许可证和所有尚未售出的 Windows 7 兼容的软件和硬件能够继续运行并受支持。 但自 Windows 的上一次重大革新(Windows…

10