前回の投稿の冒頭でも述べたとおり、今回は、以前 Engineering Windows 7 ブログでも行ったように、このブログでのこれまでの対話を振り返り、いくつかのご意見やご質問をさらに深く掘り下げてみたいと思います。前回の投稿に続いてフィードバックの重要性に触れた後、リボン、Metro スタイル、および Media Center の提供について取り上げます。

リボン

ファイル コピー関連機能の再設計についての投稿では、集まっている関心の強さを実感しました。ですから、Windows エクスプローラーについて投稿したときは、よくも悪くもたいへんな "反響" があることは覚悟のうえでした。物議をかもすブログ トピックでは、たいてい似たようなパターンが見られるものです。ここでは Slashdot からの照会数 (他の投稿をはるかに超える数です) やブログ サーバーのパフォーマンス (効率向上のためサイト レイアウトの調整を行いました) ではなく、採用された設計に注目して話していきましょう。

何よりも重要なのは、これが製品の一要素にすぎないということです。ファイル名の競合ダイアログのときと同様、一つのことに光を当てすぎると、(見る側にも見せる側にも) 見落としが出てきたり、必要以上に大きく扱ってしまう傾向があります。前回の映画の例で言うなら、映画の宣伝のために選んだシーンが、思いがけずその映画に関する議論に (あるいはターゲット市場そのものに) 変化を及ぼしてしまうようなものです。好材料は、他にもお伝えしたい内容がたくさんあることです。

最初の投稿の内容は繰り返しませんが、ここで付け加えたいのは、私たちが、皆さんからご批判があると思われる点の多くを考慮しているということです。今回、リボン メカニズムを採用していますが、この選択が間違っているとお感じの方には、私たちの考えは違うとしか申し上げられません。あらかじめ予想し、実際に証明されたことですが、このブログをご覧の皆さんの中に、リボンへのご批判が根強いことは承知しています。このご批判については、Windows 7 のブログの一部トピックに関する反響と同じく、多数のご意見をいただくと予想しており、実際に多くのご意見をいただきました。

多様な対象ユーザーに向けたメカニズムの役割がどうあるべきか (初心者向けなのか上級者向けなのか?) については、さまざまな試行錯誤がありました。皮肉なことに、メニューはかつて初心者向けの機能であり (上級者が使うのはキーボードでした)、のちにそれをさらに簡単にしたのがツール バーでした。コンテキスト メニューは当初、上級者向けのショートカットでしたが、結果的にだれもが使う機能になりました。今では、メニューもツール バーも、上級者向けの機能と認識されています。もちろん私たちは、こうした異なるメカニズムを統合して、よりシンプルな操作性を実現することを目指してきました。メカニズムの数が少なければ、当然 UI の表示領域も少なくできるからです。さまざまなご意見がある中で、明らかなのは、リボン機能搭載の弊社製品のお客様満足度は高まっており、この機能の使用率は広く浸透しつつあるということです。ご満足いただけないお客様がわずかにいらっしゃることも承知しております。それは、理由こそ異なれ、リボン メカニズムを採用する以前の各バージョンでも同じでした。どうしたところで、すべてのユーザーにご満足いただくことはできないのかもしれません。

個人的に最も興味深かったフィードバックは、視覚的なオーバーヘッドに関するものです。"Metro" 機能が登場して、より軽量のグラフィカル操作が可能になったうえ、表示するコマンドの数を簡素化してユーザーが求める "ミニマリズム" に応えています。簡素化はだれもが求めています。表示される機能が少なければ、必要な領域も少なくでき、コードの記述、テスト、管理の工数も減らせます。ミニマリズムは、機能を隠すことでもなければ、便利な機能にアクセスしにくくすることでもありません。ミニマリズムとは、余分なものをそぎ落として本質的な機能だけを残すことです。そのためには、本当に必要な機能の見極めが重要になります。私たちが考えるミニマリズムは、コマンドの多層化や、見つけにくい場所への機能のグループ化をやめ (これらのメカニズム自体が概念的になり、コードのオーバーヘッドを生みます。UI が表示する内容だけでなく、UI 自体も肥大化の原因となるのです)、同時に UI に使用するメカニズムの数を減らすことでもあります。このアプローチに従い、私たちは製品の機能を 1 種類の方法で示すことを目指しています。また、ミニマリズムとは盛り込む機能の削減ではないという点も心得ています。エクスプローラーへの機能追加に関するフィードバックの量からも、それは明らかです。

従来の機能表示は段階的、階層的なものでした。キーボード限定の機能やコンテキスト メニューにしかない機能があり、またある機能はトップ レベルのツール バーから、または表示/非表示を切り替えるツール バーから、あるいはメニューやサブメニューから、という具合です。こうしたメカニズムの集合は、習得に時間を掛けないと活用しきれません。時間を掛けて習得した方であれば、変更には反対されるかもしれません。実際そのような方もおられるのでしょう。私が強く推した Office 2000 の "アダプティブ メニュー" は多くのユーザーにたいへん不人気でしたが、これは意図的に小さい領域に機能をまとめる試みでした。1 つの失敗をそのまま傾向と捉えることはできませんが、"非表示化は簡素化ではない" という貴重な教訓を学びました。

コマンドの整理方法を見直し、整理の対象とするコマンドを仕分け (ネットワーク ドライブのマップ、PowerShell)、既定の設定やグラフィックの扱いを決めていく過程で、やるべきことはまだあります。こうした検討に、今後もフィードバックを積極的に採り入れていきます。目標が快適なユーザー エクスペリエンスの実現にあるのは、皆さんと同じです。ユーザーの皆さんが、目的どおりの作業を確実に行えるようにするのも私たちの目標です。この点で、データの正しい活用が重要な役割を果たします。また、小規模なデータ セットを採用してしまったり、マイナーな事例によって決定が左右されるのを避けることができます。

"Metro" の役割をお見せしていく中で、Metro が色やフォント、またはなんらかのコントロールを集めた特定の "パレット" を表す概念と捉えられがちであることがわかりました。既に提示した数枚のスクリーン ショットは、あまり使わないと思われるいくつかのコマンド セットを省略した図を示したものでしたが、変更の主眼はパレット全体を小さくすることにありました。Zune などの一部の Metro アプリとの比較は、より "重い" 競合製品の使用率と、どのメディア プレーヤーにもない機能 (CODEC、タグなど) に対するご要望を考えると、興味深いものであることがわかりました。

これについては検討しており、同時にこのフォーラムで寄せられている、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、基幹業務用アプリの使用が中心のユーザーがこれに当たります)。Web を頻繁に閲覧するユーザーにとっては、デスクトップは目に入らないものである場合すらあります。

Windows の独自性は常に、インターフェイスに対する「オープン マーケット」のアプローチにありました。私たちは、ユーザーが Windows API がどのように使用し採用しているかを取り入れることによって、市場にユニークなエクスペリエンスをもたらしてきました。どのような文脈においても、これこそがデスクトップだと言えるような 1 種類のエクスペリエンスがあるわけではないのです。もちろん、"Aero" が均一性や一貫性を実現しなかったとの批判は、Windows 内でもこれまでにありました。

Windows 8 のデスクトップは、1 つのアプリのようなものだと以前お伝えしました。使っても使わなくてもよく、使う度合も必要に応じます。デスクトップに移動するときに違和感があるとの意見があります。私の意見は、多様性や特定のタスクや目的に特化したエクスペリエンスを許容するなら、デスクトップへの移動にはアプリ間の切り替えと同程度の違和感しかないはずだというものです。今日の Web サイト (およびモバイル アプリケーション) は、共通点のない資産やアプリの相互間の整合性を追求しておらず、ブラウザーの枠組みには、タブ (またはアプリ) を切り替えるときに生じる違和感を防ぐ機構はほとんどありません。私たちは長い間、パレットとツール バー、全画面型とウィンドウ型、MDI と SDI、組み込みコントロールとカスタム コントロールというように、さまざまな点で多様性を持つアプリを受け入れてきました。この多様性に対応するメカニズムは、デスクトップが受け継いできた資産の一部です。均一性と方針の浸透を求めるユーザーもいます。初期の Windows ツールを構築したチームのメンバーとして私が言えるのは、少なくとも努力はした、ということです。たとえ最大限に均質化されたプラットフォーム内であっても、開発者は差別化を目指し、特定の目的やエクスペリエンスに特化したユーザー エクスペリエンスを構築しようと努めるもので、これが共通性から外れる結果になります。かつて複雑さに対する答えは共通性でした。今日の私たちはあらゆるタイプのデジタル エクスペリエンスに囲まれており、簡単に受け入れています。このことは、印刷形式やビデオ フォーマットの技術が最初の世代から進歩するにつれて、私たちがそれらの幅広い形式を受け入れてきたのと同じです。

Metro スタイルからデスクトップへの移動が、現在アプリやサイトを切り替えているのと同程度に調和したエクスペリエンスになると私たちが自信を持って言えるのは、この多様性が理由です。移動をシームレスにするために、トップ レベルで統合が図られます。そのため、ユーザーはアプリ間の切り替えやアプリ間のクリック操作が行えるだけでなく、Alt+Tab キーを使用するアプリ間の移動や、デスクトップ自体などのすべてのメカニズムがそのまま動作します。アニメーションも動作します。コピーと貼り付けも可能です。"レガシー" のコントロール パネル アプレット間の移動も、問題なく動作します。

既にお伝えしたように、このトピックに関してお話しすることはまだたくさんあります。ここでは、フィードバックのいくつかを取り上げ、これまでの対話を拝見して私とチーム メンバーが考えたことの一部をご紹介しようと考えました。製品をお見せするという点でまだやるべきことは残っていると思います。早い段階で多くの情報を公開しすぎた面もあるかもしれませんが、今後も前向きに継続していきたい考えです。BUILD は数日後に迫っています。

Media Center

フィードバックの中心的トピックではないものの、Media Center に関して 50 通ほどの電子メールをいただいています。Media Center が Windows 8 に組み込まれるのは確かだと皆さんに請け合っておきたいと思います。これは間違いありません。プレリリース テスターの間で Media Center への支持がいかに強いかを踏まえれば、私たちは引き続き、プレリリースであっても、品質およびアドインとの互換性を期待されるレベルに押し上げる必要があります (どの Windows のリリースでも、互換性は開発の取り組みの中心です。たとえば基盤となるビデオ エンジンの開発の際、これらの領域が対象を十分に扱えるまでの機能であることを確認する必要があります)。

今後の何か月かで、Windows 8 のプレリリース ビルドを多くの方々がテスティングされるでしょう。ご承知のとおり、初期の段階で常に問題になるのは 2 つの事柄です。1 つ目は、ソフトウェアがまだ完成しておらず、機能の追加や削除などの変更が加えられることです。2 つ目は、開発プロセスの終盤 (出荷近く) にならないと、各種エディションや SKU が開発または発表されないことです。

Media Center は最初のプレリリース ビルドには組み込まれません。最初のプレリリース ビルドに組み込まれない機能には、Windows 7 に付属していたゲーム、DVD クリエーター、アップグレード セットアップ、.NET 3.5 などがあります (他にも比較的注目度の低い項目がいくつか加わるかもしれません)。これらはエンジニアリング上の決定であり、ビジネス上の決定でもあります。

これらに限らず製品のすべての機能について、それぞれどのように提供されるか、市場への出荷が近づいた段階で必ずご説明していきます。余談になりますが、Windows の 1 つの SKU の好みについてディスカッションするには、まだ時期尚早です。私たちはこのフィードバックを十分認識していますが、弊社のビジネス パートナーからのフィードバックとのバランスを常に取る必要があり、彼らは異なるアプローチに価値を置いています。時機が来たらその間の橋渡しをするつもりでいます。興味深いことに、私への直接のインプットに基づいて言えば、Media Center に関するフィードバックの大部分は「お金を余分に払うから組み込んでほしい」との要望です。現在 Media Center は Windows の "Premium" SKU に組み込まれており、現在も同様の状況であることを示します。

さらに、「皆使っている」との声を多く聞きます。前述のとおり、Windows 8 での Media Center の提供に私たちは全力を挙げていますが、使用状況に関する統計データを一部お伝えしたいと思います。このデータは、最初のプレリリース ビルドでこの機能を提供しないことにはまったく影響していません。私たちは今までどおり Media Center に注力しています。

オプトイン方式で行われる使用状況の遠隔測定による 7 月のデータでは、Windows Media Center は全世界で Windows 7 ユーザーの 6% が起動しており、最も使用率が高かったのはロシア、メキシコ、ブラジル (頻度と時間) でした。しかし、ほとんどのユーザーは眺めるだけで、1 セッション中 10 分を超えて (個人平均) 使用したのはユーザーの 1/4 (6% 中の 25%) のみであり、Media Center セッションの 59% (6% のユーザー中) にほぼ活動が見られませんでした (1 ~ 2 分未満の使用)。最も多く観測されたシナリオが TV だったことは驚くに値しませんが、従来からのメディア (DVD と CD) は、ストリーミングおよびファイル ベースのコンテンツよりも使用量が低い (かつ減少傾向にある) という結果でした。比較すると、Media Player (7 月の Windows ユーザーの 66%) および IE (88%) は、"Premium" とストリーミング コンテンツのボリュームの増加を含め、全タイプのメディア コンテンツで人気の高いレンダリング エンジンであると言えます。これも、Windows での活動の多様性がとても幅広いことを実感した領域の一つです。

 

以上、これまでの投稿へのコメントで挙がった主なトピックのごく一部をご紹介しました。Engineering Windows 7 ブログの場合と同様、今回も皆さんとの対話内容の調整を図り、話し合った内容を振り返る機会を設けました。私たちの取り組みに寄せられているフィードバックと熱意の中に、ネガティブな要素を見つけるのは困難です。これほど多くの皆さんの真剣な関心事となっている仕事に取り組む以上に、価値のある仕事があるでしょうか。ソフトウェアそのものを使っていただく機会がまだないにもかかわらず、私たちの投稿や開発に対して皆さんがこれほど熱心に応じてくださることをありがたく思っております。私たちは現在 BUILD に注力し、これまでの成果を十分にご披露できるように準備しています。この対話を続けることも心から楽しみにしています。BUILD では、こうした対話が直接できることに期待していますが、このブログにも引き続きご意見をお寄せください。

--Steven